Adversary-in-the-middle (AiTM)
In phishing, an adversary-in-the-middle attack places a reverse proxy between the victim and the real site, relaying the whole login in real time and keeping the session cookie the site issues at the end. The victim authenticates successfully, second factor included, and the attacker walks away with the resulting session.
How it works
The victim is directed to a lookalike domain that is not a copy of the target site but a proxy in front of it. Every request is forwarded to the genuine site and every response is returned to the victim, so the pages are real, the branding is correct, and any challenge the site raises appears exactly as it should. The victim enters their password, receives and enters their one-time code or approves a push notification, and the real site issues a session cookie. The proxy stores that cookie before passing the response on.
From then on the attacker replays the session in their own browser and is authenticated. Tooling for this is public and configured with a template per target, so it is not an advanced capability.
What goes wrong
The advice that has been given for a decade is invalidated by this technique, and it needs saying plainly: enabling multi-factor authentication with codes or push approval does not prevent phishing. It raises the cost of credential-only attacks and does nothing against a live proxy, because the second factor is relayed like everything else.
What does resist it is a credential whose response is bound to the origin the browser actually contacted. A passkey signs a challenge that includes the lookalike domain, and the real site rejects it, so the attack fails at the authentication step rather than being detected afterwards. That is a structural property, not a detection improvement.
Where phishing-resistant credentials cannot be deployed everywhere, the fallback is to make the stolen session less useful: bind tokens to the device, require a compliant device through conditional access, evaluate risk continuously rather than only at sign-in, and alert on a session used from a different address or client than the one it was issued to. Those reduce the value of the theft; they do not prevent it.
Where this shows up in an audit
A phishing exercise that only counts who clicked is measuring a control that stopped being the deciding one. We run proxy-based scenarios under written agreement and report what a real operator would care about: how many sessions we obtained, whether we could use them, what they reached, and whether any of it was detected. Against a tenant with phishing-resistant credentials enforced the result is no usable session, and that evidence is the strongest argument for the rollout. This is part of how we run phishing exercises that reflect current technique.