"Just turn on MFA" is the security advice that everyone gives and that almost no one challenges. It is broadly correct against the threat model it was designed for, credential stuffing, password reuse, basic phishing, but it has a specific blind spot that the modern infostealer economy exploits routinely. That blind spot is the session cookie, and understanding it is essential to understanding why ransomware affiliates increasingly skip the login flow entirely.
What MFA actually protects
MFA gates the act of logging in. When you authenticate to Microsoft 365, Google Workspace, your bank, or your corporate VPN, the application verifies your password and your second factor (authenticator code, push approval, hardware key, passkey). If both check out, the application issues a credential, almost always a cookie, that represents your authenticated session.
From that moment on, MFA is out of the loop. The application no longer asks for password or second factor; it just checks the cookie’s signature and expiration. Every subsequent request is authenticated by presenting the cookie. Sessions are typically valid for hours, days, or weeks depending on the application’s configuration.
Phishing-resistant MFA (FIDO2, WebAuthn, passkeys) raises the bar dramatically against attackers who try to log in as you. It does nothing, by design, for what comes after the login.
What the stealer takes
When an infostealer infects a Windows machine, the most valuable thing it extracts is the browser cookie database. On Chromium-based browsers (Chrome, Edge, Brave, Opera) this lives at %LOCALAPPDATA%\Google\Chrome\User Data\Default\Network\Cookies. On Firefox, cookies.sqlite in the profile directory. The cookies are encrypted with the local user’s DPAPI master key, which the malware can decrypt locally because it runs as the user.
The stolen cookies include every authenticated session the user is in: Microsoft 365, Google Workspace, GitHub, Slack, AWS console, Dropbox, banking sites, social platforms, the corporate VPN portal. For a typical knowledge-worker laptop, the haul is dozens to hundreds of authenticated sessions.
Crucially, these are not credentials the attacker now has to use to log in, they are sessions the attacker can replay directly. No login flow, no MFA challenge, no anomaly detection on the auth endpoint, because there is no auth event at all.
How replay works
The attacker buys the stealer log (or a filtered subset of it). They identify the cookies for the targeted service. Using a browser instance loaded with the stolen cookies, Chrome with the Cookie-Editor extension, dedicated tools like Cookie Quick Manager, or open-source frameworks like CookieCloud, they navigate to the service.
The application sees a request bearing a valid session cookie. It checks the signature, the expiry, and increasingly the IP geolocation and User-Agent. If those match (the attacker can match IP via residential proxies and User-Agent from the log itself), the session is accepted and the attacker is inside the account.
This is functionally indistinguishable, from the application’s perspective, from the original user resuming their session from their own laptop. There is no security event to alert on.
What detection signals exist
A handful of signals can catch cookie replay, with varying reliability:
- Impossible travel. The original user logged in from Berlin two hours ago; the cookie is now being replayed from Manila. Microsoft’s Identity Protection, Okta’s risk scoring, and Google Workspace’s anomaly detection all flag this. Effective when the attacker is geographically distant; defeated by attackers who replay from the victim’s region (which sophisticated buyers explicitly seek out).
- Device posture mismatch. The session was issued to a managed device with EDR running; the replay comes from an unmanaged device with no telemetry. Conditional Access in Microsoft Entra and Okta can enforce device posture continuously, killing the session when the posture changes.
- Concurrent sessions. Two browser sessions for the same account simultaneously, one from the user’s device, one from elsewhere. Some applications detect and prompt for re-authentication.
- Unusual user-agent or browser fingerprint. Attackers often use generic Chrome User-Agents while the original user was on a specific Edge or Firefox build. Detection effectiveness varies wildly by application.
The honest summary: detection is partial. The same defenses that catch unauthorized logins do not all catch unauthorized replay, because replay does not look like a login.
What actually works
Three architectural moves that meaningfully change the equation:
1. Short session lifetimes plus continuous evaluation. The cookie’s value to an attacker decays with time. A 24-hour session is a 24-hour replay window; an 8-hour session is much less attractive. Combine with continuous-evaluation features, Microsoft’s Continuous Access Evaluation (CAE), Google’s Context-Aware Access, that revoke tokens immediately when conditional access criteria are violated. The session lifetime story has been improving steadily but most enterprises still default to multi-day cookies.
2. Device-bound credentials. Hardware-bound credentials, TPM-attested device-bound session credentials, Microsoft’s Device Registration plus token binding, make sessions valid only on the specific hardware that originated them. A stealer can copy the cookie file but cannot copy the TPM. The standard implementations are still maturing; expect this to be a major defensive shift through 2026-2027.
3. Continuous re-authentication for sensitive actions. Even within an authenticated session, sensitive actions, wire transfers, admin role assumption, IP allowlist changes, MFA-method changes, should require fresh authentication. Microsoft refers to this as "Authentication Context"; Okta calls it Step-Up Authentication. Done correctly, it limits the blast radius of a replayed session to read-only access.
What does not work, despite frequent suggestion:
- Adding more MFA. Once the session exists, additional MFA factors only matter at re-auth time, which the attacker is structured to avoid.
- Rotating passwords. The session cookie is independent of the password and survives password rotation in many implementations. Forcing logout-on-password-change is a separate setting that not all applications honour.
- IP allowlists alone. Attackers buy logs filtered for residential IPs in the victim’s region; they replay from compatible IP space.
The takeaway
MFA is necessary and not sufficient. It protects the front door, but the modern infostealer economy is walking through the windows the front door already opened. The defensive answer is not "more MFA", it is short sessions, device-bound credentials, continuous evaluation, and re-authentication for sensitive actions. Those three together close most of the replay window that stealer logs currently exploit.
Treating MFA as the end of the conversation about authentication security is the most consistent error security teams are making in 2026. The conversation is just starting.