EvilGinx and adversary-in-the-middle phishing, explained

Multi-factor authentication was supposed to make stolen passwords worthless. Adversary-in-the-middle (AiTM) phishing — popularised by open-source frameworks like EvilGinx — quietly broke that assumption by stealing the session, not the password. Understanding how it works is the first step to defending against it.

What adversary-in-the-middle phishing is

Classic phishing shows the victim a static clone of a login page and simply records whatever they type. It cannot handle a live one-time code, and it cannot pass a real MFA challenge.

AiTM phishing removes that limitation by inserting a reverse proxy between the victim and the genuine site. The attacker's server does not host a fake page at all — it relays the real one:

Victim → login.micros0ft-verify.example (attacker proxy) → login.microsoftonline.com

Every request the victim makes is forwarded to the legitimate service, and every response is passed back. The victim sees the authentic login flow — real branding, real error messages, real MFA prompts — because they are, in fact, talking to the real service, just through a relay that reads everything in transit.

Why it defeats OTP and push

The critical insight is that the attacker is not trying to know your password or your code. They are trying to capture what the successful login produces: the authenticated session cookie.

• The victim enters their username and password → relayed to the real site.
• The real site issues an MFA challenge → relayed back to the victim.
• The victim approves the push or types the OTP → relayed to the real site.
• The real site validates everything and returns a session token → the proxy captures it.

At that point the OTP has already done its job and is worthless to replay. The attacker imports the stolen cookie into their own browser and is logged in as the user — no password, no code, no second prompt. This is why SMS codes, TOTP authenticator apps, and push approvals all fall to a competent AiTM setup: each is a shared secret the human can be tricked into relaying in real time.

The MFA prompt the victim approved was genuine. That is precisely what makes AiTM so effective — nothing looks wrong to the user, and nothing looks wrong to the identity provider.

Why existing defenses struggle

• The domain is often brand-new. Freshly registered look-alike domains have no reputation history to flag.
• TLS looks legitimate. The proxy serves a valid certificate; the padlock is present.
• The content is real. Signature-based scanning finds nothing fake to match, because the page is the genuine one, relayed.
• Detection windows are short. Kits use anti-analysis filtering, single-use links, and geofencing so a URL that was live for the victim returns a harmless page to an investigating SOC.

The real fix: phishing-resistant MFA

AiTM works because the second factor travels through the attacker. Remove that possibility and the attack collapses. FIDO2 / WebAuthn and passkeys bind the credential cryptographically to the exact web origin it was registered for:

Credential registered for : https://login.microsoftonline.com
Browser sees origin       : https://login.micros0ft-verify.example
→ origin mismatch → the authenticator refuses to sign → login fails

There is no code to relay and no cookie to harvest, because authentication never succeeds against the wrong origin. The browser enforces this — not the user. Complementary controls harden the rest:

• Conditional access binding sessions to device compliance and managed networks.
• Token protection / continuous access evaluation to reduce the value of a stolen cookie.
• Rapid detection of newly registered look-alike domains via certificate-transparency monitoring.

The goal is phishing-resistant MFA as required, not merely available — any phishable fallback is a path attackers will steer users toward.

How GottaPhish automates AiTM simulations

AiTM attacks defeat OTP and push MFA by relaying the session in real time, and no proxy or filter alone reliably closes that gap. GottaPhish and its expert support team reproduce adversary-in-the-middle scenarios automatically and safely inside authorized simulations — there is no attacker infrastructure for your team to stand up, host, or tear down. We demonstrate, with full auditing, how OTP and push MFA fall to a real proxy while phishing-resistant credentials hold, giving you measurable exposure data per user, department, and role; our experts help you design the scenarios, set up the campaigns, and interpret the results. That evidence makes the business case for FIDO2/passkeys concrete, and our reporting tracks adoption alongside your click and report rates so you can prove the phishable gap is genuinely closing — not just that a policy exists on paper.