Aitm Phishing Mfa Bypass Evilginx

Your employee received a login page that looked exactly like Microsoft 365. They typed their password. They approved the MFA prompt. They were phished — and never knew it.

Traditional phishing worked by cloning a login page and harvesting credentials. But once organizations rolled out MFA, that stopped being enough. Stealing a password without the one-time code is useless.

Attackers adapted. Instead of cloning a login page, they started proxying the real one.

This technique is called Adversary-in-the-Middle (AitM) phishing — and it’s now the dominant method for bypassing MFA at scale. Microsoft reported a 146% increase in AitM attacks in 2024, and the trend has only accelerated into 2026 with dedicated Phishing-as-a-Service (PhaaS) platforms that anyone can rent.

Think of a traditional man-in-the-middle attack on a network — something intercepts traffic between two parties. AitM phishing does the same thing, but at the application layer, using an attacker-controlled server as a proxy.

Here’s what happens step by step:

The victim receives a convincing phishing email (or Teams message, SMS, or QR code) with a link. The link points to an attacker-controlled domain — something like login.microsoft-secure-portal.com or a lookalike subdomain.

Instead of showing a fake page, the attacker’s server silently fetches the real Microsoft 365 (or Google, or whatever) login page in real time and serves it to the victim.

The victim sees the real UI, the real branding, the real URL structure in the content. The only fake part is the domain in the browser’s address bar — and most users don’t look closely enough.

The victim types their username and password. The proxy forwards these to Microsoft and gets back the MFA challenge. The MFA prompt appears — push notification, TOTP code, SMS — and the victim approves it.

The proxy captures that MFA response and forwards it instantly. Microsoft sees a valid login with valid credentials and a valid MFA response. Authentication succeeds.

After authentication, Microsoft issues a session token — a cookie that proves the browser is already logged in. This is what the attacker actually wants.

The proxy captures this token before the victim ever sees it. From this point, the attacker can import the token into their own browser and have full access to the account — no password, no MFA prompt, nothing.

The victim is also redirected to their real inbox, so they notice nothing unusual.

AitM attacks used to require technical skill to set up. That’s no longer the case. Multiple commercial platforms now offer AitM phishing as a ready-to-use service.

Starkiller (documented by Krebs on Security in early 2026) is a good example of how sophisticated these tools have become. Instead of pre-built templates, it spins up a headless Chrome browser for each victim and proxies the actual live login page , which means there are no static templates to fingerprint. It captures OTP codes, recovery codes, and session tokens in real time, with Telegram alerts sent to the attacker.

This is the uncomfortable truth: most MFA implementations provide zero protection against AitM phishing .

Push notifications, TOTP codes (Google Authenticator, Authy), and SMS codes are all captured and replayed by the proxy before they expire. The attacker has milliseconds to forward them — which is more than enough.

The reason FIDO2 and passkeys work is cryptographic domain binding . When you register a passkey for login.microsoft.com , your device creates a key pair tied specifically to that domain. If a phishing proxy presents the login form from a different domain, the browser refuses to use the passkey — authentication silently fails. The proxy cannot steal what was never transmitted.

Preventing AitM at the perimeter is difficult. Detection is where defenders have the most leverage.

After a successful AitM attack, the attacker uses the stolen token from their own machine — which is almost certainly in a different location, with a different IP and ASN, than where the victim authenticated.

AitM infrastructure has recognizable patterns:

Tools like Infoblox and Cisco Umbrella can flag DNS queries to newly registered lookalike domains before the user even lands on the phishing page.

If you’re running Entra ID sign-in logs through a SIEM, this logic catches the core pattern:

Microsoft 365 + SharePoint BEC Campaign (January 2026) Attackers used an AitM proxy to compromise Microsoft 365 accounts, then abused SharePoint to send phishing links from inside the victim organization — making follow-up phishing dramatically more convincing. The campaign targeted thousands of organizations globally.

University SSO Attacks (2025) At least 18 US universities were targeted with Evilginx-based phishing kits that proxied the institutions’ own SSO login pages. Students and staff authenticated normally, not realizing their sessions were being captured. The attacker’s goal was financial aid fraud and grade manipulation.

W3LL Kit — Thousands of Microsoft 365 Accounts The W3LL phishing kit used AitM techniques to compromise thousands of Microsoft 365 accounts in targeted BEC campaigns. MFA was bypassed in every case.

These actions are ordered by impact:

1. Deploy phishing-resistant MFA everywhere you can FIDO2 hardware keys (YubiKey) or passkeys for all privileged accounts, admins, and finance users as an immediate priority. This is the only MFA that stops AitM. Roll out to the broader organization as adoption allows.

2. Enable Token Protection in Entra ID Conditional Access Token Protection binds session tokens to the specific device they were issued to. A stolen token replayed from another machine fails. This is one of the most impactful single controls against AitM and is often overlooked.

3. Alert on post-authentication MFA device registration One of the first things an attacker does after account takeover is register their own MFA device to maintain persistence. This should trigger an immediate alert and require re-verification.

4. Monitor sign-in logs for token replay patterns Look for successful authentications where the token is subsequently used from a different IP or ASN. Feed Entra ID sign-in logs to your SIEM and build detections around this pattern.

5. Train users on address bar awareness Phishing-resistant MFA is the real fix, but awareness still helps at the margins. Teach users to check the domain in the address bar before entering credentials — not the page content, which looks legitimate, but the actual URL.

6. Evaluate your email security pipeline Ensure you have link-time URL analysis (not just click-time scanning at delivery). AitM domains are often clean at delivery and only activated later.

Evilginx 3.0 is the standard tool for demonstrating AitM in authorized red team engagements. It uses a phishlet-based configuration system where you define how to handle a specific target’s authentication flow.

For blue teamers running purple team exercises: use the red team output to validate your Entra ID sign-in log detections. If your SIEM doesn’t fire when a stolen token is replayed from a different IP, that gap needs to be closed before the real attackers find it.