MFA bypass via cookie theft: the #1 breach vector of 2026

Published May 2026. Speaking from the defender side of the wire.

If you’re reading this in May 2026 and your incident-response runbook still treats “credential theft” as a phishing-email problem, the runbook is two years behind the threat. The technique that’s actually driving the bulk of identity-based breaches in 2026 isn’t a phishing form harvesting passwords. It’s an infostealer running on a managed endpoint for forty-five seconds, exfiltrating browser-saved credentials and, much more dangerously, session cookies that prove the user already passed MFA, and that the attacker can replay from their own laptop the same evening.

This piece is a 2026 field guide to that technique. What changed, why “we have MFA” stopped buying what defenders thought it bought, and what controls measurably move the needle back.

What actually happens, step by step

A 2026 session-cookie compromise plays out in five stages, and most of them take seconds:

• Initial execution on a user’s endpoint, usually a Lumma, Vidar, or Stealc successor delivered via a malvertising chain, a cracked-software lure, or a clipboard-hijack drive-by. The user runs the dropper believing it’s a software installer, a captcha verification, or a Discord client update.
• Browser-credential-store enumeration. The stealer reads the Chromium/Edge/Firefox local databases, decrypts saved passwords via Windows DPAPI (which it has because it’s running as the user), and extracts all cookies. Modern stealers do this in seconds.
• Cookie filtering. The stealer’s operator-supplied config has a target list, the cookies that have value. M365 (login.microsoftonline.com, *.office.com), Google Workspace (accounts.google.com), Okta, Salesforce, GitHub, AWS console, Atlassian, Slack. The valuable ones get prioritised in the exfiltrated log.
• Exfiltration. The complete log, system fingerprint, every saved password in cleartext, every cookie file, browser autofill, sometimes a screenshot of the running desktop, ships to attacker-controlled storage. Total runtime under one minute on a modern machine.
• Replay. Hours or weeks later (depending on whether the log went to a Telegram giveaway channel or an initial access broker for resale), an attacker loads the cookies into their own browser. They navigate to the targeted SaaS. The cookies authenticate them as the original user. MFA does not fire because the cookies prove MFA already happened.

The breach window is now between the user’s endpoint compromise and the next forced re-authentication on the SaaS in question. With default M365 session lifetimes around 90 days for refresh tokens, that window is wide.

Why this displaced password phishing

Three structural reasons:

• MFA actually works against passwords-only phishing. The 2019–2022 wave of credential-harvesting kits relied on victims typing passwords into fake-login portals. When SMS, push-prompt, and TOTP-based MFA hit critical mass in 2022–2023, that attack model started failing. The smart criminal economy adapted.
• Infostealer infrastructure scaled. Lumma’s malware-as-a-service operation alone ran at industrial scale through 2024 before international law-enforcement disruption. Successor brands picked up the same affiliate playbook. The economic threshold to launch a stealer campaign dropped to a few hundred dollars and an afternoon.
• Session-based architectures expanded. Modern SaaS uses long-lived refresh tokens specifically to avoid re-prompting users for credentials. The same mechanism that makes M365 pleasant to use also gives a stolen cookie 90 days of free authentication.

The combined effect: by mid-2025, cookie-based session replay had quietly become the leading credential-related breach vector for enterprises, displacing form-based phishing.

The corollary that nobody wants to hear

SMS-based MFA, push-prompt MFA, and TOTP-based MFA are all bypassed by cookie replay. They were designed against the password-phishing threat model. Against an attacker who already has a valid session cookie, they don’t fire because there’s nothing for them to fire against.

This is why “we rolled out MFA” stopped translating to “we’re protected against credential theft” sometime in 2024. The MFA event has already happened, captured in the cookie, in the attacker’s hands. The attacker doesn’t need to defeat MFA, they’re past it.

What actually works against cookie theft

Five controls move the needle. In rough order of leverage:

• 1. Phishing-resistant authentication for the next step-up. Even if the initial sign-in is happy with the stolen cookie, sensitive actions inside the SaaS, admin operations in M365, sending a high-value wire in a banking SaaS, changing IdP settings, should require a fresh hardware-key or device-bound passkey assertion. The cookie is not a step-up. The stolen cookie can authenticate the session; it can’t authorise the privileged action. This is the cleanest architectural answer.
• 2. Token-binding / device-bound credentials. Microsoft’s Token Protection (cross-application Continuous Access Evaluation tied to the originating device’s TPM-bound key) makes a stolen cookie useless from a different device because the TPM-bound key doesn’t travel. Roll it out where supported. Equivalent capabilities exist on Okta, Google Workspace, and several other major IdPs in 2026, turn them on.
• 3. Shorter session lifetimes for privileged accounts. A stolen cookie has a half-life equal to your session lifetime. 12-hour and 24-hour sessions are 2026 norms for general users; cut them to 4 hours or less for any account with sensitive scope. The user pain is real but small once they’re used to it.
• 4. EDR with browser-credential-store telemetry. Modern EDR catches the distinctive process tree of a stealer reading the browser credential store. The detection isn’t perfect but it shortens the kill chain. Our EDR and antivirus reviews rank products by this capability among other criteria.
• 5. Browser-level credential storage discipline. Group Policy: disable “Save password” in browsers, enforce a corporate password manager (our picks) with phishing-resistant unlock, separate the password-management surface from the browser’s default. Stealers harvest the browser store; a password manager with its own crypto and a hardware-key unlock is meaningfully harder.

The detection question

Detection on the cookie-replay side is harder than detection on the credential-theft side, because by the time replay is happening the attacker looks like a legitimate user.

Two practical signals that have proven useful in 2026 incident-response work:

• Impossible-travel / device-fingerprint anomaly on M365, Okta, or your IdP of choice. The user signed in from a corporate laptop in Madrid at 10am; the same session is now active from an unfamiliar IP in St Petersburg at 10:01am. Standard CAEP / Continuous Access Evaluation policies catch this if you’ve configured them. Most organisations have the capability and haven’t turned it on.
• Stealer-log telemetry feeds. Continuously check your domain against dark-web monitoring services (our picks) and our own Stealercheck. When a corporate device fingerprint shows up in a stealer log feed, every active session for that user across every IdP should be immediately revoked.

A 2026 incident response sequence for “stealer log found”

When a stealer log containing your domain credentials lands in a feed you monitor, the response sequence should be:

• Within 1 hour. Identify the affected user(s). Revoke all refresh tokens for those users (Entra ID: Revoke-AzureADUserAllRefreshToken; Okta: end-all-sessions admin action). Force a hardware-key-protected re-authentication on next sign-in.
• Within 4 hours. Identify the device. Stealer logs include hostname, MAC, hardware fingerprint. Match to your inventory. Isolate the device if managed, advise reinstall if BYOD. Stealers leave persistence; assume the device is compromised until reimaged.
• Within 24 hours. Review the affected user’s recent activity. Look for emails sent or forwarded that the user didn’t send, calendar invites the user didn’t create, mailbox-rule changes, and admin-action-log entries during the suspected attacker access window. The cookie replay typically maintains presence inside the mailbox for at least one business day before pivoting.
• Within 48 hours. If the user has admin privileges, expand the search. Check every system the user could reach, every API token they could have rotated, every service they could have escalated within.

For the broader incident-response framework this fits inside, see our runbook walkthrough, the stealer-log path is a specific specialisation of the same playbook.

The strategic point

Through the mid-2020s the entire security industry deployed MFA on the implicit assumption that passwords were the problem and a second factor was the solution. That worked, for a few years, against the threat model of the moment. The criminal economy adapted by attacking the layer below the MFA challenge, the session that the MFA challenge issued. Cookie theft is the rebalancing answer.

The next round of meaningful improvement comes from binding credentials to devices, from requiring fresh assertions for privileged actions rather than session-level access, and from shorter session lifetimes for the accounts that matter. Each of those is a known, deployable control in 2026. The blocker is rarely capability, it’s that the operations team hasn’t been told the threat model has changed.

If your organisation hasn’t run a tabletop on cookie-replay specifically in the last twelve months, that’s the first action item from this piece. The control story that’s been sold to your board (“we have MFA”) doesn’t survive a thirty-minute scenario where the attacker shows up with a valid session and bypasses the prompt entirely. Better to walk through the scenario in a meeting room than in a real Tuesday-night incident.

Further reading

• Our anatomy of an infostealer log, what’s actually inside the file that produces this attack chain.
• Our infostealer family overview, the operators behind the logs.
• Microsoft Token Protection, official documentation for the device-bound-cookie approach inside Entra ID.
• MITRE ATT&CK T1539, Steal Web Session Cookie, the formal-taxonomy reference for the technique.
• CISA Cybersecurity Advisories for the current month’s advisories.

The defenders who internalise the threat-model shift early will be the ones answering the next round of “how did they get past our MFA?” questions with “they didn’t, they came in past the MFA, through a cookie that proved the MFA already happened.” Get there before the post-incident review forces the conversation.