MFA bypass and session token theft: why “we have MFA” is no longer the answer

Enabling MFA closed the credential-stuffing door and opened a different one. Modern phishing kits do not try to defeat MFA - they proxy the real login page, let you complete MFA legitimately, and steal the resulting session token. From the application's perspective, everything was correct.

How the common attacks work

• Adversary-in-the-middle (AiTM). The victim visits a proxy that relays to the genuine site in real time. They see the real login, the real MFA prompt, and a valid certificate. The attacker captures the session cookie and replays it - no password or second factor needed afterwards.
• MFA fatigue. Repeated push notifications until someone approves one, often at 3am, to make it stop.
• SIM swap. Porting the victim's number to intercept SMS codes.
• Token theft from the endpoint. Malware lifting session cookies or refresh tokens directly from the browser or token cache.
• Consent phishing. Persuading the user to grant a malicious OAuth application persistent access - which survives password resets entirely.

The unifying point: the attacker ends up holding a valid session, not a credential. That is why forcing a password reset after an incident so often fails to evict them - the stolen session is unaffected.

What actually works

1. Phishing-resistant MFA. FIDO2 security keys and passkeys are cryptographically bound to the legitimate domain, so a proxy site cannot relay the authentication. This is the single control that defeats AiTM outright rather than making it harder.
2. Token binding and device compliance. Tie the session to a managed, compliant device so a replayed token from elsewhere fails.
3. Conditional access on signals - impossible travel, unfamiliar device, anomalous geography, unmanaged endpoint. These catch replay after the fact.
4. Number matching to kill MFA fatigue, and removing SMS as a factor for anything privileged.
5. Short session lifetimes for high-privilege access, with re-authentication for sensitive actions.
6. OAuth application governance - restrict which third-party apps users can consent to.

Detection

Since the authentication looks legitimate, detection has to key on what follows: sign-in from a new device or geography immediately after a successful MFA, session token used from a different IP or user agent than it was issued to, unusual mailbox rule creation, mass file access, or new OAuth grants.

Mailbox rules deserve a specific mention - creating a rule that hides or forwards mail is the most common first action after account takeover in business email compromise, and it is trivially detectable if anyone is looking.

Responding to a stolen session

Password reset alone does not evict the attacker. The response is:

1. Revoke sessions and refresh tokens explicitly - most platforms have a specific action for this, separate from a password reset.
2. Reset the credential and re-enrol MFA if the enrolment path may have been abused.
3. Review and remove OAuth grants, mailbox rules and forwarding.
4. Check for privilege changes and new accounts created during the window.

Key takeaways

• Modern kits steal the session, not the password - MFA completes normally.
• Phishing-resistant methods are the control that actually defeats AiTM.
• Detect on post-authentication behaviour, especially new mailbox rules.
• Revoke sessions and tokens explicitly; a password reset is not enough.