Pass-the-Cookie: How Stolen Session Tokens Bypass Your MFA (And How to Stop It in 2026)

Multi-factor authentication is supposed to be the wall that stops account takeover. Yet in the incident calls I take with small businesses, the most common breach pattern of the last 18 months has nothing to do with cracking a password or intercepting a code. The attacker already had a valid, fully authenticated session. They never saw the password. They never triggered an MFA prompt. They simply imported a stolen cookie into their own browser and the application treated them as you.

This is pass-the-cookie, and it is the single most underrated threat to MFA-protected accounts in 2026. If you have hardened your logins with authenticator apps or even passkeys but you have done nothing about session tokens, you have locked the front door and left the side window open. This article breaks down exactly how the attack works, why MFA does not stop it, and the specific controls that do.

What a session cookie actually is, and why attackers want it

When you log in to a web application and clear the MFA challenge, the server does not ask you to re-authenticate on every click. That would be unusable. Instead it issues a session token — a string stored as a cookie in your browser (or as a refresh/access token in a desktop or mobile app). For the lifetime of that token, every request your browser sends carries it, and the server says "I already verified this human, let them through."

That token is, functionally, your identity in a string. It represents the completed authentication, including the MFA step. Anyone holding a valid token gets the access without redoing any of the checks. By default, most cookies are not tied to the specific machine that received them, which means a token copied to a different computer on a different continent still works. That is the entire premise of the attack.

In my experience securing Microsoft 365 and Google Workspace tenants, defenders consistently overinvest in the login event and underinvest in what happens after it. Attackers have noticed. The session has become the target.

The two ways your cookies get stolen

1. Infostealer malware (the silent grab)

Infostealers like Lumma, StealC, Redline, Vidar, and Rhadamanthys are commodity malware sold as a service for as little as a few hundred dollars a month. A user runs a cracked game, a fake software installer, or pastes a malicious PowerShell command from a fake CAPTCHA, and within seconds the stealer harvests every cookie, saved password, and autofill record from Chrome, Edge, Firefox, and Brave.

Historically, Chromium browsers encrypted cookies with a key that the stealer could decrypt on the same machine. Google's App-Bound Encryption raised the bar, but stealer developers adapted within weeks using techniques that abuse the browser's own elevation service. Treat browser-stored session data as harvestable if the device is compromised. The stolen cookies are packaged into logs and sold in bulk on marketplaces and Telegram channels, sometimes within hours of theft.

2. Adversary-in-the-Middle phishing (the live intercept)

The second path does not need malware on your machine at all. AiTM (adversary-in-the-middle) phishing kits — Evilginx, Tycoon 2FA, EvilProxy, Mamba 2FA — sit as a reverse proxy between you and the real login page. You receive a phishing link, you land on what looks exactly like the Microsoft or Google sign-in page (because it is the real page, proxied), you type your password, you approve the MFA prompt on your phone. Everything works. You are logged in.

But the proxy captured the session cookie the server issued at the end of that flow. The attacker now replays it. This is why I tell clients bluntly: standard app-based MFA and SMS codes do not stop AiTM phishing. The user did everything right and still handed over a live session.

How the stolen cookie is used: pass-the-cookie in practice

The mechanics are almost insultingly simple. The attacker opens their own browser, installs a cookie-editor extension (or uses a stealer log import tool), pastes in your stolen cookie values for the target domain, and refreshes the page. The application sees a valid session and loads your mailbox, your admin console, your file storage. No password prompt. No MFA challenge. No new sign-in event that looks suspicious, because from the application's perspective the session never ended.

What I see attackers do next, in roughly this order:

• Create inbox rules to auto-forward or hide emails, so they can run invoice fraud without the victim seeing the replies.
• Register their own authenticator or add a passkey, establishing persistence that survives a password reset.
• Enumerate OAuth app consents and grant a malicious app long-lived access, so even revoking the session does not lock them out.
• Pivot to other users by sending internal phishing from the trusted account.

The dangerous part for your recovery: if you only reset the password, you have not killed the stolen session and you have not removed the persistence they added. I have watched organizations "resolve" an incident three times before realizing the attacker still held a valid token and a malicious OAuth grant the entire time.

Why this is a YMYL-level risk for small business

For an individual, a hijacked session might mean a drained email account. For a small business, it routinely means wire fraud, payroll diversion, and customer data exposure that triggers breach-notification obligations. The Canvas/Instructure and similar mass incidents show how far stolen credentials and sessions propagate downstream. If you handle money, health data, or customer PII, treat session-token theft as a financial and legal exposure, not just an IT nuisance.

The defenses that actually work

Here is the uncomfortable truth: you cannot fully prevent cookie theft with user training alone. You need controls that make a stolen cookie useless on a different device. These are the measures, ordered by impact.

1. Bind tokens to the device (the real fix)

This is the control that defeats pass-the-cookie at the root. Two technologies matter in 2026:

• Device Bound Session Credentials (DBSC) — a Chrome capability that ties the session to a private key stored in the device's TPM. The key never leaves the machine, so a cookie copied to another computer cannot be replayed because it cannot prove possession of the key. Google has been rolling this out for its own accounts and exposing it to enterprises; enable it where your identity provider and browser support it.
• Token Protection / token binding in Microsoft Entra Conditional Access — binds sign-in session tokens to the specific device. A token lifted from that device fails when replayed elsewhere. Build a Conditional Access policy that requires token protection for your high-value apps (Exchange Online, SharePoint, admin portals).

If you do one thing after reading this, it is this category. Device binding turns a stolen cookie into a worthless string.

2. Deploy phishing-resistant MFA to kill the AiTM vector

AiTM proxies break against FIDO2 passkeys and hardware security keys (YubiKey, Titan), because the cryptographic challenge is bound to the legitimate origin. The proxy domain is not the real domain, so the passkey simply refuses to authenticate. This does not stop infostealer-based cookie theft after a valid login, but it removes the entire live-phishing path. Combine it with device binding and you have closed both doors. Migrate admins and finance staff to passkeys first.

3. Enable Continuous Access Evaluation and short session lifetimes

Continuous Access Evaluation (CAE) in Entra lets the identity provider revoke an active session in near real time when risk is detected — a sudden country change, a disabled account, a credential reset — instead of waiting for the token to expire an hour later. Turn it on. Pair it with sensible token lifetimes; an attacker's window shrinks dramatically when sessions re-evaluate continuously rather than persisting for days.

4. Build risk-based Conditional Access

Policies I configure on nearly every tenant:

• Require compliant or hybrid-joined devices for access to email and admin apps, so an unknown attacker machine is rejected even with a valid token.
• Block legacy authentication protocols outright.
• Trigger step-up authentication or session revocation on medium/high sign-in risk.
• Restrict admin portal access to a small set of known IP ranges or managed devices.

5. Stop browsers from being a credential vault on endpoints

Because infostealers feast on browser storage, reduce what they can take. Do not save passwords in the browser; move users to a dedicated password manager with a strong master credential and 2FA on the vault itself. Run a reputable EDR that detects stealer behavior, and treat any "paste this command" or fake-CAPTCHA instruction as malware until proven otherwise — the ClickFix technique is the number-one stealer delivery method I see right now.

6. Lock down OAuth consent

Since attackers establish persistence through malicious app consents, disable user consent for unverified third-party apps and require admin approval. Audit existing enterprise app grants and remove anything you do not recognize. A stolen cookie that cannot grant a rogue app long-term access is far less valuable.

If you suspect a session was hijacked: the response that actually evicts the attacker

Resetting the password is necessary but nowhere near sufficient. Work this sequence:

• Revoke all active sessions and refresh tokens immediately. In Microsoft 365, run Revoke-MgUserSignInSession (Microsoft Graph PowerShell) for the affected account, or use "Revoke sessions" in the Entra admin center. In Google Workspace, the admin can sign the user out of all sessions from the Admin console; users can hit "Sign out all other sessions" under Security in their account.
• Reset the password after revoking sessions, not before — order matters so the new session is clean.
• Review and remove unrecognized MFA methods and passkeys. Attackers add their own.
• Audit OAuth app consents and inbox/forwarding rules. Delete malicious app grants and any auto-forward, redirect, or "hidden" rules.
• Check sign-in logs for the foreign session, the source IP, and what was accessed, to scope the incident and meet any notification duty.
• Re-image the endpoint if an infostealer is suspected. The cookies were taken from a compromised machine; cleaning a single account does not remove the malware that will simply steal the next session.

The mindset shift

For years the security message was "turn on MFA and you are protected." That message is no longer complete, and repeating it gives people false confidence. MFA protects the act of logging in. Pass-the-cookie attacks ignore the login entirely and target what comes after it. The defenders who stay ahead in 2026 are the ones who treat the session as a credential worth protecting — binding it to a device, revoking it fast, and assuming any unbound token can and will be stolen.

Start with device-bound sessions and phishing-resistant MFA for your highest-value accounts this week. Those two controls, working together, turn the most common account-takeover pattern of the year into a dead end.

About the author: Fanny Engriana is the founder of Warung Digital Teknologi with 12+ years in engineering and security operations, specializing in identity protection and incident response for small and mid-sized businesses. The guidance here reflects first-hand work hardening Microsoft 365 and Google Workspace environments against session-based attacks.