.png)
What is an Adversary-in-the-Middle (AiTM) Attack?
An AiTM attack relays authentication in real time to capture the session token MFA produces. How the proxy chain works, why detection is hard, and what defeats it.
The Attack Chain
1. Lure. The victim receives a link by email, SMS, or increasingly by phone call. In 2025-2026 the phone-call variant has dominated against high-value targets: an attacker impersonating internal IT walks the victim to the URL verbally, which defeats email filtering entirely.
2. The proxy. The link resolves to attacker-controlled infrastructure running a reverse proxy — commonly Evilginx2, Modlishka, or Muraena. The victim sees a pixel-accurate rendering of the real sign-in page, because it is the real sign-in page, relayed. The domain is typosquatted and usually carries a valid TLS certificate.
3. Credential relay. The victim enters username and password. The proxy forwards them to the legitimate identity provider and receives the genuine MFA challenge in response.
4. MFA relay. The proxy presents the real challenge to the victim, who approves the push or enters the code. The victim's second factor is satisfied against the real identity provider.
5. Token capture. The identity provider issues a session token. The proxy captures it before forwarding the victim to the real destination, so the victim's experience is a successful login with nothing visibly wrong.
6. Session replay. The attacker loads the token into their own browser and accesses resources as the user.
Why Detection Is Hard
From the identity provider's perspective, every step was legitimate. The password was correct. The MFA challenge was completed by a human. The token was issued through the normal flow. There is no failed authentication, no anomalous credential use, no malware on the endpoint.
The available signals are contextual rather than authentication-based:
- Sign-in from an IP or ASN inconsistent with the user's pattern, particularly commercial VPN or residential proxy infrastructure
- Impossible travel between the legitimate session and the attacker session
- User agent inconsistencies, though these are easily spoofed
- New device registration shortly after the sign-in — a common persistence step
- OAuth grants or mailbox rules created shortly after — also persistence
Each of these is noisy in isolation. Detection depends on correlating them, which requires either a well-tuned identity protection product or a human reviewing identity telemetry deliberately.
What Prevents It
FIDO2 and WebAuthn. The definitive control. These protocols perform origin binding: the authenticator cryptographically verifies it is communicating with the legitimate domain before releasing the assertion. A proxy at microsoftonline-verify[.]com is not login.microsoftonline.com, so the ceremony fails and no token is issued. This is not a mitigation, it is a defeat of the technique.
Certificate-based authentication. Similar origin-binding property.
Device-bound sessions and Conditional Access. If the token only works from a registered compliant device, replay from the attacker's machine fails.
Number matching and context in push notifications. A meaningful improvement over simple approve/deny, and still relayable. Better than nothing, weaker than FIDO2.
The Phishing-Awareness Problem
Security awareness training teaches users to check the URL, look for the padlock, and be suspicious of unexpected requests. AiTM defeats all three: the page is a perfect rendering, TLS is valid, and in the vishing variant the request arrives with a human voice explaining why it is expected.
Training remains worth doing. It should not be relied on as the control against this technique. The control is authentication that cannot be relayed.
Related Reading
The 2025-2026 Wave
AiTM was the technical foundation of the campaign that ran from UK retail through Wall Street. In April 2025, attackers reached Marks & Spencer, Co-op, and Harrods through helpdesk manipulation and MFA reset. In March 2026 the same ecosystem took ~900K records from Aura. In July 2026 it reached Apollo Global Management, with Blackstone, Bridgewater, and Bain Capital also targeted per Google's Threat Intelligence Group.
The consistent element across all of them: the victim organization had MFA deployed, and the attacker obtained authenticated access anyway.
is the property that defeats AiTM. FIDO2 and WebAuthn authenticators verify the legitimate domain before releasing an assertion, which means a relay proxy on a lookalike domain never receives a usable token.