Skip to content
Start with Identity
Join free
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
First observed: 2020ATT&CK T1550.001 ↗ATT&CK T1098.005 ↗

How it works

A Primary Refresh Token (PRT) is the device-level single sign-on credential in Microsoft Entra ID. Windows issues it at sign-in on an Entra joined, hybrid joined or registered device, and the Web Account Manager uses it to mint access and refresh tokens for Outlook, Teams, SharePoint and browser sessions without asking the user again. Microsoft documents that a PRT is valid for 90 days, is renewed every four hours while the device is in use, and carries the device and MFA claims that Conditional Access evaluates. Conditional Access is not evaluated when a PRT is issued or renewed. Holding a usable PRT means holding the user's whole Microsoft 365 session.

Microsoft protects the PRT by binding it to the device. At registration the device creates a device key and a transport key, kept in the TPM where one exists. Entra returns a session key encrypted to the transport key, and every PRT request must be signed with that session key, which Microsoft calls the proof-of-possession key. Attacks on the PRT therefore aim either to use the keys from inside the device or to get a new PRT for a device the attacker controls. Three public routes exist:

  1. Ask for a PRT cookie as the user (2020). Dirk-jan Mollema showed that code running in the user's session could call the same component browsers use (BrowserCore.exe) and receive a signed PRT cookie, the x-ms-RefreshTokenCredential header, then trade it for refresh tokens elsewhere. He stressed that "this can all be done from the context of the user, thus without requiring admin access."
  2. Extract the PRT and session key (2020). With Benjamin Delpy, Mollema extended Mimikatz to pull the PRT and key material from LSASS with administrator rights. Even with a TPM, the derived signing key was present in LSASS memory, so the PRT could be reused on another machine.
  3. Mint a new PRT from a borrowed Windows Hello key (2026). Mollema showed that malware in a signed-in session can make Windows sign with the user's TPM-bound Windows Hello for Business key, because "the WHFB key is a user key, so we do not need Administrator rights to access it." The attacker requests an Entra WebAuthn challenge, which is valid for five minutes and "not bound to a session, a user or even a tenant", has the victim's machine sign it, and redeems the assertion from their own host. The resulting tokens lack a device ID claim, so they can register a new attacker-controlled device, which then obtains its own 90-day PRT. Because a Windows Hello sign-in counts as fresh MFA, the attacker can also add passkeys or Hello keys as backdoors. Mollema notes Microsoft fixed earlier issues he reported, but left this technique as-is.

A fourth route skips the endpoint entirely. Microsoft reported in February 2025 that Storm-2372 used device code phishing with the Microsoft Authentication Broker client ID, used the refresh token to register an actor-controlled device in Entra ID, and with that device identity was "able to obtain a Primary Refresh Token (PRT) and access an organization's resources."

Why it works

Windows Hello for Business and the TPM are built on the assumption that a key that cannot leave the hardware cannot be misused. The first half is true. The second fails once malware runs inside the user's session, because Windows authorizes key use by which session is asking, not by a fresh proof of presence for each signature. A phishing-resistant MFA credential is not the same as one that resists local, in-session abuse. Entra's unbound WebAuthn challenge then turns a same-host problem into a cross-host one, and device registration turns a five-minute assertion into 90 days of renewable access.

The PRT also concentrates trust. It carries the MFA and device claims that downstream policy relies on, so stealing one inherits a compliant-looking session, and the Storm-2372 route shows that a single phished refresh token can be converted into one. That route is a talk-past attack: the user approved real access on a real Microsoft page.

How to detect it

  • Entra ID Protection attemptedPrtAccess. "Possible attempt to access Primary Refresh Token (PRT)" uses Microsoft Defender for Endpoint telemetry, moves the user to high risk and only fires where MDE is deployed. It is calculated offline.
  • Windows Hello sign-ins with no device. Mollema's query filters SigninLogs for AuthenticationDetails containing "authenticationMethod":"Windows Hello for Business" with an empty DeviceDetail.deviceId. A refined version from Fabian Bader also requires ResultType == 0, CrossTenantAccessType == "none", a single-entry AuthenticationDetails array and an empty AuthenticationContextClassReferences.
  • New device registrations. Microsoft's Storm-2372 guidance hunts CloudAppEvents where AccountDisplayName == "Device Registration Service" and recommends alerting on token or PRT activity near a registration. Huntress's 2026 replay campaign registered 48 rogue devices named DESKTOP- plus eight hex characters.
  • New authentication methods. suspiciousCredentialAddition fires in real time when a method is added under suspicious circumstances.
  • Endpoint telemetry. The public tools call BrowserCore.exe or open the Hello key with NCryptOpenKey from PowerShell; script-driven use of either is worth an EDR rule.

Be honest about the limits: Mollema says the basic query catches many benign sign-ins (browser SSO, which supplies the device, does not apply in InPrivate or incognito sessions), and filtering on the device registration resource lowers noise but is easy to sidestep. Users join devices legitimately, too. Correlate with provisioning records and endpoint alerts.

How to stop it

  1. Treat endpoint compromise as identity compromise. Every route except Storm-2372's needs code in the user's session. Mollema's 2020 advice still holds: do not give users local admin.
  2. Restrict who can register or join devices. Limit device join to named groups, use enrollment restrictions as Microsoft recommends for Storm-2372, and apply a Conditional Access policy on the Register or join devices user action. Requiring MFA for that action does not stop the Hello route, since the borrowed key counts as MFA.
  3. Require compliant devices and Token Protection. Policies that demand a compliant or hybrid joined device stop a freshly registered, unmanaged device from using its PRT. Token Protection enforces device-bound sessions for supported native apps; pair it with blocking unknown platforms.
  4. Revoke properly. Disabling or deleting the device invalidates its PRT, but Mollema notes refresh tokens already obtained stay valid until revoked. Disable the device, revoke the user's sessions, and remove any methods the attacker added. A password change only invalidates PRTs obtained with the password.
  5. Use sign-in frequency for sensitive apps so a stolen PRT must re-authenticate interactively sooner than 90 days.

Seen in the wild

No incident in our Identity Breach Database is attributed to PRT theft. The closest record is the Microsoft 365 token replay into 79 organizations (2026), where the actor registered rogue Entra devices, though Huntress does not say PRTs were obtained.

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 community@startwithidentity.com. 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.