Cookie Theft and Session Hijacking: How Attackers Steal Sessions and How to Stop Them

TL;DR: post-authentication session token replay across devices

• The gap: Every pitch deck treats MFA as the finish line. Cookie theft calls the bluff. MFA authenticates the login event, and a stolen session cookie is the receipt that proves login already happened, so the server hands over the account with no second prompt.
• The evidence: SpyCloud recaptured over 17 billion stolen credential records from the criminal underground in 2024, and DBSC only covers Chrome 146+ on Windows. cside fingerprints devices across 250+ signals at 99.7% accuracy to catch the moment a cookie is replayed from the wrong machine.
• The decision: Any team relying on MFA plus HttpOnly to guard live sessions is exposed. Add runtime script monitoring for token exfiltration and device-level behavioral scoring this quarter, before an infostealer sale on Telegram becomes your incident.

Short on time? See cside's account-takeover detection. It covers everything below in one deployment.

Cookie theft is when an attacker captures the session token a website issued after a user logged in and replays it from a different device. The attacker inherits the user's access without knowing their password. No MFA prompt fires. The user stays logged in and notices nothing; both sessions run in parallel.

The reason MFA does not stop this is structural. MFA authenticates the user at the login event. After login, the server relies on the session cookie, a time-limited credential that proves the browser already passed authentication. A stolen cookie is proof the browser already passed. The server cannot tell the difference between the real user and the attacker unless it checks something beyond the token itself.

Security researchers call this a pass-the-cookie attack. It is the dominant technique behind a large share of account takeovers in 2026.

How session hijacking works

The attack chain is the same regardless of how the cookie was obtained.

1. The user authenticates. The browser completes login and MFA. The server issues a session cookie, a long random string, and sends it back with the response.
2. The attacker captures the cookie. This happens through infostealer malware, a phishing proxy, or a malicious script running in the page.
3. The attacker replays the cookie. From their own browser or a script, they set the stolen cookie and send a request to the target site.
4. The server sees a valid session. The cookie is active and was issued to an authenticated user. Access is granted.

The legitimate session remains open. The user is still browsing on their device; the attacker is browsing the same account on theirs.

Three ways attackers steal session tokens

Infostealer malware

Infostealer malware is the most common route. Families like Lumma, Vidar, and RedLine sweep the browser's on-disk cookie store, extract session tokens for hundreds of sites, and transmit them to an attacker-controlled server within minutes of infection. SpyCloud's 2025 Annual Identity Exposure Report recaptured over 17 billion stolen credential records from the criminal underground in 2024. Stolen session cookies reach Telegram markets within hours of a successful infection.

The browser's cookie store is a local file, plaintext or a local SQLite database. Any process running with the user's privileges can read it. Infostealers do not intercept network traffic; they read from disk after the browser has already decrypted the data.

Adversary-in-the-middle (AiTM) phishing

AiTM phishing places a reverse proxy between the victim and the real login page. The victim sees an exact visual copy of the login, enters credentials, and completes MFA. The proxy forwards everything to the real site and captures the resulting session cookie on its way back. The attacker now holds a valid post-authentication token without having passed MFA themselves.

This technique defeats traditional anti-phishing controls because the page looks authentic, the MFA prompt completes against the real service, and the victim logs in normally. Only the attacker's proxy sits in the middle, invisible.

Malicious third-party scripts and XSS

An XSS vulnerability or a compromised third-party script can extract session tokens from the browser at runtime. JavaScript running in the page's origin context can read cookies not flagged HttpOnly, encode them, and exfiltrate them in requests that look like routine analytics calls.

This is the client-side supply-chain vector: the attacker does not target your site directly but compromises an analytics tag, chat widget, or payment library that your site trusts and loads on every page. The skimmer arrives inside code the site already considers safe.

Why standard defenses miss this

The HttpOnly flag

HttpOnly prevents JavaScript from reading the cookie via document.cookie. It blocks XSS token reads for that specific cookie, which matters. But it does nothing against infostealer malware that reads the cookie directly from disk after the browser has stored it, and it does not protect against an AiTM proxy capturing the token over the network before it reaches the protected store.

HTTPS and TLS

TLS encrypts traffic in transit and stops passive network sniffing. Infostealers read from disk, after decryption. AiTM proxies terminate TLS on both sides of the connection. Neither is stopped by transport encryption alone.

MFA

MFA verifies the user at login. After login, the server relies on the cookie alone. A stolen cookie never triggers another MFA prompt unless the server forces re-authentication based on device or behavioral signals, which most servers do not do on every request.

Device-bound sessions and DBSC

The structural fix for pass-the-cookie attacks is binding the session to the hardware that created it. A stolen cookie becomes useless if the server requires cryptographic proof that the browser still controls a specific device-held private key.

Google's Device Bound Session Credentials (DBSC) protocol does this using the device's TPM or Secure Enclave. On Chrome 146+ for Windows, the browser generates a private key in hardware during session establishment. Short-lived session cookies are issued only as long as the browser can prove possession of that key. An attacker who steals the cookie from another device cannot refresh it without the private key.

DBSC is a meaningful advance against replay attacks. The practical limits as of mid-2026:

• Coverage: Chrome 146+ on Windows is the primary deployment. iOS, Firefox, and Safari do not yet support DBSC.
• Fallback paths: when no TPM is present or a network error occurs during key verification, DBSC may skip binding. That session then behaves like a conventional cookie.
• On-device malware: if an infostealer runs on the same machine holding the private key, the attacker can use the session from that device. DBSC addresses off-device replay, not same-device compromise.

These gaps mean DBSC is one layer, not a complete solution.

Session hijacking prevention: a layered checklist

No single control is complete. Infostealers defeat transport controls. AiTM proxies defeat MFA and HTTPS at the session layer. HttpOnly limits one JavaScript read vector but not disk reads. The layered model works because each control defeats what the others miss.

Detecting a hijacked session in the live browser

Prevention reduces the probability of token theft. Detection catches the session that was already stolen and is being replayed.

cside runs as a single first-party JavaScript snippet in the visitor's browser with no proxy and no DNS changes. It monitors what third-party scripts and the session itself actually do on the live page for real users, not what a crawler or scanner observes at code rest.

Token exfiltration at the source. A third-party script that attaches unexpected event listeners to form fields, reads cookie values outside normal analytics calls, or sends data to an unknown domain fires a detection signal before the token leaves the page. This closes the XSS and supply-chain vector before a cookie is stolen in the first place. The same runtime monitoring also catches affiliate cookie stuffing and link hijacking, where injected scripts drop attacker-controlled affiliate cookies or rewrite outbound links to redirect attribution, a distinct but equally invisible browser-layer attack.

Device mismatch on replay. When a stolen cookie is used from a different device, the session's fingerprint changes. cside's device intelligence builds a persistent device ID from 250+ browser, hardware, and network signals at 99.7% accuracy. A fingerprint mismatch after an established session is an anomaly the behavioral scoring layer flags for re-authentication or block.

Behavioral signals. Automated session replay from a script or an AI agent produces patterns that differ from real human sessions: no realistic mouse movement, no scroll variance, no natural typing cadence. cside's behavior-level signals separate automation from genuine use.

cside also integrates AI agent detection, catching orchestration tools and automated browsers that replay stolen sessions or run scripted account access at scale.

PCI DSS 4.0.1 and session security on payment pages

For e-commerce and payment platforms, the client-side script and XSS vectors that exfiltrate session tokens are the same risks PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 target. Requirement 6.4.3 mandates a script inventory and authorization method for every script on payment pages. Requirement 11.6.1 requires continuous monitoring and alerting on unauthorized changes to payment-page scripts and HTTP security headers.

A malicious third-party script exfiltrating a session token or payment card data on a checkout page is precisely the threat those requirements address. cside automates both controls and produces QSA-ready weekly reports (VikingCloud-validated). Monitoring that catches a rogue script stealing session tokens also satisfies the tamper-detection mandate QSAs now assess.

PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 are mandatory and have been assessed since 1 April 2025.