Session cookie theft: the attack that walks around your 2FA

In January 2023, CircleCI disclosed a breach that made the security community uncomfortable for one specific reason: the attacker cracked no password, exploited no zero-day and never needed a single authentication code. Malware installed on an employee's device extracted the 2FA-protected SSO session token and, with that cookie in hand, kept unrestricted access to the company's infrastructure for weeks. The second factor was completely bypassed — not because it was misconfigured, but because the attack happened after the login.

That's session hijacking through cookie theft. And according to Bleeping Computer, it is the main objective of modern infostealers — more so than passwords themselves.

What a session cookie is

When you log in to any service — Gmail, GitHub, your bank, your work account — the server generates a unique identifier called a session cookie and sends it to your browser. That cookie works like a temporary badge: instead of asking for your password and 2FA on every click, the server checks the cookie and confirms "this browser is authenticated".

The problem is that the badge is transferable. If someone copies that cookie and presents it to the server from another device, the server has no way to tell the original holder from the impostor — after all, the badge is valid. Authentication already happened. 2FA was already approved. The cookie is the proof of it.

How the theft happens in practice

There are three main ways to steal active session cookies:

Infostealers that extract cookies from disk

Browsers like Chrome, Firefox and Edge store cookies in SQLite database files in the user's local profile. Infostealers — malware designed specifically for credential harvesting — read those files directly, decrypt the values (using the operating system's keys) and export everything to the attacker's server.

Storm, an infostealer that appeared in cybercrime networks in early 2026, offered exactly that capability for under US$1,000 a month on a subscription model, including extraction of cookies, saved credentials and cryptocurrency wallets. It isn't sophisticated malware — it's cheap, available and effective because most users don't expect local browser files to be an attack vector.

That kind of threat falls into the category of malware traditional antivirus rarely catches, especially when it runs quickly and then removes itself.

Malicious browser extensions

An extension installed in the browser has native access to the cookies of any domain its permissions cover. Malicious Chrome extensions have already been caught silently exfiltrating authentication tokens, with no user interaction beyond the initial install.

The difference from an infostealer is that the extension doesn't even need to decrypt anything — it operates inside the browser context, where the cookies are already decrypted and available through the API.

XSS and interception on open networks

Cross-site scripting (XSS) lets an attacker inject JavaScript into a vulnerable page and read cookies that don't have the HttpOnly flag set. On networks without HTTPS — still around in some legacy services — cookies can be captured in transit through network interception. Both vectors have technical mitigations on the server side (security flags on cookies, mandatory HTTPS), but they depend on correct implementation by the service's developers, not on the end user.

Why doesn't 2FA protect against session hijacking?

2FA authenticates the login, not the session. Once the server issues the cookie after a successful login with the second factor, that cookie represents an already-authenticated session. The server doesn't re-request 2FA on every request — that would be unworkable. So by presenting the stolen cookie from another device, the attacker arrives after the authentication gate, at a point where 2FA has already done (and finished) its job.

This is different from attacks like MFA fatigue, which try to trick the victim into approving the second factor. In session hijacking, 2FA is never even invoked — the attacker skips that step entirely.

How to protect yourself: 6 concrete measures

On the user's side, it's possible to shrink the attack surface considerably:

• Log out explicitly from sensitive services when you finish. Logging out invalidates the cookie on the server — a cookie stolen from a closed session no longer works.
• Review active sessions periodically. Google, GitHub, Microsoft and most major services show where your account is logged in. End unknown sessions immediately.
• Avoid unnecessary extensions. Every installed extension is an attack surface. Remove the ones you don't use and prefer those published by verified organizations, with a long track record and no excessive permissions.
• Keep the endpoint protected. An infostealer that never runs steals nothing. Keeping Windows on the right security settings, with an updated antivirus and SmartScreen enabled, significantly reduces the risk of malware executing.
• Use HTTPS everywhere. In 2026 that's nearly guaranteed, but legacy services without HTTPS still exist. If the padlock doesn't appear in the address bar, don't enter credentials and don't trust sessions.
• Consider passkeys. FIDO2/WebAuthn passkeys eliminate session cookies tied to traditional credentials. Authentication is bound to the device through asymmetric cryptography, and the resulting token isn't exportable the way a conventional cookie is.

What Chrome 146 did to mitigate it

In Chrome 146 (Windows), Google shipped Device Bound Session Credentials (DBSC), a protection that cryptographically binds the session cookie to the device where it was created. In practice, even if an infostealer manages to extract the cookie from disk, it can't use it on another device — presenting the cookie requires proof of possession of a private key that never leaves the hardware security chip.

DBSC isn't magic: it requires server support (services have to adopt the protocol), and the protection is limited to scenarios where the cookie is used from another device. If the attacker operates on the same compromised device, DBSC doesn't help. But it's a real advance against the classic infostealer vector, which is precisely the most prevalent one.

The lesson that sticks

Authentication security goes beyond the moment of login. The token you receive after authenticating with a password, 2FA and biometrics is as valuable as the password itself — and often less protected. Treating session cookies as disposable credentials (logging out, reviewing active sessions, keeping the device clean) is the most effective defense an end user has today, while the industry standardizes protections like DBSC.

If you want to understand the other vectors attackers use to bypass modern authentication, the post on MFA fatigue and push bombing covers the social engineering side — the direct complement to what we saw here.