Primary Refresh Token Theft on Entra-Joined Windows: The SSO Cookie Attackers Love

How attackers steal the PRT from Entra-joined Windows devices to bypass MFA, and the endpoint posture that shuts the attack down.

Your organization rolled out phishing-resistant MFA, conditional access, and device compliance. Then a laptop gets popped, and within an hour the attacker is reading the user's mailbox from an IP you've never seen — without ever being prompted for MFA. The culprit is almost always the same: a stolen Primary Refresh Token (PRT). It's the single most valuable credential on a modern Entra-joined Windows endpoint, and most defenders have never looked at where it lives.

What the PRT actually is

When a Windows device is Entra-joined (formerly Azure AD joined) or hybrid-joined, it registers a device key and, at each interactive logon, obtains a Primary Refresh Token from Entra ID. The PRT is a long-lived (typically 14-day, rolling) token that underpins single sign-on across every browser and app on the box. Present a valid PRT and you get access tokens for Microsoft 365, Azure, and any app federated to Entra — MFA already satisfied, because MFA state is baked into the PRT at issuance.

That's the whole problem in one sentence: a PRT is a bearer token that represents an already-authenticated, already-MFA'd user. Steal it and you inherit the session. It is functionally the cloud-era equivalent of a Kerberos TGT.

How attackers steal it

The PRT never sits in plaintext on disk — it's protected by the device transport key, which is bound to the TPM when one is present. But an attacker with the right foothold has several paths:

Local admin / SYSTEM abuse of the CloudAP plugin. Tools in the Mimikatz/ROADtools family call the same CloudAP interfaces LSASS uses to request a PRT-cookie. If the transport key is software-protected (no TPM), the key material can be exported outright.
TPM-bound key proxying. When a TPM protects the key, the raw PRT can't leave — but an attacker running as the user can still ask the local BrowserCore.exe / token broker to mint a fresh x-ms-RefreshTokenCredential PRT-cookie and exfiltrate that, replaying it from their own machine.
Browser session cookie theft. The related ESTSAUTH / ESTSAUTHPERSISTENT cookies and the PRT-cookie injected into browser requests are lootable from a hijacked user session — the post-MFA attack we covered in browser cookie and token theft.

In every case the prerequisite is code execution on the endpoint — usually local admin or SYSTEM. That's the pivot point defenders can actually control.

Why cloud-side controls don't save you

Conditional access evaluates the token, not the machine it was replayed from. A stolen PRT replayed over a residential proxy in the right country, from a "compliant" device claim, sails straight through. Token Protection (a.k.a. token binding) helps by cryptographically binding some tokens to the device, but coverage is still partial across apps and requires modern clients. The durable fix is to stop the theft at the source: the endpoint's posture.

The endpoint posture that shuts it down

PRT theft is an endpoint-hardening problem wearing a cloud-identity costume. The controls that matter are all local:

TPM present and used. A TPM 2.0 makes the transport and device keys non-exportable, downgrading full PRT theft to (harder, noisier) live-session proxying. Verify the device actually bound its keys to the TPM rather than falling back to software.
Credential Guard enabled. Virtualization-based isolation of LSASS blocks the classic memory-scraping route into CloudAP secrets.
No standing local admin. Every PRT-theft technique needs privileged execution. Least privilege plus LAPS-rotated local admin passwords removes the launchpad.
LSASS hardening (RunAsPPL) and ASR rules that block credential-stealing tooling from touching LSASS and the token broker.
Sysmon / process-lineage telemetry to catch BrowserCore.exe, dsregcmd, or unsigned binaries requesting PRT-cookies from unexpected parents.

You can eyeball the device's join and key state quickly:

dsregcmd /status
# Look for: AzureAdJoined : YES, TpmProtected : YES,
#           and a healthy DeviceAuthStatus. TpmProtected : NO
#           means the transport key is software-protected — exportable.

Where WinSentinel fits

The trouble with the list above is that it spans five different subsystems, and any one regressing quietly re-opens the door. WinSentinel audits all of them as part of its 33 modules — TPM binding, Credential Guard, LSASS protection, local admin sprawl, ASR coverage, and endpoint telemetry — and rolls the result into a single posture score, free, with no limits, on any one machine. Run it on your own workstation and you'll see exactly which of these PRT-theft preconditions are currently true.

For organizations running fleets, the same checks become an ongoing control. WinSentinel Pro's central node collects each endpoint's PRT-relevant posture, rolls it into compliance reporting, and fires a drift alert the moment a machine loses TPM binding, has Credential Guard disabled, or sprouts a new local admin — the exact regressions that turn one compromised laptop into a tenant-wide identity breach.

Phishing-resistant MFA raises the cost of the front door. PRT theft is the attacker walking in through the endpoint and picking up a key that says the door was already opened. Harden the endpoint, and the stolen key stops working.

If you've invested in Entra conditional access, spend the next hour on the machines that hold the PRTs. That's where this attack is won or lost.