The proxy that steals the session, not the password (AiTM)
Adversary-in-the-middle phishing sits between the user and the real login, relaying everything including MFA, then steals the session cookie. The password and the second factor do not matter. Here is AiTM, and the fix.
The user did everything right: real site, correct password, approved the MFA prompt. The attacker still walked away as them.
What it is
Adversary-in-the-middle (AiTM) phishing uses a reverse proxy (tooling like Evilginx) that sits between the victim and the real login page. The victim enters their password and approves MFA against the genuine site; the proxy relays it all and captures the resulting session cookie, then replays it to access the account with MFA already satisfied. This is T1557 (adversary in the middle) with T1539 (steal session cookie) and T1550.
Why it works
Standard MFA verifies the login, not the session, so a stolen post-authentication cookie sails past it. The victim interacts with the real, working login the whole time.
How to detect it
Look for session use from a new IP or device right after a login, impossible travel, known AiTM phishing domains, and sign-in logs showing token replay.
The fix that holds
Phishing-resistant MFA (FIDO2 / passkeys, certificate-based) defeats AiTM because the credential is bound to the real origin and cannot be relayed. Add conditional access (device compliance, token protection) and alert on session anomalies.
Practice it
We built an AiTM session-theft scenario in GraphLattice Range so teams learn why standard MFA is not enough and what actually stops it.