AiTM phishing puts the attacker between you and the real login page. You type your password on what looks like the genuine site, you approve the MFA prompt, and everything works, because the page really is talking to the real service. What the attacker takes is not your password. It is the session.
That is why this one matters more than ordinary phishing. Most defensive advice assumes multi-factor authentication is the backstop. Against this technique it usually is not, and the reason is worth understanding before you decide what to change.
Microsoft is explicit that this is not a vulnerability in MFA. The attacker steals the session cookie, so they are authenticated on your behalf regardless of how you signed in.
What Is an AiTM Phishing Attack?
Adversary-in-the-middle phishing, usually shortened to AiTM. The attacker runs a proxy server between the victim and the real website, so every keystroke and every response passes through them. The victim sees the genuine login page because they are, in effect, looking at it through the attacker’s window.
It is a step up from a fake login page. A conventional phishing page is a copy that collects what you type. A proxy relays it live, which is what lets the attacker complete the real sign-in at the same moment you do.
The payoff is the session cookie. Once the attacker holds the token that proves you are signed in, they can replay it and be inside the account without needing your password or your second factor again. Transputec treats a suspected AiTM compromise as a session incident rather than a password one, which changes the whole response.
How Does It Actually Work?
In four steps, and the user experience is completely normal throughout. There is no error, no second prompt, nothing that feels wrong. The victim signs in successfully, lands where they expected, and carries on with their day while the attacker holds a copy of the session.
One. A link reaches the victim, usually by email. It points at a domain the attacker controls, which proxies the real sign-in page.
Two. The victim enters their password. The proxy passes it straight to the genuine service and keeps a copy.
Three. The real service asks for MFA. The victim approves it. The proxy relays that too, and the sign-in completes properly.
Four. The genuine service issues a session cookie. The proxy captures it. Microsoft describes exactly this in its analysis of AiTM campaigns, noting the proxy intercepts both the password and the cookie that proves an authenticated session.
Scale is not theoretical. Microsoft reported one campaign that attempted to target more than 10,000 organisations from September 2021.
Not Sure Your MFA Would Hold?
Transputec deploys Mimecast email security for anti-phishing, business email compromise and impersonation defence, with a 24/7 UK managed SOC watching for the sign-ins that follow. Talk to our team about the security work behind your logins.
Get a Strategic ConsultationCan MFA Stop AiTM Phishing?
Some types can and most cannot, which is the single most useful thing to know here. The NCSC ranks MFA methods by resistance, and the gap between the top of that list and the rest is exactly the gap an AiTM proxy walks through. Its recommended types of MFA put them in this order.
| NCSC rank | MFA type | Holds against AiTM? |
|---|---|---|
| 1 | FIDO2 credentials, including passkeys and hardware keys | Yes. NCSC calls it phishing resistant. The credential is tied to the real domain, so it will not work on the attacker’s proxy |
| 2 | Challenge-based authenticator apps | Partly. NCSC says partial phishing resistance, and it is vulnerable to prompt fatigue |
| 3 | App-based code generators | No. NCSC notes these are vulnerable to OTP interception phishing |
| 4 | Hardware-based code generators | No. Same OTP interception problem, and not theft resistant |
| 5 | Message-based: SMS, email, phone call | No. Bottom of the NCSC list |
Anything that produces a code a human can retype can be relayed by a proxy in real time. That covers rows three to five entirely. FIDO2 is different because the credential is bound to the genuine domain, so when the browser is pointed at the attacker’s site the authenticator simply will not produce anything usable.
How Is This Different From Normal Phishing?
Ordinary phishing takes your password and has to use it somewhere else. AiTM phishing takes a live, already-authenticated session, which is a different object entirely. Changing your password afterwards closes the first attack and does very little about the second.
Detection differs too. A classic phishing page is a static copy, often with tells in the content. An AiTM proxy is showing you the real page, so there is nothing visibly wrong with it. The only reliable signal is the domain in the address bar.
And the response differs. For credential phishing you reset the password. For this you have to revoke the session tokens as well, or the attacker stays signed in with the password you just changed. We cover the broader comparison in our post on spear phishing versus phishing.
What Happens After They Have Your Session?
Usually quiet reconnaissance, then fraud. Microsoft’s research traced AiTM compromises straight into business email compromise: the attacker reads the mailbox, finds an invoice thread in progress, and inserts themselves into it. The account behaves normally throughout because it is genuinely the user’s account.
Mailbox rules are the usual fingerprint. An attacker who wants time will quietly create a rule that moves replies from a finance contact into an obscure folder, so the real user never sees the conversation happening in their name.
Then the payment request goes out from a real internal address, mid-thread, with correct context. That is why this technique converts into money so reliably, and why the phishing playbook matters more than the filter once a session is gone.
How Do You Defend Against It?
Move the top of your MFA stack to FIDO2, then assume some sessions will still be stolen and build for that. Microsoft’s own recommendations pair phishing-resistant authentication with conditional access that weighs device state and location, because the two together make a stolen cookie far less useful on an unmanaged machine.
In practice that means passkeys, which are FIDO2 credentials bound to the real domain. Start with the accounts that can move money or change access: finance, payroll, IT administrators, executives. Universal rollout takes months and these take weeks.
Add session revocation to your incident process. Resetting a password without killing active tokens leaves the attacker signed in, and it is the step most often missed.
Then watch the sign-ins rather than the emails. Impossible travel, a new device, a mailbox rule created minutes after a login: those are the signals a Transputec managed SOC is looking for, and they are what catches this after the proxy has already done its work.
What Should Staff Be Told?
One thing, and it is not about spotting a fake page, because there is not one. Check the domain before you type a password, every time, and treat a login prompt that arrives via a link as suspect by default. Navigate to the service yourself instead of following the link.
Tell them the prompt approving normally is not reassurance. People assume that if MFA worked, the site was genuine. With this technique MFA working is precisely what the attacker needs.
And make reporting easy afterwards. Someone who realises an hour later that a login page looked slightly off is giving you the window to revoke the session, which is worth far more than them staying quiet. Phishing simulations can test whether that reporting habit actually exists.
Your Checklist
In rough order of impact.
- Move finance, payroll, IT admins and executives to FIDO2 or passkeys first.
- Turn on conditional access that checks device state and location, not just identity.
- Add session and token revocation to the incident runbook, next to password reset.
- Alert on mailbox rules created shortly after a sign-in.
- Alert on impossible travel and new-device sign-ins for privileged accounts.
- Teach staff to check the domain, and that a working MFA prompt proves nothing.
- Make sure somebody receives what the report button sends.
Conclusion
AiTM phishing works by stealing a live session rather than a credential, which is why a correct MFA prompt does not save you. Microsoft is clear that this is not a flaw in MFA. It is a technique built specifically because MFA became common.
The practical answer has two halves. Move the accounts that matter onto FIDO2, where the credential is tied to the real domain and the proxy gets nothing usable. Then assume a session will go anyway and make sure you can see it and revoke it. Transputec runs that second half through cyber security services, with Mimecast on the email and a 24/7 UK SOC on the sign-ins. Talk to us about the security work behind your logins.
FAQs
What Is an AiTM Phishing Attack?
Adversary-in-the-middle phishing. The attacker runs a proxy between the victim and the real website, so the victim sees the genuine login page while every keystroke passes through the attacker. The goal is the session cookie rather than the password, because that cookie proves an already-authenticated session.
How Does AiTM Phishing Bypass MFA?
It does not break MFA, it goes around it. The proxy relays the MFA challenge to the real service and the victim approves it normally, so the sign-in genuinely succeeds. The attacker then captures the session cookie the service issues. Microsoft states plainly that this is not a vulnerability in MFA, because the stolen cookie authenticates the attacker regardless of sign-in method.
Can MFA Stop Adversary-in-the-Middle Attacks?
FIDO2 credentials and passkeys can, because the credential is bound to the real domain and will not produce anything usable on the attacker’s proxy. The NCSC ranks FIDO2 first and describes it as phishing resistant. Codes from apps, hardware tokens, SMS or email can all be relayed by a proxy in real time, so they do not stop it.
How Do You Recover From a Stolen Session Token?
Revoke the sessions, not just the password. Resetting the password alone leaves active tokens working, so the attacker stays signed in. Revoke tokens, sign the account out everywhere, check for mailbox rules created around the time of the sign-in, and review anything sent from the account since. Transputec treats token revocation as a standard step in that runbook.
Is AiTM Phishing the Same as a Man-in-the-Middle Attack?
It is a specific application of the same idea. Man-in-the-middle is the general pattern of intercepting traffic between two parties. AiTM phishing is that pattern applied to a login flow, with the goal of capturing an authenticated session rather than reading traffic.
This article was drafted with AI assistance and reviewed by the Transputec team. Featured image: AI-generated.
