SOP-96: Primary Refresh Token (PRT) Theft & Token Replay Response | CyberHawk Threat Intel

A stolen PRT is not killed by a password reset. It must be neutralised by revoking the user's refresh tokens (revokeSignInSessions) AND disabling/re-registering the leaking device so its device key can no longer sign PRT requests. Reset-only responses leave the attacker's session live.

PRT theft is the "why did MFA not fire?" answer to an impossible-travel alert on a managed device. If a Conditional Access impossible-travel or unfamiliar-location sign-in shows the session as already MFA-satisfied from a compliant device, suspect a replayed PRT before you write it off as a VPN quirk.

Five yes/no questions decide whether this jumps the queue. Any single YES on Q1–Q3 makes it live-incident SEV1 — a stolen PRT is actively usable and every minute of dwell buys the attacker more federated-app reach.

Do not downgrade on "the device is compliant." Compliant/managed device is exactly what a replayed PRT looks like — the device identity is the victim's; only the network origin and behaviour betray the attacker.

The most direct theft path: with SYSTEM/admin, an attacker reads the PRT and its derived session keys straight out of the CloudAP plug-in inside LSASS. Any non-security process opening a handle to lsass.exe, or a Mimikatz cloudap/dpapi::cloudapkd command line, is a confirmed key-theft attempt.

• 1Open Hunting → Advanced Hunting and paste the KQL below. Set Time range to Last 24 hours.
• 2For each hit, open the Device Timeline from the DeviceName link and confirm the initiating process and the account that ran it.
• 3Note the DeviceName, AccountName, and timestamp — this is the leaking endpoint and the compromised identity for Containment.
• 4Pivot to Incidents & alerts and check for a co-incident "Possible credential theft from LSASS" or Mimikatz detection.

On TPM-backed devices the raw keys cannot be exported off-box, so attackers pivot to I2 (BrowserCore cookie minting) instead — they mint tokens while on the machine. Absence of an LSASS hit does not clear the host; check I2 next.

BrowserCore.exe is the legitimate local broker that hands the browser a signed PRT cookie (x-ms-RefreshTokenCredential). Tools such as ROADtoken and requestaadrefreshtoken drive it directly to mint a fresh cookie the attacker can replay — no LSASS memory read required, so it evades TPM protection. A BrowserCore.exe launched by cmd/powershell/rundll32 rather than the browser is the tell.

• 1Run the KQL below and inspect InitiatingProcessFileName — a browser parent (msedge/chrome) is normal; a shell or unknown parent is suspicious.
• 2Check the command line for a nonce argument or piped JSON request — ROADtoken/requestaadrefreshtoken pass a server nonce to sign the cookie.
• 3Correlate the timestamp with any I3 sign-in from a new IP within minutes — a mint immediately followed by an off-host replay is a confirmed chain.
• 4Hunt for the tool binaries themselves (ROADtoken.exe, roadtx, AADInternals import) in the same session.

This is the payoff signal. When the stolen PRT is replayed, the sign-in carries the victim's device identity (managed / Entra-joined / compliant) but originates from the attacker's IP, ASN and geo. Because the MFA claim rides inside the PRT, the sign-in shows strong auth as already satisfied — an impossible-travel event with no MFA prompt on a "trusted" device is the classic Pass-the-PRT footprint.

• 1Open the user's Sign-in logs and add columns for Device / Managed, Location, IP address, and Authentication requirement.
• 2Look for the same DeviceId / DeviceName appearing from two irreconcilable locations inside a short window, with MFA shown as previously satisfied.
• 3Run the KQL below in Sentinel to auto-surface trusted-device sign-ins from a new IP/country against the device's baseline.
• 4Record the attacker IP, ASN, user agent, and the DeviceDetail.deviceId — these feed the IOC list (I6) and Containment blocks.

The device identity being "yours" is not exculpatory — it is the whole point of Pass-the-PRT. Correlate on network origin and behaviour (I4/I5), never on device trust alone.

Entra ID Protection scores token characteristics and flags anomalousToken when a token's lifetime or replay pattern is unusual, and tokenIssuerAnomaly when issuer claims don't match. When the leaking endpoint is unmanaged (no MDE telemetry), these risk detections are frequently the only signal a replay happened — treat them as first-class evidence, not background noise.

• 1Open Risk detections and filter Detection type to Anomalous Token and Token Issuer Anomaly.
• 2For the flagged user, open Risky users → [user] → Recent risk detections and note the linked sign-in and correlationId.
• 3Pivot each detection to its sign-in and cross-check against I3 (new IP/device mismatch) and I5 (non-interactive replay).
• 4Run the KQL below to join risk events to their sign-ins in Sentinel for a full picture.

Once a PRT yields access/refresh tokens, the attacker's follow-on calls to Graph, Exchange, and SharePoint are non-interactive — they never re-authenticate, so the activity lands in AADNonInteractiveUserSignInLogs and CloudAppEvents, not the interactive sign-in blade. A burst of non-interactive token use from a new ASN, or sudden mailbox/file access right after I3, confirms the session is being actively used.

• 1Switch the Sign-in logs tab to Non-interactive user sign-ins and filter to the affected UPN.
• 2Look for token use from the attacker IP/ASN identified in I3, targeting Microsoft Graph, Office 365 Exchange Online, or SharePoint.
• 3Pivot to CloudAppEvents to see the actual actions taken (mail read, file download, inbox-rule creation) from that session.
• 4Any inbox-rule or OAuth-grant follow-on means the compromise is expanding — cross-reference SOP-85 (mailbox rules) and SOP-21 (OAuth consent).

Refresh tokens minted from a PRT are long-lived (default ~90 days of sliding activity). Hunt back at least 7–14 days, not just the alert hour — the initial replay may predate the alert that finally tripped I4.

Before Containment, consolidate the artifacts and make an explicit call. PRT theft has a real false-positive edge (roaming, VPN egress, authorised red-team) — but "probably the user travelled" is a hypothesis, not a verdict. Confirm with a record that names the user, device, origin and window.

If any I1/I2 endpoint artifact OR an I3 replay to a privileged account is present, declare TP and go straight to Containment. Do not wait for all six indicators to line up — a live PRT is being spent while you deliberate.

Order matters: revoke tokens (C3) BEFORE or alongside device isolation. Isolating the host stops new mints but does not kill tokens already exfiltrated — those die only on refresh-token revocation.

• 1Before isolation, start a Live Response session and collect a memory image + running-process list — CloudAP state and tooling are volatile.
• 2Click Actions (⋮) → Isolate Device and choose Full Isolation to cut the host off from further token minting.
• 3Collect the investigation package (Actions → Collect investigation package) for offline forensics.
• 4Query other devices in the same subnet/user scope for the same I1/I2 activity — PRT theft is often part of a broader hands-on-keyboard intrusion.

Do not power off the endpoint — CloudAP keys and the attacker's in-memory tooling are lost on shutdown. Network isolation preserves the memory-resident evidence.

• 1Revoke all refresh tokens — user profile → Revoke sessions (or Graph POST /users/{id}/revokeSignInSessions). This invalidates every token minted from the PRT.
• 2Reset the user's password and require change at next sign-in — needed to stop re-authentication, but on its own it does NOT kill the PRT (revocation in step 1 does).
• 3Block sign-in temporarily (Account enabled = No) for privileged accounts until the device is cleared.
• 4Re-evaluate MFA methods — confirm no attacker-registered method was added post-replay (Authentication methods blade); remove any rogue method and cross-reference SOP-80.
• 5Confirm the user as compromised in ID Protection so risk-based Conditional Access enforces re-auth on next attempt.

Graph one-liner to revoke: Invoke-MgInvalidateUserRefreshToken -UserId <UPN> (or the REST revokeSignInSessions action). Verify the response is true before moving on.

• 1Disable the compromised device object in Entra — this stops its device key from signing new PRT requests. Plan a full re-registration/re-image before re-enabling.
• 2Block the attacker IP/ASN via a Conditional Access named location (block policy) and add it as an MDE network indicator (Settings → Endpoints → Indicators → IP addresses).
• 3Tighten Conditional Access for the user: require compliant device + phishing-resistant MFA, and enable token protection (bind sessions to the device) where licensed.
• 4For any app the attacker touched (I5), review and revoke suspicious OAuth grants (Enterprise applications → Permissions) — cross-reference SOP-21.

• All refresh tokens revoked and password reset confirmed (C3 response = true)
• Leaking device disabled and re-imaged/re-registered; device object re-enabled only after rebuild
• Attacker IP/ASN blocked in Conditional Access and MDE indicators
• No rogue MFA method, inbox rule, or OAuth grant remains on the account
• I1/I2/I3/I5 queries return 0 hits over the incident window
• Timeline reconstructed: extraction/mint → first replay → post-access actions
• Token protection / Credential Guard / RunAsPPL enforced to prevent recurrence

Do not close on a password reset alone. Until refresh tokens are revoked and the device key is invalidated (disable + rebuild), the attacker's replayed session and any long-lived refresh tokens remain valid.

A single confirmed replay to a Global Admin or PIM-eligible account is a potential tenant-takeover — escalate straight to IR + CISO regardless of how few sign-in events appear. One replayed privileged token is enough.