Start with Identity
SWI-T009 · Session and tokens

Primary Refresh Token theft

Code already running in a signed-in Windows session can drive the device's own Windows Hello key to obtain a Primary Refresh Token, no PIN prompt, no admin rights, no CVE required.

EmergingHard to detect to detect
First observed: 2020ATT&CK T1550.001

How it works

A Primary Refresh Token (PRT) is Microsoft Entra ID's device-level session credential, a specialized refresh token: once a Windows device registers with Entra ID, the PRT lets that device produce fresh tokens for the signed-in user without repeating full authentication each time, and it is designed to be long-lived and continuously renewed. Dirk-jan Mollema first published PRT extraction and reuse from a compromised Windows session in 2020, showing that a PRT and its session key, once pulled from LSASS or the TPM-backed key store, could be replayed to mint fresh tokens without triggering conditional access checks tied to the original device state.

A newer variant of the same underlying weakness, disclosed in 2026, does not require extracting anything: Mollema demonstrated that malware running as the logged-in user, with no administrator rights and no exploit, can quietly use the victim's TPM-bound Windows Hello for Business key to sign a WebAuthn-style authentication to Entra ID and obtain a brand-new PRT on demand. Windows keeps private key operations for that key available to any code running as the interactively signed-in user, so the TPM's protection against key extraction is irrelevant here: the malware never needs to extract the key, only to ask Windows to use it.

Mollema also found that Entra's WebAuthn challenge window is around five minutes and is not bound to the session, user, or tenant that requested it, so a challenge obtained on one host can be signed on another. The resulting signed assertion satisfies phishing-resistant authentication policy and can be used to register a new, attacker-controlled device and obtain its own PRT, valid for around 90 days and renewed automatically as long as it stays in use.

Why it works

The design assumption behind Windows Hello for Business is that the private key never leaves the TPM, which is true, and separately assumes that only the legitimate user, proven present by a PIN or biometric, can trigger a signature with it. The second assumption fails once malware is already running inside the signed-in session: Windows authorizes key operations based on which user session is asking, not on a fresh proof of physical presence for each request. A credential built to be phishing-resistant is not the same as a credential that resists local, in-session abuse, and Entra's unbound challenge window turns a same-host limitation into a cross-host one.

How to detect it

  • Windows Hello for Business sign-ins where the resulting token lacks a device ID claim, which the technique can produce when registering a new device.
  • WebAuthn challenges issued to one host and completed from a different one, where telemetry allows correlating the two.
  • New device registrations immediately following a PRT issuance for an account with no corresponding help desk or IT provisioning record.

Be honest about the limits: legitimate incognito or fresh-profile sessions can also produce sign-ins with an empty device ID, and Mollema's own writeup notes this overlap directly. This is not a clean signature; it needs to be combined with device compliance state and provisioning records to separate the two.

How to stop it

  • Enforce device compliance policies in conditional access so a newly registered, non-compliant device cannot obtain a usable PRT even after a valid signature.
  • Treat endpoint compromise as identity compromise. If malware can run as the signed-in user, no phishing-resistant credential on that device is safe from in-session abuse; endpoint detection matters as much as the credential choice.
  • Monitor PRT and device registration events for the empty-device-ID pattern and cross-reference against known provisioning workflows rather than treating it as benign noise.
  • Limit PRT lifetime and renewal windows where the platform allows configuration, so a hijacked persistence chain has a shorter useful life.
  • Watch for post-registration privilege changes, since the attacker's goal after establishing a PRT is typically to add further authentication methods or expand access while the reset window has already closed.

Seen in the wild

Sources

Last reviewed By SWI Community TeamSuggest a correctionHow we research
Seeing this technique used differently, or have a detection rule that works better? Email [email protected]. See all briefs in the technique catalog, or volunteer as a CVE Analyst.
Mapped to MITRE ATT&CK where a technique ID exists. Independent, community-driven analysis, not a substitute for the ATT&CK knowledge base. See the disclaimer.