MFA Alone Won't Save You: Defending M365 Against AiTM Phishing

Multi-factor authentication is still one of the most effective defenses against account compromise. But a growing class of phishing attacks bypasses MFA completely by stealing session tokens in real time. Adversary-in-the-middle (AiTM) phishing proxy tools like Kali365 and EvilGinx sit between users and the real Microsoft 365 login page, capturing both credentials and the authenticated session cookie before the user even notices something is wrong.

If your M365 security strategy starts and stops at “we turned on MFA,” these attacks are a serious gap. The good news: Microsoft 365 includes several features that can block AiTM attacks, but most SMB tenants haven’t enabled them.

How AiTM Phishing Actually Works

Traditional phishing sends users to a fake login page that collects their username and password. MFA blocks that attack because the stolen password alone isn’t enough to authenticate. AiTM phishing is different. Instead of a static fake page, the attacker runs a reverse proxy server that sits between the victim and the real Microsoft login portal.

When a user clicks a phishing link, they see what appears to be the genuine Microsoft sign-in page, because it is the genuine page, just served through the attacker’s proxy. The user enters their username and password. The proxy forwards those credentials to Microsoft’s real authentication endpoint. Microsoft prompts for MFA. The user completes the MFA challenge (push notification, authenticator code, or SMS). Microsoft issues an authenticated session token. The proxy captures that session token before passing it to the user.

The attacker now holds a fully authenticated session cookie. They can import it into their own browser and access the victim’s M365 account without ever needing the password or MFA again. The session is already authenticated. From Microsoft’s perspective, it looks like a legitimate login.

Tools like EvilGinx2 have been publicly available since 2018, but newer variants specifically targeting M365 have lowered the skill barrier significantly. The phishing kits include pre-built M365 login page templates, automated session capture, and even dashboards for managing compromised accounts at scale. Security researchers at Microsoft, Proofpoint, and Zscaler have all documented sharp increases in AiTM phishing campaigns targeting Microsoft 365 tenants over the past 18 months.

Why Standard MFA Doesn’t Help

The critical thing to understand: MFA works perfectly during an AiTM attack. The user successfully authenticates. The MFA challenge completes. The problem is that the attacker’s proxy captures the result of that authentication, the session cookie, and uses it directly.

Push-notification MFA (Microsoft Authenticator), time-based one-time passwords (TOTP), and SMS codes are all vulnerable because they verify the user’s identity at login time, then the resulting session token carries that trust forward. The token doesn’t care how it was obtained. Once the attacker has it, they’re in.

This is why organizations that check the “MFA enabled” box and assume they’re protected are missing a real threat vector. MFA still blocks the vast majority of credential-stuffing and password-spray attacks, and you should absolutely keep it enabled. But it’s one layer, not the entire defense. Your M365 security configuration needs additional controls to address token theft.

Phishing-Resistant MFA: FIDO2 and Passkeys

The most effective defense against AiTM phishing is phishing-resistant MFA, specifically FIDO2 security keys and passkeys. These authentication methods are fundamentally different from push notifications or TOTP codes because they’re bound to the legitimate domain.

When you register a FIDO2 key or passkey with Microsoft Entra ID, the credential is cryptographically tied to login.microsoftonline.com. If the user lands on an AiTM proxy at login-microsoftonline.attacker.com, the FIDO2 key simply won’t respond. The domain doesn’t match, so the authentication ceremony never starts. There’s nothing for the proxy to capture because the phishing-resistant credential refuses to engage with the wrong server.

Microsoft has been expanding passkey support across M365 and Entra ID. FIDO2 security keys (like YubiKeys) have been supported for several years. The newer device-bound passkeys work with Windows Hello, Apple Face ID/Touch ID, and Android biometrics, which removes the need for separate hardware tokens for most users.

For SMBs, the practical rollout path looks like this:

• Start with admin accounts. Require FIDO2 or passkeys for all Global Admin, Security Admin, and Exchange Admin accounts. These are the highest-value targets.
• Expand to finance and executive users. Anyone who can approve wire transfers or access sensitive financial data should use phishing-resistant MFA.
• Roll out company-wide over 3-6 months. Pair the rollout with Conditional Access policies (see below) that enforce phishing-resistant MFA for high-risk sign-ins and sensitive applications.

Conditional Access Policies That Block AiTM

Conditional Access in Microsoft Entra ID is your policy engine for stopping AiTM attacks before they succeed. Several specific policies directly counter the AiTM technique:

Require compliant or managed devices. This is the single most effective policy against AiTM. When you require that M365 access comes from an Intune-enrolled or hybrid Azure AD-joined device, the attacker’s proxy fails because the token request originates from the attacker’s infrastructure, not from a compliant device. Even if they steal a session cookie, replaying it from an unmanaged device triggers re-authentication. Your managed security team should have this policy active on every tenant.

Require phishing-resistant MFA for sensitive apps. Create a Conditional Access policy that requires FIDO2 or passkey authentication (authentication strength: “Phishing-resistant MFA”) for access to Exchange Online, SharePoint, and the Azure portal. Users can still use standard MFA for lower-risk apps, but the accounts that matter most get the strongest protection.

Block legacy authentication protocols. POP3, IMAP, SMTP Basic Auth, and ActiveSync Basic Auth all bypass Conditional Access entirely. An attacker with stolen credentials can authenticate through these older protocols and skip every security policy you’ve configured. Block them at the tenant level if you haven’t already.

Enable Continuous Access Evaluation (CAE). Standard M365 access tokens are valid for 60-75 minutes by default, meaning a stolen token gives an attacker that entire window regardless of what you do. CAE shortens that window dramatically by enabling near-real-time token revocation. When you detect a compromised account and disable it or change its password, CAE-enabled applications invalidate the active session within minutes rather than waiting for the token to expire. CAE also evaluates network location changes, so a token that was issued to an IP in Dallas and suddenly appears from an overseas IP can be challenged or blocked.

Use token protection (preview/GA depending on your tenant). Token binding ties access tokens to the specific device that requested them. A token issued to a user’s enrolled laptop can’t be replayed from the attacker’s server because the cryptographic binding doesn’t match. This feature has been rolling out across M365 and directly counters the core AiTM technique.

Detection: Catching AiTM Attacks in Progress

Prevention is the priority, but you also need visibility into attempted AiTM attacks. Several signals in your M365 logs indicate proxy-based phishing:

• Impossible travel alerts. A user authenticates from Dallas, then the stolen token appears from a foreign IP minutes later. Entra ID Protection flags these automatically if you have P2 licensing.
• Unfamiliar sign-in properties. AiTM proxies often present different browser fingerprints, operating system strings, or TLS characteristics than the user’s real device.
• Inbox rule creation after sign-in. One of the first actions attackers take with a compromised M365 account is creating mail forwarding rules to exfiltrate email silently. Monitor for new inbox rules created within minutes of a sign-in event, especially rules forwarding to external domains.
• MFA registration changes. If an attacker gains access through a stolen session, they often register their own MFA method to maintain persistent access. Alert on new MFA method registrations, particularly from unfamiliar devices or locations.

Your email security monitoring should include automated alerting on these indicators. Microsoft Defender for Office 365 and Entra ID Protection both generate these alerts natively, but someone needs to be watching and responding.

Action Plan for Your M365 Tenant

If you haven’t specifically hardened your tenant against AiTM attacks, here’s a prioritized checklist:

1. Block legacy authentication across the tenant. This closes the easiest bypass.
2. Require managed/compliant devices via Conditional Access for all M365 access. Test in report-only mode for one week before enforcement.
3. Deploy FIDO2 keys or passkeys to admin accounts, finance users, and executives immediately. Expand to all users over the next quarter.
4. Enable Continuous Access Evaluation if it’s not already active on your tenant.
5. Configure Entra ID Protection risk policies to flag impossible travel and unfamiliar sign-in properties.
6. Audit existing inbox rules across all mailboxes for hidden forwarding to external addresses.
7. Run a phishing simulation that includes an AiTM-style proxy page to test whether your security awareness training covers this attack type.

MFA remains essential. It blocks the vast majority of automated attacks that hit M365 tenants every day. But treating it as the complete answer to phishing leaves a growing gap that attackers are actively exploiting. Layering phishing-resistant credentials, device compliance, and continuous evaluation on top of MFA is what closes that gap. Most of these controls are already included in your M365 Business Premium or E3/E5 license. The tools are there. The question is whether they’re turned on.