Critical Windows Hello for Business Bug Lets Attackers Impersonate Users in Entra ID
Key Takeaways A new attack technique allows malware in a compromised Windows user session to exploit Windows Hello for Business (WHFB) cryptographic keys. Attackers can impersonate users in Microsoft...
Key Takeaways
- A new attack technique allows malware in a compromised Windows user session to exploit Windows Hello for Business (WHFB) cryptographic keys.
- Attackers can impersonate users in Microsoft Entra ID without needing passwords, PINs, or biometric data.
- This vulnerability enables cloud access and persistence, potentially bypassing strong multi-factor authentication policies.
- The attack leverages cached authentication information and does not directly steal TPM-protected private keys.
- Organizations should monitor Entra ID sign-in logs for unusual activity, especially empty device IDs in WHFB authentications.
A recently uncovered attack technique demonstrates how malicious software operating within an active Windows user session can exploit Windows Hello for Business (WHFB) cryptographic keys. This allows unauthorized access to Microsoft Entra ID, effectively enabling attackers to impersonate users and gain cloud access without requiring the victim’s password, PIN, or biometric information.
Table Of Content
Windows Hello for Business is fundamentally designed as a robust, passwordless authentication solution. It typically safeguards a user’s private key within the device’s Trusted Platform Module (TPM), making it extremely difficult to extract or compromise. Users traditionally unlock access to this key through a local verification method, such as a PIN, fingerprint scan, or facial recognition.
However, researcher Dirk-jan Mollema found that a process already executing within an active user session can utilize the key via standard Windows cryptographic interfaces without prompting for re-authentication (like a PIN or biometric scan). This behavior is attributed to cached authentication information that Windows Hello maintains.
It is crucial to understand that this issue does not imply attackers can simply copy a private key from a TPM-protected device. Instead, malware with privileges within an unlocked user session can instruct Windows to perform cryptographic signing operations using the protected key. These generated signatures can then be leveraged in identity authentication flows to prove control over the Windows Hello credential.
Windows Hello Key Abuse Targets Entra ID
One significant attack vector involves requesting a Primary Refresh Token (PRT). PRTs are vital Microsoft Entra ID authentication artifacts that facilitate single sign-on (SSO) across various Microsoft services and applications.
A valid PRT grants long-lived access and can be renewed, making it an extremely valuable target for attackers aiming to establish persistent access within a cloud environment.
Historically, an attacker would also need access to another Entra ID-joined or registered device to complete this particular authentication flow. However, this new research reveals an alternative method: treating the Windows Hello for Business key as a FIDO2 passkey through the WebAuthn authentication protocol.
WebAuthn is a widely adopted standard for passwordless and phishing-resistant authentication. By crafting a valid WebAuthn assertion using the victim’s Windows Hello key, an attacker can authenticate to Microsoft Entra ID from an entirely separate, attacker-controlled machine.
The access tokens obtained through this method may lack a device identifier because the sign-in process bypasses the victim device’s normal registration state.
This absence of a device identifier can be advantageous for an attacker. Tokens without device-bound state can potentially be used to register a new, attacker-controlled device within Entra ID.
From that point, an attacker could attempt to acquire a PRT, establish persistence, or add new authentication methods, such as additional passkeys. The research also underscores a significant challenge for Conditional Access policies.
Given that both Windows Hello and FIDO2 are considered strong, phishing-resistant authentication methods, a fabricated authentication flow originating from a compromised session might satisfy policies that mandate robust multi-factor authentication.
While policies requiring compliant or managed devices could still block certain activities, attackers might seek to circumvent device restrictions once initial cloud access is achieved.
What You Should Do
- Monitor Entra ID Sign-in Logs: Actively review Entra ID sign-in logs for Windows Hello for Business authentications where the device ID field is empty. While this can occur legitimately in specific scenarios (e.g., private browsing, browsers without SSO), it should be rare in most enterprise settings.
- Investigate Anomalous Activity: Promptly investigate any unexpected device registrations, newly added authentication methods, unusual token activity, and sign-ins that follow a known endpoint compromise.
- Strengthen Endpoint Security: Prioritize protecting active Windows user sessions, as this attack relies on malware already running with the targeted user’s privileges. Implement robust endpoint detection and response (EDR) solutions and ensure timely patching.
- Review Conditional Access Policies: Evaluate Conditional Access policies to ensure they effectively mitigate risks even when strong authentication methods like WHFB are involved. Consider policies that enforce device compliance in addition to strong authentication.
Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.



No Comment! Be the first one.