Windows Hello for Business – Past and Present Attacks

Windows Hello for Business is a key component of Microsoft’s passwordless authentication strategy. It enables user authentication not only during system sign-in but also in conjunction with new and advanced features such as Personal Data Encryption, Administrator Protection, and Recall. Rather than depending on traditional passwords, Windows Hello leverages a PIN or biometric methods – such as fingerprint or facial recognition – to unlock cryptographic keys protected by the Trusted Platform Module (TPM).

Passwordless and password-based logon mechanisms share largely similar architectures, with only a few key distinctions. As previously discussed, in a traditional password-based logon process, WinLogon initiates user authentication by launching LogonUI. This presents the login interface and relies on a credential provider to collect the user’s credentials – usually username and password. These credentials are then passed via WinLogon to the Local Security Authority Subsystem Service (LSASS.exe) for validation and user authentication.

In contrast, during a passwordless authentication procedure, the credential provider uses the Windows Biometric Service to identify the user using, for example, face recognition. Rather than verifying a password, the system utilizes cryptography for authentication. The cryptographic keys are managed by a separate component: Microsoft Passport.

This blog post examines the biometric authentication mechanisms implemented in Windows Hello for Business (WHfB). We begin by presenting a comprehensive overview of the authentication process. Following this, we highlight specific components of the procedure targeted in the past by attackers and explain the nature of a recently discovered vulnerability. This research was primarily funded by the German Federal Office for Information Security (BSI – Bundesamt für Sicherheit in der Informationstechnik) as part of the “Windows Dissect” project. A detailed technical report elaborating on all aspects of WHfB is planned for release soon by BSI and ERNW.

 

The following list summarizes the biometric authentication procedure in Windows Hello for Business. WHfB leverages existing components of the Windows platform; however, several of these components have been extended or enhanced to enable seamless integration and interoperability within the WHfB framework.

1. Winlogon initiates the user authentication procedure. First the system needs to collect the user’s credential, therefore Winlogon starts LogonUi.

1. LogonUi initializes its credential providers to collect the user’s credential. Among them, the FaceCredentialProvider is loaded to handle the face recognition. Internally, the FaceCredentialProvider relies on the Windows Biometric Framework for identification. It uses the biometric framework to identify the user in front of the system.

2. The Windows Biometric Service first needs to get a biometric sample from the user’s face. Therefore, it requests the camera to capture biometric data. This means it sends an IOCTL to the Windows Biometric Driver Interface to start a capture procedure.

3. The camera captures frames which are then sent back to the Windows Biometric Framework.

4. As part of the identification procedure, the Windows Biometric Framework uses the biometric templates stored in the database to perform an identification.

5. The identification procedure itself is performed in the engine adapter. This identification procedure also includes presentation attack detection. At the end of the procedure, if a user was identified an Authorize Ticket is generated.

6. When a user has been identified, the Windows Biometric Framework returns the user’s SID and a biometric Authorize Ticket to the FaceCredentialProvider. This ticket authorizes the decryption of data set up previously in the enrollment phase. This data is called the protector data, and it is stored encrypted. The protector data can be used to create a signature with the user’s smart card certificate (which itself is protected by the TPM and created when the user has enrolled with WHfB) to authenticate against the identity provider.

7. The FaceCredentialProvider transfers this Authorize Ticket to Microsoft Passport.

8. The Passport infrastructure redeems the Authorize Ticket with the Windows Biometric Framework to decrypt the protector data. It subsequently creates an intermediate smart card PIN that references the decrypted data, without revealing it to the rest of the system.

9. The Passport infrastructure returns this intermediate smart card PIN to the FaceCredentialProvider.

10. In LogonUi, a credential structure is serialized and then passed to Winlogon. This serialized credential holds the user’s SID, the intermediate PIN, and information about the smart card certificate managed by Microsoft Passport.

11. Winlogon transfers this serialized credential to LSASS.

12. LSASS authenticates the user using the Kerberos authentication package. For cryptographic operations, the user’s smart card certificate is used. These operations are not performed directly in LSASS but rather in the Microsoft Passport infrastructure. The underlying key is set up with the intermediate PIN from the serialized credential.

13. In the Passport infrastructure, the intermediate PIN is checked for validity. Then the protector data is used to set up the key protected by the TPM. This key is subsequently used to perform the actual signature operation. This signature is done in the TPM and authorized with the previously decrypted authentication key from the protector data.

14. The Passport infrastructure returns this signature to LSASS.

15. This signature is used in the PKINIT pre authentication step of the Kerberos protocol to authenticate the user against the identity provider (in our case, Active Directory).

The image and accompanying list below present an overview of previously identified attacks targeting WHfB. Attacks specific to identity providers are excluded from this overview; for instance, those involving Primary Refresh Tokens are not considered. As a result, the listed attacks are applicable across all deployment models – whether on-premises, hybrid, or Entra ID – and have worked independently of the identity provider in use.

1. CVE-2021-34466, presented at Black Hat USA 2021, involved the use of a malicious USB device designed to impersonate a camera and transmit spoofed infrared frames to the biometric framework. This attack has since been mitigated through the introduction of a registry value that allows administrators to restrict the use of external cameras.

2. In 2017 Researchers from SySS demonstrated that at the time it was possible to authenticate using a paper printout. Prior to Windows 10 version 1607, the presentation attack detection capabilities of Windows Hello were relatively weak. In response, Microsoft later introduced an enhanced anti-spoofing feature. This topic will be examined in greater detail in the forthcoming technical report.

3. CVE-2017-15361 is a vulnerability that affected certain TPM chips, leading to the generation of cryptographically weak keys. Michael Grafnetter explored the implications of this vulnerability for domains using WHfB authentication during his presentation at Black Hat Europe 2019. For a detailed examination of Microsoft’s response to the vulnerability, we encourage you to consult our comprehensive analysis of the mitigations.

4. At DEF CON 2024, Dirk-jan Mollema and Ceri Coburn presented research revealing that the protector data, used to safeguard the user’s smart card certificate for authentication, is not securely encrypted. As a result, a local attacker with administrative privileges can decrypt this data and leverage the smart card certificate of any enrolled user to authenticate as that user.

5. To date, limited research has focused specifically on the biometric unit itself. In our analysis of the Windows Biometric Service, we found that the template database lacks adequate protection against administrative attackers. Notably, no entropy (from outside of the system) is used in the encryption of this database, leaving it vulnerable. This enables an attacker with administrative privileges to access and manipulate the stored biometric data. Consequently, such an attacker could potentially authenticate as any enrolled user and gain access to their so-called “encrypted” biometric data.

If you’re interested in understanding how WHfB works and want to know the real-world challenges it faces and the critical questions around the confidentiality and integrity of biometric data, don’t miss our in-depth talk at TROOPERS. We will provide a detailed walkthrough of WHfB’s architecture and highlight the subtle security risks. Our research is backed by extensive reverse engineering. Join us for a closer look at where user convenience meets system complexity.

Cheers!

Baptiste & Till