Black Hat Crafty infosec researchers have figured out how to remotely set answers to Windows 10’s password reset questions “without even executing code on the targeted machine”.
Thanks to some alarmingly straightforward registry tweaks allied with a simple Python script, Illusive Networks’ Magal Baz and Tom Sela were not only able to remotely define their own choice of password reset answers, they were also able to revert local users’ password changes.
Part of the problem is that Windows 10’s password reset questions are in effect hard-coded; you cannot define your own questions, limiting users to picking one of Microsoft’s six. Thus questions such as “what was your first’s pet name” are now defending your box against intruders.
The catch is that to do this, one first needs suitable account privileges. This isn’t an attack vector per se but it is something that an attacker who has already gained access to your network could use to give themselves near-invisible persistence on local machines, defying attempts to shut them out.
The Windows registry, said Baz and Sela, stores items such as the local machine and service users’ passwords within the well-known LSA Secrets entry, which is so secret and secure that even Microsoft Technet bloggers offer step-by-step Powershell guides to examining their contents, which are encrypted. Inevitably, there is a way round that.
Baz told his Black Hat presentation’s audience: “The important thing to understand about how it’s encrypted is that in order to assemble the AES key with which the LSA secrets are encrypted, you need to collect artefacts from the registry on that machine. So if you have full access to the registry on the machine, it’s really not that difficult to get the key with which you can rewrite LSA Secrets.”
Working on the “lucky” assumption that the elevated-privs account they were using for their proof-of-concept test was able to edit local access control lists, the two gave themselves read/write permissions, with Baz adding: “If you want to locate the secret you find the registry key through the format L, for local; SQSA, which stands for security question and security answer; and the GUID of the user to whom the questions belong.” The actual Q&A data was stored as JSON.
Opening a remote desktop session to the target machine gives you the standard Windows logon screen. “Nowadays… if you look at it closely you won’t see a reset password button,” said Baz, who went on to demonstrate a method of bypassing this security protection by forcing the remote desktop session to “fall back to non-network level authentication”.
“Luckily,” said Baz, “as an RDP client you can say you do not support NLA. Thus you can ask the server to give you back the old Windows logon screen with the password reset option”. He and Sela simply created an RDP file with the appropriate flag set.
Once they had obtained access to the standard password reset screen, the two then looked into persistence. It is no good having local access if a suspicious user simply changes his password. But what if you can revert that password back to your known one? “It’s pretty simple, luckily,” said Baz.
“In order to prevent people from reusing their passwords, Windows stores hashes of the old passwords. They’re stored under AES in the registry. If you have access to the registry, it’s not that hard to read them. You can use an undocumented API and reinstate the hash that was active just before you changed it. Effectively I’m doing a password change and nobody is going to notice that,” he continued, explaining that he'd used existing features in the post-exploitation tool Mimikatz to achieve that.
As for protecting against this post-attack persistence problem? “Add additional auditing and GPO settings,” said Sela. The two also suggested that Microsoft allows custom security questions as well as the ability to disable the feature altogether in Windows 10 Enterprise. The presentation slides are available here (PDF). ®