Session token theft turns a single successful login into an ongoing account takeover. Once an attacker has a valid session token, they can impersonate the user in SaaS apps, email, and cloud platforms without re-entering passwords or repeating MFA, until that token is revoked or tightly bound to a specific device. Microsoft’s token theft playbook provides guidance on investigation and response for this class of attack.
Session Token Theft: What It Actually Means
Session token theft is an attack in which adversaries steal or intercept the artefact representing an authenticated user, typically a cookie or token, and then reuse it to impersonate the user.
Instead of attacking the login step directly, attackers target the post-login state. Hijacked Cloud Sessions bypass fresh authentication because the stolen artefact represents a successful login. The stolen session token is presented to the service as proof that the user has already authenticated, so requests made with that token are processed as if they came from the legitimate user. Halock’s session token theft analysis provides additional context on how attackers exploit authenticated sessions.
Because the original login was valid, logs and dashboards often show only a series of normal authenticated operations. The difference lies in who holds the token, not in how it was issued.
Cookies, Access Tokens, Refresh Tokens, and Device-Bound Tokens
“Session token” is a convenient umbrella term, but incident response becomes much clearer when you identify the exact artefact that was stolen. Different tokens create different risks and require different containment actions.
Browser session cookies
Web applications commonly use session cookies to maintain continuity after a user signs in. In platforms such as Microsoft Entra ID, persistent cookies can survive browser restarts, while non-persistent cookies usually disappear when the browser session ends.
If an attacker obtains a reusable authentication cookie, injecting it into their own browser can restore an authenticated state without repeating the password or MFA challenge, within the scope of that cookie. Cookie theft often results from adversary-in-the-middle phishing, endpoint malware, or unsafe extensions that expose browser storage.
OAuth access tokens
Access tokens authorize calls to specific APIs or resources. They carry information about the identity, client, scopes, and intended audience, so a stolen access token lets an attacker call the APIs that token was meant for, but not automatically every service the user can reach.
During investigation, distinguishing which audience and scopes a stolen access token carries helps determine which data and operations are exposed and which remain out of reach.
Refresh tokens
Refresh tokens allow clients to obtain new access tokens without requiring the user to go through another interactive login. In Microsoft’s identity platform, refresh tokens are tied to the user, client, and flow, with lifetimes and revocation options that depend on configuration.
A stolen refresh token is particularly dangerous because it can quietly extend access long past the original login by repeatedly minting fresh access tokens. However, browser-based AiTM phishing does not automatically yield refresh tokens. Issued artefacts depend on the service, client type, and authentication protocol.
Device-bound tokens
Device binding changes the replay test by requiring not just possession of the token, but also proof that the request comes from the registered device or from a key associated with that device. Microsoft’s Token Protection and Google’s Device Bound Session Credentials, or DBSC, both aim to make stolen cookies and tokens unusable when replayed from other machines.
Coverage is still evolving. DBSC applies only to supported sessions and environments, while Microsoft’s Token Protection is available for specific applications, platforms, and resources. Both technologies require careful pilot deployment because unsupported or incompatible clients can experience access problems.
How Session Tokens Get Stolen in Modern Environments
Session token theft is an outcome; the acquisition path can vary widely from case to case. Revoking one token without closing the path that leaked it simply forces the attacker to steal another.
AiTM proxies and live authentication relay
Adversary-in-the-middle phishing proxies sit between the victim and the real identity provider. The victim visits an attacker-controlled domain, enters their credentials, completes MFA, and the proxy relays all of that traffic to the legitimate service.
When the identity provider returns session cookies, those cookies pass through the proxy and can be captured for reuse. Hijacked Cloud Sessions bypass the need for additional multi-factor authentication (MFA) or two-factor authentication (2FA) challenges because captured cookies preserve the victim’s authenticated state. The attacker does not break MFA or 2FA; they allow the user to complete authentication successfully, then steal the resulting session.
This is the same class of infrastructure used by modern AI-assisted phishing kits and phishing-as-a-service platforms. AI helps craft convincing lures, but the modern proxy performs the relay and session capture.
Endpoint malware and local browser scraping
Commodity info-stealer malware now routinely targets browser profiles, local cookie stores, and application credential caches. Running in the user’s context, the malware can export session cookies and tokens for active SaaS apps, including email, collaboration platforms, and cloud consoles.
Unlike AiTM phishing, this path does not depend on a fresh login. The malware can steal tokens from long-established sessions, making endpoint hardening and device management just as important as identity controls. Obsidian Security’s session hijacking analysis explains how stolen sessions can be used in SaaS environments.
Unsafe extensions and browser modifications
Browser extensions can have permissions to read page content and interact with cookies. A malicious or compromised extension can expose session data in ways a phishing proxy cannot, including data from internal applications that users never access through external email links. Unexpected extensions, homepage changes, redirects, and unfamiliar browser behavior may also be signs your browser has been hijacked.
Google’s DBSC documentation notes that certain extensions or manual cookie changes can interfere with session binding, leaving some cookies unprotected even when DBSC is enabled.
OAuth flows and device codes
Attackers are also abusing legitimate OAuth and device-code flows to obtain access and refresh tokens without relying on traditional login pages. Campaigns such as Storm-2372’s device-code phishing show that tricking users into completing a device-code prompt can hand over tokens directly to attacker-controlled apps.
In these cases, session token theft is tied to consent and token issuance rather than browser cookies alone, which is why investigating OAuth grants and application registrations is a separate step from reviewing web sessions.
Diagnostic artefacts and exported traffic
Support tools, HAR captures, and diagnostic exports can inadvertently contain raw cookies and tokens. When these artefacts are shared outside secure channels or stored unsafely, they become another source of session token leakage.
Why Hijacked Cloud Sessions Bypass MFA
Multi-factor authentication is designed to protect credential-based logins. It raises the cost of using stolen passwords or guessing credentials by requiring an additional factor.
Session token theft targets the post-authentication state. Microsoft’s token theft playbook notes explicitly that token theft occurs when attackers compromise and replay tokens issued to users after MFA requirements have already been satisfied. Hijacked Cloud Sessions Bypass repeated authentication checks by presenting evidence that the required checks have already occurred.
From the platform’s perspective:
- The original MFA was valid.
- The session token is valid and within its lifetime.
- Requests made with that token appear as authenticated activity.
The attacker never attempts to bypass MFA directly; they skip the login ceremony and reuse the evidence that it has already occurred.
Where Stolen Tokens Are Used
Once attackers have a reusable session token, they typically start with the services that token naturally exposes and then pivot where possible.
Common impacts include:
- Reading and exfiltrating email and chat messages from cloud mailboxes.
- Accessing files and collaboration spaces in SharePoint, OneDrive, or Google Drive.
- Sending messages as the compromised user to launch internal or external phishing.
- Creating inbox rules and forwarding to maintain persistence and hide warnings.
- Approving OAuth apps or changing settings where the compromised identity has enough privileges.
In federated or single sign-on environments, a privileged session token can support lateral movement into other SaaS platforms or cloud accounts, especially where refresh tokens and primary refresh tokens, or PRTs, are involved.
Making Session Token Theft Harder to Succeed
Defending against session token theft is about reducing opportunities to steal tokens and making stolen tokens harder to reuse. Guidance from cloud providers and independent SaaS security research converges on several layers.
Phishing-resistant authentication and safer enrolment
Phishing-resistant MFA, such as FIDO2 security keys and WebAuthn-based passkeys, binds credentials to legitimate origins and relying parties. That removes a major acquisition path for tokens issued through browser-based flows because phishing domains cannot successfully complete authentication using those credentials.
CISA and NIST consider phishing-resistant authenticators stronger than SMS codes or app-based time-based one-time passwords, especially for high-impact accounts. However, stronger authentication still requires secure recovery processes and careful help desk verification. Weak recovery can undermine strong enrolment.
Hardened and managed endpoints
Since many tokens are stolen from local browsers and apps, endpoint security, including EDR, patching, application control, and browser hardening, remains essential. Managed devices and device compliance checks help ensure that sensitive sessions exist only on hosts that are being monitored and controlled.
Device-aware access and token binding
Conditional access policies that require trusted devices, compliant endpoints, or low-risk conditions before granting sensitive access limit the environments where valid sessions can operate.
Token-binding mechanisms such as DBSC and Microsoft Token Protection add cryptographic proof that the session is being used from the expected device. This makes cross-device replay of stolen cookies much less effective in supported scenarios.
Shorter token lifetimes and rotation
Shorter lifetimes for session cookies, access tokens, and refresh tokens reduce the window in which a stolen artefact is useful. Refresh-token rotation and revocation workflows help prevent long-term persistence when a refresh token is compromised.
Continuous session monitoring
Risk-based conditional access and user and entity behavior analytics tools can reevaluate session trust midstream, not just at login. They can force reauthentication, block access, or terminate sessions when token use deviates from expected patterns, such as sudden geolocation changes or the appearance of new device types.
Detecting Session Token Theft in SaaS and Cloud Apps
Because attackers use valid tokens, detection focuses on how sessions behave, not only on who logged in.
Useful signals include:
- The same session or device ID appearing from unrelated geolocations or hosting providers.
- Non-interactive sign-ins or refresh events that do not match normal client behavior.
- New user-agent or device fingerprints that appear only after suspicious sign-ins.
- Mailbox-rule and forwarding changes tied to the suspected session.
- Unexpected OAuth consent or application registration.
- Bulk downloads or unusual file-access patterns.
- Security notifications being deleted or moved.
Microsoft’s token theft playbook and session-cookie alerts recommend correlating activity by session identifier across Entra sign-in logs, cloud application events, and SIEM data to see where a stolen cookie or token was used. Google Workspace records events for users who are signed out due to suspicious cookies, which can serve as pivot points for device and account investigations.
Incident Response When Session Token Theft Is Suspected
When a session token is suspected to be compromised, treating it as a simple password issue is not enough. Practical guidance from cloud providers and SaaS response playbooks converges on a multi-step approach:
- Restrict or temporarily disable the affected identity if ongoing misuse is likely or the account is sensitive.
- Revoke browser sessions, access tokens, refresh tokens, and application tokens using identity-platform and SaaS controls, not just sign-out buttons.
- Reset credentials through trusted administrative workflows, avoiding self-service flows on potentially compromised devices.
- Review MFA methods, passkeys, recovery details, and enrolled devices, removing unauthorized entries and tightening recovery paths.
- Remove malicious inbox rules, forwarding targets, OAuth grants, and application registrations created while the stolen session was active.
- Search email and SaaS logs for follow-on phishing, sensitive data access, downloads, and configuration changes associated with the session.
- Investigate and remediate the endpoint or browser that exposed the session, including malware cleanup and extension review.
- Verify that attacker sessions no longer work, checking that revocation has taken effect across applications and that new suspicious activity is not appearing.
Providers such as Microsoft and Google document that different token types and sessions may not terminate at exactly the same moment, which is why explicit post-revocation verification is part of the recommended workflow.
Session Token Theft: The New Security Boundary
Session token theft shows that the real security boundary in cloud environments is not just “did the password and MFA succeed?”, but “who currently holds the session that success created?”. Hijacked Cloud Sessions Bypass login-focused defences when possession of a valid session remains sufficient proof of identity.
For identity and SaaS teams, the practical shift is to treat sessions and tokens as first-class security objects:
- Design authentication so that strong, phishing-resistant factors are used where they matter most.
- Assume a session token can be stolen and plan how quickly you can detect, revoke, and contain that event.
- Combine endpoint hardening, device-aware access, token binding, shorter lifetimes, and continuous session monitoring so that one stolen token becomes a short incident, not a long-term compromise.
In a world where attackers increasingly steal and replay session tokens instead of attacking logins directly, the strength of your session governance will often decide whether “one wrong click” is a brief disruption or the start of a sustained cloud breach.