Endpoint security just got a new challenge. Researcher **Dirk-jan Mollema** has showcased a concerning vulnerability, demonstrating how malware already active within a signed-in **Windows** session can silently exploit a victim's **Windows Hello for Business** key to authenticate with **Microsoft Entra ID**. This technique allows an attacker to achieve long-term cloud access, register attacker-controlled devices, obtain a **Primary Refresh Token (PRT)**, and even add additional authentication methods, depending on tenant policies. ### Bypassing Security Prompts Crucially, on **TPM**-backed systems, this attack doesn't involve extracting the private key, recovering the **PIN**, or triggering any biometric prompts. **Windows**' internal ticketing system maintains private-key operations while a user is interactively signed in, enabling code running under the user's context to request **Windows** to sign authentication data. Notably, administrator privileges are not required for this to occur. **Mollema** describes this behavior as an inherent consequence of how **Windows Hello for Business** operates, indicating it was left as-is by **Microsoft**. As of the disclosure, there is no report of active exploitation or identified victims. **Mollema** advises organizations to monitor for unexpected device registrations as a detection measure. ### Lack of Official Acknowledgment As of August 6, 2026, searches of **Microsoft**'s **Security Update Guide**, **NVD**, and **CVE.org** by The Hacker News have revealed no **CVE** or official **Microsoft** advisory tied to this technique. The specific **Windows** builds or **Windows Hello for Business** deployment models tested were not identified in the initial disclosure. **Microsoft**'s documentation acknowledges the ticketing behavior that underpins this method. **Mollema** previously presented the ability to invoke **Windows Hello for Business** keys from a compromised session at **DEF CON 32** in 2024. That earlier method, while capable of producing a signed assertion for a **PRT**, still required access to an **Entra**-registered or joined device.  ### The WebAuthn Breakthrough **Mollema**'s latest work, detailed in his research, removes the device requirement by treating the **Windows Hello for Business** key as a **FIDO2** passkey through **WebAuthn**. He discovered that the five-minute **Entra ID** challenge is not bound to a specific session, user, or tenant. This allows an attacker to request the challenge on a different host and have the compromised endpoint generate the signed assertion. The **ROADtools** framework, designed for interacting with **Entra ID**, can then utilize this assertion to request tokens or open a browser session impersonating the victim. ### Persistence and Conditional Access Bypass Notably, **Mollema** found that the generated token lacks a device ID claim. This omission enables the attacker to register a new device, request a **PRT** for it, and access **Microsoft** cloud services. **Microsoft**'s documentation confirms that a **PRT** remains valid for 90 days and is continuously renewed with active device usage. Furthermore, the **WebAuthn** sign-in can satisfy **Conditional Access** policies that demand **Microsoft**'s phishing-resistant authentication strength. **Mollema** also observed that this sign-in counts as fresh multi-factor authentication, potentially allowing an attacker to add new passkeys or **Windows Hello for Business** keys on the newly registered device, provided tenant policies permit such actions. It is important to note that separate device-state or compliance policies could still interrupt this complete persistence chain, meaning the full attack might not succeed in every deployment.  ### Implications for Phishing-Resistant Authentication This finding highlights a critical limitation of phishing-resistant authentication mechanisms: while the credential itself remains hardware-bound and unexported, malware executing within the signed-in endpoint session can still invoke it on behalf of an attacker. **Mollema** has published PowerShell proof-of-concept scripts, `fido_assertion.ps1` and `hellopoc.ps1`, in the **ROADtools** repository for this technique. For detection, he recommends hunting for **Windows Hello for Business** sign-ins that appear with an empty device ID. However, it's worth noting that legitimate incognito or non-**SSO** browser sessions can also exhibit this pattern, requiring careful analysis.