The MFA Paradox
Multi-factor authentication was supposed to end credential-based account takeover. For most organizations, it did, until attackers stopped trying to guess passwords and started stealing the thing that gets issued after login. Session hijacking via stolen cookies is now the preferred path around MFA, and it works precisely because the authentication event already happened. The attacker is not logging in. They are reusing a session the victim's browser already established.
This technique, commonly called pass-the-cookie, is the reason security teams keep finding compromised accounts that never generated a failed login, never triggered an impossible-travel alert, and never prompted an MFA challenge. The session token was valid. The device fingerprint matched well enough. Everything about the request looked routine to the identity provider, because from its perspective it was a legitimate continuation of an authenticated user's day.
How Pass-the-Cookie Attacks Actually Work
When a user successfully authenticates to a SaaS application, the identity provider issues a session artifact. Depending on the platform, that artifact lives in the browser as:
- An HTTP session cookie tied to the application's domain
- A refresh token stored in local or session storage
- An OAuth bearer token held in an in-memory or persistent store
- A primary refresh token (PRT) on Windows for Microsoft Entra
Infostealer malware running on the victim's machine scrapes these artifacts straight out of browser SQLite databases, the Windows DPAPI store, or process memory. The attacker then imports those cookies into their own browser (Cookie-Editor and EditThisCookie are the most common tools on cybercrime forums) and visits the target application. The application sees a session that has already cleared MFA, already passed device registration, and already been trusted by conditional access. No second factor is requested because no authentication is occurring.
The Four Steps
- Initial infection through a malvertised installer, cracked software, or lure attachment
- Silent exfiltration of browser profiles, cookies, and tokens to a command-and-control server
- Log parsing and resale through automated Telegram channels or dedicated marketplaces
- Import of session artifacts by a buyer who walks into the victim's account in minutes
The Infostealers Driving the Ecosystem
A handful of malware families dominate cookie theft. They are not equal, and their feature sets shape which cookies end up in which markets.
RedLine
RedLine has been the volume leader for years. It is cheap, widely sold on Russian-language forums, and ships with broad browser coverage for Chromium, Gecko, and a long tail of niche browsers. RedLine specializes in bulk collection and is responsible for a large share of the raw stealer logs that end up on Russian Market and similar hubs.
Lumma (LummaC2)
Lumma has aggressively displaced RedLine on some forums in 2024. Its operators focus on cookie and token freshness, advertising features like live session resale and targeted collection from crypto extensions and password managers. Lumma logs frequently contain still-valid session cookies for Microsoft 365, Google Workspace, GitHub, and AWS consoles.
Vidar
Vidar predates Lumma and shares lineage with Arkei. It is modular, supports custom collection profiles, and has been tied to multiple ransomware affiliate campaigns where the initial access was a Vidar-harvested cookie rather than a credential.
Honorable mentions
- StealC, which copies Vidar's architecture and is aggressively priced
- Meta Stealer and Rhadamanthys, frequently bundled with loader families
- Atomic Stealer (AMOS) on macOS, which has made cookie theft a cross-platform problem
The Underground Market for Session Tokens
Raw stealer logs are sold two ways. The first is bulk, zip files of thousands of infected machines dumped for a flat fee, often under fifty dollars. The second is curated, where brokers filter logs for specific applications (Okta, Azure, Salesforce, Coinbase) and sell single sessions for hundreds or thousands of dollars depending on the target.
Genesis Market pioneered the curated model before its 2023 takedown. The void was filled almost immediately. Today the same function is served by:
- Russian Market, still the largest generalist cloud of stealer logs
- 2easy, which focuses on browser fingerprint bundling
- Telegram clouds run by stealer operators themselves, offering subscription feeds of fresh logs
- Private brokers who buy bulk logs, filter for corporate sessions, and resell upstream to initial access brokers
What buyers pay for is more than the cookie. Premium listings include the full browser fingerprint, saved passwords, installed extensions, timezone, and user-agent string, so the buyer can match the victim's environment closely enough to defeat device binding and behavioral checks.
Why This Bypasses MFA So Cleanly
MFA protects the authentication event. Session hijacking attacks the authenticated state. The distinction matters because most identity providers reauthenticate only on a handful of triggers:
- Explicit session expiration
- Password reset or credential change
- A risk signal strong enough to invalidate the session
- Step-up challenges tied to sensitive actions
If none of those fire, the stolen session simply rides until its natural expiration. Long-lived refresh tokens, which some applications issue for weeks or months of background use, make this dramatically worse. Once stolen, they function as a key that quietly mints new access tokens on demand.
Adversary-in-the-middle (AitM) phishing kits like Evilginx, EvilProxy, and Tycoon 2FA push this further. Instead of waiting for an infostealer infection, AitM kits proxy the entire login flow, capturing both the credential and the resulting session cookie in real time. The victim completes MFA on the real Microsoft or Google page they see through the proxy, and the attacker walks away with a fully valid, already-MFA-cleared session.
What Defenders Can Actually Do
You cannot prevent cookie theft on an endpoint you do not control. You can make stolen cookies worth less.
Shorten the Window
- Reduce session and refresh token lifetimes for high-value applications
- Force reauthentication on sensitive scopes (admin consoles, billing, data export)
- Expire sessions on suspicious signals rather than after a fixed timer
Bind Sessions to Devices
- Use token binding and Microsoft's token protection where available
- Require device compliance signals from Intune, Jamf, or Kandji on session refresh
- Enforce managed-device checks for privileged roles via conditional access
Watch the Session, Not Just the Login
- Deploy Identity Threat Detection and Response (ITDR) tooling that inspects session behavior
- Alert on impossible travel measured across sessions, not just logins
- Flag new user agents, new ASN jumps, and sudden download bursts inside an existing session
Monitor for Exposure
- Ingest stealer log telemetry so you know the moment a corporate cookie appears in a market
- Track employees whose personal devices show up in infostealer feeds, even if the corporate account is not the direct victim
- Force session invalidation and credential rotation the moment exposure is confirmed
Revealer.US maintains continuous coverage of infostealer logs and underground cookie brokers. When a session token tied to your domain surfaces, Revealer.US surfaces it as an active incident so your team can revoke and reauthenticate before the buyer acts. See pricing for team and enterprise tiers.
Building an Incident Playbook
Treat confirmed cookie theft as a contained breach, not a password reset event. The minimum response should include:
- Immediate revocation of all active sessions for the affected user across every federated application
- Rotation of credentials plus forced re-enrollment of MFA factors
- Review of audit logs for the full cookie lifetime, not just the last hour
- Isolation and reimaging of the source device, not just malware removal
- Hunt for lateral access, OAuth app grants, mailbox rules, token-granted API integrations
The audit log review step matters most. Attackers who buy sessions often drop persistence such as an OAuth app consent, a forwarding rule, or a new service principal, so that losing the cookie does not lose them the tenant. Killing the session without auditing the aftermath is the most common failure we see in post-incident reviews.
Conclusion
Session hijacking via stolen cookies is an old technique. It is the dominant MFA bypass now because infostealers industrialized cookie theft and AitM phishing kits made real-time harvesting cheap. MFA still matters. It just no longer ends the conversation.
Stop treating authentication as a one-time gate. Monitor the session as a living object. Short-lived tokens, device-bound sessions, ITDR coverage, and underground monitoring turn a stolen cookie from a guaranteed takeover into a race the defender can still win. Read our full guidance in the docs.
Frequently asked questions
What is session hijacking?
Session hijacking, often called pass-the-cookie, is account takeover by reusing a session token the victim's browser already earned. The attacker skips the login entirely, imports the stolen cookie into their own browser, and inherits the authenticated session.
Can stolen cookies really bypass MFA?
Yes. MFA protects the authentication event, and a stolen session cookie is proof that the event already happened. The application issues access without asking for a second factor, and the attacker rides the session until it expires or is revoked.
How do attackers get session cookies?
Two main routes. Infostealer malware scrapes cookies and tokens directly from the browser and sells them in logs, and adversary-in-the-middle phishing kits proxy a live login to capture the cookie in real time, after the victim completes MFA.
How do we detect session hijacking?
Watch the session, not just the login: impossible travel measured across sessions, new user agents or ASN jumps mid-session, and sudden download bursts. Pair that with stealer log feeds and breach dataset checks so you learn about exposed cookies from the market side as well as from anomalies.
What should we do if a session cookie is stolen?
Treat it as a contained breach. Revoke every active session for the user, rotate credentials and re-enroll MFA factors, audit logs for the full cookie lifetime, reimage the source device, and hunt for persistence such as OAuth app grants, mailbox rules, and new service principals.
Does MFA still matter?
Yes. MFA still blocks password guessing, credential stuffing, and simple phishing. It just no longer ends the conversation once a session exists. Pair it with short token lifetimes, device-bound sessions, and session-level monitoring.
Want to detect stolen session cookies before they become account takeovers? Start a free trial of Revealer.US and monitor your domains across live infostealer feeds.