Windows Hello for Business Can Be Abused by Malware to Maintain Access to Entra ID

The Technique Exploits an Already Authenticated Windows Session

Research published on August 7, 2026, shows that malware already running in a user’s interactive session can use the user’s Windows Hello for Business (WHfB) key to authenticate to Microsoft Entra ID.

No administrative privileges are required. Code execution in the user’s session and an existing authenticated session are sufficient.

The technique was demonstrated by Entra ID researcher Dirk-jan Mollema. No CVE, Microsoft advisory, active exploitation campaign, or known victims have been associated with this behavior. The exact Windows builds and WHfB deployment models tested were not disclosed.

The Private Key Remains Protected but Can Still Be Invoked

On systems equipped with a TPM, the attack does not extract the private key, recover the PIN, or require a new biometric verification. However, Windows’ ticketing mechanism keeps key operations available as long as the user remains interactively authenticated.

The malware treats the WHfB key as a FIDO2 passkey, using WebAuthn. A valid five-minute Entra ID request can even be initiated from another host: the compromised endpoint generates the signed assertion, while the remote system handles the rest of the flow.

This removes the previous requirement to already have an Entra-registered or Entra-joined device. The token obtained through ROADtools can be used to request additional tokens or open a browser session while impersonating the user.

From a Compromised Session to Cloud Persistence

Mollema found that authentication can produce a response without a device ID. In certain configurations, this allows an attacker to register a new device under their control and request a Primary Refresh Token (PRT) for it.

Microsoft documents a 90-day PRT lifetime, with continuous renewal while the device is actively used. As a result, a compromise initially limited to a Windows session can become prolonged cloud access.

WebAuthn authentication can also satisfy Conditional Access policies requiring phishing-resistant authentication and is treated as recent MFA. If tenant policies permit it, the attacker may add passkeys or additional WHfB keys.

This chain is not guaranteed in every environment. Separate checks for device state and compliance may block device registration or token issuance.

Detection and Mitigations for Administrators

Administrators should monitor:

• Entra ID sign-ins using WHfB authentication with an empty device ID;
• unexpected registration of new devices;
• unauthorized changes to authentication methods;
• the addition of passkeys or Windows Hello for Business keys.

An empty device ID alone does not prove compromise: it can also appear in private browser sessions or scenarios without Single Sign-On. It should therefore be correlated with the user, timestamp, endpoint, network address, and device-registration activity.

Organizations should enforce strict device-state and compliance policies, restrict the ability to add new authentication methods where possible, and manually validate new registrations.

Mollema’s published PoC includes the PowerShell scripts fido_assertion.ps1 and hellopoc.ps1 in the ROADtools repository. When malware is present on an endpoint, the Windows session should be considered compromised: the TPM protects the key from export, but it does not prevent malicious code from invoking its authorized use.