.png)
What is Session Token Theft?
Session token theft steals the authentication artifact issued after login, so MFA never has to be defeated. How it works, why it beats standard MFA, and what stops it.
How Session Tokens Work
When you sign in to Microsoft 365, Okta, Google Workspace, or any modern identity provider, the system verifies your password, verifies your second factor, and then issues a session token — a cryptographically signed artifact that proves you have already authenticated. Every subsequent request carries that token instead of re-running the login.
This is by design and it is good design. Re-authenticating on every action would be unusable. The token has a defined lifetime, is scoped to particular resources, and expires.
The consequence is that possession of a valid session token is equivalent to being the authenticated user, for as long as the token remains valid, from any device that presents it. The identity provider does not re-check the password. It does not re-issue the MFA challenge. Both already happened.
How Tokens Are Stolen
Adversary-in-the-Middle phishing. The dominant method. A victim is directed to a proxy that relays credentials and the MFA challenge to the real identity provider in real time, then captures the returned token. See Adversary-in-the-Middle.
Infostealer malware. Commodity malware harvests browser cookie stores from infected endpoints. Session cookies for corporate SaaS applications are sold in bulk on stealer-log markets, often for a few dollars.
Cross-site scripting and malicious extensions. Code executing in the browser context can read tokens the browser holds, unless protective flags are set.
Token theft from logs and code. Tokens written to application logs, embedded in URLs, or committed to repositories.
Why This Defeats Standard MFA
Multi-factor authentication protects the authentication event. Session token theft attacks the authenticated state that follows it. The distinction is the whole problem.
Push notifications, SMS codes, and TOTP authenticator apps all successfully verify that a human completed a challenge. None of them binds the resulting session to the device or origin that requested it. Once issued, the token travels.
From the identity provider's telemetry, a stolen-token session frequently looks unremarkable. The authentication succeeded. The MFA challenge was satisfied. The user agent can be spoofed to match. The only anomalies are contextual — a different IP, a different geography, a device that has not been seen before — and those signals are noisy in an organization with remote work and VPN use.
What Actually Stops It
Phishing-resistant MFA. FIDO2 hardware keys and platform authenticators cryptographically bind the authentication to the legitimate origin. A proxy at a lookalike domain cannot complete the ceremony, so no token is ever issued to the attacker. This is the single highest-value control. See phishing-resistant MFA.
Token binding and device attestation. Conditional Access policies requiring a managed, compliant, hardware-attested device mean a stolen token presented from an unmanaged machine fails.
Continuous Access Evaluation. Re-evaluating session validity when risk signals change — geography shift, network change, privilege escalation — rather than trusting the token until expiry. See CAE.
Shorter token lifetimes for privileged sessions. A trade-off against usability, and worth making for administrative and finance accounts.
Detection. Impossible-travel alerting, unfamiliar sign-in properties, and anomalous token use are the signals that catch what prevention missed.
Why It Matters in Diligence
Session token theft is the mechanism behind the majority of 2025-2026 cloud intrusions at organizations that had MFA fully deployed. A target company reporting 100% MFA coverage has not answered the question. The follow-ups that matter: which MFA methods, on which accounts, and is anything phishing-resistant?
The finding is cheap to surface and inexpensive to remediate relative to most security gaps. Hardware keys for privileged and executive accounts, Conditional Access requiring compliant devices, and Continuous Access Evaluation enabled — these are configuration and procurement decisions, not architecture projects.
Related Reading
Apollo Global Management, July 2026
Attackers called Apollo employees posing as internal IT helpdesk staff, walked them to lookalike sign-in portals, and captured credentials and MFA codes in real time. The resulting authenticated sessions were used to reach Apollo cloud platforms directly from the attackers' browsers.
Apollo's MFA worked. Employees completed the challenge. That is precisely what the attackers needed. Access ran from July 6 to July 10; forensic determination came August 12, and public disclosure August 21.
The same technique appeared in the UK retail attacks in April 2025, the Aura breach in March 2026, and the RingCentral breach in July 2026.
describes most organizations compromised by session token theft in 2025 and 2026. Full MFA deployment is not a defense against an attack that steals what MFA produces rather than defeating MFA itself.