2

I work as a security researcher, tonight I implemented Windows Hello For Business in our environment, because it is marketed as the "passwordless way of the future" and I wanted to see if it holds up to its promises.

The decision was made to go on-premise with certificate-based authentication (AD2016+ADFS+WindowsCA), and then to test it out from a lateral movement perspective. I registered my laptop and enrolled WH4B with facial recognition and backup pin. Albeit the installation itself was a real PITA (10+ hours to get it running) it now works fine and I can see how face unlock is a nice convenience factor compared to typing in a password.

But security wise? run mimikatz... sekurlsa::logonpasswords... and I still get all the NTLM hashes, kerberos tickets and plaintext passwords. Lateral movement: same as before. nothing has changed.

Did I implement WH4B wrong or is this just the way it is? I followed this Microsoft guide.

  • Is it meant to be a control against lateral movement? – schroeder Oct 25 '19 at 20:12
  • probably not, i am asking this just for clarification if NTLM hash and kerberos ticket are the same as before, and therefore the attack vectors are the same as before. not bashing WH4B, it is nicely designed and very convenient to use. – Robert R Oct 28 '19 at 15:40
2

Disclosure: I work on the team that builds WHfB.

Windows Hello for Business is only one vertical for reducing credential theft and lateral movement. There's no one-size-fits-all solution for this problem because the space is so huge.

Windows Hello is intended to prevent the theft of long term secrets so that attackers are forced to move higher up the stack to short term or ephemeral secrets. That on it's own makes it more detectable, limits attackers to shorter windows of attack, and prevents movement between machines and services. This is done by creating per-device keys for a user, and using the biometrics or PIN to unlock those keys. The keys themselves are device-bound through encryption by the TPM. Those keys are then used as client credentials for Kerberos through PKInit.

That does not mean you can't steal derived secrets like Kerberos tickets or NTLM hashes. There are other features that make that more difficult, like Credential Guard or LSA Isolation.

| improve this answer | |
  • thanks, this confirms my expectations. if i can steal the hash, i can steal the hash, and lateral movement is not reduced IMHO, so i currently see this as a convenience feat. what i am missing in this puzzle is the official recommendation how to handle the user account password - i did not find anything in the docs. shall it be set to a random long string? shall it obey regular password changing policies? handled as usual,etc. if i get this right, the user will still need to know his/her password, at the very least, to logon to a service not supporting SSO to mention just one example. correct? – Robert R Oct 28 '19 at 15:35
  • Hang on, that's not what I said. Convenience is important, but this is about making sure you can't steal the raw password because there is no more password in use. That has more value than just convenience. If you have a password in memory still then it's probably not configured correctly. – Steve Oct 28 '19 at 16:33
  • now we're getting to the meat of my question ;) should i still be able to logon to windows with my password or not? – Robert R Oct 28 '19 at 16:36
  • If you don't disable password auth for the user in AD you will still be able to log on with that password. The password will not be in memory if WHFB is configured correctly, nor is it used any auth flows. If it IS still in memory or used for auth then you're likely going down the password-stuffing flow, which is noted as insecure and only for convenience. – Steve Oct 28 '19 at 20:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.