.png)
What Is Session Token Theft?
Session token theft steals the credential 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
What is session token theft?
Session token theft is the capture and reuse of the authentication token an identity provider issues after a successful login. Because the token proves authentication already occurred, an attacker holding it can access resources as the user without a password or an MFA challenge.
Does MFA stop session token theft?
Standard MFA does not. Push notifications, SMS codes, and authenticator apps verify the login event but do not bind the resulting session to a device or origin. Phishing-resistant MFA using FIDO2 or platform authenticators does prevent the theft, because the authentication cannot be completed through an attacker-controlled proxy.
How are session tokens stolen?
Primarily through adversary-in-the-middle phishing proxies that capture the token as it is issued, and through infostealer malware that harvests browser cookie stores from infected endpoints. Tokens are also exposed via cross-site scripting, malicious browser extensions, and tokens written into logs or repositories.
How do you detect stolen token use?
Impossible-travel sign-ins, sessions from unfamiliar ASNs or residential proxy infrastructure, new device registrations for privileged users, and anomalous API access patterns. Continuous Access Evaluation reduces the window by re-evaluating sessions when risk signals change.
What is the single most effective control?
Phishing-resistant MFA — FIDO2 hardware keys or platform authenticators bound to the legitimate origin. It prevents the token from ever being issued to an attacker, which addresses the problem at the source rather than at detection.
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.
How Cloudskope Can Help
Cloudskope's SARTUS™ engagement assesses identity posture including MFA method coverage, Conditional Access configuration, session lifetime policy, and indicators that token theft has already occurred, then remediates what can be closed through configuration inside the deployment window.
If you suspect stolen sessions are already in use, our Microsoft 365 compromise assessment reviews sign-ins, mailbox rules and app consents for signs of attacker access and tells you in writing what it found.