Windows Hello flaw opens path to Entra access

A Windows Hello for Business authentication technique can allow malware operating inside an unlocked Windows session to gain access to Microsoft Entra ID services without obtaining the user’s password, PIN or biometric data.

Security researcher Dirk-jan Mollema demonstrated that an attacker who already controls a user process can invoke the cryptographic key underpinning Windows Hello for Business, or WHFB, and use it to generate authentication signatures. The private key itself does not have to be extracted from the device’s Trusted Platform Module, preserving the appearance of hardware-backed protection while allowing its capabilities to be exploited.

The finding places renewed attention on endpoint security in organisations that use passwordless authentication as part of their Microsoft identity architecture. Windows Hello for Business normally combines a device-bound credential with a PIN or biometric gesture. Microsoft describes the system as phishing-resistant two-factor authentication because the private credential remains associated with the device and is typically protected by hardware.

Mollema found that this protection does not necessarily force fresh user verification whenever the cryptographic key is used. Code running within an authenticated user session can call Windows cryptographic interfaces and request signing operations without triggering another PIN or biometric prompt. Administrator privileges are not required because the Windows Hello credential belongs to the logged-in user.

The attack therefore differs from conventional credential theft. An adversary does not copy the TPM-protected private key or discover the victim’s PIN. Instead, malware effectively borrows the key by asking Windows to perform cryptographic operations on its behalf while the legitimate user’s session remains active.

The technique can be used to construct a signed WebAuthn assertion and authenticate to Entra ID using the Windows Hello credential as a FIDO2-style passkey. WebAuthn authentication relies on signing a server-issued challenge. Mollema found that the Entra challenge involved in the tested flow remains valid for five minutes and is not bound to a particular session, user or tenant.

That characteristic allows an attacker to initiate part of the authentication process on another machine, pass the challenge to malware running on the compromised Windows endpoint and have the victim’s Windows Hello key sign it. The resulting assertion can then be returned to the attacker-controlled system and presented to Entra ID.

Tokens obtained through the method may lack a device ID because the authentication takes place without presenting the normal device state. That absence creates another potential avenue for attackers. A token without the device binding can, where tenant controls permit, be used during registration of a new device under the attacker’s control.

The attacker could subsequently seek a Primary Refresh Token, a powerful Entra authentication artefact used to support single sign-on across Microsoft-connected applications and services. PRTs can provide durable access and are renewable, making them particularly valuable for maintaining persistence after an endpoint compromise.

Mollema also demonstrated that authentication performed through the Windows Hello key can satisfy Conditional Access requirements configured for phishing-resistant authentication. Because the sign-in is recognised as strong authentication, it may also carry sufficiently fresh multifactor authentication status to permit additional authentication methods to be enrolled where organisational policy allows.

The technique does not amount to a remote compromise of Windows Hello on its own. An attacker must first obtain code execution inside the victim’s active Windows session. That prerequisite makes endpoint compromise the initial security boundary and means organisations with strong application controls, endpoint detection and response systems and disciplined session management retain significant defensive layers.

Device-based Conditional Access restrictions can also interrupt the attack chain. Organisations requiring access to originate from compliant, managed or hybrid-joined devices may block subsequent activity even after the attacker successfully produces a Windows Hello authentication assertion.

No evidence of active exploitation against organisations has been disclosed. The research has not been associated with a publicly identified CVE, and the behaviour is presented as a consequence of Windows Hello for Business authentication design rather than theft of its underlying hardware-protected secret.

Detection may nevertheless require organisations to rethink how they interpret strong-authentication events. Mollema recommends examining Entra sign-in logs for Windows Hello for Business authentications where the device ID is empty. Such events can occur legitimately, including when users authenticate from private browser sessions or browsers without normal single-sign-on integration, so alerts require contextual investigation rather than automatic classification as malicious.