Malware doesn’t always need to steal credentials in the classic sense. A recent demonstration by Entra ID researcher Dirk-jan Mollema shows a more subtle path: code running inside a victim’s signed-in Windows session can silently leverage Windows Hello for Business keys to authenticate to Microsoft Entra ID.
The core concern is persistence. Once the attacker can obtain access tokens and cloud session artifacts, the window for long-term control can widen—especially when tenant policies allow additional authentication methods and device actions.
How malware can use Windows Hello for Business keys
Mollema’s finding centers on a behavior of Windows Hello for Business. If malware is already running in the context of a user who is interactively signed in, the operating system can still perform the underlying cryptographic steps required for authentication.
In the demonstrated workflow, the attacker can use the victim’s Windows Hello for Business key to sign authentication data without triggering obvious prompts. This enables authentication to Entra ID and can then be followed by longer-term access steps in the Microsoft cloud.
Importantly, the technique described does not require administrator privileges. The only prerequisite is code execution within the compromised, signed-in endpoint session.
No biometric prompt on some systems
On systems backed by a TPM (Trusted Platform Module), the behavior can differ from what you might expect from normal interactive sign-in. According to the disclosure, the attacker does not extract the private key, recover the PIN, or trigger a biometric prompt.
The reason is that Windows ticketing keeps private-key operations available while the user is signed in. Because of that, code running as the user can ask Windows to sign authentication data for the attacker’s benefit.
Mollema frames the behavior as a consequence of how Windows Hello for Business works and notes that it was left as-is.
From sign-in to longer-term Entra ID access
Once the malware can authenticate, the next phase is about extending the attacker’s ability to act across time and devices.
- Authentication to Entra ID using the victim’s Windows Hello for Business key.
- Device registration for a device the attacker controls (where tenant policies permit).
- Obtaining a Primary Refresh Token (PRT), which is a key component in maintaining access.
- Adding additional authentication methods on the new device if the tenant allows it.
While this sounds powerful, it is not guaranteed everywhere. The disclosure emphasizes that tenant configuration matters, and separate policies (for example, device state or compliance checks) may break the chain in some deployments.
Why the approach may work even without a specific device setup
In earlier work presented at DEF CON 32 in 2024, the method could produce a signed assertion for a PRT, but it also required access to an Entra-registered or joined device.
The new work removes that requirement by treating the Windows Hello for Business key as a FIDO2 passkey through WebAuthn. Mollema found that the five-minute Entra ID challenge used in this flow is not bound to a session, user, or tenant.
That means an attacker can request the challenge on another host, while the compromised endpoint produces the signed assertion.
Using ROADtools to interact with Entra ID
Mollema also points to tooling that can take advantage of the flow. The ROADtools framework can use the signed assertion to request tokens or even open a browser session as the victim.
In practice, this provides a path from “malware is running” to “attacker can interact with identity services as if they were the user,” all without extracting the underlying Windows Hello for Business private key.
Token characteristics and device binding limits
A notable detail in the investigation is what the resulting token does not contain. Mollema found that the token carries no device ID claim.
That absence affects how device binding behaves. With a token that isn’t tied to a device identity claim, the attacker can register a new device, request a PRT for it, and reach Microsoft cloud services.
Microsoft documentation indicates that a PRT remains valid for 90 days and is continuously renewed while the user actively uses the device. That renewal behavior can make the persistence window longer in real-world conditions.
Conditional Access: phishing-resistant, but not immune
Mollema’s findings also touch on Conditional Access. He reports that the WebAuthn sign-in can satisfy Conditional Access policies that require Microsoft’s phishing-resistant authentication strength.
Equally important, the sign-in can count as fresh multi-factor authentication. In other words, where policies allow it, the attacker may be able to add passkeys or Windows Hello for Business keys on the new device.
However, the full persistence route will not work in every environment. Separate controls tied to device state or compliance can interrupt the process, depending on how an organization has configured its tenant.
What is known—and what is still unclear
The disclosure does not report active exploitation or provide information about real victims. It also does not identify the exact Windows builds or the precise Windows Hello for Business deployment models tested.
As of August 6, 2026, The Hacker News reported no CVE or Microsoft advisory tied to this technique in searches of Microsoft’s Security Update Guide, NVD, and CVE.org. The publication states that they contacted Microsoft and Mollema, with responses pending at the time of writing.
Detection guidance: watch for unexpected registrations
Since this approach depends on silent authentication and follow-on device activity, monitoring becomes central.
Mollema recommends looking for unexpected device registrations. For detection details, he also suggests hunting for Windows Hello for Business sign-ins that show an empty device ID pattern.
That said, legitimate scenarios can produce similar artifacts. For example, incognito or non-SSO browser sessions may generate comparable patterns, so alerts should be reviewed in context.
Proof-of-concept scripts and what they imply
Mollema published PowerShell proof-of-concept scripts in the ROADtools repository. The Hacker News reported finding files named fido_assertion.ps1 and hellopoc.ps1 in the folder as of August 6, 2026.
These scripts demonstrate the mechanics of the technique rather than claiming a widespread, active campaign. Still, PoCs are a useful signal for defenders: they show which identity behaviors are reachable from an authenticated, compromised endpoint session.
Practical takeaway for organizations
The main lesson is not that Windows Hello for Business is “broken.” Instead, it highlights a boundary of phishing-resistant authentication: the credential can remain hardware-bound and non-exportable, yet malware operating inside an already signed-in environment may still be able to invoke it.
To reduce risk, organizations should focus on hardening endpoints to prevent code execution in the first place, and on identity monitoring to catch abnormal follow-on actions—especially device registration and authentication patterns that don’t match expected user behavior.
Ultimately, the effectiveness of this attack path depends on tenant policies and additional checks around device state and compliance. Where those controls are strong, the persistence chain may be disrupted. Where they are weak or absent, attackers could gain a meaningful foothold in the cloud.
Source: https://thehackernews.com/2026/08/malware-can-abuse-windows-hello-for.html
