Post cover image
Figure 1. MFA verified the user. The attacker kept the session.

October 25, 2026

MFA Passed. The Session Was Still Stolen.

Attackers have stopped fighting your login. They steal what comes after it. Here is how to defend the session itself.

By Peter Dunn

10 min read

TL;DR: Multi-factor authentication proves that the right person was present at sign-in. It says nothing about who holds the session afterward. Phishing kits, infostealer malware, and token-based phishing now target the session cookies and tokens issued after MFA succeeds, and a stolen session works without a password or a second factor. This article explains how session theft works, why most MFA methods cannot stop it, and the four-layer model that does: protect the login, bind the session, watch the session, and kill it fast.

The login was perfect

The email looks routine: an HR notice asking employees to acknowledge an updated code of conduct. The employee opens the attached PDF, clicks through a CAPTCHA, and lands on a familiar sign-in page. They enter their password and approve the push notification on their phone. Everything works exactly as security training promised.

Except the sign-in page was a proxy. It forwarded every keystroke to the real identity provider, relayed the MFA challenge in real time, and kept a copy of the session cookie that came back. The attacker now holds a fully authenticated session. MFA did not fail. It succeeded, and then the attacker walked away with the result.

This is not a hypothetical. In May 2026, Microsoft Threat Intelligence published its analysis of an adversary-in-the-middle (AiTM) campaign built on exactly this lure. Between April 14 and 16, 2026, it targeted more than 35,000 users at more than 13,000 organizations across 26 countries, with about 92% of targets in the United States.

MFA answers one question: was the right person present at sign-in? It does not answer the question that matters next: who is holding the session now?

Authentication is a moment. A session is a bearer instrument.

Authentication happens once. After it succeeds, the identity provider issues credentials that let the user keep working without signing in again: a browser session cookie, an access token, a refresh token, or a device-level token. Those artifacts are what applications actually check on every request.

Most of them are bearer tokens. Like cash, they belong to whoever holds them. An application that receives a valid session cookie does not ask how it was obtained or which device presented it. It simply grants access.

Timeline of a session. Password and MFA each take seconds and are marked as what MFA protects. The session cookie and access token last minutes to hours, and the refresh token lasts days to weeks; together these are marked as the theft window, because the session is a bearer credential.

The timeline above shows the imbalance. MFA protects a window of a few seconds. The session it creates can stay valid for hours, and the refresh token behind it can stay valid for weeks. Every minute of that window is an opportunity for theft.

Not every token carries the same risk. The table below summarizes the artifacts attackers target most often.

Table of five session artifacts: browser session cookie, OAuth access token, OAuth refresh token, device SSO token, and API key or personal access token. For each, it lists where it lives, typical lifetime, what theft gives an attacker, how to revoke it, and a risk rating. Session cookies, refresh tokens, and API keys are rated critical.

Four ways sessions get stolen

Session theft follows four main paths. Each one sidesteps MFA in a different way.

Four ways sessions get stolen: adversary-in-the-middle phishing, such as Tycoon 2FA; infostealer malware, such as Lumma; token-based phishing through device codes or OAuth consent; and leaked session artifacts, such as the 2023 Okta HAR files. Every path ends the same way: a stolen session looks exactly like a valid, MFA-approved user.
  1. Adversary-in-the-middle phishing. A reverse proxy sits between the user and the real sign-in page, relays the MFA challenge, and captures the resulting session cookie. Phishing-as-a-service kits have made this a commodity. Tycoon 2FA, one of the largest, sold access for about $120 for ten days. Microsoft estimates it reached roughly 96,000 victims after it appeared in 2023.
  2. Infostealer malware. Malware on the user's device copies browser cookies and tokens directly from disk or memory, long after a legitimate sign-in. Microsoft and Europol estimated that the Lumma infostealer infected about 394,000 Windows devices in just two months in 2025.
  3. Token-based phishing. The attacker never touches the password. Instead, the victim is tricked into approving a device code or granting consent to a malicious OAuth application. The identity provider then issues legitimate tokens directly to the attacker.
  4. Leaked session artifacts. Tokens also leak through ordinary operational channels such as browser HAR files, debug logs, and support tickets. In 2023, an attacker who reached Okta's support case system used session tokens embedded in customers' HAR files to hijack the sessions of five customers, according to Okta's root-cause report.

The AiTM path deserves a closer look, because it defeats the controls most organizations rely on.

Sequence diagram of an adversary-in-the-middle attack across four lanes: user, AiTM proxy, identity provider, and target app. The user opens a lure link, the proxy relays the real sign-in page and the password, the identity provider sends an MFA push that the user approves, and the identity provider issues a session cookie. The proxy keeps a copy, redirects the user to the real site, and replays the cookie to the target app from attacker infrastructure.

Notice the step that matters most. After the identity provider issues the session cookie, the proxy keeps a copy. From that point on, the attacker does not need the password or the phone. A password reset does not help either, because the stolen session remains valid until it is explicitly revoked.

The numbers behind the shift

Attackers are moving toward session theft because it works and because it scales. The figures below come from 2025 and 2026 reporting by Microsoft, Europol, CrowdStrike, and others.

Six statistics on session theft: more than 35,000 users targeted by one AiTM campaign in three days; about 96,000 victims attributed to Tycoon 2FA since 2023; about one week for Tycoon 2FA to recover after its takedown; 394,000 Windows devices infected by Lumma in two months; 82% of 2025 detections involved no malware; and a 29-minute average eCrime breakout time.

Two of these numbers deserve emphasis. Tycoon 2FA returned to its pre-takedown volume within about a week of a coordinated law-enforcement action in March 2026, so disruption alone will not solve this problem. And with average breakout times measured in minutes, a stolen session that goes unnoticed for an hour is already too late.

Why your MFA did not help

MFA methods differ widely in how well they resist session theft. The key distinction is between protecting the login and protecting the session.

Matrix of MFA methods versus session theft. SMS codes, authenticator app codes, push approval, and push with number matching are vulnerable to AiTM phishing, infostealer cookie theft, and device code phishing. Passkeys resist AiTM phishing and MFA fatigue but remain vulnerable to infostealer cookie theft. Passkeys plus session binding also resist cookie replay from another device. Device code and consent phishing require blocking the flow and restricting consent.

The matrix leads to an uncomfortable conclusion. Passkeys and other FIDO2 methods stop AiTM phishing, but they do not stop an infostealer. A passkey is bound to the real website's origin, so a proxy cannot complete the sign-in. But once a legitimate sign-in succeeds, the session cookie is just as stealable as it would be after a text-message code. Phishing-resistant authentication is necessary, but it is not sufficient. The session needs its own protection.

The defense model: four layers

A resilient program treats the login and the session as separate problems and stacks four layers of control.

Four-layer defense model. Layer 1, protect the login: passkeys, retiring SMS codes, number matching, and blocking device code flow. Layer 2, bind the session: Chrome DBSC, Entra Token Protection, and DPoP or mTLS. Layer 3, watch the session: continuous access evaluation and alerts on network, device, and persistence changes. Layer 4, kill the session: revoke refresh tokens, sign out everywhere, and remove persistence.
  • Protect the login. Move to passkeys or other FIDO2 authenticators, starting with administrators and high-risk roles. Retire SMS and one-time codes where possible, require number matching for any remaining push approvals, and block the device code flow wherever it is not needed.
  • Bind the session. Tie session credentials to the device that earned them, so a copied cookie is useless elsewhere. Shorten session lifetimes for privileged access.
  • Watch the session. Evaluate risk continuously, not only at sign-in. Look for a session that changes networks, devices, or behavior after MFA completes.
  • Kill the session. Make revocation fast, complete, and automatic. Revoke refresh tokens and sign the user out everywhere, rather than relying on a password reset.

How session binding works

Binding changes a session credential from cash into something closer to a signed check. The device that signed in creates a cryptographic key pair and keeps the private key in protected hardware, such as a TPM. The server issues only short-lived credentials and requires proof of possession of that private key to renew them.

Side-by-side comparison. In a bearer session, the server issues a long-lived cookie, an infostealer copies it, the attacker replays it from another device, and access is granted. In a bound session, the device keeps a private key in the TPM, the server issues a short-lived cookie tied to that key, and when the stolen cookie expires the attacker cannot renew the session without the device signature.

Binding is finally available at scale. In May 2026, Google made Device Bound Session Credentials (DBSC) generally available in Chrome on Windows and enabled it by default for Google Workspace accounts. Microsoft Entra ID offers Token Protection as a Conditional Access control that accepts only device-bound sign-in tokens; it is generally available for supported native apps, with browser support in preview. For APIs, DPoP (RFC 9449) binds OAuth access tokens to a client key, so every request must carry a fresh signed proof.

DBSC and Token Protection protect browser and app sessions. DPoP does the same job for APIs, including the calls that AI agents and automation make on a user's behalf. The following example shows a DPoP-bound request. A stolen access token is useless without the private key that signs each proof.

POST /api/payments/transfer HTTP/1.1
Host: api.example.com
Authorization: DPoP eyJhbGciOiJFUzI1NiIsImtpZCI6...
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2Ii...

// Decoded DPoP proof header (signed with the client's private key)
{
  "typ": "dpop+jwt",
  "alg": "ES256",
  "jwk": { "kty": "EC", "crv": "P-256", "x": "l8tFrhx...", "y": "9VE4jf_..." }
}

// Decoded DPoP proof claims (a fresh proof is required for every request)
{
  "jti": "e1j3V_bKic8-LAEB",
  "htm": "POST",
  "htu": "https://api.example.com/api/payments/transfer",
  "iat": 1792699200,
  "ath": "fUHyO2r2Z3DZ53EsNrWBb0xWXoaNy59IiKCAqksmQEo"
}

Coverage is still uneven across browsers, platforms, and applications, so binding should be rolled out where it is supported and combined with the detection and revocation layers everywhere else.

Watching the session: detection engineering

Identity logs already contain most of the signals needed to spot session theft. The challenge is correlating them over time rather than evaluating each sign-in in isolation.

Table of eight session-theft detections with severity. Critical: session reuse from a new network within 30 minutes of MFA, concurrent use of one session from two locations, and a new MFA method after a risky sign-in. High: device mismatch, mailbox rules after a new session, OAuth consent to a new app, and unusual device code sign-ins. Medium: session activity from hosting-provider networks.

The highest-value signal is session reuse from a new network shortly after MFA. A user completes MFA from a home connection, and minutes later the same session is used from a hosting provider in another country. The following vendor-neutral rule expresses that logic. Adapt the field names to your SIEM or identity threat detection platform.

# Vendor-neutral pseudo-rule. Map fields to your SIEM or ITDR platform.
title: Session reuse from a new network shortly after MFA
severity: critical
description: >
  A session completes MFA from one network, then is used from a
  different ASN or country within 30 minutes.
sources:
  - identity_provider.signin
  - identity_provider.token_activity
match:
  first:
    event: sign_in
    mfa_result: success
  then:
    event: token_use
    same_session_id: true
    asn_changed: true
  within: 30m
exclude:
  - known_vpn_egress_ranges
  - approved_travel_profiles
output_fields: [user, session_id, src_ip, asn, country, device_id, user_agent, app]
response:
  - revoke_all_sessions
  - require_phishing_resistant_reauth
  - page_soc

Pay equal attention to what attackers do immediately after they take over a session. Creating inbox rules, registering a new MFA method, adding a device, or consenting to an OAuth application are common persistence steps, and each one should generate an alert when it follows a risky sign-in.

If you run Microsoft Sentinel, the following query applies the same idea to Entra ID sign-in logs. It flags any session ID used from more than one country or network in the past day. Tune it for mobile users and corporate VPNs, which can change networks legitimately.

// Microsoft Sentinel: one Entra ID session used from multiple countries or networks
let lookback = 1d;
let Interactive = SigninLogs
    | where TimeGenerated > ago(lookback)
    | extend Country = tostring(LocationDetails.countryOrRegion);
let NonInteractive = AADNonInteractiveUserSignInLogs
    | where TimeGenerated > ago(lookback)
    | extend Country = tostring(parse_json(LocationDetails).countryOrRegion);
union Interactive, NonInteractive
| where ResultType == "0" and isnotempty(SessionId)
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
    Countries = make_set(Country, 10), ASNs = make_set(AutonomousSystemNumber, 10),
    IPs = make_set(IPAddress, 10), Apps = make_set(AppDisplayName, 10)
    by UserPrincipalName, SessionId
| where array_length(Countries) > 1 or array_length(ASNs) > 1
| extend MinutesActive = datetime_diff('minute', LastSeen, FirstSeen)
| order by LastSeen desc

When a session is stolen: incident response

The most common response mistake is resetting the password and closing the ticket. A password reset does not end a stolen session. Containment must target the tokens themselves.

Incident response flowchart for a stolen session. Revoke all sessions and refresh tokens rather than only resetting the password, block sign-in or require phishing-resistant reauthentication, remove persistence, and scope the session window. Then branch: for phishing, block the lure domain and find other recipients; for an infostealer, reimage the device and rotate every credential stored in the browser. Finish by hardening with passkeys and session binding, and record lessons learned.

Two steps are easy to miss. First, check for persistence that survives revocation, such as attacker-registered MFA methods, mail forwarding rules, and OAuth grants. Second, if the session was stolen by an infostealer, treat the endpoint as compromised. Every credential and cookie stored in that browser is exposed, not just the one you saw being abused.

The AI angle: more sessions, faster attackers

Artificial intelligence is changing both sides of this problem.

Lures are getting better. Generative AI produces polished, localized phishing emails at scale, which removes many of the spelling and tone cues that users were trained to notice. CrowdStrike's 2026 Global Threat Report found that AI-enabled adversary operations rose 89% year over year.

Sessions are multiplying. AI assistants, browser agents, and MCP connectors each hold their own OAuth tokens to mail, files, calendars, and code repositories. Consider a coding assistant connected to source control with a refresh token that stays valid for 90 days and can read every repository the developer can. If an infostealer lifts that token from the developer's laptop, the attacker gains quiet, long-term access to your source code, and none of it appears as a human sign-in. Apply the same rules to agent tokens as to user sessions: inventory every OAuth grant, keep lifetimes short, bind tokens where possible, and include agent identities in session-anomaly detection.

Defenders gain leverage too. Behavioral models are well suited to scoring session anomalies, such as a sudden change in device, network, or activity pattern. They work only if identity, endpoint, and application logs are correlated by session, so invest in that data foundation first.

A practical roadmap

You do not need to finish a multi-year identity program before you reduce this risk. Several of the most effective controls can be enabled this week.

Roadmap in three columns. This week: revoke sessions on every password reset, block unused device code flow, alert on new MFA methods and mailbox rules, shorten admin session lifetimes, and restrict OAuth consent. This quarter: passkeys for admins, continuous access evaluation, pilot session binding, session-reuse detections, and an inventory of app and AI agent OAuth grants. This year: phishing-resistant MFA for all, bound sessions by default, DPoP or mTLS for APIs, automated revocation, and qu

Track four metrics to show progress: the percentage of privileged users on phishing-resistant authentication, the percentage of sign-ins with bound sessions, the median time from detection to full session revocation, and the number of risky sign-ins followed by a persistence change.

MFA is a gate. The session is the hallway.

Most organizations have spent years reinforcing the front gate. MFA, and especially phishing-resistant MFA, makes it far harder to walk through that gate as someone else. But attackers have adapted. They no longer need to break through the gate when they can follow an authorized user inside and take their badge.

Defending the session means accepting that authentication is only the beginning of trust, not the end of verification. Bind sessions to devices, watch them continuously, and make sure you can end them in minutes.

MFA passed. Make sure that is not the last thing your security controls checked.

Key takeaways

  • MFA protects the moment of sign-in. Session cookies and tokens issued afterward are bearer credentials that work for whoever holds them.
  • Attackers steal sessions through AiTM phishing, infostealer malware, token-based phishing, and leaked artifacts.
  • Passkeys stop AiTM phishing but not infostealers. Session binding is required to protect the session itself.
  • Detect session reuse from new networks or devices after MFA, and alert on persistence changes that follow risky sign-ins.
  • A password reset does not end a stolen session. Revoke tokens everywhere, remove persistence, and clean the endpoint.

References

Figures are drawn from vendor, law-enforcement, and media reporting and may be revised. Code examples are illustrative and should be adapted to your environment.

If you found this useful, follow me for more on identity security and AI-era threats, and share it with the person who owns your MFA rollout.