# Malware Abuses Windows Hello for Business Key to Authenticate to Microsoft Entra ID

> 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.

- **Published:** 2026-08-09T00:00:00Z
- **Last reviewed:** 2026-08-09T00:00:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-1952
- **ID:** TL-2026-1952
- **Severity:** HIGH
- **Category:** VULNERABILITY
- **Status:** ACTIVE
- **Detections:** 9 · **IOCs:** 11 (full data via the Threadlinqs MCP server — Purple tier)

## Description

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

- T1588.002 Tool
- T1059.001 PowerShell
- T1098.005 Device Registration
- T1556.006 Multi-Factor Authentication
- T1078.004 Cloud Accounts
- T1098.005 Device Registration
- T1550.001 Application Access Token
- T1111 Multi-Factor Authentication Interception
- T1528 Steal Application Access Token
- T1606 Forge Web Credentials
- T1021.007 Cloud Services

## Sources

- [Malware Abuses Windows Hello for Business Key to Authenticate Microsoft Entra ID](https://cybersecuritynews.com/malware-abuses-windows-hello-key/)
- [Malware Can Abuse Windows Hello for Business Keys for Persistent Entra ID Access](https://thehackernews.com/2026/08/malware-can-abuse-windows-hello-for.html)
- [Windows Hello Key Abuse Lets Attackers Access Microsoft Entra ID Accounts](https://gbhackers.com/windows-hello-key-abuse/)
- [Borrowing Windows Hello keys for authentication and persistence](https://dirkjanm.io/borrowing-windows-hello-keys/)
- [Windows Hello abuse - The sequel (Dirk-jan Mollema @ Ekoparty)](https://dirkjanm.io/assets/raw/Windows%20Hello%20abuse%20the%20sequel.pdf)
- [ROADtools - Azure AD/Entra ID interaction framework](https://github.com/dirkjanm/ROADtools)
- [Detecting non-privileged Windows Hello abuse](https://hybridbrothers.com/detecting-non-privileged-windows-hello-abuse/)
- [DEF CON 32 - Abusing Windows Hello Without a Severed Hand (Ceri Coburn, Dirk-jan Mollema)](https://www.youtube.com/watch?v=mFJ-NUnFBac)
- [MITRE ATT&CK T1606 - Forge Web Credentials](https://attack.mitre.org/techniques/T1606/)
- [MITRE ATT&CK T1098.005 - Account Manipulation: Device Registration](https://attack.mitre.org/techniques/T1098/005/)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-1952