Malware Abuses Windows Hello for Business Key to Authenticate to Microsoft Entra ID
Malware Abuses Windows Hello for Business Key to (TL-2026-1952) is a high-severity software vulnerability, first published 2026-08-09. It has no confirmed attribution, affects Microsoft Windows Hello for Business (TPM-backed) / Microsoft Entra ID, maps to 10 MITRE ATT&CK techniques (T1021.007, T1059.001, T1078.004), and is covered by 9 detection rules and 11 indicators of compromise.
Key facts for TL-2026-1952
- Threat ID
- TL-2026-1952
- Severity
- HIGH
- Status
- ACTIVE
- Category
- VULNERABILITY
- First published
- 2026-08-09
- Last reviewed
- 2026-08-09
- Attribution confidence
- LOW
- Motivation
- UNKNOWN
- Detection rules
- 9
- Indicators of compromise
- 11
Malware and tooling in Malware Abuses Windows Hello for Business Key to
Malware and tooling: ROADTools - S0684, roadtx
Researcher Dirk-jan Mollema demonstrated that malware already running in a signed-in Windows session can silently invoke a victim's Windows Hello for Business (WHFB) private key to authenticate to Microsoft Entra ID, without extracting the TPM-backed key, recovering the PIN, or triggering a biometric prompt. The technique lets an attacker request a Primary Refresh Token (PRT) for persistent SSO access, register an attacker-controlled device, and treat the WHFB key as a FIDO2 passkey via WebAuthn to authenticate from a separate machine without the original device identifier.
How Malware Abuses Windows Hello for Business Key to works
Windows Hello for Business (WHFB) keeps its per-device authentication private key inside the TPM and normally requires a PIN or biometric gesture to unlock it. Dirk-jan Mollema's research (building on his and Ceri Coburn's DEF CON 32 talk 'Abusing Windows Hello Without a Severed Hand' and its follow-ups, and on Benjamin Delpy's earlier mimikatz work exploring WHFB key operations) shows that Windows caches the unlocked state of that key as a 'ticket' for the duration of an interactive sign-in. Windows exposes two Cryptography API: Next Generation (CNG) key storage providers for WHFB keys: the Platform Key Storage Provider, which re-prompts for a PIN/biometric on each signing operation, and the Passport Key Storage Provider, which serves signing requests from the cached ticket instead. Any code running as the signed-in user -- including PowerShell, with no elevation required -- can call the Passport KSP through NCrypt.dll (e.g. `NCryptOpenKey`) and request signatures from the cached key without a fresh PIN or biometric prompt, because the operation is served from the cached ticket rather than a live user-presence check.
The original abuse path signs a locally generated JWT assertion (valid roughly 5 minutes) with the borrowed key and exchanges it for a Microsoft Entra ID Primary Refresh Token (PRT) -- a long-lived (up to 90 days, renewable) SSO artifact that grants broad access to Microsoft cloud services without re-prompting the user; RDP sessions are noted as a common legitimate vector that already exercises WHFB signing and can mask this abuse. Mollema's newer research (published 2026-08-05 as 'Borrowing Windows Hello keys for authentication and persistence') extends this by treating the WHFB key as a FIDO2 passkey through the WebAuthn protocol: the attacker fetches an Entra-issued WebAuthn challenge (a JWT prefixed 'O.', valid roughly five minutes, and notably not bound to any particular session, user, or tenant) on an attacker-controlled host, has the compromised, signed-in endpoint sign it with the victim's WHFB key using a PowerShell PoC (`fido_assertion.ps1`), and then completes the WebAuthn ceremony from the separate attacker-controlled machine using ROADtools' `roadtx fidoauth`. Constructing a valid assertion requires deriving the WebAuthn `user_handle` value, which Mollema documents as the static string `ON:` concatenated with the tenant ID (little-endian binary) and a SHA256 hash of the user ID. Because the resulting token can lack a bound device-ID claim, the attacker can use it to register a new, attacker-controlled device in the tenant via `roadtx`, request a Web Account Manager (WAM) broker refresh token for that device, and obtain a fresh PRT tied to attacker-controlled hardware rather than the victim's original device -- with continued renewal thereafter, independent of the original compromised host. Because the WebAuthn/FIDO2 flow satisfies Conditional Access policies that require phishing-resistant authentication strength, and because it counts as fresh multi-factor authentication, tenant policy permitting, the attacker can also enroll additional passkeys or WHFB keys on the new device via `roadtx registerpasskey` (which requires the `UserAuthenticationMethod.ReadWrite` scope and an `ngcmfa` claim, and is blocked where FIDO2 attestation enforcement is configured), creating durable backdoor authentication material independent of the original compromised host.
Publicly available proof-of-concept tooling exists in Dirk-jan Mollema's ROADtools framework (roadtx subcommands `fidoauth` and `registerpasskey`, and PowerShell scripts including `hellopoc.ps1` and `fido_assertion.ps1` in the `winhello_assertion` folder), meaning the barrier to reproducing the technique is low for anyone with existing code execution in a target's signed-in session. No CVE has been assigned and no vendor patch has shipped as of 2026-08-07; this is a design-level abuse of cached authentication state rather than a single, patchable memory-safety bug, and there are no reports of confirmed in-the-wild exploitation or named victims. The primary detection signal identified by both the researcher and independent write-ups (e.g. Hybrid Brothers, 2025-04-26) is Entra ID sign-in telemetry showing a Windows Hello for Business authentication method with an empty/blank device ID -- a state that is unusual outside of legitimate incognito or non-SSO-capable browser sessions.
MITRE ATT&CK techniques used in TL-2026-1952
Lateral Movement
Execution
Privilege Escalation
T1078.004 Cloud Accounts; T1098.005 Device Registration
Persistence
T1098.005 Device Registration; T1556.006 Multi-Factor Authentication
Credential Access
T1111 Multi-Factor Authentication Interception; T1528 Steal Application Access Token; T1606 Forge Web Credentials
lateral-movement
T1550.001 Application Access Token
Resource Development
Affected products and versions in Malware Abuses Windows Hello for Business Key to
- Microsoft — Windows Hello for Business (TPM-backed) / Microsoft Entra ID
Vulnerable versions: Entra-joined and hybrid-joined Windows devices using Windows Hello for Business with TPM-backed keys, current as of 2026-08-07
Remediation for Malware Abuses Windows Hello for Business Key to
Immediate actions
- Hunt Entra ID sign-in logs for Windows Hello for Business authentications with an empty Entra device ID (KQL: SigninLogs | where AuthenticationDetails has '"authenticationMethod":"Windows Hello for Business"' | where DeviceDetail.deviceId == ""), while accounting for legitimate incognito/non-SSO-browser false positives
- Alert on newly registered devices and newly added authentication methods (passkeys, additional WHFB keys) per user, especially when they follow a device-ID-less WHFB sign-in for that user
- Tighten Conditional Access so device-compliance/managed-device state is required in addition to authentication strength, since a fresh WebAuthn/FIDO2 assertion alone can satisfy phishing-resistant MFA requirements
- Prioritize endpoint detection/response on interactively signed-in sessions -- the technique requires no privilege escalation beyond existing code execution as the logged-in user, so session-level compromise is the actual control point
Workarounds
- Treat any interactively signed-in user session as capable of exercising that user's WHFB key; do not rely on WHFB/PIN/biometric prompting as evidence a session has not been compromised
- Where feasible, require managed/compliant-device Conditional Access in addition to authentication-method strength to blunt the device-registration bypass path
Longer-term hardening
- Deploy EDR/behavioral detection for anomalous calls into the NCrypt/CNG Passport Key Storage Provider (e.g. NCryptOpenKey) from non-standard or scripting-host processes, distinguishing them from expected Platform KSP PIN/biometric-prompted calls
- Monitor Primary Refresh Token issuance and renewal per device/user for anomalies such as a new device suddenly inheriting an existing user's PRT chain
- Enforce FIDO2 attestation on passkey/security-key registration where supported, since Mollema notes unattested registration paths (e.g. `roadtx registerpasskey`) are blocked by attestation enforcement
- Review Conditional Access and authentication-method policies tenant-wide for whether device registration and MFA-method enrollment are appropriately gated for high-privilege accounts
- Track Microsoft's response and any forthcoming guidance or mitigations for this class of cached Windows Hello ticket behavior
Timeline of Malware Abuses Windows Hello for Business Key to
- Ceri Coburn and Dirk-jan Mollema present 'Abusing Windows Hello Without a Severed Hand' at DEF CON 32, the foundational research into non-privileged abuse of Windows Hello for Business key signing operations, building on Benjamin Delpy's earlier mimikatz work exploring WHFB key operations.
- Hybrid Brothers publishes 'Detecting non-privileged Windows Hello abuse,' covering the Mollema/Coburn findings and early detection approaches for WHFB key abuse.
- Dirk-jan Mollema publishes 'Borrowing Windows Hello keys for authentication and persistence' on dirkjanm.io, detailing the WebAuthn/FIDO2-based technique that lets a borrowed WHFB key be used as a passkey from a separate attacker-controlled machine, including the user_handle derivation method and the device-registration/PRT-persistence follow-on.
- Follow-on reporting (GBHackers) confirms no CVE has been assigned to the technique as of this date.
- GBHackers News publishes corroborating coverage of the disclosure, including the fido_assertion.ps1 and hellopoc.ps1 PoC script names.
- The Hacker News publishes corroborating coverage, detailing the 90-day PRT renewal and device-registration persistence chain.
- Cyber Security News publishes coverage of the technique -- the source article ingested into this pipeline's hunt.
Sources cited for Malware Abuses Windows Hello for Business Key to
- Malware Abuses Windows Hello for Business Key to Authenticate Microsoft Entra ID
- Malware Can Abuse Windows Hello for Business Keys for Persistent Entra ID Access
- Windows Hello Key Abuse Lets Attackers Access Microsoft Entra ID Accounts
- Borrowing Windows Hello keys for authentication and persistence
- Windows Hello abuse - The sequel (Dirk-jan Mollema @ Ekoparty)
- ROADtools - Azure AD/Entra ID interaction framework
- Detecting non-privileged Windows Hello abuse
- DEF CON 32 - Abusing Windows Hello Without a Severed Hand (Ceri Coburn, Dirk-jan Mollema)
- MITRE ATT&CK T1606 - Forge Web Credentials
- MITRE ATT&CK T1098.005 - Account Manipulation: Device Registration
Threats related to Malware Abuses Windows Hello for Business Key to
- Pass-ta-key: Novel Attack Surface in Google Password Manager Synced Passkey Authentication
- BeyondTrust Microsoft Vulnerabilities Report 2026: Critical Flaws More Than Double as Elevation of Privilege Dominates (CVE-2025-55241, CVE-2025-62557, CVE-2025-62554)
- Dashlane Device-Registration API 2FA OTP Brute-Force Campaign — Encrypted Vaults of <20 Personal-Plan Accounts Exfiltrated (May–June 2026)
Detection coverage for TL-2026-1952
As of 2026-08-09, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-1952 across Splunk SPL, Microsoft KQL and Sigma, covering 11 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.