AiTM phishing in Microsoft 365 needs more than standard MFA to stop

These days I run into AiTM phishing attacks against Microsoft 365 tenants in almost every environment I review. This stopped being a theoretical risk a while ago. Attackers are actively using phishing kits that proxy the real sign-in page, and they fool experienced users too. What makes it dangerous is what happens after a successful sign-in and MFA: the attacker quietly takes the session cookie and uses it for full access, without needing the password or a second factor. From there I've seen attackers immediately create forwarding rules to cover their tracks, register their own MFA devices and prepare the ground for serious business email compromise (BEC).

AiTM phishing works by proxying the sign-in, stealing the token and replaying it

Technically, AiTM phishing is simple, and that's part of why it works so well. The phishing kit sits in the middle, between the user and the genuine Microsoft 365 authentication service. Every input and every MFA prompt passes through the attacker's server. When the user completes MFA, the attacker pulls the session cookie out of the traffic and replays it in their own browser, which skips any further authentication. So the attacker gets in even though MFA looked solid. Usually the next move is an inbox rule that hides their presence or forwards messages. All of this can happen before a defender notices anything.

The flow looks like this as a Mermaid flowchart:

flowchart TD
  User["User"] --> PhishProxy["Phishing proxy"]
  PhishProxy --> Real365["Microsoft 365 sign-in"]
  Real365 --> PhishProxy
  PhishProxy --> User
  PhishProxy -- "Cookie stolen" --> Attacker["Attacker browser"]
  Attacker --> Real365["Microsoft 365 sign-in"]

Figure: How an AiTM phishing attack unfolds, with the session hijacked after MFA.

The whole exchange takes a few seconds. Most users and older alerting setups can't react that fast.

Authentication strengths and token protection block AiTM phishing

When I raise this threat in projects, people want to know what actually helps, given that traditional MFA no longer does the job. My answer is phishing-resistant MFA, meaning FIDO2 security keys, Windows Hello for Business or certificate-based authentication. With these methods, a stolen cookie can't be replayed from an attacker's device. Conditional Access lets you require this level of authentication strength, and I always advise enforcing it for admins and sensitive groups. In my experience it reduces AiTM exposure a great deal.

Device compliance adds another layer if you require a compliant or hybrid Azure AD joined device in Conditional Access, because attackers rarely get their hands on managed endpoints. There's also a newer option, token protection for Conditional Access (in public preview as of March 2024). It blocks token replay on unauthorized devices, though only on Windows and for certain client apps. The official documentation has the details.

Several other measures make a real difference:

• Setting sign-in frequency for high-risk scenarios
• Using Entra ID Protection risk-based policies to detect and block automatically
• Continuous Access Evaluation (CAE) to end sessions quickly when risk changes
• Automatic Attack Disruption in Microsoft Defender XDR, which can contain compromised users while an AiTM attack is in progress (I cover this in my post on getting started with Defender XDR)
• Watching for suspicious inbox rules and new MFA registrations

Pro tip: A lot of organizations still don't monitor inbox rules. This short PowerShell snippet helps you spot risky forwarding or deletion rules fast:

Get-InboxRule -Mailbox <user> | Where-Object { $_.RedirectTo || $_.ForwardTo || $_.DeleteMessage }

Any rule that forwards or auto-deletes messages deserves a close look.

Fast detection and response limit the damage when AiTM strikes

No defense is perfect, and sooner or later an AiTM phishing attack may get through. In the incidents I've worked on, speed decided everything. Start right away by revoking all sessions for the compromised account and resetting the password. Then check for malicious inbox rules or forwarding and remove them, and wipe any MFA methods that were newly registered. Entra ID audits these events well, and the automatic detection in Defender XDR keeps getting better. Talk to the affected user quickly as well, mainly to prevent BEC or further abuse.

I think it's time to move beyond basic MFA to real zero trust

For me, AiTM phishing should be a wake-up call for anyone who still relies on basic MFA. Attackers have changed their methods, and we have to change ours. Real protection now means rolling out phishing-resistant MFA and enforcing it with Conditional Access, combined with device compliance and newer features like token protection. Zero trust is more than a buzzword in this context. It's the practical framework that ties these layers together, even while some of the tools are still maturing. AiTM phishing will stay a real headache throughout 2024, but with the right measures in place you can get ahead of it.