The threat model people picture when they hear “credential theft” is twenty years out of date. Username + password used to be enough to take over an account. In 2026, MFA-protected accounts are the norm, and the attacker who only steals passwords is doing themselves a disservice. Modern infostealers prioritise session cookies, and once those are gone, MFA is gone with them.
Why session cookies beat passwords
When you sign into a web app, the server checks your password and (if required) your MFA. If both pass, the server issues a session cookie, a long random string that proves you’ve already authenticated. For the next several hours or days, the browser sends that cookie with every request and the server treats you as already-authenticated.
An attacker who steals that cookie can paste it into their own browser and the server will treat them the same way. No password needed. No MFA challenge. The session is already authenticated, and the cookie is the proof.
What infostealers actually grab
The cookie databases for Chrome, Edge, Firefox, and Safari are all stored at predictable paths on the user’s machine. They’re encrypted with the browser’s local key, which is itself stored alongside in a way the malware can decrypt. So the malware decrypts every cookie on the system and uploads them in bulk.
The valuable cookies are the long-lived authenticated ones for SaaS applications: Gmail, Microsoft 365, Slack, Discord, AWS console, GitHub, banking portals. The attacker filters the cookie dump for the high-value domains and replays the cookies that haven’t expired.
Why this defeats MFA
MFA happens at sign-in. It does not happen on subsequent requests. Once the user has signed in and proven both factors, the session cookie issued at that moment is the only authentication proof for the rest of the session, typically hours, sometimes days. If the attacker steals the cookie at any point during that window, MFA is irrelevant. It already passed.
Some applications mitigate by requiring MFA re-authentication for sensitive actions (changing passwords, transferring money). Most don’t.
What’s actually working as defence
Cookie binding. Modern browsers and identity providers are rolling out token-binding mechanisms (DPoP, MTLS-bound cookies, the Chrome Device-Bound Session Credentials proposal) that tie the session cookie to a cryptographic key on the device. A stolen cookie replayed on another machine fails because the new machine can’t sign with the original device’s key. Adoption is incomplete in 2026 but accelerating.
Aggressive session-lifetime policies. Reducing how long a session cookie stays valid before re-authentication is required. Painful for users, effective against stolen-cookie replay.
Continuous risk-scoring. Modern IdPs revalidate sessions periodically with risk signals, IP changes, user-agent changes, impossible-travel, and force re-authentication when the score crosses a threshold. The stolen-cookie replay produces an obvious anomaly that conditional-access policies catch.
What individuals should do
Sign out of high-value sessions when you’re done. Don’t run “verification” PowerShell commands from any website. Don’t install software cracks. Use a separate browser profile or container for high-value accounts (banking, primary email, password manager) so a malware infection in your main profile doesn’t reach those cookies.
For organisations: enable conditional-access policies that revalidate on anomalous signals, push the cookie-binding adoption with the IdPs you use, and shorten session lifetimes for the most sensitive applications. The threat is mature. The defence stack catching up to it is mature too, for the organisations that have configured it.