For years, multi-factor authentication (MFA) was sold as the definitive answer to credential theft: turn on MFA and phishing becomes a manageable problem. That premise no longer holds. The dominant phishing technique of 2025 and 2026 against Microsoft 365, Google Workspace and Okta does not try to break MFA: it lets the user authenticate correctly and then steals the result. It is called AiTM phishing (adversary-in-the-middle), and it is worth understanding properly.
This article is about awareness and defense. It explains what AiTM is, how it works at a high level, why classic MFA does not stop it, how it differs from the device code phishing that exploded in 2026, and above all how to detect it, defend against it and respond if it has already happened. It contains no instructions for setting it up or running it.
- What AiTM phishing is
- The attack in five phases
- Why classic MFA does not stop it
- Three ways to steal a session
- The 2026 frontier: device code phishing
- Token theft without phishing: infostealers
- The scale of the problem: phishing as a service
- How to detect an AiTM attack
- How to actually defend against it
- What to do if it has already happened
- Frequently asked questions
What AiTM phishing is
AiTM (adversary-in-the-middle) is a phishing technique that uses a reverse proxy to intercept credentials and session tokens in real time. The attacker places a server between the victim and the legitimate login page: the victim sees what looks like the real login (because it is, relayed), enters their details and completes MFA. The proxy captures the session cookie that the legitimate site issues at the end, and replays it to log in as the victim.
The difference from old-school phishing matters. Classic phishing builds a fake page, steals your username and password and stops there; if you have MFA, the attacker stays locked out. AiTM is not satisfied with the password: it takes the already-authenticated session, which is exactly what MFA was protecting. In the MITRE ATT&CK framework this falls under techniques T1557 (adversary-in-the-middle) and T1539 (steal web session cookie).
The attack in five phases
# The 5 phases of an AiTM attack (defensive view) Phase 1 Lure: the victim clicks a phishing link Phase 2 Reverse proxy: lands on a server that relays to the real login Phase 3 Capture: enters username and password; the proxy relays and copies them Phase 4 MFA relay: approves the second factor, which the proxy forwards to the real site Phase 5 Cookie theft: the real site issues the session cookie and the proxy steals it → the attacker imports the cookie and gets in with no password and no MFA
The key detail is in phase 5: what gets stolen is not the password, it is the session cookie, the token that proves authentication (including MFA) was already completed successfully. With that cookie in their browser, the attacker has an authenticated session and is never prompted again. They do not even need the password: the session is already open.
Why classic MFA does not stop it
Here is the shift in mindset. MFA based on SMS, TOTP or push notifications protects the moment of login. But in an AiTM attack the victim completes a fully legitimate authentication flow: they enter the real code, approve the real push. MFA does its job. The problem is that the attacker does not attack the login, but what comes after it: the token that proves the login was good. You cannot stop something that never even gets triggered.
Incident-response telemetry backs this up. Cisco Talos reported that, in the first quarter of 2024, nearly half of the incidents it responded to were related to MFA (fraudulent push notifications accepted by the user and poor implementations), and that across the full year identity was involved in around 60 percent of cases. MFA stopped being a box you tick and forget.
Three ways to steal a session, one same outcome
AiTM with a reverse proxy is the best-known variant, but it is not the only way to end up inside an account without breaking MFA. It is worth telling them apart because they are not defended the same way, and this is the most common mistake: applying the right defense to the wrong variant.
| Technique | How it works | What defense stops it |
|---|---|---|
| AiTM (reverse proxy) Evilginx, Tycoon 2FA, EvilProxy, Mamba 2FA, Sneaky 2FA |
A phishing domain relays the real login and captures the session cookie issued at the end. | FIDO2 / passkeys. The credential is origin-bound and will not sign for the fake domain. |
| Device code phishing Storm-2372, EvilTokens, Kali365 |
The attacker starts an OAuth device code flow and convinces the victim to type the code on the real Microsoft page. The attacker's device receives the tokens. | Conditional access blocking the device code flow where it is not used. Passkeys are not enough here: the victim authenticates on the legitimate origin. |
| Token theft via infostealer Credential-stealing malware families |
Malware on the victim's machine dumps cookies and tokens from already-authenticated sessions. There is no login and no MFA. | Device-bound tokens (token protection), EDR and short session lifetimes. |
The 2026 frontier: device code phishing
If reverse-proxy AiTM was the big story of 2024 and 2025, the variant that has taken off in 2026 is device code phishing. The OAuth device code flow exists so that devices without a convenient keyboard (televisions, printers, consoles) can authenticate: the device shows a short code and you enter it on a web page from your phone or computer.
The abuse is elegant in its simplicity: the attacker starts that flow and sends the victim an email inviting them to go to a real Microsoft page and enter a code. Because the page is genuine, MFA completes without suspicion, and when it finishes the one who receives the access tokens is not the victim, but the attacker's device. There is no fake domain and no proxy: just a legitimate flow used against you.
Microsoft tracked a large-scale campaign using this technique in early 2025 (the Storm-2372 group). In 2026 it has been industrialized with platforms such as EvilTokens and Kali365. The latter was the subject of an FBI alert (PSA dated 21 May 2026) for hijacking Microsoft 365 accounts by stealing OAuth tokens without touching the password, sold over Telegram from around 250 dollars a month. Detections of this technique surged sharply in early 2026, with multiple kits competing in the market.
Token theft without phishing: infostealers
There is an even more direct route that does not even need a fake page: token theft via malware. So-called infostealers harvest cookies and tokens from the browser, which represent already-authenticated sessions. The attacker imports that cookie, skips the login page entirely, and MFA never fires, because there is no login to protect.
It is the same underlying idea as AiTM (the valuable thing is the token, not the password), but through a different door. That is why a solid EDR and endpoint hygiene are part of the anti-AiTM defense even though they seem to have nothing to do with phishing: if the machine is clean, there are no cookies to dump.
The scale of the problem: phishing as a service
This is not a cottage industry: it is industrialized. There is a whole phishing-as-a-service (PhaaS) market. It is worth separating two things that often get conflated: on one hand, open-source frameworks such as Evilginx, which anyone can download; on the other, commercial kits rented by subscription, such as Tycoon 2FA, EvilProxy, Sneaky 2FA or Mamba 2FA, and the more recent device-code-oriented ones such as EvilTokens and Kali365.
The entry price is low, in some cases under 300 dollars a month, and the sophistication is high: panels with real-time victim tracking, campaign templates and AI-generated lures. AiTM and its cousins are attractive to attackers precisely because they do not require the research or the time of a SIM swap or social-engineering a help desk: the kit does the heavy lifting.
How to detect an AiTM attack
Even though the attack is stealthy, it leaves traces if you know where to look. The most reliable signal is the same session used from two incompatible contexts:
# Detection signal: same session, two contexts (access log) 2026-06-15 09:41:22 [email protected] ip=198.51.100.23 ua="Windows NT 10.0; Edge" geo=Madrid,ES action=login_ok 2026-06-15 09:43:05 [email protected] ip=203.0.113.77 ua="X11; Linux x86_64" geo=Amsterdam,NL action=mailbox_read → same account, +1500 km in 2 min, different User-Agent: impossible travel + session reuse
Signals worth watching:
- Impossible travel: the same account signing in from two geographically incompatible locations in a short time.
- Same cookie, different context: the same session cookie or token used from two different User-Agents or IP addresses (the victim's and the attacker's). That is visible in the logs.
- Session anomalies: sessions that appear without a coherent preceding login event.
- Unexpected device code events: device code authentications the victim did not initiate, especially from hosting or cloud IPs.
- Suspicious OAuth consents: newly registered applications or broad permission grants that nobody remembers authorizing.
How to actually defend against it
Effective defense is not "more MFA", it is phishing-resistant MFA combined with policies that limit the value of a stolen token:
- FIDO2 / WebAuthn and passkeys: this is the defense that truly neutralizes reverse-proxy AiTM. These credentials are origin-bound: the cryptographic signature only works on the legitimate domain. If the victim is on a phishing domain, the browser detects the mismatch and refuses to sign. The proxy is left with nothing to steal.
- Block the device code flow via conditional access wherever it is not used. It is the only real defense against the device code variant, which passkeys do not cover.
- Conditional access: require a managed or compliant device, not just valid credentials.
- Device-bound tokens (token protection) and short session lifetimes, so a stolen cookie expires soon or does not work on another machine.
- Continuous access evaluation (CAE): revokes tokens in near real time on risk changes, instead of waiting for them to expire.
- Monitoring for impossible travel, anomalous tokens and OAuth consents.
- Awareness: no legitimate login arrives via an unexpected link with urgency, and nobody should ask you to enter a code you did not request.
What to do if it has already happened
This is where the most expensive mistakes are made. The instinctive reaction to a compromised account is to change the password, and that on its own does not evict the attacker. The stolen token, and especially the refresh token, stays valid until it expires or is explicitly revoked. There are incidents where the attacker kept access after a password reset for exactly this reason.
The correct order of action:
- Revoke all sessions and tokens for the affected account, not just change the password.
- Review and remove OAuth consents and registered applications you do not recognize.
- Check mailbox rules and auto-forwarding: a common action after the theft is to create rules that hide or forward emails.
- Reset the password and, where possible, migrate the account to passkeys.
- Look for lateral movement: a stolen token is usually the beginning, not the end.
Frequently asked questions
Does AiTM mean MFA is useless?
No. MFA still blocks the majority of attacks and turning it off would be a serious mistake. What AiTM shows is that classic MFA (SMS, TOTP, push) is no longer enough on its own and that you need to migrate to phishing-resistant MFA.
What exactly does the attacker steal in an AiTM attack?
The session cookie or token, not the password. That token proves authentication (including MFA) was completed, so with it the attacker gets in without being prompted for anything more.
Why do passkeys stop AiTM?
Because they are origin-bound: the credential only signs for the legitimate domain. On a phishing domain the browser detects the mismatch and refuses, so the proxy gets nothing reusable.
Do passkeys protect me completely?
They stop reverse-proxy AiTM, but not device code phishing, because in that variant the victim authenticates on the provider's real page. For that route the defense is conditional access that blocks the device code flow where it is not used.
What is the difference between AiTM and device code phishing?
AiTM uses a reverse proxy and a fake domain that relays the real login to steal the cookie. Device code phishing uses no fake domain: it abuses a legitimate OAuth flow and tricks the victim into authorizing the attacker's device on the genuine page.
How do I detect if it happened to me?
Look for signals such as impossible travel, the same session cookie used from two different User-Agents or IPs, sessions without a coherent login, and device code events or OAuth consents you do not recognize. Access logs are your best ally.
If I change the password, do I evict the attacker?
Not necessarily. The stolen session token stays valid until it expires or is revoked. After an incident you have to revoke sessions and tokens, remove OAuth consents and review mailbox rules, in addition to changing the password.
References
- MITRE ATT&CK T1557: adversary-in-the-middle.
- MITRE ATT&CK T1539: steal web session cookie.
- FBI / IC3: alert on the Kali365 kit and Microsoft 365 token theft (21 May 2026).
- CISA: guidance on phishing-resistant MFA.
- FIDO Alliance: passkeys and phishing-resistant authentication.