Credential phishing is dying. Token theft is what killed it. Over the first half of 2022, Microsoft's threat intelligence team has published three separate reports describing large-scale Azure AD token theft campaigns: the DEV-0537 (LAPSUS$) session-cookie exfiltrations that compromised Okta, Microsoft, and Nvidia in the March window; the ongoing adversary-in-the-middle phishing using the EvilProxy, Evilginx, and Modlishka toolkits that Microsoft quantified at more than 10,000 organizations hit by a single AiTM campaign; and the uptick in OAuth consent phishing, where attackers never need the password at all because the user clicks "consent" on a malicious app. The common thread is that multi-factor authentication, as deployed in most organizations, did not stop any of these. Token theft bypasses MFA by definition — it takes the thing MFA creates, not the thing MFA protects. This retrospective walks through what those campaigns actually looked like, why the standard defenses failed, and which detection and hardening patterns have held up across a full year of aggressive attacker iteration.
What exactly is a stolen Azure AD token?
A stolen Azure AD token is either a primary refresh token (PRT), an OAuth access or refresh token, or a session cookie, depending on the attack path. Each grants the attacker the ability to act as the user without needing the password or the MFA factor again, for the lifetime of the token.
A PRT is the token a Windows device receives when it joins Azure AD, and it represents the device's trust relationship with the tenant. Stealing a PRT — typically via ROADtoken, a PRT cookie dump from an unlocked workstation, or LSASS memory extraction — gives the attacker single sign-on across every Microsoft service the user has. An OAuth access token, by contrast, is scoped to a specific client application and resource, and is typically short-lived (one hour by default). An OAuth refresh token, used to obtain fresh access tokens, can live up to 90 days without explicit revocation, and is the token that AiTM phishing kits are principally trying to capture.
How do adversary-in-the-middle phishing kits actually work?
Adversary-in-the-middle phishing kits work by proxying the legitimate Microsoft login page through attacker-controlled infrastructure, so the victim sees a pixel-perfect Microsoft login, enters their password, completes MFA, and the attacker silently captures the resulting session cookie. Microsoft's July 2022 writeup on the large-scale AiTM campaign described the flow in detail: the victim clicks a link in a phishing email, lands on a lookalike domain hosting Evilginx2 or a similar reverse-proxy toolkit, and the toolkit transparently forwards every request and response between the victim and the real login.microsoftonline.com.
The critical step is at the end: once authentication completes, the victim's browser is handed the session cookie (ESTSAUTH, ESTSAUTHPERSISTENT) by the proxy. The same cookie has just been logged by the attacker. The attacker loads the cookie into their own browser and is now the user for the session lifetime — typically up to 24 hours, extended by refresh tokens to indefinite.
Victim → Attacker proxy (login.microsoft-o365.help) → login.microsoftonline.com
← redirect + ESTSAUTH cookie ← ← redirect + cookie ←
Attacker now holds ESTSAUTH. No password, no MFA needed for re-entry.
Why didn't the organization's MFA stop this?
The organization's MFA didn't stop this because MFA operates at the moment of authentication, and the stolen token is the artifact produced by successful authentication. Once the authentication ceremony — including MFA — is complete, the resulting token is what grants access. An attacker who captures that token is holding a bearer credential that the identity provider will honor until it expires or is explicitly revoked.
This is the reason every Azure AD hardening guide in 2022 now mentions phishing-resistant MFA prominently. FIDO2/WebAuthn security keys, Windows Hello for Business, and certificate-based authentication all produce tokens that are bound to device-held private keys. Even if the attacker captures the resulting session cookie via AiTM, the next use of the cookie from a different device triggers a re-authentication that the attacker cannot complete because they don't have the key. Push-based MFA (Microsoft Authenticator, Duo Push) without number matching does not have this property — the token it produces is a regular bearer cookie, and AiTM captures it the same as any other.
How did the Okta and LAPSUS$ intrusions fit this pattern?
The Okta and LAPSUS$ intrusions fit the session-token-theft pattern almost exactly, with the variation that the initial access vector was a compromised third-party support contractor's laptop rather than AiTM phishing. The March 22, 2022 disclosure by Okta, responding to screenshots LAPSUS$ posted to Telegram, described a five-day window in January during which the attackers had Sitel support-engineer access to Okta's customer support tools. That access was enabled by the support engineer's session tokens, captured from their workstation after initial compromise.
The LAPSUS$ playbook across Microsoft (March 20), Nvidia (February 23), and Samsung (March 4) was consistent: obtain employee credentials or session cookies via bribery, SIM-swap, or direct purchase from initial access brokers; use those cookies to access internal systems from attacker-controlled infrastructure; exfiltrate source code and credentials; post to Telegram. None of this required novel malware. It required tokens, and tokens were available.
What detection patterns actually work against token theft?
Detection patterns that actually work against token theft focus on the inconsistency between the token and the environment using it. A legitimate session cookie from a user in Seattle should not show up 20 minutes later in a sign-in from Lagos. Azure AD Identity Protection's impossible-travel and anonymous-IP risk detections catch this pattern, and for organizations that have turned them on and connected them to Conditional Access policies, they catch a meaningful fraction of AiTM-driven takeovers before the attacker gets to interesting data.
The higher-fidelity detection is anomalous token use from a different device fingerprint than the one the token was issued to. Continuous Access Evaluation, rolled out by Microsoft in 2021 and expanded through 2022, propagates token revocation decisions across Microsoft 365 services within minutes, so when a risk signal triggers, the blast radius is bounded. Combined with sign-in frequency policies that shorten session lifetimes to 4 hours for high-risk roles (admins, finance, developers with production access), the window an attacker has to use a stolen token shrinks from days to hours.
The detection that consistently falls short is user-reported phishing. By the time a user reports the suspicious email, the attacker has typically been in the tenant for several hours. Only controls that operate on the cookie itself — not the email it was delivered from — move this needle.
How Safeguard Helps
Safeguard's TPRM module tracks the identity posture of every vendor in your supply chain, surfacing suppliers whose published security practices do not include phishing-resistant MFA, session management aligned with CAE, or documented token-revocation playbooks — which are the upstream signals that a vendor is exposed to exactly the attack classes above. The policy engine lets you require vendors in sensitive tiers to maintain specific identity controls as a condition of access, and flags drift automatically as new questionnaire data arrives. Inside your own tenant, Safeguard ingests Azure AD sign-in logs alongside your CI/CD audit trails, so a suspicious token use that aligns with a code-signing event or a package publish shows up as a correlated finding rather than two separate alerts in two separate tools. Griffin AI answers natural-language questions against that correlated data — "which of our publish tokens were exercised from sign-ins flagged as impossible travel this quarter" — directly, without the usual five-tool dashboard tour.