Nobody broke your MFA. They took the token it handed out.

Read the incident writeups from the last four years and a strange sameness shows up. LAPSUS$ bought session tokens on a criminal forum in 2022 and replayed them. The Okta support breach in October 2023 turned on HAR files with live session tokens baked in. Storm-2372 talked victims into typing a device code on the real Microsoft sign-in page. In August 2025, stolen OAuth tokens for a chat widget let attackers walk data out of more than 700 Salesforce tenants. Different actors, different tools, different years. None of them cracked multi-factor authentication in the cryptographic sense; the campaigns took the thing MFA hands out and replayed it. LAPSUS$ also leaned on MFA-fatigue prompts, a separate trick that gets a user to approve the challenge rather than steal the token behind it. The through-line worth naming is the token replay.

MFA at the login page is not the finish line. It is a gate you pass once, and what you get for passing it is a token. That token is the live credential for everything that happens next, and because it already carries the satisfied-MFA claim, replaying it never triggers a second challenge. The effort has moved past the login accordingly. The front door got hard, so the attack went to the thing behind the door.

Three tokens, and they are not equally bad

The identity provider mints one of a few artifacts after you authenticate, and the differences decide how much a stolen one costs you.

An access token is the short-lived one, roughly an hour by default, presented to a resource like Exchange or SharePoint. Steal it and you have that resource until it expires. A refresh token is worse: it is longer-lived, it silently mints new access tokens without another sign-in, and in Entra it is bound to the app that requested it. That is the token OAuth-consent phishing is after, because it survives the lifespan of a tenant policy rather than a session. The one that should worry you most is the Primary Refresh Token. It is Entra’s device-wide refresh token for joined and registered machines, valid for 90 days, renewed every four hours, and it carries the MFA claim with it. Microsoft’s description of an attacker who hijacks a PRT is blunt: such an attacker “does not need to know the user’s password or possess the user’s physical MFA device.” The session cookie your browser holds after sign-in rounds out the set, and it is the one infostealers scrape by the thousands.

The turn: four vectors, one blind spot

Microsoft states the mechanism plainly in its token-theft playbook: “A token theft attack occurs when threat actors compromise and replay tokens issued to a user, even if that user has satisfied multifactor authentication.” The more interesting detail is that four unrelated attack styles all arrive at that one sentence. Line them up by what they steal and where the MFA check actually sits, and the shared gap is hard to miss.

Vector	What’s stolen	Where MFA sits	What actually stops it
Infostealer malware (Lumma, RedLine, StealC)	Browser session cookie or token cache	Already passed; irrelevant by the time the malware runs	Device-bound sessions (Token Protection, DBSC); short sign-in frequency; remove the malware
Adversary-in-the-middle phishing (Evilginx, Tycoon 2FA)	Session cookie minted after MFA	Relayed live through the proxy	Phishing-resistant MFA (origin binding)
Browser-in-the-middle	The whole authenticated browser profile	Relayed through a remote browser	Phishing-resistant MFA; device binding
Malicious or consented OAuth app	Long-lived refresh token	Never challenged; it is a grant, not a login	Restrict user consent; admin consent workflow; grant review

Two of these relay the MFA prompt through a proxy so a phishing-resistant credential shuts them down at the door. The other two never see the login at all: the infostealer copies a cookie that already exists, and the OAuth grant hands over a refresh token because the app was authorized to receive it. One control does not cover all four, which is the entire problem.

The evidence reads as refinement, not novelty

DEV-0537, the group better known as LAPSUS$, ran RedLine stealer to harvest passwords and session tokens, bought more tokens on criminal forums, and paired replay with MFA-fatigue prompts. Microsoft was among the confirmed victims and published the writeup in March 2022. The Okta support-system breach the following year showed the same move in a cleaner form: customer support cases held HAR files with live session tokens inside them, and the actor replayed those tokens to hijack the active sessions of five customers, 1Password and BeyondTrust and Cloudflare among them. No login was involved, because none was needed.

By 2025 the technique had a delivery method for every taste. Storm-2372’s device-code phishing, documented by Microsoft in February 2025, never touched a fake page at all: the victim entered an attacker-supplied device code on the genuine Microsoft sign-in flow, and the attacker collected valid access and refresh tokens carrying the MFA claim. The strongest recent case is Salesloft Drift. In August 2025, Google’s threat group tied UNC6395 to the theft of OAuth tokens for the Drift chat integration and the replay of those tokens against every Salesforce tenant Drift was connected to. The victim list is a security-vendor roll call: Cloudflare, Google, PagerDuty, Palo Alto Networks, Proofpoint, Zscaler, Tanium, and more than 700 organizations in total. There was no Salesforce vulnerability. The OAuth token was the authenticated artifact, and it sat inside a third-party app nobody was watching. That is the same shape as the Vercel OAuth token supply-chain breach and the broader OAuth mess in the MCP ecosystem: the token is the perimeter, held by an integration you approved once and forgot.

The contrast that sharpens the point is the 2024 Snowflake campaign, which gets filed next to these cases and does not belong there. UNC5537 stole no token. It reused static usernames and passwords pulled from infostealer logs against tenants that had never enabled MFA. That is the absence of MFA, not the bypass of it. The distinction carries the argument: where MFA was enforced, attackers stopped attacking the login and started taking the token behind it; where MFA was absent, they simply walked in.

Worth noting how little time any of this takes. Mandiant’s M-Trends 2026 puts the median from initial access to hand-off at 22 seconds. Whatever detection you are counting on runs against that clock.

The route to the stolen session isn’t even always malware. CitrixBleed was a memory-disclosure bug in a network appliance that leaked session tokens straight out of the box, and it ended at the same place an infostealer does: replay the session, skip the login. A firmware flaw and a browser-cookie thief converge on one outcome, which tells you what the attacker is actually after: the live session. How they reach it is interchangeable.

What this changes about priority

The session itself is what now needs protecting; guarding the sign-in was never the whole job. The honest version of that advice comes with its limits attached.

Phishing-resistant MFA (FIDO2, passkeys, Windows Hello) is real and worth doing. An origin-bound assertion collapses the adversary-in-the-middle model at the front door, because the browser refuses to release the credential to a lookalike domain. It does nothing about a cookie lifted off the endpoint after a legitimate sign-in. By then the strength of the login is beside the point; the malware is copying an artifact that already exists.

The control built specifically for replay is Entra Token Protection, which binds a session to the device’s TPM-backed key so a bearer token replayed from another machine fails. Here is the uncomfortable structural fact. Token Protection is generally available on Windows native applications only. iOS and macOS are in preview. There is no browser coverage. Most session-cookie theft happens in the browser. The marquee anti-replay control does not yet reach the surface where the theft economy actually operates.

Continuous Access Evaluation helps around the edges by shrinking the revocation window from “whenever the token expires” to minutes, pushing signals like a disable or a password reset to resource providers that understand them. It also raises token lifetime to as much as 28 hours precisely because it can revoke on demand, so absent a fired event a stolen token can live longer than it used to, and critical-event propagation still runs up to about 15 minutes. The lever people reach for next, shortening token lifetimes directly, no longer exists. Microsoft retired Configurable Token Lifetime for refresh and session tokens on January 30, 2021, and the properties are now ignored. The supported knob is Conditional Access sign-in frequency, which is a session-lifetime control wearing a different name.

If you want one concrete afternoon out of this, audit what holds your tokens. Enumerate the enterprise apps and their consent grants, and check the scope column for offline_access, the flag that means “this app holds a refresh token.” A single user who self-consented to an app with mail or directory write scopes is the illicit-consent path in miniature. Keep Revoke-MgUserSignInSession in the runbook and know its edge: it invalidates refresh tokens and cookies at once, but already-issued access tokens on non-CAE apps stay valid up to an hour, and it does not reset the password. Two risk-based Conditional Access policies, one on user risk and one on sign-in risk, plus restricting user consent, cover the paths the campaigns above actually used. None of that depends on the one feature that does not cover the browser yet.

What to watch

The industry is converging on the same fix: bind the session to hardware so a copied token is worthless off the device that earned it. Google’s Device Bound Session Credentials reached general availability in Chrome for Windows in May 2026, re-signing a challenge from a non-exportable TPM key every few minutes. Okta is shipping DPoP and device-bound SSO. Microsoft’s Token Protection is on the same road and not yet at the browser.

The open question is timing. Device-bound sessions only matter where they reach the place tokens are actually stolen, and today that is mostly the browser, where the coverage is thinnest. The theft economy moved from the login to the token the moment the login got hard, and it did it in months rather than years. Whether hardware-bound cookies reach the browser fleet before attackers find the next artifact worth lifting is the part nobody can answer yet.

Sources

• Microsoft — Token theft playbook
• Microsoft — Primary Refresh Token concept
• Microsoft — Token Protection (Conditional Access)
• Microsoft — Continuous Access Evaluation
• Microsoft — Configurable token lifetimes
• Microsoft — Revoke-MgUserSignInSession
• Microsoft — DEV-0537 (LAPSUS$)
• Microsoft — Storm-2372 device-code phishing
• Okta — Support case management system root cause
• Google Cloud / Mandiant — Salesloft Drift (UNC6395)
• Google Cloud / Mandiant — UNC5537 (Snowflake, contrast case)
• Google Workspace — Device Bound Session Credentials GA
• Okta — DPoP support
• Mandiant M-Trends 2026 (via Help Net Security)