Adversary-in-the-middle phishing is a real-time proxy attack that relays a victim's login to the real site and captures the resulting session token, letting the attacker in even when MFA is on. Because it steals the authenticated session rather than just the password, it defeats most one-time-code and push-based multi-factor authentication.
What is AiTM phishing?
Ordinary phishing steals a username and password. Adversary-in-the-middle phishing goes further by placing a reverse proxy between the victim and the real login page. The victim lands on a convincing fake, but every keystroke is passed straight through to the genuine site, and the genuine site's responses are passed back. To the victim, everything looks and behaves exactly like the real service.
The point of sitting in the middle is to capture what happens after the password. When the victim completes MFA, the real site issues a session cookie, and the proxy grabs it. Armed with that session token, the attacker can replay the authenticated session in their own browser without ever needing the password or the second factor again. Toolkits sold as phishing-as-a-service make this point-and-click, so it is no longer an advanced-only technique.
For a fraud or security team, AiTM is the answer to "we turned on MFA, why are accounts still getting taken over?" It targets the session, not the credential, which is why traditional MFA does not stop it and why session-level controls matter.
How an AiTM attack unfolds
The attack runs live, in the seconds while the victim is logging in:
- LureSend the phishing link An email or message points the victim to a proxy page cloned from the real login screen.
- RelayProxy the login live The victim enters credentials and MFA, and the proxy passes each step to the genuine site in real time.
- CaptureSteal the session cookie The real site authenticates and issues a session token, which the proxy intercepts and keeps.
- ReplayReuse the session The attacker imports the cookie into their own browser and is logged in, no password or MFA needed.
Who is involved?
Who | Their role |
The attacker | Runs the proxy kit, sends the lure, and replays the stolen session. |
The victim | Logs in through the proxy, completing MFA on what looks like the real site. |
The real service | Authenticates the login normally and issues the session token that gets stolen. |
The phishing-kit vendor | Sells the ready-made AiTM toolkit and hosting that make the attack easy to run. |
What it looks like in practice
An employee receives an email that looks like a shared-document notification and clicks through to a login page identical to their company's sign-on. They enter their password and approve the push prompt on their phone, exactly as they always do. The page loads the real document, so nothing seems wrong.
Behind the scenes, the page was a proxy. It captured the session cookie the moment MFA succeeded. Within minutes, the attacker loads that cookie in their own browser, is fully signed in without any further challenge, sets up a mailbox forwarding rule, and begins hunting for invoices to redirect. The identity provider logged a clean, MFA-satisfied login.
Why it matters to operators
AiTM breaks the comfortable assumption that MFA equals safe. Because it steals an already-authenticated session, one-time codes and push approvals do not help, and the fraudulent access shows up in logs as a successful, compliant login. That makes it dangerous precisely for teams that consider MFA their strongest control.
The defenses that work are the ones tied to the session and the device rather than the login moment. Phishing-resistant authentication such as passkeys and hardware keys will not complete against a proxy domain, so the attack fails at step two. Beyond that, binding sessions to a device, watching for a token suddenly used from a new IP, browser, or geography, and shortening session lifetimes all shrink the window in which a stolen cookie is useful.
What to watch in the data
- Session relocation. A valid session token appearing from a new IP, device, or country moments after a normal login elsewhere.
- Proxy domains. Logins referred from look-alike or newly registered domains standing in for the real sign-on page.
- Impossible travel on one session. The same authenticated session used from two far-apart locations in quick succession.
- Post-login persistence. New mailbox forwarding rules, OAuth grants, or MFA methods added right after a clean sign-in.
- Device mismatch. A session cookie presented from a browser fingerprint that does not match the one that authenticated.
Quick questions
Why doesn't MFA stop AiTM?
MFA proves who is logging in, but AiTM lets the real login succeed and then steals the session token issued afterward. The attacker replays that token, so they never have to satisfy MFA themselves. The credential is not the prize; the session is.
What actually defends against it?
Phishing-resistant factors like passkeys and hardware security keys, because they cryptographically bind to the real domain and will not complete against a proxy. Session binding, token-reuse detection, and short session lifetimes reduce the damage of any cookie that does get stolen.
How is it different from man-in-the-middle?
It is a phishing-specific form of man-in-the-middle. The victim is lured to a proxy page rather than intercepted on the network, and the goal is the authenticated session cookie rather than just eavesdropping on traffic.
Is this hard for attackers to run?
Not anymore. Off-the-shelf phishing-as-a-service kits automate the proxy, cloning, and cookie capture, so a low-skill operator can launch AiTM campaigns at scale.
What should a team do after a suspected AiTM hit?
Revoke the active sessions and tokens immediately, not just reset the password, since the stolen cookie stays valid until the session is killed. Then check for persistence like forwarding rules, new devices, and added MFA methods.
Adversary-in-the-middle (AiTM) phishingと併せて知っておきたい用語
2026年 不正・AMLレポート
予測は不要です。このレポートは、不正・AMLチームが実際に直面していることと、その対応方法を分解して解説します。