Evilginx3, AiTM, and Why MFA Isn't the Last Line of Defence

What AiTM actually is

There’s a lot of loose talk about “MFA bypass” that conflates several different techniques. Adversary-in-the-Middle (AiTM) is specific: MITRE ATT&CK T1557. The attacker positions a reverse proxy between the victim and the legitimate service. The victim authenticates for real, MFA included, and the attacker captures the resulting session token.

The distinction from traditional MITM is important. Classic MITM tries to intercept traffic between two parties. AiTM with a phishing lure works differently:

1. Victim clicks a phishing link and lands on the attacker’s proxy (looks identical to the real site, valid TLS cert for the phishing domain)
2. Victim enters credentials and completes MFA
3. The proxy forwards the request to the legitimate service, the user is actually authenticating against the real Microsoft/Okta/whatever
4. The real service issues a session token; the proxy captures it
5. Attacker now has a valid, MFA-authenticated session token and can replay it immediately

The victim sees a successful login and gets redirected normally. Nothing feels wrong. By the time they’re using their account, the attacker has been in it for minutes.

This is why TOTP-based MFA doesn’t stop AiTM. TOTP proves you have the device, but the attacker isn’t trying to defeat TOTP, they’re letting you prove it for them and stealing what comes after. Phishing-resistant MFA (FIDO2/passkeys) does stop this, because the key is bound to the origin domain. A passkey registered for microsoft.com won’t sign a challenge from micros0ft-login.com regardless of how good the proxy is.

Getting Evilginx3 running

Evilginx is kgretzky’s open-source implementation of exactly this attack pattern. It’s designed for authorised red team engagements, the tool doesn’t know or care whether you have permission, so it goes without saying you need a scoped engagement or a lab environment.

Setup was mostly straightforward:

• Needs a VPS with a real domain and valid TLS cert: it runs its own HTTPS server
• Phishlets define how to proxy a specific service: where to redirect after auth, what cookies to capture, what headers to rewrite
• The phishlet library covers Microsoft, Okta, LinkedIn, and a few others out of the box

The interesting part is the botguard integration in the Pro version, it uses JA4 signature fingerprinting combined with JavaScript-based browser telemetry to distinguish automated crawlers from real browsers. If a headless browser hits your phishing page, it serves something benign. If it looks like a real Chrome session on a mobile device, it serves the lure. That makes automated scanning of phishing pages significantly less reliable as a defence.

For PhishRig, I’m wrapping Evilginx in a management layer that:

• Handles lure generation (the initial email/SMS that drives the victim to the proxy)
• Logs captured credentials and tokens to our controlled backend
• Tracks per-target engagement (who clicked, who authenticated, who got to credential entry)
• Generates the engagement report

The quishing module I planned last week will feed into this (QR code → Evilginx proxy → credential capture) as a complete simulation scenario.

What doesn’t work

Hit a few issues this week:

Domain categorisation latency. New domains get flagged as “uncategorised” by web filters and some email gateways for days to weeks. In a real engagement this matters, you’d need domains registered and aged in advance. PhishRig needs a domain management layer. Putting that on the backlog.

Evilginx and HSTS preloading. Sites on the HSTS preload list with includeSubDomains set can’t be proxied via a similar domain because the browser enforces HTTPS on any subdomain of the parent. For major services this is mostly mitigated by using lookalike domains rather than subdomains, but it’s worth understanding.

Related: Scattered Spider’s AiTM playbook

Scattered Spider used AiTM extensively in 2023-2024 alongside voice phishing and SIM swapping. Their pattern was sophisticated: voice phish the IT help desk to get a password reset or new MFA device added, then use that to bypass everything else. By the time Okta added the ability to require FIDO2 for specific high-privilege roles, the group had already pivoted.

The defensive lesson isn’t just “use better MFA”, it’s that the attack targets the weakest link in the human chain, not the technology. Help desk social engineering is often easier than technical AiTM.

---

Next week: shifting gears to GPU infrastructure. The Moxel VRAM pooling project needs actual benchmarks. Planning the first proper test run.