4

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.

2
  • Is it meant to be a control against lateral movement?
    – schroeder
    Commented Oct 25, 2019 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
    Commented Oct 28, 2019 at 15:40

2 Answers 2

6

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.

4
  • 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
    Commented Oct 28, 2019 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
    Commented Oct 28, 2019 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
    Commented Oct 28, 2019 at 16:36
  • 1
    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
    Commented Oct 28, 2019 at 20:25
0

Please rerun the exercise making user member of Protected Users and enabling for that user the flag : Smart Card is Required for Interactive Logon.

More info :

https://techcommunity.microsoft.com/t5/security-compliance-and-identity/how-to-enabling-mfa-for-active-directory-domain-admins-with/m-p/2803878

1
  • SCRIL and PUG were not part of this exercise on purpose, but thanks anyway
    – Robert R
    Commented Feb 21, 2022 at 14:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .