Stolen session cookies: how attackers bypass MFA and how to revoke access

Session cookie theft is the reuse of a stolen, already-authenticated session token to impersonate a user without their password or a second factor. Infostealer malware lifts the cookie from the browser, and a buyer replays it to log in as the victim. Because the session is already trusted, the attacker skips both the password and the MFA prompt. SpyCloud recaptured 17.3 billion stolen session cookies from infected devices in 2024.

What is a session cookie, and why does it count as a credential?

A session cookie, also called a session token, is the small piece of data a server hands your browser after you sign in, so it recognizes you on every later request without re-checking your password. That makes it a bearer credential: whoever holds the token is treated as the logged-in user. Steal it, and you inherit the session. Recorded Future found 276 million credentials indexed in 2025 came bundled with an active session cookie (Recorded Future).

The key property is that the token stands in for the whole authentication ceremony. The password check, the MFA prompt and any passkey step all happen once, at login. After that, the session token is the proof, and it's what the browser sends on every request. An attacker who replays it never faces the checks the user already passed.

• Session cookies: browser tokens that keep a web app signed in until they expire or are revoked.
• OAuth refresh tokens: long-lived tokens that silently mint new access tokens without another login.
• SSO and SAML assertions: single-sign-on artifacts that open many linked apps at once.
• Access tokens (JWTs): short-lived bearer tokens, often valid for about an hour by default (Microsoft Entra docs).

How do infostealers steal session cookies?

Infostealers read the browser's own cookie store and copy it wholesale. Once a device is infected, the malware decrypts the cookie database, scrapes saved logins and autofill, and ships the bundle to the operator in seconds. SpyCloud measured an average of 1,861 cookies harvested per infection in 2024 (SpyCloud). One sweep of one browser can expose hundreds of active sessions.

The result is a stealer log: a snapshot of one device holding cookies for email, SSO, cloud consoles and internal apps, each paired with the URL it belongs to. A buyer doesn't need to guess where a cookie works, because the log says so. As SpyCloud puts it, session hijacking lets an attacker impersonate legitimate users without the need for credentials, MFA, or passkeys (SpyCloud).

How does replaying a stolen cookie bypass MFA?

About 31% of malware-stolen credentials in 2025 shipped with a session cookie ready to replay (Recorded Future). MFA guards the login event, not the session that follows it. When an attacker imports a stolen cookie into their own browser, the app sees a session that already cleared authentication, so it never asks for a password or a second factor. Recorded Future describes session hijacking as an attack that skips the login process altogether (Recorded Future). The control fired once, and the token outlived it.

Concretely, cookie replay runs in four steps, and none of them touch the MFA prompt the user already answered:

• The victim signs in normally, clears MFA, and the app issues a session cookie to the browser.
• An infostealer on the device copies that cookie and exfiltrates it inside a stealer log.
• A buyer imports the cookie into their own browser or an anti-detect tool matched to the victim's fingerprint.
• The app validates the session and grants access. No password, no MFA prompt, no anomaly at the login form.

Why doesn't a password reset kill a stolen session?

SpyCloud recaptured 17.3 billion stolen cookies in 2024, and a reset touches none of them (SpyCloud). Because the password and the session token are two separate credentials with separate lifetimes. Resetting the password invalidates a secret the attacker may not even be using, while the stolen cookie keeps working until it expires or is explicitly revoked. Microsoft's own guidance is blunt: to end a session you must revoke the token, and for app-issued session tokens the application, not the identity provider, has to do it (Microsoft Entra docs).

This is the gap most incident playbooks leave open. A team detects a compromised account, forces a password change, and calls it contained, while the replayed session quietly stays live. Containment means killing the active session, not only rotating the secret behind it. The stolen token is the credential in use.

How do you actually revoke a stolen session?

On Microsoft Entra, an access token can stay valid for up to 1 hour unless you revoke it (Microsoft). You revoke the session itself, then force the next request to reauthenticate. In Microsoft Entra that means blocking sign-in and calling revoke on the user's sessions, which invalidates the refresh tokens so no new access tokens can be minted (Microsoft Entra docs). Because a default access token can live for about an hour, revocation alone still leaves a short window unless you also enforce continuous evaluation.

• Invalidate sessions: revoke refresh tokens and sign-in sessions for the user, not just the password.
• Rotate what the token reaches: reset the password and any API keys or app secrets the session could reach.
• Force reauthentication: apply conditional access so the next request must re-prove identity with phishing-resistant MFA.
• Close the token window: enable Continuous Access Evaluation (CAE) so revocation lands in near real time, not after the token expires (Microsoft Entra docs).
• Revoke at the app too: app-issued session tokens must be killed by the app, since the identity provider can't revoke them for you.

One more shift matters: shorten session lifetimes and bind tokens to a device or client where you can. A stolen cookie is only useful while it's valid, so the smaller the window and the tighter the binding, the less a replayed token buys an attacker.

How do you detect stolen session cookies before they're replayed?

You watch the criminal supply of stealer logs for your domains, because the theft happens on devices your controls never see. Stolen credentials move fast once indexed: Recorded Future found 36.4% surface within 24 hours of exfiltration and 52.9% within a week (Recorded Future). Waiting for a suspicious login means reacting after the replay, not before it.

This is post-compromise exposure monitoring, and it's the model Ashetrace is built around: find every exposed identity and session tied to a domain you control, confirm what is still live, and hand your team an auditable list to revoke. You verify a domain you own, and no passwords, cookies or tokens ever change hands. The useful question isn't whether your users' cookies leak, it's how fast you cut the live sessions once they do.