An adversary-in-the-middle (AiTM) attack is a phishing kit that sits between your staff member and the real login page: the user sees a genuine Microsoft or Google login, enters real credentials, approves a real MFA prompt — and the attacker harvests both the password and a usable session cookie in the same session. It is the attack that made "we have MFA, so we're safe" obsolete, because the MFA prompt is genuine and the approval is real. Mandiant's M-Trends 2026 report records email phishing at just 6% of intrusions as automated filters improve, while highly interactive, human-directed techniques like AiTM and voice phishing surged to 11% (M-Trends 2026) — attackers are not giving up on phishing, they are making it harder to detect. This guide explains how AiTM works, why it defeats MFA, and the controls that actually stop it.
TL;DR
- AiTM phishing proxies the real login page in real time: real password, real MFA approval, stolen session.
- It defeats MFA because the prompt is genuine — the attacker steals the session cookie the moment it is issued.
- The strongest counter is FIDO2 hardware keys, which are cryptographically bound to the real domain.
- Conditional access, device binding and phishing-resistant MFA close the rest of the gap.
- Detection still depends on people: awareness training that teaches staff to notice the wrong URL is the last line.
How an AiTM attack works
- The lure. A staff member receives a phishing email — a shared document, an e-signature request, a payroll change. The link points to a lookalike domain the attacker controls.
- The proxy. Instead of showing a fake login page, the kit silently proxies every request to the real Microsoft 365 or Google login page. What the user sees is pixel-perfect because it is pixel-perfect — it is the real page, fetched live.
- The harvest. The user types their password; the proxy records it and forwards it. The real MFA prompt arrives; the user approves it; the proxy records the session cookie that the real site issues.
- The replay. The attacker imports the stolen session cookie into their own browser and lands inside the real mailbox — no password needed, no MFA prompt fires again. They read mail, send invoices, redirect payments, all while the user believes they just completed an ordinary login.
The whole sequence takes under a minute and requires no exploit. The "vulnerability" is a person completing a login.
Why MFA does not stop it
MFA authenticates a login; AiTM steals the session that login produces. The prompt the user approves is the real one from the real site, relayed through the proxy. Nothing about the authentication is fake — only the address bar is.
That is why the answer is not "more MFA" but "MFA that cannot be relayed":
| Method | Survives AiTM? | Why |
|---|---|---|
| Password + SMS code | No | Both relayed in real time |
| Password + authenticator app | No | The TOTP code and approval are relayed too |
| Push approval | No | The push is real; the user approves it |
| FIDO2 hardware key / passkey | Yes | The key signs the real domain's challenge; a proxy domain cannot trigger it |
What attackers do once inside
- Business email compromise. Send payment-fraud requests from a real mailbox, in real threads, with real signatures.
- Payroll diversion. Change a staff member's bank details in the payroll system from inside the tenant.
- OAuth persistence. Grant a malicious app consent, so access survives password resets and MFA re-enrolment.
- Inbox rules. Hide or forward the attacker's traces so the fraud continues undetected for weeks.
- Lateral movement. Reuse the stolen session and credentials on other company systems that share the identity.
How to stop AiTM attacks
- Phishing-resistant MFA. FIDO2 hardware keys or passkeys for finance, directors and admins — the single highest-value change. They cannot be relayed because the key signs the real domain's cryptographic challenge.
- Conditional access with device binding. Require the sign-in to come from a known, managed, compliant device; a stolen cookie replayed from the attacker's laptop fails the device check.
- Short session lifetimes and token protection. Limit how long a stolen cookie remains usable.
- Alert on impossible travel and risky sign-ins. The replayed session often lands from a different geography than the original login.
- Kill legacy authentication. AiTM kits love legacy mail protocols that bypass MFA entirely.
- Train the URL reflex. The lookalike domain is still the tell — training with phishing simulations that include proxy-kit lures teaches staff to check the address bar before they type.
- Rehearse the response. When a staff member reports the lure, reset the password and revoke all sessions and refresh tokens immediately — a stolen session dies at revocation.
A gap assessment tells you which of these controls you already have and which are missing — ranked, not guessed.
FAQ
What is an adversary-in-the-middle attack in simple terms? A phishing kit that proxies the real login page in real time, capturing the password, the MFA approval and the session cookie in one genuine login — then replays that session from the attacker's machine.
How is AiTM different from ordinary phishing? Ordinary phishing shows a fake page and harvests a password that MFA then blocks. AiTM shows the real page, harvests the password AND the MFA approval, and walks away with a working session.
Does MFA stop AiTM attacks? Standard MFA does not — the approval is genuine and relayed. Only phishing-resistant methods (FIDO2 keys, passkeys) stop it, because they cannot work on a proxy domain.
What is the fastest partial fix if we can't roll out hardware keys? Conditional access requiring managed devices. A session cookie replayed from an unmanaged device fails the device check, even if the cookie is valid.
How do we detect an AiTM attack that already succeeded? Look for sign-ins from unfamiliar devices or geographies, new inbox rules, new OAuth app consents, and colleagues receiving messages the sender never sent.
What should staff do when they spot a lookalike domain? Do not type anything — close the tab, report the email with the suspicious link, and let IT reset any credentials already entered. Reporting beats deletion: the report lets you warn the rest of the team.
One last thing
Order hardware security keys for your finance and admin staff this week. They cost less than one hour of an incident responder's time, and they are the one MFA method an AiTM kit cannot relay. Until then, switch on conditional access device checks — a stolen session cookie that only works on a managed device is a session cookie that does not work.