Skip to content
Start with Identity
Join free
SWI-T007 · Session and tokens

Session cookie theft

A session cookie is a bearer credential that proves nothing beyond possession. Whoever copies it inherits the logged-in session, skipping the password and the MFA challenge that produced it.

WidespreadHard to detect
First observed: 2019ATT&CK T1539 ↗ATT&CK T1550.004 ↗

How it works

After a user authenticates, most web applications issue a session cookie so the browser does not have to prove identity on every request. That cookie is the session: it stays valid for hours, days, or weeks, and any browser or tool that presents it is treated as the authenticated user, with no further password or MFA check. A stolen identity provider session cookie is worse: it mints fresh sessions for every application behind single sign-on. This is the pass-the-cookie pattern.

Attackers get hold of these cookies in four main ways.

  1. Infostealer malware on the endpoint. RedLine, Lumma, Vidar, StealC and their successors read the browser's cookie store directly. On Windows, Chromium-based browsers historically protected that store with the Data Protection API, which stops other users and offline attacks but not a process running as the logged-in user, which is exactly what an infostealer is. Google added App-Bound Encryption in Chrome 127 in 2024 to tie the data to Chrome's own identity, which raises the bar for a stealer that only reads files from disk but does not change what a cookie is once it has been copied. The cookies leave the machine in a log alongside saved passwords and are sold in bulk.
  2. Diagnostic and support artifacts. HAR files, browser exports and log bundles capture request headers, including live Cookie and Authorization values. They were never designed as credential stores, so a breach of the ticketing system that holds them becomes a breach of every session captured inside.
  3. Bugs that leak or swap sessions. Citrix Bleed (CVE-2023-4966) was a buffer over-read in NetScaler that returned valid session tokens from memory to an unauthenticated request. Keycloak's CVE-2023-6787 let a cancelled prompt=login re-authentication leave a new session with a different subject sharing the old session ID. Cross-site scripting on an IdP login path, as in Keycloak's CVE-2023-6717, can read whatever the page can.
  4. A proxy during login. An AiTM phishing proxy captures the cookie at the moment it is issued.

Once an attacker has the cookie, they import it into their own browser and are logged in as the victim immediately, with no login form and no MFA prompt.

Why it works

MFA protects the moment of authentication. It says nothing about what happens after, and a session cookie is a bearer token: whoever holds it is the user until it expires or is revoked, with no further check on origin, device, or intent. The control assumption that fails is that the session stays attached to the device that authenticated. Nothing in a plain cookie enforces that. Most applications do not bind the cookie to a key, a device, or even an IP range, so a copy is exactly as good as the original anywhere it is presented.

Two operational assumptions fail alongside it. The first is that a password reset ends access; it changes the credential that produced the session, not the session already issued. The second is that the endpoint is a trustworthy place to keep long-lived secrets. A browser holding a persistent "stay signed in" session for the identity provider is storing a credential more powerful than the password, protected only by the user account it runs under. The industry's investment in stronger login-time authentication has, in effect, made the post-authentication session the more attractive and less defended target.

How to detect it

  • Session used where it was not issued. In Entra sign-in logs (SigninLogs and AADNonInteractiveUserSignInLogs), the same SessionId appearing from a new IPAddress, AutonomousSystemNumber, or UserAgent with no corresponding interactive sign-in from that location. The TokenProtectionStatusDetails column shows whether the sign-in token was device-bound, which tells you how much to trust the session in the first place.
  • Identity provider detections. Entra ID Protection's anomalousToken detection covers session tokens and refresh tokens replayed with unexpected location, application, IP or user agent. Microsoft notes it was historically tuned to be noisier than other detections and still has a higher than normal false-positive chance at low and medium risk. In Okta, security.session.detect_client_roaming records a roaming session, and user.session.context.change records a significant change in device or network on an active session.
  • Activity after revocation. Session activity continuing after a password reset or revokeSignInSessions call, beyond the few minutes Microsoft documents for revocation to take effect, means a session or token outside the revocation path.
  • Endpoint telemetry. EDR alerts for known stealer families, or for an unexpected process reading the browser's cookie database, are the earliest and most reliable signal, because they fire before the cookie is used.
  • Application-level anomalies. Anthropic detected stolen Claude sessions through unusual usage patterns rather than anomalous logins, because the login was never repeated. Usage baselines catch what sign-in logs cannot.

Be honest about the limits: users legitimately switch networks, VPNs, and devices throughout a workday, and a session opened at home and continued at an office shows exactly the IP change this detection looks for. An attacker who buys a residential proxy near the victim defeats geography checks entirely. Treat roaming as a reason to re-evaluate the session, not as proof of theft.

How to stop it

  • Bind sessions to the device. Entra Token Protection accepts only device-bound sign-in session tokens for supported resources (Exchange Online, SharePoint Online and Teams for native apps on Windows, macOS and iOS, with browser support in preview). Device-bound session credentials (DBSC) bring the same idea to the browser, keeping the private key in a TPM and refreshing short-lived cookies against it. DPoP and mTLS do it for API tokens.
  • Treat an infostealer infection as an identity compromise. Revoke every session for the user, rotate every credential the browser stored, and check for new MFA methods and OAuth grants. Clean the machine first, or it re-harvests the next session.
  • Shorten session lifetimes for privileged roles and re-evaluate risk continuously with continuous access evaluation rather than trusting a long-lived cookie for its full validity window.
  • Sanitize diagnostic and support artifacts to strip cookies and tokens before they are stored, and treat support systems that hold them as tier zero.
  • Patch session-handling flaws on identity infrastructure, then kill sessions. Citrix Bleed showed that patching alone leaves already-stolen tokens valid.
  • Rehearse full session revocation as part of incident response. See token theft and the identity incident response runbook.

Seen in the wild

The Identity Breach Report 2026 counts three MFA bypasses where a session or token was stolen after MFA, plus LastPass's trusted device cookie, and notes that phishing-resistant MFA would not have stopped CircleCI. Its fifth-ranked control, bound, short-lived sessions revoked on reset, addresses 18 incidents.

Sources

Related identity CVEs and breaches

Last reviewed By SWI Community TeamSuggest a correctionHow we research

In the Identity Breach Database

Real incidents in our sourced breach database where this technique was used.

Browse the full database

Seeing this technique used differently, or have a detection rule that works better? Email community@startwithidentity.com. See all briefs in the technique catalog, or volunteer as a CVE Analyst.
Mapped to MITRE ATT&CK where a technique ID exists. Independent, community-driven analysis, not a substitute for the ATT&CK knowledge base. See the disclaimer.