Even after users change their account password, however, it remains valid for RDP logins indefinitely. In some cases, [independent security researcher Daniel] Wade reported, multiple older passwords will work while newer ones won’t.
I’m not exactly calling bullshit, but I’ve worked almost the entire last decade in IT in a Windows environment that has a decent amount of RDP use and has grown from ~2000-4000 employees during that time.
We’ve never encountered this as described. Whatever this situation that allows the cached password to persist indefinitely is, it is a situation that would need to be engineered by the attacker.
From what I can tell, this “exploit” is just the standard NT password caching functionality that Windows has had for literal decades. Windows caches the last valid password used to log in, so if you lose your connection to your identity provider (AD or Entra) you can still log in with the last password confirmed to be valid.
In AD environments, this is what allows you to log into your laptop at home before you connect to VPN. You can’t hit your work AD before you’re on the work network. It also causes some fun because if you changed your password at work but didn’t lock and unlock your computer with the new one, it might still have your old one cached for the login screen but need the new one for VPN. This was a fairly common support call (I’m out of direct user support now so I can’t easily see if it still is).
Any situation where an old password would be valid indefinitely and a new one not recognized would require the machine to not be able to reach AD or Entra, but also to still be reachable by RDP… indefinitely. That’s definitely not impossible, but it’s one hell of an edge case to use the term “indefinitely” for.
It’s annoying that there aren’t separate settings from “local logins with AD as the IDP” and “remote logins with RDP” or “logins with Entra”, but this feature is pretty damn critical for remote workers to be able to function and it is an intentional design choice as Microsoft states. Any potential workaround for a theoretical lack of this functionality is worse than the current state. Can’t rotate passwords on a local break glass account if the machine can’t reach your IDP, leaving effectively the same hole except with an account known to have elevated access.
There’s no nefariousness here or lack of due dilligence. Labeling it as some horribly dangerous security hole with the amount of vagueness this article has is just misleading and clickbaity.
Any situation where an old password would be valid indefinitely and a new one not recognized would require the machine to not be able to reach AD or Entra, but also to still be reachable by RDP… indefinitely. That’s definitely not impossible, but it’s one hell of an edge case to use the term “indefinitely” for.
Would something like this happen if AD and Entra is in a remote office, the machine has a networking issue that prevents non local connections?
Yep. If the network is local only and can’t reach Azure (for Entra) or the Domain Controller (for AD) that we’re saying is at another physical location, then there’s no way for the machine to see the new password. It will continue to accept the old cached password until that network issue is resolved.
But that’s always been the case. It’s how Windows NT and forward work. In that scenario, you could only reach the machine over RDP if you were on another machine on that isolated network.
Yeah, but “some cases” is extremely vague. If it is indeed cached indefinitely under all circumstances I would expect changed passwords to never work at all.
If it is just “some cases” it could be anything from the system using a stale cache just when it can not reach the online server (reasonable) over caches still being in some kind of TTL period to some sort of bug.
In typical MS fashion this might be very hard to debug with the hundreds of interacting components./s
In all seriousness they reviewed their internal docs not even the code (likely because it’s extremely complex) and said fixing this would brake existing functionality. I think “some cases” is doing heavy lifting for “we know many cases, but won’t tell the bad guys out there”.
“We originally looked at a code change for this issue, but after further review of design documentation, changes to code could break compatibility with functionality used by many applications.”
Year of the Linux (Server|Desktop). Seriously. If you are in IT pls look into this (and hide your RDP server behind some VPN. No not MS RDP Gateway.)
Anyone who isn’t doing this already is dumb. Same goes for exposing ssh publicly. I don’t care that you’re using a cert to log in, if there’s a 0 day in the openssh server you’re boned
If there’s a 0 day in the VPN software then I’m also probably boned. The chances of that seem on par with the likelihood of an openssh vulnerability? I feel like vpns are useful to secure services without good authentication, but their use in front of an openssh server has never made much sense to me.
That is addressed in the article
I’m not exactly calling bullshit, but I’ve worked almost the entire last decade in IT in a Windows environment that has a decent amount of RDP use and has grown from ~2000-4000 employees during that time.
We’ve never encountered this as described. Whatever this situation that allows the cached password to persist indefinitely is, it is a situation that would need to be engineered by the attacker.
From what I can tell, this “exploit” is just the standard NT password caching functionality that Windows has had for literal decades. Windows caches the last valid password used to log in, so if you lose your connection to your identity provider (AD or Entra) you can still log in with the last password confirmed to be valid.
In AD environments, this is what allows you to log into your laptop at home before you connect to VPN. You can’t hit your work AD before you’re on the work network. It also causes some fun because if you changed your password at work but didn’t lock and unlock your computer with the new one, it might still have your old one cached for the login screen but need the new one for VPN. This was a fairly common support call (I’m out of direct user support now so I can’t easily see if it still is).
Any situation where an old password would be valid indefinitely and a new one not recognized would require the machine to not be able to reach AD or Entra, but also to still be reachable by RDP… indefinitely. That’s definitely not impossible, but it’s one hell of an edge case to use the term “indefinitely” for.
It’s annoying that there aren’t separate settings from “local logins with AD as the IDP” and “remote logins with RDP” or “logins with Entra”, but this feature is pretty damn critical for remote workers to be able to function and it is an intentional design choice as Microsoft states. Any potential workaround for a theoretical lack of this functionality is worse than the current state. Can’t rotate passwords on a local break glass account if the machine can’t reach your IDP, leaving effectively the same hole except with an account known to have elevated access.
There’s no nefariousness here or lack of due dilligence. Labeling it as some horribly dangerous security hole with the amount of vagueness this article has is just misleading and clickbaity.
Would something like this happen if AD and Entra is in a remote office, the machine has a networking issue that prevents non local connections?
Yep. If the network is local only and can’t reach Azure (for Entra) or the Domain Controller (for AD) that we’re saying is at another physical location, then there’s no way for the machine to see the new password. It will continue to accept the old cached password until that network issue is resolved.
But that’s always been the case. It’s how Windows NT and forward work. In that scenario, you could only reach the machine over RDP if you were on another machine on that isolated network.
Yeah, but “some cases” is extremely vague. If it is indeed cached indefinitely under all circumstances I would expect changed passwords to never work at all.
If it is just “some cases” it could be anything from the system using a stale cache just when it can not reach the online server (reasonable) over caches still being in some kind of TTL period to some sort of bug.
In typical MS fashion this might be very hard to debug with the hundreds of interacting components./s
In all seriousness they reviewed their internal docs not even the code (likely because it’s extremely complex) and said fixing this would brake existing functionality. I think “some cases” is doing heavy lifting for “we know many cases, but won’t tell the bad guys out there”.
Year of the Linux (Server|Desktop). Seriously. If you are in IT pls look into this (and hide your RDP server behind some VPN. No not MS RDP Gateway.)
Anyone who isn’t doing this already is dumb. Same goes for exposing ssh publicly. I don’t care that you’re using a cert to log in, if there’s a 0 day in the openssh server you’re boned
If there’s a 0 day in the VPN software then I’m also probably boned. The chances of that seem on par with the likelihood of an openssh vulnerability? I feel like vpns are useful to secure services without good authentication, but their use in front of an openssh server has never made much sense to me.
They would have to breach the vpn and then also breach the other services once they’re on your network. It’s another layer of protection.