Adversary-in-the-Middle Attacks Are Bypassing MFA at Scale

AiTM Reverse-Proxy Authentication Hijacking Flow, AI generated

For years, multi-factor authentication (MFA) was the gold standard of account security. Security teams deployed it across every critical system, confident that even if a password was stolen, the attacker couldn’t get in. That confidence is no longer justified.

Adversary-in-the-Middle (AiTM) phishing attacks have rendered traditional MFA nearly useless for credential-based authentication, and the kits that power these attacks are now cheap, widely available, and increasingly used by threat actors at every skill level.

What Is an AiTM Attack?
Unlike traditional phishing, which simply steals a username and password, AiTM attacks go further. The attacker positions a reverse proxy server between the victim and the legitimate website they’re trying to reach. When the victim visits the phishing page, they’re actually interacting with a real-time proxy of the legitimate login portal.

Here’s how the attack chain unfolds:

1. The victim receives a convincing phishing email and clicks a link
2. The link takes them to an attacker-controlled proxy server
3. The proxy fetches the real login page (e.g. Microsoft 365) and relays it to the victim in real time
4. The victim enters their credentials — which the proxy captures
5. The victim completes MFA — the proxy relays this too
6. Microsoft issues a session cookie — the proxy steals it
7. The attacker now has a valid authenticated session cookie, bypassing MFA entirely

The session cookie is the key. Authentication in modern web applications relies on session tokens issued after successful login. Once an attacker has your session token, they don’t need your password or your MFA code — they’re already authenticated.

The Evilginx Ecosystem
The most widely deployed AiTM toolkit is Evilginx, an open-source man-in-the-middle attack framework originally built for penetration testing. The current version, Evilginx3, supports “phishlets” — modular configuration files for specific targets including Microsoft 365, Google Workspace, GitHub, and dozens of banking portals.

Evilginx3 can be deployed on a virtual private server in under 30 minutes. Pre-built phishlets are freely available on GitHub. The barrier to entry is essentially zero for anyone with basic technical knowledge.

Other popular AiTM kits include:
– Modlishka — an open-source reverse proxy with session token capture
– Muraena — a Go-based framework with automatic TLS certificate generation
– EvilnoVNC — takes a different approach, streaming a remote browser session to the victim rather than proxying requests

AiTM attacks are not random. They are targeted campaigns, typically focused on:

Microsoft 365 tenants— the largest attack surface. Business email, SharePoint, Teams, and OneDrive access all flow through a single authenticated session. Compromising one account often means access to an entire organisation’s communications.

Financial sector employees — CFOs, finance teams, and accounts payable staff are primary targets for Business Email Compromise (BEC) follow-on attacks after session hijacking.

Healthcare and government— high-value data, often with weaker security tooling than enterprise environments.

Cloud platform administrators — AWS, Azure, and GCP console sessions are increasingly targeted, with attackers pivoting from email compromise to cloud infrastructure access.

Real-World Campaign: The 10,000-Organisation Attack

In 2022, Microsoft Threat Intelligence documented an AiTM campaign that targeted more than 10,000 organisations over a single month. The attackers used the stolen sessions not for immediate data theft but to launch BEC fraud — intercepting finance email threads and redirecting wire transfers.

The 2026 landscape is worse. PhishScout’s threat feed has observed AiTM kits being sold on criminal forums for as little as $150 per month, complete with customer support, update subscriptions, and pre-configured phishlets for over 100 target organisations.

It’s important to understand which MFA methods are vulnerable and which are not-
Vulnerable to AiTM:
– SMS one-time passwords (OTP)
– Authenticator app TOTP codes (Google Authenticator, Microsoft Authenticator)
– Email OTP codes
– Push notifications (if the user approves)

Resistant to AiTM:
– FIDO2/WebAuthn hardware keys (YubiKey, Google Titan)
– Passkeys
– Certificate-based authentication

The reason FIDO2 is resistant is that the authentication is cryptographically bound to the specific origin domain. When a victim is on an attacker’s proxy domain, the FIDO2 key detects the domain mismatch and refuses to authenticate — even if the victim can’t tell the difference visually.

Detection Strategies
Detecting AiTM attacks requires looking beyond failed login attempts — these attacks succeed at authentication, so traditional brute-force detection won’t fire.

Impossible travel detection — if a user authenticates from London and then a session is used from Eastern Europe seconds later, that’s an immediate red flag. Enable impossible travel alerts in Microsoft Entra ID / Azure AD Conditional Access.

Token replay detection— monitor for session tokens being used from IP addresses that differ from the original authentication IP. Microsoft Sentinel has built-in analytics rules for this.

User agent analysis — AiTM proxies often forward requests with slightly modified or inconsistent user agent strings. Analyse authentication logs for anomalies in user agent patterns across sessions.

Unfamiliar sign-in properties— Microsoft 365 and Google Workspace both alert on logins from new devices, locations, or ASNs. Ensure these alerts are routed to your SOC, not just emailed to the end user.

Sigma Detection Rule:

“`
title: AiTM Session Token Replay
status: experimental
description: Detects session token usage from a different IP than authentication origin
logsource:
    product: azure
    service: signinlogs
detection:
    selection:
        ResultType: 0
    filter:
        IPAddress|contains:
            – AuthenticationIP
    condition: selection and not filter
falsepositives:
    – VPN usage
    – Corporate proxies
level: high
tags:
    – attack.credential_access
    – attack.t1557
“`

Immediate actions:
1. Deploy Conditional Access policies requiring compliant devices for all cloud application access. A stolen session cookie from an unmanaged device will be blocked if the Conditional Access policy requires Intune compliance.

2. Enable Continuous Access Evaluation (CAE) in Microsoft Entra ID. CAE forces real-time re-evaluation of access policies, meaning a revoked session is blocked immediately rather than waiting for token expiry.

3. Reduce session token lifetime — default Microsoft 365 session tokens can live for up to 90 days. Reduce this to 1 hour for high-risk users and privileged accounts.

4. Move to phishing-resistant MFA — begin a migration to FIDO2 hardware keys or Microsoft’s Certificate-Based Authentication for all privileged accounts as a minimum. End-user rollout of passkeys should be on every organisation’s 2026 security roadmap.

5. Monitor Microsoft 365 sign-in logs — specifically filter for `TokenIssuerType: AzureAD` with `AuthenticationProtocol: ropc` or unusual `clientAppUsed` values which can indicate proxy-based authentication.

Longer-term controls:
– Implement Microsoft Entra ID Protection risk-based Conditional Access — automatically blocking sign-ins assessed as high risk
– Deploy a Cloud Access Security Broker (CASB) to monitor post-authentication behaviour
– Train users specifically on AiTM — traditional phishing awareness training doesn’t cover proxy-based attacks adequately

AiTM attacks represent the most significant evolution in phishing technique since the shift to HTTPS. The widespread assumption that MFA stops phishing is dangerously outdated. Security teams need to audit their MFA deployments now, prioritise phishing-resistant authentication methods, and implement detection controls that look for post-authentication anomalies rather than relying solely on preventing initial access.

The tools to defend against AiTM exist. The question is whether organisations deploy them before attackers exploit the gap.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *