Adversary-in-the-Middle Phishing: Stealing the Session, Not the Password

Adversary-in-the-middle (AiTM) phishing defeats most multi-factor authentication by stealing the authenticated session rather than the password. Instead of a static fake page, the attacker runs a reverse proxy that relays the victim’s traffic to the genuine login site in real time. The victim enters credentials and completes the MFA challenge against the real service; the proxy captures both the credentials and the resulting session cookie. Replaying that cookie (“pass-the-cookie”) gives the attacker an authenticated session without ever re-triggering MFA. The technique is packaged in open-source toolkits like Evilginx and sold as phishing-as-a-service through kits such as Tycoon 2FA and EvilProxy.

How It Works

The attacker stands up a reverse proxy between the victim and the legitimate identity provider. A lure links to the proxy’s domain; the proxy fetches and rewrites the real login page on the fly, so the victim sees an authentic experience including the genuine MFA prompt. When the victim authenticates, the proxy harvests the username, password and — critically — the session token the identity provider issues after a successful MFA challenge. With that token, the attacker resumes an authenticated session and often registers their own MFA method or creates mail rules for persistence. T1557 T1539 T1550.004

Tooling & Kits

• Evilginx — an open-source reverse-proxy phishing framework using “phishlets” to template target sites; the reference implementation of the technique.
• Phishing-as-a-service: Tycoon 2FA, EvilProxy, Mamba 2FA and the Greatness kit lower the skill barrier, offering hosted AiTM infrastructure, anti-analysis and ready-made templates for Microsoft 365 and Google.
• Microsoft has tracked large-scale AiTM campaigns and clusters (for example the actor it tracks as Storm-1167) using these techniques to reach business email compromise.

MITRE ATT&CK Mapping

Detection & Mitigation

• Deploy phishing-resistant MFA (FIDO2 security keys or passkeys); because the credential is cryptographically bound to the legitimate origin, an AiTM proxy on a look-alike domain cannot complete the authentication.
• Use conditional access to require compliant or managed devices, and enable token protection / token binding where the platform supports it so a stolen cookie is not portable.
• Alert on session-cookie reuse from a new IP, ASN or device; impossible-travel sign-ins; and post-authentication additions of MFA methods or new inbox rules. Revoke sessions and rotate tokens on suspicion.
• Block newly registered and look-alike domains at the proxy and mail gateway, and invest in user reporting for lures that lead to a login prompt.