Stolen Cookies: The Attack That Walks Right Past Your MFA
Your team uses strong passwords. You rolled out MFA. Maybe you even moved to passkeys. And yet an attacker can still walk into your SaaS apps without ever seeing a password or a login prompt.
All they need is a cookie.
Session cookie theft (also called session hijacking or "pass-the-cookie") has quietly become one of the most effective ways into modern organizations. It doesn't break your authentication. It skips it. In this post we'll look at how cookies get stolen, which authentication platforms are exposed, three real breaches that started this way, and why continuous verification, the model NearAuth.ai is built on, changes the math.
What a session cookie is, and how it gets stolen
When you log in to a web app, the server checks your password and MFA once. Then it hands your browser a session cookie: a token that says "this person already proved who they are." Every request after that just shows the cookie. No password, no MFA prompt.
That convenience is the weakness. A session cookie is a bearer token: whoever holds it is treated as you. Copy it into another browser on another continent, and most apps can't tell the difference until the session expires.
Attackers get these cookies three main ways:
- Infostealer malware. Commodity stealers sweep browser profiles for saved cookies and passwords and ship them to the attacker within minutes. Often the infection comes from a fake download, a cracked tool, or a malicious attachment, and signature-based antivirus frequently misses it.
- Adversary-in-the-middle (AiTM) phishing. A fake login page proxies the real one in real time. The victim types their password and approves their MFA, the real site issues a session cookie, and the proxy keeps a copy. (More on this in how second-factor phishing works.)
- Leaked files and logs. Browser debug captures (HAR files), crash dumps, and support tickets can contain live session tokens. Hand one to the wrong place and you've handed over a logged-in session.
Which platforms are exposed? Almost all of them
Cookie theft works against any platform that verifies identity once at login and then trusts a portable session token. That describes nearly every mainstream setup: Microsoft 365 and Entra ID, Google Workspace, Okta and other SSO providers, apps protected by push MFA like Duo, cloud consoles such as AWS, and SaaS tools like GitHub, Slack and Salesforce. If the attacker grabs the cookie your SSO provider issues, they often inherit every app behind it.
The MFA method matters for how the cookie can be stolen, but not for whether a stolen cookie works:
| Login method | Stops AiTM phishing? | Stops a stolen cookie being replayed? |
|---|---|---|
| Password only | No | No |
| SMS or email codes | No | No |
| Authenticator app (TOTP) | No | No |
| Push approval (e.g. Duo, Okta Verify) | No | No |
| Passkeys / FIDO2 security keys | Yes | No |
| Continuous, device-bound presence checks | Yes | Designed to, where it controls access |
That second-to-last row surprises people. Passkeys are excellent and phishing-resistant, because the key won't sign for a fake domain. But once the real site issues a session cookie, an infostealer on the laptop can still take it. Strong login is necessary. It just isn't sufficient.
Three breaches that started with a cookie
CircleCI (December 2022)
On December 16, 2022, malware landed on a CircleCI engineer's laptop and went undetected by antivirus. It stole the engineer's valid, 2FA-backed SSO session, letting the attacker impersonate them from a remote location. Because that engineer could generate production access tokens, the attacker exfiltrated customer environment variables, tokens and keys. Three days passed between infection and access, and three more before exfiltration. CircleCI had to ask every customer to rotate every secret. MFA was in place the whole time; it simply never got asked again.
Linus Tech Tips (March 2023)
On March 23, 2023, the 15-million-subscriber Linus Tech Tips YouTube channel and two sister channels were taken over and used to stream crypto scams. Linus Sebastian explained afterward that the attacker never needed a password or 2FA code: an employee opened a malicious file, and malware copied the browser's session tokens. Linus's own proposed fix was telling: re-authenticate users when sensitive things change, like location or channel name.
Okta support system (Fall 2023)
Between September 28 and October 17, 2023, an attacker accessed Okta's customer support system and the HAR files customers had uploaded for troubleshooting. Some contained live session tokens. Attackers used them to hijack Okta sessions at five customers, including 1Password, BeyondTrust and Cloudflare. BeyondTrust saw the attacker try to use a cookie within 30 minutes of its admin uploading the file. Afterward, Okta began binding administrator session tokens to network location, a direct admission that a free-floating cookie is a liability, even at an identity provider.
Why point-in-time authentication can't win this fight
Every breach above shares one flaw: identity was checked once, then trusted for hours. The cookie became the identity. Stronger login prompts don't fix that, because the attacker never sees a login prompt.
NearAuth.ai approaches the problem differently. Instead of asking "did this person log in correctly earlier?", it keeps asking "is this person actually here, right now?"
- Presence is tied to a physical device. NearAuth.ai checks that your registered phone is next to your registered computer with an encrypted Bluetooth handshake, signed with keys that stay on the devices. A cookie copied to an attacker's machine in another city doesn't come with your phone.
- Verification keeps going after login. Instead of trusting a single morning sign-in, NearAuth.ai keeps re-checking that the phone is nearby during the day. When the phone leaves, NearAuth.ai records the moment, so activity in that gap stands out. See our post on authentication tracking for how those records work.
- No prompts to phish or bomb. Because the check is local and ambient, there's no push notification for an attacker to spam and no code to relay through a fake login page. More on that in Kill the Push: the Duo alternative.
The result: where NearAuth.ai controls access, a stolen cookie stops being a skeleton key. Without your phone next to your computer, the session shouldn't stay trusted for long. And your people get fewer interruptions, not more.
To be straight about the limits: if another service, say Microsoft or Google, has already issued a cookie and an attacker copies it, that service decides whether to accept it, and no sign-in method can see that happen. That's why short session lifetimes, token binding and the steps below still matter. Presence makes stolen sessions much harder to use and much easier to spot. It works best alongside those controls, not instead of them.
What to do this quarter
- Assume MFA can be bypassed after login. Audit which apps trust a session for hours without re-checking.
- Shorten and bind sessions. Cut session lifetimes for admin and production access, and require step-up checks for sensitive actions.
- Harden endpoints against infostealers. Add behavior-based EDR, not just signature antivirus, and keep personal browser profiles off managed machines.
- Sanitize what you share. Strip cookies and tokens from HAR files and logs before sending them to any vendor.
- Move to continuous verification. Replace one-time checks with presence-aware sessions so a stolen cookie isn't enough on its own.
Passwords got stolen, so we added MFA. MFA got phished, so we added passkeys. Attackers responded by skipping login entirely. The next step is authentication that doesn't stop at the front door.
NearAuth.ai is free for teams of up to 12 people, and most teams protect their first five people in about 15 minutes with Google Workspace or Microsoft 365.
chris@nearauth.ai