Session cookie theft

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. Attackers get hold of these cookies in two main ways. Infostealer malware (RedLine, Lumma, and successors) sitting on an endpoint reads browser storage directly and exfiltrates cookies alongside saved passwords. Separately, support and diagnostic tooling routinely collects artifacts, HAR files, log bundles, browser exports, that were never designed as credential stores but happen to contain live cookies, so a breach of the tooling becomes a breach of every session captured inside it.

Once an attacker has the cookie, they import it into their own browser using standard extensions or scripts and are logged in as the victim immediately. There is no login form to fill, no password to guess, and no MFA prompt to face, because the session already cleared all of that.

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. Most applications also do not bind the cookie to the device or IP that first obtained it, so a copy is exactly as good as the original anywhere it is used. The industry's heavy 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

• A session used from an IP, ASN, device, or user agent that has never appeared for that account, with no corresponding new interactive login event.
• Session activity continuing normally after a password reset or MFA re-enrollment, which a stolen but unrevoked cookie will do since the reset does not touch it.
• Anomalous velocity between two locations using the same session in a timeframe that rules out normal travel.

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 will show exactly the IP change this detection looks for. This needs correlation with device fingerprinting and behavioral baselines, not a standalone blocking rule.

How to stop it

• Shorten session lifetimes and re-evaluate risk continuously rather than trusting a long-lived cookie for its full validity window.
• Bind sessions to a device or client with DPoP or mutual TLS, so a copied cookie fails everywhere except the device that obtained it.
• Sanitize diagnostic and support artifacts (HAR files, log exports) to strip cookies and tokens before they are stored anywhere.
• Deploy endpoint protection to catch infostealers before they read browser storage, and treat browser credential stores as a protected surface.
• Rehearse full session revocation as part of incident response, since a password reset alone leaves an already-issued session alive. See token theft.

Seen in the wild

• Infostealers and session hijacking: stealing the session, skipping the login
• Okta's 2023 support-system breach: when your IdP gets phished
• Mirage2FA reached 4,500 organizations by stealing sessions instead of breaking MFA

Sources

• MITRE ATT&CK T1539: Steal Web Session Cookie
• OWASP Session Management Cheat Sheet