Leaked Sessions and Cookie Theft

What it is

When you log into a web application, the server gives your browser a token (typically a cookie) that proves you are authenticated. For the lifetime of that cookie, the browser sends it with every request, and the server treats those requests as coming from a logged-in user. No re-prompt for credentials, no MFA challenge, just access.

Session cookies are the practical implementation of "stay logged in". They make web applications usable. They also make stolen sessions devastating, because the cookie itself is the credential.

A leaked session is a session cookie that has been exfiltrated from a legitimate user's browser, usually by infostealer malware, and is now in the hands of an attacker. The attacker imports the cookie into their own browser and is, from the application's point of view, the user.

What gets stolen typically includes:

• SSO session cookies for Okta, Microsoft Entra ID, Google Workspace, Ping, and similar identity providers
• Application-specific cookies for Office 365, Gmail, Slack, Salesforce, Workday, Jira, and any other SaaS in active use
• VPN and remote access tokens for services like GlobalProtect, AnyConnect, Citrix, and Zscaler
• Cloud admin console cookies for AWS, Azure, GCP, and other infrastructure providers
• Banking and financial application cookies, where the impact is immediate and direct

A single stealer log can contain dozens of active session cookies. Each one is a potential intrusion.

Why it matters

The shift toward session theft has fundamentally changed initial access economics, and most defenders have not caught up.

Five years ago, the standard attack chain was: phish a credential, then deal with MFA. MFA defeated most casual attacks. The rise of phishing-resistant MFA was supposed to push that even further.

Session theft routes around the entire problem. The user already passed MFA when they originally logged in. The cookie issued at that point does not carry MFA state, it just represents an authenticated session. An attacker who imports that cookie inherits the post-MFA state.

Several incidents made this concrete:

Uber, 2022. The contractor whose credentials kicked off the breach was MFA-protected. The attackers used MFA fatigue to get in initially, but session theft from internal tools enabled lateral movement.

LastPass, 2022. A DevOps engineer's home computer was compromised. Stolen sessions and credentials enabled attackers to access encrypted vault backups.

Cisco, 2022. An employee's personal Google account had Cisco corporate credentials saved. Once the personal account was compromised, the attacker pivoted into the corporate environment, including via session reuse.

Numerous post-Snowflake incidents in 2024. Many of the affected accounts had no MFA, but for those that did, session token reuse from stealer logs was a common bypass.

The pattern keeps repeating because the economics keep working. A session cookie is worth more to an attacker than a password, but it costs the same on stealer markets.

How attackers exploit it

The session theft chain is short and reliable:

1. Infect a device. Almost always via infostealer malware (Lumma, RedLine, Vidar, StealC) installed through cracked software, malvertising, or fake downloads.
2. Exfiltrate cookies. The malware extracts every cookie from every browser profile on the machine, including session cookies for active SaaS sessions.
3. Package and sell. The cookies appear in stealer logs alongside credentials, system info, and other artefacts. Logs are sold on Telegram channels, Russian Market, and similar venues.
4. Import and replay. The buyer loads the cookies into their own browser using extensions designed for this (Cookie-Editor, EditThisCookie, or purpose-built tools). The target application sees a continuing session and grants access.
5. Operate. The attacker now has whatever access the user had. They read email, exfiltrate documents, send messages as the user, modify cloud configurations, or pivot to other systems.

The window of usefulness depends on session lifetime. A short-lived session (an hour) gives the attacker a small window. A long-lived session (the typical "remember me" 30-day cookie, or some SaaS sessions that effectively never expire) gives them a long one.

How to detect leaked sessions

Detection is harder than detecting credential theft, because session reuse often produces no anomalous signal.

The user's browser logs in normally and gets a cookie. The attacker imports that cookie and uses it from a different IP, possibly with a different user agent, possibly from a different geography. Some of these differences trigger detection. Many do not, especially when attackers use residential proxies in the user's home country.

Effective detection combines several signals:

• Stealer log monitoring. If a session cookie for your SSO or critical applications appears in a fresh stealer log, you know the user's machine is compromised right now.
• Impossible travel and concurrent session detection. If the same session is being used from two distant locations within minutes, one of them is not legitimate.
• User-agent and device fingerprint changes. A session that suddenly switches from Chrome on Windows to Firefox on Linux mid-conversation is suspicious.
• Behavioural anomaly detection. Unusual access patterns, downloads, mailbox rule changes, or admin actions during a session.
• Risk-based reauthentication. Force re-prompt when the application sees signals (new IP, sensitive action, long idle period).
• Token binding and device-bound credentials. Where supported, these prevent the cookie from being usable on a different device entirely.

The hardest case is the calm attacker who waits, blends in, and uses the session for a single high-value action. Detection in those cases relies on monitoring the action itself (a wire transfer, a configuration change, a data download) rather than the session.

How to remediate

When you have credible evidence of a leaked session:

1. Invalidate the session immediately. Force a logout across the user's account, on every application that supports server-side session revocation. SSO providers usually expose this. Some SaaS platforms make it harder than it should be.
2. Rotate the user's credentials. The attacker likely has the password too, since they came from the same compromised device.
3. Treat the device as compromised. Stealer logs do not produce just one cookie. They produce the whole bag. Assume every session and credential on that machine is gone.
4. Investigate prior usage. Check every application the cookie could have accessed for activity that does not match the user's normal behaviour. Look back at least to the date the stealer log was published, ideally further.
5. Hunt for follow-on activity. New mailbox rules, new OAuth grants, new MFA devices, new API tokens. Attackers establish persistence beyond the initial session.
6. Reimage the device. Cleaning the malware does not guarantee the device is clean. Reimage and rebuild.
7. Revoke and reissue every credential the user has access to. Including service accounts, API tokens, and saved credentials in tools like password managers if those were also compromised.

Best practices

• Shorten high-value session lifetimes. Cloud admin consoles, financial systems, and similar should expire sessions in hours, not weeks. The convenience cost is real but the security benefit is larger.
• Use device-bound credentials where possible. Modern protocols like DPoP, MTLS-bound tokens, and Credential Manager API integrations tie sessions to a specific device. Replay from another device fails.
• Adopt phishing-resistant MFA. FIDO2 and passkeys do not directly stop session theft, but they make many attack chains harder, and combined with token binding they raise the bar substantially.
• Monitor for stealer log appearances. This is the only way to know a user's sessions have been exfiltrated before the attacker uses them. Daily monitoring is the floor, real time is better.
• Force step-up authentication on sensitive actions. Wire transfers, configuration changes, admin escalation. A live MFA prompt at the moment of action defeats a stolen session that lacks the second factor.
• Build a session revocation playbook. When you find a compromised user, you should be able to invalidate their sessions across every SaaS in minutes, not days. Most organisations cannot do this cleanly. Practise it.
• Restrict session sharing across IP ranges and devices. Many SaaS platforms allow this configuration but ship with it disabled.

Why this is the dominant problem now

Credential phishing trained a generation of defenders to deploy MFA. MFA worked, mostly. The attackers adapted.

The shift to stealer-log-driven session theft in 2022 to 2024 was not subtle. It was the largest change in initial access economics since the rise of credential stuffing a decade earlier. The Mandiant and CrowdStrike threat reports for 2024 and 2025 both put session theft at or near the top of observed initial access techniques.

The defenders who got ahead of this treat session monitoring with the same urgency they once applied to phishing detection. Those who have not are still measuring their MFA coverage and wondering why it stopped reducing incidents.