AiTM phishing (How it works and how to stop it) - Email security - Learn

What it is#

Adversary-in-the-middle (AiTM) phishing is a technique where an attacker positions a reverse-proxy server between the victim and a legitimate login page. The proxy relays the victim's credentials to the real service in real time, completes the authentication flow, including any multi-factor authentication (MFA) challenge, and captures the resulting session cookie or token. The attacker then replays that token to access the victim's account without needing their password or MFA device again.

Unlike traditional credential phishing, where an attacker collects a username and password for later use, AiTM attacks steal the authenticated session itself. This is what makes them effective against time-based one-time passwords (TOTP), push-based MFA, and SMS codes.

Architecture of an AiTM attack#

Tools like Evilginx, Modlishka, and Muraena automate the reverse-proxy setup. The attacker registers a lookalike domain (e.g., login-contoso.com), configures the proxy to forward traffic to the real login.microsoftonline.com, and sends a phishing link to the victim.

Maintaining the illusion requires more than simple traffic forwarding. The proxy rewrites every reference to the legitimate domain across the entire response body, spanning HTML links, JavaScript variables, CSS resource URLs, HTTP headers, and Set-Cookie domains. Without comprehensive rewriting, a single unmodified link would send the victim's browser directly to the real service, breaking the proxy chain. Many AiTM proxies also inject a <script> tag into the <head> element of each proxied page. This injected code hooks password input fields and form submissions, firing callbacks to the attacker's server the moment credentials are entered, independent of cookie capture.

From the victim's perspective, the page looks and behaves exactly like the real login portal. Credentials, MFA responses, and form inputs all pass through the proxy to the legitimate server, which responds normally. Once authentication succeeds, the server issues a session cookie, and the proxy intercepts it before forwarding the response. The attacker now holds a valid session that does not require further MFA.

Multi-step OAuth login flows present additional complexity. Services like Microsoft 365 route authentication through several subdomains (login.microsoftonline.com, aadcdn.msauth.net, login.live.com) and embed redirect_uri parameters that must all point back through the proxy. The proxy rewrites these OAuth parameters so that every redirect in the chain returns to the attacker-controlled domain rather than the legitimate one, enabling full session capture across complex multi-subdomain authentication sequences.

These proxy-based attacks are frequently packaged as turnkey phishing kits, making AiTM capabilities accessible to operators with minimal technical skill.

How Evilginx works#

Evilginx is the most widely deployed AiTM framework. It operates as a standalone reverse proxy with integrated DNS and TLS handling.

The core concept is the phishlet, a configuration file that defines how Evilginx should proxy a specific target service. A phishlet maps the target's domain structure, specifies which subdomains to intercept (e.g., login.microsoftonline.com, aadcdn.msauth.net), identifies the authentication cookies to capture, and defines the URL trigger that signals a successful login. The Evilginx community maintains phishlets for Microsoft 365, Google Workspace, Okta, AWS, GitHub, and dozens of other services.

When an operator deploys Evilginx, the tool:

Provisions TLS certificates automatically via Let's Encrypt for the attacker-controlled domain, including wildcard certificates for services with complex subdomain structures. The phishing site appears fully legitimate in the browser's address bar.
Rewrites URLs across the entire proxied response, replacing legitimate domain references in HTML, JavaScript, CSS, and HTTP headers with the attacker's domain so that all subsequent requests continue flowing through the proxy. A slow proxy that visibly delays page loads can alert observant victims, so speed is critical and newer implementations use streaming HTML parsers to minimize latency.
Captures authentication tokens by monitoring HTTP responses for the specific cookie names defined in the phishlet. Once the target cookies appear, Evilginx logs them and can optionally redirect the victim to a benign page.
Generates lure URLs, unique per-victim links that the operator distributes via email or messaging. Each lure can be single-use, making URL-based blocklisting less effective.

Once tokens are captured, post-exploit automation tools can execute scripted actions within seconds, accessing mailboxes, exfiltrating data, or establishing persistence before the victim finishes the session. This rapid automated follow-on is a common path to full email account compromise.

The victim's browser establishes a TLS connection to the attacker's domain and validates the certificate Evilginx provisioned for it, not the real identity provider's certificate. Because the attacker's cert is legitimately issued, no browser warning fires. The only visible clue is the attacker's hostname in the address bar rather than the real one.

Defenders can detect Evilginx deployments by monitoring Certificate Transparency logs for newly issued certificates on domains that mimic corporate login portals. The automated Let's Encrypt provisioning leaves a clear trail in CT logs, often hours before the first phishing email is sent.

Why MFA alone doesn't stop it#

Traditional MFA protects against credential replay. If an attacker steals a password, they still cannot log in without the second factor. AiTM attacks sidestep this by completing the full authentication in real time. The MFA challenge is answered by the legitimate user; the attacker simply captures what comes out the other end.

This distinction matters operationally. Organizations that rely solely on TOTP or push notifications as their MFA layer remain vulnerable to AiTM. The session token, not the credential, becomes the target.

Detection signals#

Impossible travel. A session token used from a location or IP inconsistent with the original authentication
Device compliance mismatches. A token obtained through a compliant device suddenly appearing on an unmanaged device
Token anomalies. Sessions with abnormal lifetimes, unusual user-agent strings, or tokens replayed from known proxy infrastructure
Phishing infrastructure indicators. Newly registered domains with certificate transparency entries mimicking corporate login pages, often hosted on bulletproof providers

Sign-in logs in Azure AD and Google Workspace can surface many of these signals when conditional access policies enforce device compliance and location checks. Combining sign-in telemetry with proactive domain monitoring for lookalike registrations provides earlier detection, often before phishing emails reach inboxes.

Phishing-resistant MFA#

The most effective countermeasure is phishing-resistant MFA based on FIDO2/WebAuthn. Hardware security keys and platform authenticators (like Windows Hello or passkeys) bind the authentication to the legitimate origin domain. A reverse proxy on login-contoso.com cannot satisfy an authentication challenge scoped to login.microsoftonline.com, so the ceremony fails and no session token is issued.

Deploying FIDO2 at scale requires planning, hardware key distribution, fallback flows, and user enrollment, but it is the primary widely deployed MFA mechanism that structurally prevents AiTM session theft.

What is adversary-in-the-middle (AiTM) phishing?