A newly demonstrated technique shows how malware in a compromised Windows user session can abuse Windows Hello for Business (WHFB) cryptographic keys to authenticate to Microsoft Entra ID, enabling attackers to gain cloud access without the victim’s password, PIN, or biometric data.
Windows Hello for Business is designed as a passwordless authentication system. It normally stores a user’s private key in the device’s Trusted Platform Module, or TPM, making the key difficult to export or steal. Users unlock access to that key with a PIN, fingerprint, facial recognition, or another local verification method.
However, researcher Dirk-jan Mollema found that a process already operating within an active user session may be able to use the key through Windows cryptographic interfaces without triggering a fresh PIN or biometric prompt. This behavior appears linked to cached authentication information used by Windows Hello.
The issue does not mean that attackers can simply copy a TPM-protected private key from a device. Instead, malware with access to an unlocked user session could ask Windows to perform cryptographic signing operations using the protected key. Those signatures can then be used in identity flows that prove control of the Windows Hello credential.
Windows Hello Key Abuse Targets Entra ID
One attack path involves requesting a Primary Refresh Token, also known as a PRT. PRTs are important Microsoft Entra ID authentication artifacts that support single sign-on across Microsoft services and applications.
A valid PRT can provide long-lived access and may be renewed, making it highly valuable to attackers seeking persistence in a cloud environment.
Previously, an attacker would also need access to another Entra ID-joined or registered device to complete this flow. The new research shows a second option: treating the Windows Hello for Business key as a FIDO2 passkey through the WebAuthn authentication protocol.
WebAuthn is widely used for passwordless authentication and phishing-resistant sign-in. By generating a valid WebAuthn assertion with the victim’s Windows Hello key, an attacker could authenticate to Microsoft Entra ID from a separate machine.
The resulting access tokens may lack a device identifier because the sign-in does not include the victim device’s normal registration state.
That missing device identifier can be useful to an attacker. Tokens without device-bound state may be used to register a new attacker-controlled device in Entra ID.
From there, an attacker could attempt to obtain a PRT, establish persistence, or add new authentication methods such as passkeys. The research also highlights a challenge for Conditional Access policies.
Because Windows Hello and FIDO2 are considered phishing-resistant authentication methods, a forged authentication flow based on a compromised session may satisfy policies requiring strong multifactor authentication.
Policies that require compliant or managed devices could still block some activity, but attackers may attempt to work around device restrictions after gaining cloud access.
Defenders should monitor Entra ID sign-in logs for Windows Hello for Business authentications where the device ID is empty. While this can occur legitimately in private browsing sessions or browsers without single sign-on support, it should be relatively uncommon in many enterprise environments.
Organizations should also investigate unexpected device registrations, newly added authentication methods, unusual token activity, and sign-ins that follow endpoint compromise. Protecting active Windows sessions remains essential, because the attack relies on malware already running as the targeted user.
Strengthen Your SOC by Accelerating Threat Detection & Rapid Investigations. -> Integrate ANY.RUN With Your SOC Now.
