STOLEN TOKENS, NOT STOLEN PASSWORDS: Why Token Protection Is the Third Zero Trust Pillar in Microsoft Entra ID

"Modern identity compromises don’t bypass MFA. They reuse what MFA already granted.”

This is not theoretical. In the 2024–2025 threat landscape, the costliest attacks against Microsoft 365 tenants didn’t bypass Multi-Factor Authentication (MFA); they bypassed the need for it by stealing the tokens MFA had already issued.

An attacker doesn’t need your password or your second factor. They only need to land on a Windows endpoint, escalate privileges, extract a cryptographically-bound credential from memory, and replay it from any internet-connected machine on Earth. MFA becomes irrelevant because the token proves authentication already happened.

What follows is a deep technical breakdown of how enterprises unconsciously created this vulnerability — and why the industry has treated the fix as optional for far too long.

The Architecture Trap: Login-Centric Trust

Most organizations have crystallized their Zero Trust thinking around a single moment: the login event. The mental model is reflexive:

User → MFA Passed → Token Issued → Trust Frozen Until Expiry

Everything operationally reinforces this: Conditional Access policies evaluate the login moment. Risk-based signals feed the login decision. Session controls manage post-login behavior. But once that token is in hand — whether it’s a Primary Refresh Token (PRT) valid for 90 days or a Bearer Access Token living 28 hours in Continuous Access Evaluation (CAE) — the architecture assumes the token is effectively trustworthy.

The perimeter shifted from “the network” to “the token,” but the vulnerability remained: a token is still just a string. If an attacker possesses the string, they use it exactly like the legitimate owner would.

NIST SP 800–207 calls this the implicit trust zone problem. In the Zero Trust framework, the Policy Engine (PE) makes the decision “should I issue a token?”, and the Policy Administrator (PA) executes that decision. But neither explicitly binds the token to where it came from. That binding — the third pillar — is left to implicit assumptions about security posture. Those assumptions collapse when an attacker has privileged access to the endpoint itself.

Why This Matters Now: The Dwell Time Problem

In modern incident response timelines, the gap between token theft and detection has narrowed but not disappeared. Consider the mechanics:

1. Attacker lands on endpoint (phishing, supply chain malware, lateral movement): ~Minutes to Hours
2. Attacker escalates to Admin/SYSTEM: Immediate (if LSASS injection succeeds)
3. Attacker extracts PRT + derived keys from LSASS (using tools like Mimikatz with cloudap modules): Seconds
4. Attacker replays token from attacker infrastructure: Immediate
5. Attacker requests new access tokens using stolen PRT: Immediate
6. SOC Detection: 5–15 minutes (if CAE is enabled), 24+ hours (if not)

The window where an attacker operates undetected using valid credentials is real and often exceeds the time needed to compromise sensitive resources — send a payment directive, bulk-export email, modify permissions, or establish persistence via App Registration.

Token Protection collapses this window by making Step 5 fail outright: the stolen token cannot be used off the original device, regardless of how legitimate the token signature appears.

PRT 101: Why Tokens Became the New Perimeter

When a Windows 10/11 device is Entra-joined or Hybrid-joined, Entra ID issues a Primary Refresh Token (PRT) after successful user sign-in. Conceptually, the PRT is a structured credential:

PRT {
  "user_identity": "(oid, upn)",
  "device_id": "(device_oid)",
  "tenant": "(tid)",
  "mfa_claims": ["pwd", "mfa"],
  "validity": "~90 days (auto-renewed during active session)",
  "protection": "TPM-bound session key (Windows) or DPAPI-encrypted (non-TPM)"
}

Crucial Architecture Detail: The PRT is not the actual token sent to Entra ID over the wire. Instead, the Web Account Manager (WAM) and CloudAP subsystem use the PRT to derive a PRT Cookie — a JSON Web Token (JWT). This cookie is cryptographically signed using a session key derived from the PRT’s protected material.

WAM (Web Account Manager) is the Windows component that handles authentication brokers. CloudAP is the plugin that specifically handles Azure AD/Entra ID authentication flow. Think of them as the gatekeepers of your identity on the OS.

The Authentication Flow:

1. Password + MFA → Entra ID validates → Issues PRT (Securely stored on device).
2. Request: WAM silently requests a new token.
3. Derivation: CloudAP derives a signing key from the Session Key.
4. Signing: PRT Cookie signed with the derived key is sent to Entra ID.
5. Validation: Entra ID validates signature using PRT claims.
6. Issuance: New access/refresh tokens issued for services.

The Critical Insight: The PRT Cookie acts as a Bearer Token. If an attacker extracts the session key, they can derive the signing key and mint valid PRT Cookies from anywhere. For 90 days, this is the master key to enterprise access.

Pass-the-PRT: How Token Theft Actually Works (Field Example)

Dirk-jan Mollema’s 2020 research (published before “Token Protection” was even a product feature) detailed the complete attack chain. Here is the technical walkthrough, grounded in real attack tools:

Stage 1: Endpoint Compromise & Admin Escalation

An attacker gains initial access via phishing attachment or lateral movement. They escalate to SYSTEM privileges (local admin). On a managed Windows device, this typically involves:

• Exploiting a local privilege escalation vulnerability (e.g., PrintNightmare).
• UAC bypass via COM object.
• Passing stolen credentials via Kerberos/NTLM relay.

Stage 2: Extract PRT & Session Key from LSASS

Once admin, the attacker targets the Local Security Authority Subsystem (LSASS), where CloudAP stores PRT material. Using Mimikatz with the cloudap module:

mimikatz> privilege::debug
mimikatz> token::elevate      # Elevate to SYSTEM if not already
mimikatz> sekurlsa::cloudap   # Dump CloudAP data

This returns a JSON structure containing:

• PRT Blob: (Encrypted by Entra ID, opaque to the user).
• ProofOfPossessionKey: (DPAPI-encrypted session key).
• Context/Nonce: (24 random bytes used in key derivation).

Note: Even Credential Guard, which isolates on-prem credentials, does not fully protect Entra credentials stored by CloudAP in all scenarios.

Stage 3: Decrypt Session Key

The attacker decrypts the DPAPI-protected session key using either:

• Cached DPAPI keys (if they still have SYSTEM context)
• Dumped DPAPI masterkeys + key derivation tools.

Stage 4: Derive Signing Key & Craft New PRT Cookie

The attacker runs the key derivation process locally (on any machine). The derived key used to sign the PRT cookie lives in memory as plaintext once derived.

// Pseudo-code representation of the attack logic
BCryptOpenAlgorithmProvider(SP800108_CTR_HMAC);
BCryptGenerateSymmetricKey(session_key);

BCryptKeyDerivation(
  key,
  label: "AzureAD-SecureConversation",  // Fixed Microsoft label
  context: extracted_24byte_context,    // From LSASS dump
  output: derived_key                   // THE SIGNING KEY
);

The attacker constructs a new JWT with header/payload/signature, using the derived_key to HMAC-SHA256 sign it. Key Insight: The attacker can do this on any OS (Linux, macOS), without the original device. The derived key is symmetric; once known, it's the only secret needed.

Stage 5: Replay from Attacker’s Infrastructure

The attacker imports the signed PRT cookie into a custom OAuth client. They request a new access token from Entra ID using the stolen PRT:

POST /oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&client_id=<Office365_AppId>
&scope=https://graph.microsoft.com/.default
&refresh_token=<FORGED_PRT_COOKIE>

Entra ID’s Validation Logic (Without Token Protection):

1. Is the JWT signature valid? YES. (Signed with correct derived key).
2. Is the PRT valid? YES. (Valid for 90 days).
3. Does the PRT contain MFA claims? YES. (Claims travel with PRT).
4. Result: Issue Access Tokens for Exchange, SharePoint, Teams.

From Entra ID’s perspective, it sees a valid user, on a valid device, with valid MFA. The geography and device identity are just claims inside the token, not enforced at the cryptographic level. This is MITRE T1550.001.

Token Protection: The Cryptographic Binding

Token Protection introduces a cryptographic constraint that ties a token to the device it was issued on.

Without Token Protection (Status Quo):

1. Attacker steals PRT + Key.
2. Attacker uses it from Device B.
3. Entra ID checks signature. Valid.
4. Access Granted.

With Token Protection (New Behavior):

1. Attacker steals PRT + Key.
2. Attacker uses it from Device B.
3. Entra ID validates signature. Valid.
4. Entra ID checks: “Is the request signed with the hardware-bound key of Device A?”
5. Device B cannot produce Device A’s hardware signature.
6. Access Denied.

This is often called “Sender-Constrained Tokens” or “Proof-of-Possession” (PoP). Token Protection is the enforcement that turns policy decisions into cryptographic reality.

Conclusion: The Path Forward

Modern attacks against Entra ID don’t bypass MFA — they ignore it.

Token Protection is not an incremental improvement to Conditional Access. It is a fundamental architectural shift that makes stolen tokens worthless if they leave the device they were issued on. This is foundational to NIST SP 800–207’s vision of continuous, context-aware access decisions.

Organizations that have “done their homework” on Conditional Access and CAE are already 70% of the way there. Token Protection is the remaining 30% — and it is the difference between a token theft attack that gets caught in 5–15 minutes (current state with CAE) and one that gets caught in zero minutes (Token Protection).

For architects tasked with defending against the actual threats of 2025 — not theoretical ones — Token Protection isn’t optional. It’s the Third Pillar. It’s how you stop moving Zero Trust from a marketing phrase to a cryptographic reality.