Windows Hello for Business Key Abuse: Defending Against Malware-Driven Persistent Entra ID Access

Introduction

Entra ID security researcher Dirk-jan Mollema has demonstrated a technique that should concern every organization running a hybrid or cloud-joined Windows estate: malware already executing inside an authenticated Windows session can silently leverage the victim's Windows Hello for Business (WHfB) key material to authenticate to Microsoft Entra ID. No credential theft, no phishing, no password spray — the attacker rides the cryptographic identity the operating system already trusts.

The downstream impact is significant. Once the attacker authenticates with the WHfB key, they can register a device under their control to the tenant, obtain a Primary Refresh Token (PRT), and — where tenant policy permits — add additional authentication methods to maintain durable, phishing-resistant-looking access. This converts a transient malware foothold into long-term cloud persistence that survives password resets and, in many configurations, even MFA re-prompts.

This is not a software vulnerability with a patch. It is an abuse of legitimate Entra ID device identity architecture, which means the defensive burden falls squarely on configuration hygiene, Conditional Access enforcement, and detection engineering. Identity is the perimeter here, and the perimeter just moved into your TPM.

Technical Analysis

Affected Components

Platform: Windows 10/11 devices that are Entra-joined or hybrid-joined with WHfB provisioned
Identity stack: Microsoft Entra ID device registration service, Cloud Authentication Provider (CloudAP), PRT issuance flow
Key material: WHfB asymmetric keys (TPM-backed or software-backed), the device certificate chain (MS-Organization-Access), and NGC (Next Generation Credentials) containers
Tenant controls implicated: Device registration settings, Conditional Access token protection, and authentication method policy

How the Attack Works

Initial foothold: Malware executes in the context of a signed-in user on a WHfB-provisioned device. Administrative rights are not strictly required for the core key-usage abuse — the key is usable from the user's own session because WHfB is designed for silent, non-interactive authentication.
Silent authentication: The malicious process invokes the same OS components (CloudAP, the AAD Broker Plugin) that legitimate apps use to request tokens. It presents a proof-of-possession signature from the WHfB private key to Entra ID. From the token service's perspective, this is a compliant, phishing-resistant sign-in.
Device registration: With a valid user token, the attacker registers a new device object it controls into the tenant. If the tenant allows users to register/join devices without strong additional controls, this succeeds silently. dsregcmd.exe or direct calls to the Device Registration Service endpoints are the typical mechanisms.
PRT acquisition: The attacker-controlled device receives a PRT — the crown jewel. A PRT is a long-lived refresh artifact bound to user + device, enabling continuous token minting for cloud resources.
Persistence hardening: Where authentication method policy permits, the attacker adds methods (e.g., new FIDO2 keys, phone sign-in, authenticator app bindings) to the victim account, cementing access that survives incident response actions targeting only passwords or sessions.

Exploitation Status

This is a publicly demonstrated research technique by a recognized authority in Entra ID offensive tooling (the author of ROADrecon/AADInternals-adjacent research lineage). There is no CVE assigned — this is architectural abuse, not a patched bug. While widespread in-the-wild campaigns have not been confirmed at time of writing, the technique is fully reproducible and requires no zero-day. Organizations should assume red teams and sophisticated intrusion sets will operationalize it immediately, if they have not already.

Detection & Response

The detection surface here spans endpoint (registration tooling, NGC key store access) and identity telemetry (device registration, PRT issuance, security info changes). The highest-fidelity signal is the correlation of a device registration event with a security info registration event in a short window from the same user — that sequence is rarely legitimate outside of controlled onboarding.

YAML

---
title: Device Registration Tool Execution with Join Parameters
id: 3f8a2c14-7b9d-4e61-a5c2-9d1e4f6a8b3c
status: experimental
description: Detects execution of dsregcmd.exe with join or debug parameters, which can indicate interactive or malware-driven device registration into Microsoft Entra ID outside of standard provisioning flows such as Autopilot.
references:
  - https://thehackernews.com/2026/08/malware-can-abuse-windows-hello-for.html
  - https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.persistence
  - attack.t1078.004
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    Image|endswith: '\dsregcmd.exe'
  selection_args:
    CommandLine|contains:
      - '/join'
      - '/debug'
      - '/leave'
  condition: selection_img and selection_args
falsepositives:
  - Autopilot provisioning and IT-driven device re-registration
  - Helpdesk troubleshooting with /debug
level: high
---
title: Non-System Process Accessing NGC Key Container Storage
id: 9c4e7b21-3a6f-4d58-b2e1-7f5a9c3d8e42
status: experimental
description: Detects user-context or non-system processes accessing the Next Generation Credentials (NGC) store used by Windows Hello for Business. Legitimate access is performed by system services (lsass, svchost, NgcSvc); direct access from other processes may indicate WHfB key material abuse for silent Entra ID authentication.
references:
  - https://thehackernews.com/2026/08/malware-can-abuse-windows-hello-for.html
  - https://attack.mitre.org/techniques/T1552/
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.credential_access
  - attack.t1552.004
logsource:
  category: file_event
  product: windows
detection:
  selection:
    TargetFilename|contains:
      - '\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc\'
      - '\Microsoft\Crypto\Keys\'
  filter_system:
    Image|endswith:
      - '\svchost.exe'
      - '\lsass.exe'
      - '\NgcCtnrSvc.exe'
      - '\wbengine.exe'
  condition: selection and not filter_system
falsepositives:
  - EDR and backup agents reading the Ngc directory (tune by Image hash)
level: high

KQL — Microsoft Sentinel / Defender

// Correlate device registration with authentication method changes — the persistence signature
let window = 4h;
let DeviceReg = AuditLogs
| where OperationName in ("Add device", "Register device", "Add registered owner to device")
| extend UserUpn = tostring(InitiatedBy.user.userPrincipalName)
| extend RegTime = TimeGenerated
| extend DeviceName = tostring(TargetResources[0].displayName)
| project UserUpn, RegTime, DeviceName, CorrelationId;
let SecInfo = AuditLogs
| where OperationName has_any ("User registered security info", "User started security info registration")
| extend UserUpn = tostring(TargetResources[0].userPrincipalName)
| extend SecInfoTime = TimeGenerated
| project UserUpn, SecInfoTime, OperationName;
DeviceReg
| join kind=inner SecInfo on UserUpn
| where abs(datetime_diff('second', SecInfoTime, RegTime)) < tolong(window / 1s)
| project UserUpn, RegTime, DeviceName, SecInfoTime, OperationName, CorrelationId
| order by RegTime desc;

// Hunt PRT issuance to newly registered devices in Entra sign-in telemetry
SigninLogs
| where TimeGenerated > ago(7d)
| where AuthenticationRequirement == "multiFactorAuthentication"
| extend DeviceId = tostring(DeviceDetail.deviceId)
| extend DeviceDisplay = tostring(DeviceDetail.displayName)
| join kind=inner (
    AuditLogs
    | where OperationName == "Add device"
    | extend NewDevice = tostring(TargetResources[0].displayName)
    | extend RegTime = TimeGenerated
    | project NewDevice, RegTime
) on $left.DeviceDisplay == $right.NewDevice
| where TimeGenerated between (RegTime .. RegTime + 1d)
| project TimeGenerated, UserPrincipalName, DeviceDisplay, IPAddress, AppDisplayName, RegTime;

VQL — Velociraptor

-- Hunt for device registration tooling and AAD broker activity in unexpected contexts
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)dsregcmd.*(join|debug|leave)'
   OR Name =~ '(?i)dsregcmd'

-- Enumerate NGC key container artifacts for timeline analysis
SELECT FullPath, Size, Mtime, Btime
FROM glob(globs='C:/Windows/ServiceProfiles/LocalService/AppData/Local/Microsoft/Ngc/**')
ORDER BY Btime DESC

PowerShell

# WHfB / Entra ID device registration audit — run on suspect endpoints and against the tenant

# 1. Local device join state and PRT status
Write-Host '=== Device Join Status ===' -ForegroundColor Cyan
dsregcmd /status | Select-String -Pattern 'AzureAdJoined|DeviceId|AzureAdPrt|AzureAdPrtUpdateTime|KeyProvider'

# 2. Check for device certificates (MS-Organization-Access) issued recently
Write-Host '=== Device Certificates ===' -ForegroundColor Cyan
Get-ChildItem Cert:\LocalMachine\My | Where-Object {
    $_.Issuer -match 'MS-Organization-Access' -and $_.NotBefore -gt (Get-Date).AddDays(-30)
} | Select-Object Subject, Issuer, NotBefore, Thumbprint | Format-List

# 3. Review recent device registrations in the tenant (requires Microsoft.Graph)
# Connect-MgGraph -Scopes 'Device.Read.All','AuditLog.Read.All'
Write-Host '=== Recent Tenant Device Registrations ===' -ForegroundColor Cyan
Get-MgDevice -All | Where-Object {
    $_.CreatedDateTime -gt (Get-Date).AddDays(-14)
} | Select-Object DisplayName, DeviceId, CreatedDateTime, TrustType, OperatingSystem | Format-Table -AutoSize

# 4. Recent security info registration events (persistence indicator)
Write-Host '=== Recent Security Info Registrations ===' -ForegroundColor Cyan
Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'User registered security info'" -Top 50 |
  Select-Object ActivityDateTime, @{N='User';E={$_.TargetResources[0].UserPrincipalName}}, Result |
  Format-Table -AutoSize

# 5. Verify Conditional Access token protection policy exists for PRT protection
Write-Host '=== Token Protection CA Policies ===' -ForegroundColor Cyan
Get-MgIdentityConditionalAccessPolicy | Where-Object {
    $_.State -eq 'enabled'
} | Select-Object DisplayName, State | Format-Table -AutoSize
Write-Host 'Manually verify at least one enabled policy includes tokenProtection in session controls.' -ForegroundColor Yellow

Remediation

There is no patch — remediation is architectural and policy-driven. Prioritize in this order:

Enable Conditional Access token protection. Microsoft's token protection in Conditional Access cryptographically binds tokens — including PRTs — to the device they were issued to, directly blunting token replay and exfiltration abuse. Reference: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-token-protection
Require MFA for device registration and join. In the Entra portal under Devices > Device Settings, enable 'Require multifactor authentication to register or join devices' and set 'Maximum number of devices per user' to the minimum your operation tolerates (typically 1–3). If users have no business need to register devices, set 'Users may register their devices' to None.
Harden authentication method policy. Alert on and restrict who can register FIDO2 keys, Temporary Access Passes, and Authenticator bindings. Attackers adding a method post-compromise is the persistence choke point — treat every security info registration as a reviewable security event.
Deploy the detection content above. The device registration + security info correlation query is your highest-value hunt. Pipe AuditLogs into Sentinel if you have not already; without identity telemetry in the SIEM, this technique is nearly invisible.
Endpoint hardening. Enforce Credential Guard and TPM attestation where hardware supports it (TPM-backed WHfB keys raise the bar versus software keys), keep tamper protection enabled, and ensure dsregcmd /join outside provisioning windows triggers investigation.
Incident response playbook update. If you suspect this technique was used: revoke all refresh tokens for the user (Revoke-MgUserSignInSession), review and delete attacker-registered device objects in Entra ID, audit and remove unauthorized authentication methods, re-provision WHfB credentials (dsregcmd /leave and rejoin on the endpoint if the device itself is untrusted), and review all PRT-issued sessions during the exposure window.

The lesson for defenders: WHfB's phishing resistance protects the authentication ceremony, not the identity lifecycle. If your tenant lets any authenticated user mint a new trusted device and bolt on new authentication methods without friction, a single malware foothold becomes an identity takeover. Close the policy gaps now — the tooling to abuse them is public.

Related Resources

Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub