Another biometrics vulnerability from Redmond (Windows Hello compromise)

Ask the Community Password Manager
, ,
1

Bitwarden users who rely on Windows Hello to unlock their Bitwarden vaults should be aware of the following recently discovered security vulnerability, which has potentially far-reaching implications:

https://windowsforum.com/threads/windows-hello-vulnerability-biometric-security-under-threat-at-black-hat-2025.376272/

Basically, if an attacker has access to a local admin account on your Windows computer (either because your account already has admin privileges, or the attacker is able to use privilege escalation to obtain admin privileges starting from a non-admin account), they are able to inject biometric templates so that their own biometrics will be recognized as yours. This in effect allows them to fully bypass Windows Hello, and everything that is protected by Windows Hello.

2 Likes
2

Very interesting…..

I don’t think this represents a risk to my laptop itself or the data stored on it, given that “has access to a local admin account” already puts the laptop itself in game-over territory. However it seems like a substantial risk to lateral-movement (using a compromised device to log into other devices). With Bitwarden (versions <= 2025.08.0), this could happen by gaining access to Windows Credential manager and therefore the encryption key to my Bitwarden vault.

Keeping my focus on Bitwarden, I have a few initial observations:

  1. Bitwarden would be well served to prioritize “Unlock with Device”, in addition to the existing “Login with Device” so that I can use my phone’s biometrics in lieu of Hello.

  2. This likely will delay any efforts to fix “ Unable to unlock Bitwarden desktop app on app start using Windows Hello ".

  3. Bitwarden had some extremely lucky foresight in releasing 2025.08.0. P.R. wise, they might well be ahead of their peers on this one.

  4. It will be interesting to see how Bitwarden, other password managers, and Microsoft react to this. None of them are having a good day.

1 Like
3

This vulnerability only affects biometrics, not Windows Hello PIN (as far as I understand).

Why and why is this vulnerability even possible, because surely encrypted credentials cant be decrypted by wizardy, but only with proper decryption keys? I try to explain this the best way I see this happens (please correct me if Im wrong):

When Windows Hello PIN is used, TPM steps in and only releases credentials when proper PIN is entered, period. To be able to perform this kind of attack would require hacking the physical TPM itself and its PIN protection.

But incase of biometrics, the biometric device (fingerprint reader, camera, etc.) actually stores the (encrypted) credentials and releases them to Windows (in plaintext) if, well, to say it plain and overly simplyflying manner, “it is properly asked to do so”. Normally this “properly asked to do” happens, when the biometric device gets the proper, matching input by the proper users fingerprint of face. The problem is, that now, because of this vulnerability, who process can be manipulated by basically telling windows/biometric devices “concider this X valid”. The biometric device goes “ok that X is valid I will decrypt and release the credentials for that now” and then the attacker “inputs” “X” and biometric device goes “yeah that is valid here, take these my decrypted credentials”. THOSE credentials are used to decrypt various Windows secrets related to that user. And since, if Windows Hello Biometric are used to secure Bitwarden vault content, could be used to decrypt them aswell.

There was some Windows Hello biometrics vulnerability earlier that had similiar issues related to these devices, essentially allowing them to release the (plaintext) credentials without proper authentications and yes, it was really a vulnerability of those devices, not really Windows Hello biometrics.

:thinking: So Im not really sure is this actually Windows security vulnerability - or the device (fingerprint reader, camera, etc.) vulnerability? Surely the device should NEVER allow anything like this to happen and always ask, if new biometric data is to be inserted, the OLD DATA FIRST to make sure the whoeveristrying to insert new biometric data, to actually have right to do that! In analog, “asking for the password before the old password can be changed”. Surely an admin could “reset the biometrics” (or passwords ofcourse) for the Windows users, but that would destroy those credentials used to decrypt secrets…for example resetting users passphrase would make it impossible to decrypt EFS files encrypted by that user, since the EFS private key is encrypted using users passphrase.

:grimacing: If this is Windows vulnerability, well, then I must have understod something terribly wrong about how biometrics of Windows Hello works. And then essentially the Windows Hello system is completely broken and was never, ever, secure in any possible way in the first place, but a complete joke and can never, ever be fixed in any meaningfull way. :grimacing:

4

Initial attack: admin access, biometrics injection.

Subsequent attack: local biometrics authentication.

This seems like a good link in the attack chain for a tool like Cellebrite that leads into logging in as the user instead of logging in as a “non-user” admin, compromising all the secrets that Windows Hello/account separation (including the EFS key, info in the credential manager, and passkeys) keeps for the user. I generally think that against a tool like Cellebrite, you can’t count on anything beyond a pre-boot PIN (or other keys) with BitLocker.

This still seems like a local attack, though.

5

This vulnerability disclosure leads me in the opposite direction… that Microsoft has the keying material. If stored in the camera or reader, the vulnerability would have mentioned vulnerable manufacturers. (Logitech, HID, Kensington, etc.). Plus, Microsoft even says the biometric data is typically (with exceptions) on the device (laptop): “Windows Hello biometrics data is stored on the device as an encrypted template database.”

and releases them to Windows (in plaintext)

Much more likely than directly spitting out a username/password is that cameras and (most) fingerprint readers end up creating a hash that is used much like the PIN to gain access the TPM and the Credential Manager.

There was some Windows Hello biometrics vulnerability earlier that had similiar issues related to these devices, essentially allowing them to release the (plaintext) credentials without proper authentications and yes, it was really a vulnerability of those devices, not really Windows Hello biometrics.

Cite please.

Are you referring to KB5005478, in which envisioned a hypothetical “camera” functioning more as a VCR, replaying a image that had earlier been stolen?

6

If this really is the case, then all the encryption and protection systems of Windows are a complete joke. And all the consumers and companies should put up a class action suite against Microsoft for scamming them for decades. Really. Im not joking.

Data that should have been encrypted by something was actually NOT encrypted properly in the first place. Its really as simple as that. If it would have been encrypted properly, any attempts to “slip in” or “change” some biometric data SHOULD HAVE resulted corruption of the decryption keys / inability to recreate proper encryption keys and the data would have been safe. For a good comparison: Try to change Veracrypt containers header with “your own header” that has “you selected password” in it? Does it work? Can you now open any random Veracrypt container? Ofcourse not! But apparently, doing something similiar in Windows allows you to open its encryption keys.

Then this reminds me of 25 year old Windows 2000 EFS vulnerability, where admin could simply overwrite users password and then login with that password and gain access to users EFS encrypted files!!! This was possible, because EFS private key was NOT encrypted using the users passphrase, but simply “protected” “somehow” in some “Windows protection” “System”.

Much more likely than directly spitting out a username/password is that cameras and (most) fingerprint readers end up creating a hash that is used much like the PIN to gain access the TPM and the Credential Manager.

Yes that is better way of saying it. :slight_smile:
But, anyway, any attempt to replace any of that data with other data (like this vulnerability) should have resulted in destruction of the original data or unability to recreate the proper TPM unlocking / decryption keys. And NOT as a “software way”, but as a simple mathematical/cryptographical way. as, well, it happens if you try similiar trick with Veracrypt containers headers.

Cite please.

This was the vulnerability I was talking about:
" Windows Hello fingerprint authentication can be bypassed on popular laptops"

7

:see_no_evil_monkey: :clown_face: Why doesnt Windows Hello for Business simply do:

  1. hmac-sha256(userfingerprint key values + system wide 256bit salt) (10000 iterations) and store the output (X) in Windows Hello for Business directory
  2. hmac-sha256(X + userfingerprint key values) (10000 iterations) and use this (Y) to encrypt all user secrets.

User walks into any computer on the network → Plugs in their finger to fingerprint reader → Reader/computer calculates (1.) → Checks from Windows Hello for Business directory of the output (X) for matches → Match found, user identified → Computer now calculates (2.) → Decryption key (Y) for the user secrets now created → User secrets can be opened safely.

If anyone gets their hands to Windows Hello for Business directory and try to slip in their own biometrics for someone else, it is impossible to create decryption key (Y) anymore to decrypt that users secrets.

If anyone gets their hands to Windows Hello for Business directory to read the value X, without users fingerprint values + system wide salt it cant be used to create Y to decrypt that users secrets.

Only way to break the system would be to get users fingerprint key values and system wide salt to calculate the Y…but the only way to get users fingerprint values would be to capture their fingerprint, print a fake finger, implant it to fingerprint reader so it would read the proper fingerprint key values out of it etc.etc. but then again if you already have the fake finger with proper fingerprint, you could just login with it anyway.

8

The details are summarized in the Technical Dissection section of the article I linked above. Basically, the biometric template data that are used to match fingerprints or facial features to system users are all stored in an encrypted local database, but the random key that decrypts that template database is freely available to any process that has admin privileges on the local system. Key in hand, the attacker is free to not only read the biometric template database, but to alter it; thus, they can swap their own biometric templates for those of any user whose biometric data are stored in the database on the compromised device.

Here are the two key slides about the biometric template database, from the original research presentation by David and Osswald (2025):

image
image997Ă—1057 113 KB

 

It’s definitely a Windows Operating System security vulnerability, if you read the linked source materials.

 

It’s an attack on a local device, but I have read nothing that would lead me to think that it couldn’t be carried out remotely, using malware. The description of the researchers’ demo does not mention that any local biometric sensors (fingerprint reader or camera) were used to inject the spoofed biometric profile:

“The live demonstration was startlingly simple. One researcher logged into a Windows machine using Windows Hello’s facial recognition. The other, with a few lines of code and administrator rights, injected a different facial biometric template into the system’s database.”

 

Only in the sense that the Windows operating system has it. I don’t think you’re saying that the keys are stored in Redmond (or on some Azure server), right?

 

I’m not going to argue against you. Here is what the linked article has to say about Microsoft’s position on the vulnerability:

“Silence from Redmond​: At the time of disclosure, Microsoft had not provided an official response to the findings, despite the flaw’s implications for the security of millions of business endpoints worldwide. The ambiguity fuels uncertainty among IT administrators and security professionals seeking clear mitigation guidance.”

9

Yes, but to log in using the injected biometric profiles, the attacker will still have to use the local biometric device to log into the local computer. The attacker will need local access to “complete” the attack.

1 Like
10

Correct. Microsoft’s operating system, as opposed to Logitech’s camera or Kensington’s fingerprint reader.