Cached credentials have been a thing for a long time, and that’s saved my bacon more than once.
The trouble here is that RDP will check the cached credentials first, even if the machine is online and able to check the authoritative creds. And then it doesn’t erase the obsolete cached creds. This is apparently only for Microsoft or Azure accounts, but ffs they’ve been pushing individuals and businesses that way for so long.
This most definitely is a security issue.
This most definitely is a security issue
Meaning that Microsoft won’t fix it
Ransomware Delivery Protocol at it again.
Sounds like this is nothing more than the native credential token caching NT always had. So even if you lost domain connectivity for months, anyone who had previously logged into that machine could still log in (of course, because it hasn’t connected to the domain directory for credential updates).
Not sure why it’s seen as an RDP specific thing, I don’t see anything in the article clarifying this only affects RDP. It should affect the entire machine/any local logins (not local credentials, any logins that happened on the machine, so the domain credential token was cached).
Some clarification around how credentials are updated from Azure/MS would be helpful, and clarify if this is any more than the original NT token caching.
Thank you. It’s annoying that there isn’t a separate set of settings for RDP connections specifically, but as far as I can tell this is the standard caching feature controlled/mitigated by the same means as it always has been.
Microsoft said the behavior is a “a design decision to ensure that at least one user account always has the ability to log in no matter how long a system has been offline.” As such, Microsoft said the behavior doesn’t meet the definition of a security vulnerability, and company engineers have no plans to change it.
Install Linux already, just get it over with
