Session Hijacking: How Stolen Cookies Let Attackers Skip Past MFA

Multi-factor authentication is the single control most small businesses lean on to stop account takeover, and for good reason: it stops the vast majority of password-based attacks cold. But MFA only guards the moment you log in. Once you're authenticated, your browser stores a session cookie (sometimes called a token) that says, in effect, "this device already proved who it is, let it through." Session hijacking, also called cookie theft or pass-the-cookie, steals that cookie and hands an attacker the same access, no login screen, no MFA prompt, no password required.

How a session actually gets stolen

Two methods account for most real-world cases. The first is adversary-in-the-middle (AiTM) phishing: an employee clicks a convincing link, lands on a proxy site that sits invisibly between them and the real login page, and enters their password and MFA code exactly like normal. The proxy passes everything through in real time, so the login succeeds, but it also silently copies the session cookie that comes back and hands it to the attacker. The employee is now logged in, and so is the attacker, using the exact same session. The second method is infostealer malware, often delivered through a fake software update, a cracked download, or a malicious browser extension, which simply reads saved cookies straight out of the browser and uploads them to the attacker without needing to phish anything.

Why this matters more as small businesses adopt MFA

• It bypasses the control you're relying on. The more a business leans on MFA as its main defense, the more attackers lean on session hijacking as the workaround, since it doesn't touch the second factor at all.
• Access can last as long as the session does. Many business apps keep sessions valid for hours, days, or until an active sign-out, giving an attacker a long window to read email, download files, or set up persistent access before anyone notices.
• It's quiet by design. Because the attacker is reusing a session that already passed authentication, there's no failed-login alert and often no new MFA prompt to tip anyone off.
• Stolen sessions are for sale. Infostealer logs containing thousands of harvested cookies circulate on criminal marketplaces, making this a commodity attack rather than a rare, targeted one.

What actually stops it

• Shorter session lifetimes and continuous conditional access, so a session token is re-checked against device compliance and location on an ongoing basis, not just once at login — this shrinks the window a stolen cookie is useful.
• Phishing-resistant MFA like passkeys, which are tied to the real site's domain and can't be relayed through an AiTM proxy the way a typed password and code can.
• Endpoint detection and response (EDR) on every device, to catch the infostealer malware that harvests saved cookies before it can exfiltrate anything.
• A managed browser extension policy that blocks unapproved installs, since malicious extensions are one of the quieter ways cookies get read and sent out.
• Sign-in log monitoring for impossible travel or new-device activity immediately following a legitimate login, which is often the only visible sign a session was reused somewhere it shouldn't have been.

Where this fits

• The OAuth app phishing post, for another way attackers keep access to an account without ever needing your password.
• The MFA fatigue post, for how attackers defeat weaker MFA at the login step itself, before a session ever exists.
• The passkeys post, for the phishing-resistant login method that closes off the AiTM proxy route entirely.
• The EDR vs. antivirus post, for the endpoint protection that catches infostealer malware before it can harvest a cookie.
• The cybersecurity page, for where identity and session security fit into a full security program.

FAQs about session hijacking

Can session hijacking happen even if I use MFA?

Yes, and that's exactly why it's dangerous. MFA protects the login step, but session hijacking skips the login step entirely. Once you've authenticated once, whether with a password and a code or a passkey, your browser holds a session cookie that proves you're already signed in. An attacker who steals that cookie is handed the same access without ever seeing your password or your MFA prompt. Phishing-resistant MFA like passkeys stops the theft method that captures the cookie in real time, but it doesn't help if the cookie is stolen afterward by malware already on the device.

How would I know if my session has been hijacked?

There's often no obvious sign from the user's side, since the attacker is using a valid, already-authenticated session rather than triggering a new login prompt. The tell usually shows up in the logs: a sign-in or activity event from an unfamiliar location or device right after a legitimate one, sometimes called impossible travel, or a burst of unusual activity in email or cloud storage. This is why conditional access policies that check device and location on every request, not just at login, matter as much as the initial authentication.

What's the difference between session hijacking and a stolen password?

A stolen password still has to get past MFA before an attacker can use it, which is the barrier that stops most account takeovers today. Session hijacking steals the proof of a login that already cleared MFA, so there's no second factor left to get past. It's the difference between stealing someone's house key and stealing their unlocked, running car with them already inside; one still faces a locked door, the other doesn't.