AiTM Phishing: When MFA Is Not Enough for Microsoft 365
AiTM Phishing: How Attackers Bypass MFA and What You Need to Defend Against It
Multi-factor authentication is one of the most widely recommended controls in enterprise security. Most organisations have it. Most users find it inconvenient but accept it because the messaging is clear: it stops account takeovers. The problem is that this is no longer fully true, and the gap between perception and reality is now being exploited at scale.
Adversary-in-the-middle phishing – AiTM – is the mechanism. It does not crack your password or defeat your MFA code in any conventional sense. It waits for you to complete the authentication successfully, then steals what that authentication just produced: the session cookie that proves to Microsoft 365, Google Workspace, or any other SaaS platform that you already passed the check. With that cookie, the attacker inherits your authenticated session. No password needed. No MFA prompt triggered. Just direct access to your inbox, your files, and every connected application.
AiTM incidents surged 46% in 2025. Proofpoint tracked multiple large-scale campaigns using the Tycoon 2FA phishing kit targeting thousands of organisations worldwide. Microsoft reported over 10,000 AiTM attacks per month hitting its user base. This is established, industrialised attack infrastructure, not experimental technique.
What Adversary-in-the-Middle Actually Means
The name describes the architecture. In a standard AiTM attack, the attacker operates a reverse proxy server that sits between the victim’s browser and the legitimate authentication service – Microsoft, Google, Okta, or similar.
When the victim clicks the phishing link, they land on the attacker’s proxy rather than the real login page. The proxy forwards their request to the real Microsoft login page, receives the genuine page in response, and serves it to the victim. The victim sees exactly what they would normally see: the real Microsoft login page, including any custom branding configured for their organisation’s Entra ID tenant.
The victim enters their credentials. The proxy forwards them to Microsoft. Microsoft validates them and requests MFA. The victim completes MFA – entering their code or approving the push notification – and Microsoft issues a session cookie confirming successful authentication. The proxy intercepts that cookie before passing the final session to the victim.
At this point, the attacker holds a valid authenticated session. They can open a browser, inject the stolen cookie, and access the victim’s Microsoft 365 environment as if they were the account owner. The victim has their session too, so they notice nothing unusual.
The Tools Making AiTM Accessible to Low-Skill Attackers
What makes the AiTM threat category particularly urgent right now is industrialisation. Reverse proxy phishing used to require meaningful technical skill to set up and operate. It no longer does.
Phishing-as-a-service platforms
Tycoon 2FA is the most widely observed AiTM platform in active use. It is sold as a subscription service, includes pre-built phishing templates mimicking Microsoft 365 authentication pages with correct custom branding, automates the real-time proxying and session cookie harvesting, and is accessible to anyone willing to pay. Security researchers detected over one million Tycoon 2FA-powered attacks in just the first few months of 2025.
EvilProxy is the other major platform, with similar capabilities and a similar commercial model. Muraena, Evilginx2, and Modlishka are open-source frameworks that provide the reverse proxy infrastructure without a subscription cost.
The barrier to launching an AiTM campaign is now roughly comparable to the barrier to launching a commodity phishing campaign. That is the inflection point the 46% surge reflects.
The Microsoft 365 targeting problem
AiTM campaigns disproportionately target Microsoft 365 for practical reasons: it is the most widely deployed business email and productivity platform, a successful session compromise gives access to email, SharePoint, OneDrive, Teams, and every connected application, and the session cookie model used by M365 authentication is well understood and consistently exploitable. Finance teams, executives, and IT administrators receive the highest volume of targeting.
What Happens After the Session Is Stolen
Account takeover is rarely the end goal. It is the beginning of a second attack phase.
In documented AiTM campaigns, post-compromise activity follows a consistent pattern. The attacker accesses the victim’s mailbox and searches for financial communications, vendor relationships, and in-progress transactions. They create email forwarding rules to copy incoming mail to an external address, maintaining intelligence access even after the original session expires. They use the compromised account to launch further BEC attacks – either internally to other employees or externally to the victim organisation’s vendors and clients.
The Microsoft Threat Intelligence team documented a multi-stage campaign in which AiTM compromise of a single account in one organisation was used to launch VEC-style attacks against that organisation’s supplier chain – the initial session theft became the first link in a chain of fraud spanning multiple companies. Because each subsequent attack originated from a legitimately compromised account, it passed authentication checks at each step.
Why Standard Phishing Controls Miss AiTM Attacks
AiTM phishing emails often use advanced evasion techniques specifically designed to defeat email security scanning. QR codes instead of direct links – so the URL is encoded in an image the scanner cannot read. Redirects through trusted platforms like SharePoint, SendGrid, or legitimate cloud storage services – so the initial link passes reputation checks before the chain reaches the malicious proxy. CAPTCHA gates on the phishing page that prevent automated sandboxing tools from loading and analysing the full page content.
The destination of the phishing link – the attacker’s proxy server – is typically a newly registered domain with no prior malicious history, meaning reputation-based blocking produces no result on first contact.
What is needed is analysis of link destination behaviour rather than domain reputation alone – the ability to follow a redirect chain, reach the actual destination page, and analyse what it does when credentials are entered. The Spambrella anti-phishing service with GenAI URL inspection applies exactly this kind of destination-level analysis, evaluating page behaviour rather than just domain history.
What Phishing-Resistant MFA Actually Means
Not all MFA is equal in the context of AiTM threats. Standard MFA methods – SMS codes, time-based one-time passwords (TOTP) from an authenticator app, push notifications – all fail against AiTM attacks because they rely on sending a token that the proxy can intercept and relay in real time.
FIDO2 hardware security keys and passkeys that use the WebAuthn standard are the exception. These methods bind the authentication response to the specific domain of the site being authenticated against. When a FIDO2 key signs an authentication challenge, the response is only valid for the exact origin domain of the request. An attacker’s proxy operating on a different domain receives a response that is cryptographically invalid for the real login endpoint – and the authentication fails.
For organisations with high-value accounts – executives, finance personnel, IT administrators – migrating to FIDO2 hardware keys removes the AiTM vulnerability at the authentication level rather than relying purely on detection.
Practical Defence Across the Organisation
Advanced email filtering with destination-page analysis
The phishing email is the delivery mechanism. Stopping it before delivery is the highest-value intervention. Email security that goes beyond domain reputation and actually analyses the behaviour of destination pages – including redirect chains, CAPTCHA-gated pages, and newly registered domains – provides meaningful AiTM-specific coverage that standard filtering does not.
Conditional access with anomaly detection
Enforcing conditional access policies that flag and block sessions originating from unusual geographic locations, unrecognised devices, or IP addresses associated with proxy infrastructure adds friction to stolen-session exploitation. Even when an attacker holds a valid session cookie, a conditional access policy requiring a compliant managed device or a registered location can prevent that cookie from being useful.
Security awareness training covering session theft mechanics
Most employees understand that phishing emails try to steal passwords. Very few understand that a phishing page can steal an authenticated session even after MFA is completed. That knowledge gap matters: employees who understand AiTM mechanics are more likely to check destination URLs carefully, notice that a login page is slightly different from what they expect, and report suspicious authentication requests rather than completing them under time pressure.
Security awareness training that includes session cookie theft as a specific topic, alongside simulations targeting the Microsoft 365 login impersonation lures used in active AiTM campaigns, closes a genuine knowledge gap in most organisations’ security training curricula.
Short session token lifetimes and continuous access evaluation
Microsoft’s Continuous Access Evaluation capability revokes active sessions in near-real-time when anomalous behaviour is detected – new location, policy change, account risk signals. Enabling it for Microsoft 365, and configuring reasonably short session token lifetimes for sensitive applications, limits how long a stolen cookie remains operationally useful. A token that expires in one hour is significantly less valuable than one that persists for twenty-four.
The Practical Takeaway
MFA remains worth enabling. It stops a very large proportion of account takeover attempts and is not being argued against here. But treating MFA as a complete answer to email-based account compromise is now inaccurate, and that inaccuracy has a real cost when employees are trained to believe they are protected and then encounter an AiTM lure that defeats the protection they were promised.
The organisations defending well against AiTM in 2026 are the ones running advanced email filtering that catches phishing infrastructure before delivery, enforcing FIDO2 authentication for high-value accounts, running conditional access policies that make stolen cookies difficult to exploit, and training employees to approach any unexpected authentication request with specific scepticism – not because the MFA prompt looks wrong, but because it arrived without warning and under urgency.
That combination is not perfect. But it closes the specific gaps that AiTM attacks are designed to exploit.
Further reading:
QR Code Phishing (Quishing): How It Bypasses Your Email Filters
