AitM Phishing: How Attackers Bypass MFA and How to Stop Them

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.

TL;DR

• AitM (Adversary-in-the-Middle) phishing proxies the real login page in real time, so it looks and behaves completely legitimately
• MFA codes — TOTP, SMS, push notifications — are captured and used instantly, making standard MFA useless against this attack
• The attacker walks away with a valid session token, not a password — no credentials needed after that
• Detection requires looking at token behavior, sign-in context, and DNS anomalies — not just login attempts
• Only phishing-resistant MFA (FIDO2/Passkeys, certificate-based auth) actually stops this attack

Why Standard Phishing Stopped Working — and What Replaced 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.

How AitM Phishing Works

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:

Step 1 — The Victim Clicks a Phishing Link

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.

Step 2 — The Proxy Loads the Real Login Page

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.

Victim browser → [Attacker Proxy] → Real Microsoft login server
                      ↑
               Captures everything
               passing through

Step 3 — Credentials and MFA Are Captured in Real Time

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.

Step 4 — The Session Token Is Stolen

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.

The PhaaS Ecosystem: Phishing as a Service

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.

Why MFA Doesn’t Help (and What Does)

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.

Detection: What to Look For

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

Sign-In Anomalies (Microsoft Entra ID / Azure AD)

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.

What to monitor:

• Token used from a different IP than where it was issued within a short timeframe
• “Unfamiliar sign-in properties” alerts — new IP, new ASN, new country vs. token origin
• Impossible travel alerts — location A and location B within an impossible timeframe
• New MFA device registered shortly after sign-in (a critical gap: this often triggers no alert by default)
• Inbox rules created immediately after first sign-in — a classic BEC preparation step

DNS and Infrastructure Anomalies

AitM infrastructure has recognizable patterns:

• Domains registered within 24-48 hours before the attack
• Wildcard TLS certificates for newly registered domains
• Hosting on ASNs that don’t match the target organization’s known infrastructure
• Short TTL values (attackers rotate infrastructure quickly)

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

Email Delivery Signals

• Links pointing to domains registered within the last week
• Redirect chains through URL shorteners or legitimate services (Google Docs, OneDrive) before the final AitM proxy
• Sender domain with no DMARC enforcement (though attackers increasingly abuse legitimate senders)

Sigma Rule — Token Replay Detection

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

# Token issued in one location, used from another
# within a short window — classic AitM token replay
detection:
  condition: all of them
  sign_in:
    EventType: 'Sign-in'
    ResultType: 0  # Success
  token_replay:
    TokenIssuerType: 'AzureAD'
    IPAddress|not: '%token_issue_ip%'
    TimeDelta|lt: 300  # 5 minutes between issue and use

Real-World Examples

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.

What You Can Do Today

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.

For Red Teamers

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.

# Evilginx setup overview (authorized testing only)
# 1. Configure your domain and phishlet
evilginx2 -p /path/to/phishlets -developer
> config domain yourdomain.com
> config ipv4 YOUR_SERVER_IP
> phishlets hostname microsoft365 login.yourdomain.com
> phishlets enable microsoft365

# 2. Create a lure (phishing URL)
> lures create microsoft365
> lures get-url 0
# Returns the phishing URL to use in your campaign

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.

Related Posts

• Entra ID Attacks: Device Code Phishing, PRT Theft, and Conditional Access Bypass — Entra ID attack techniques that complement AitM for full identity compromise
• Identity-First Attacks in the Cloud — How attackers pivot from credential theft to cloud resource abuse
• ClickFix, FileFix, and Pastejacking Attacks Explained — Social engineering delivery techniques often used alongside AitM phishing campaigns
• Non-Human Identity Security: The Biggest Blind Spot of 2026 — After account takeover, attackers frequently target service accounts and API keys

Sources

• Hackers use AiTM attack to monitor Microsoft 365 accounts for BEC scams — BleepingComputer
• Starkiller Phishing Service Proxies Real Login Pages, MFA — Krebs on Security
• Multistage AiTM Phishing and BEC Campaign Abusing SharePoint — Microsoft Security Blog
• W3LL phishing kit hijacks thousands of Microsoft 365 accounts, bypasses MFA — BleepingComputer
• New Mamba 2FA bypass service targets Microsoft 365 accounts — BleepingComputer
• Catching the Phish – Detecting Evilginx & AiTM — Deepwatch Labs
• Defending against evolving identity attack techniques — Microsoft Security Blog
• Global analysis of Adversary-in-the-Middle phishing threats — Sekoia