This article was written with the help of AI. We used an AI assistant to draft it, then checked the facts against Microsoft's threat research and documentation. Sources are linked throughout.
Adversary-in-the-middle phishing is the reason "we have MFA" no longer settles the question. Microsoft described one such campaign that attempted to target more than 10,000 organizations starting in September 2021, and the technique has only become easier since, with free toolkits that automate it.
How It Works
The phishing site does not imitate Microsoft's sign-in page. It shows the real one, passed through a proxy the attacker controls. Microsoft explains that the proxy holds two connections, one to the victim and one to Microsoft, so everything the victim types and approves goes straight through. When Microsoft issues the session cookie at the end, the proxy keeps a copy.
From the employee's side, nothing looks wrong. The page looks right, the MFA prompt arrives, they approve it, and they land in their mailbox. The only visible difference is the web address.
We covered what attackers do with that stolen session, and how to clean up afterwards, in Microsoft 365 Token Replay Attack. This post is about stopping the theft in the first place.
Why Common MFA Does Not Stop It
Text codes, phone calls, authenticator codes and push approvals all prove the person has their phone. None of them check which website is asking. If the employee is on a relay page, they will happily type the code or tap approve, because they started the sign-in themselves.
That is also one reason Microsoft is retiring text and voice codes. See our post on the Entra SMS retirement for dates.
What Stops It
Phishing-resistant sign-in
Microsoft's first recommendation is MFA that supports FIDO2 or certificate-based authentication. Passkeys, security keys and Windows Hello for Business are tied to the real Microsoft address. On a relay page, the browser will not hand them over. In Entra you enforce this with the built-in Phishing-resistant MFA authentication strength in a Conditional Access policy.
You do not have to move everyone at once. Start with administrators and anyone who approves payments or changes bank details, since those accounts are worth the most to an attacker.
Require a managed device
Microsoft also recommends Conditional Access rules that look at device compliance and location. If Microsoft 365 only accepts sign-ins from company-managed or compliant devices, a session cookie replayed from the attacker's computer has a much harder time getting in.
Filter links and watch sign-ins
Email filtering and browsers that block known phishing sites stop many lures before anyone clicks. And because no control is perfect, someone should be reviewing risky sign-ins and new inbox rules. Our phishing protection guide covers the email side.
A Short Plan for a Small Office
- Turn on Conditional Access requiring MFA for all users, in report-only mode first.
- Register passkeys for admins and finance staff and require phishing-resistant MFA for them.
- Require compliant or registered devices for Microsoft 365 where your setup allows it.
- Block sign-in methods you do not use, such as the device code flow.
- Review sign-in logs and inbox rules regularly, not just after a problem.
Most of this needs Microsoft 365 Business Premium. Our Business Standard vs. Premium comparison explains the difference.
Sources
- Microsoft Threat Intelligence: From cookie theft to BEC, attackers use AiTM phishing sites as entry point to further financial fraud
- Microsoft Learn: Conditional Access authentication strengths
Common questions
Is adversary-in-the-middle phishing a flaw in MFA?
No. Microsoft says plainly that it is not a vulnerability in MFA. The attacker relays the whole sign-in, so the victim really does complete MFA, and the attacker keeps the session that results.
Does number matching in Microsoft Authenticator stop it?
No. Number matching stops people approving prompts they did not start. In an adversary-in-the-middle attack the victim did start the sign-in, on a page they believe is real, so they match the number willingly.
What stops it?
Phishing-resistant sign-in methods such as passkeys, FIDO2 security keys, Windows Hello for Business and certificate-based authentication, because they check the real website address. Conditional Access rules that require a managed or compliant device also make a stolen session much harder to use.
How would we know it happened?
Look for a successful sign-in from an unusual location, internet provider or browser shortly after someone clicked a link, followed by mailbox changes such as new inbox rules.
