HomeBlog › Threat Intelligence
Threat Intelligence

AiTM Phishing Explained: How Attackers Bypass Your MFA

BreachLens Research·May 25, 2026·7 min read

MFA is necessary but no longer sufficient. Here's how adversary-in-the-middle phishing defeats it by stealing session tokens — and what actually stops it.

Think your Microsoft 365 may be compromised?

Upload your M365 audit log to BreachLens and get an instant, forensic-grade timeline of attacker activity — inbox rules, token theft, mailbox access and more. Free tier, no credit card, results in minutes.

Start a free investigation →

"But we have MFA" is the sentence we hear most often after a Microsoft 365 breach. The uncomfortable reality in 2026 is that multi-factor authentication, while essential, is routinely bypassed by adversary-in-the-middle (AiTM) phishing. Understanding the mechanism is the first step to defending against it.

How adversary-in-the-middle phishing works

In a traditional phishing attack, the criminal captures your password on a fake login page. AiTM goes a step further. The phishing page acts as a reverse proxy sitting between you and the real Microsoft login. You enter your username, password, and even complete your MFA prompt — and the proxy relays each step to the genuine service in real time. Because the login actually succeeds, Microsoft issues a valid session token, and the attacker's proxy captures it.

With that stolen session token, the attacker can access the mailbox directly, without ever needing the password or triggering MFA again. The session looks legitimate because, technically, it is.

Why this matters more every quarter

Phishing-as-a-service kits have made AiTM push-button. Platforms such as Tycoon2FA lease ready-made AiTM infrastructure, and in 2026 the FBI warned about Kali365, a subscription kit sold on Telegram from around $250 that hijacks Microsoft 365 accounts without touching the password. A single AiTM campaign observed in April 2026 targeted more than 35,000 users across 13,000+ organizations. Token theft is now the dominant path into M365 tenants.

What AiTM looks like in your logs

The tell-tale pattern is a successful sign-in that satisfied MFA but originated from an unusual IP, ASN, or geography — often shortly after the user clicked a link. You may then see token reuse from a different location, new inbox rules created, and mailbox access that doesn't match the user's normal hours. Correlating sign-in logs with MailItemsAccessed events exposes the hijacked session.

How to defend against AiTM

If you suspect a token was stolen

Changing the password will not help on its own — you must revoke the account's sessions in Microsoft Entra ID. Then investigate the dwell time: what the session accessed and whether persistence (inbox rules, OAuth grants) was established. BreachLens reconstructs that token-theft timeline from your M365 logs automatically.

Get answers in minutes, not days

BreachLens parses your Microsoft 365 logs automatically and reconstructs exactly what an attacker did. Run your first investigation free.

Start a free investigation →

Frequently asked questions

Does MFA stop adversary-in-the-middle phishing?

Standard MFA (SMS, authenticator app push/code) does not. AiTM proxies the entire login including the MFA step and steals the resulting session token. Phishing-resistant methods like FIDO2 keys, Windows Hello, and passkeys do defeat AiTM because they are cryptographically bound to the real domain.

What is a session token and why do attackers steal it?

A session token is the credential your browser holds after a successful login so you don't re-authenticate on every request. If an attacker steals it via an AiTM proxy, they can use it to access your account directly without the password or MFA until the token is revoked or expires.

How can I tell if I was hit by AiTM phishing?

Look for a successful, MFA-satisfied sign-in from an unusual IP or location shortly after a phishing click, followed by token reuse from elsewhere, new inbox rules, or off-hours mailbox access. Correlating Entra ID sign-in logs with MailItemsAccessed events reveals it.