Adversary-in-the-middle (AiTM) phishing kits sit between the victim and the genuine sign-in page. The user sees the real Microsoft login, enters their password, approves the MFA prompt — and the kit captures the resulting session cookie. The attacker replays that cookie and is signed in without ever needing the password or MFA again.
Why ordinary MFA does not help
Push notifications, SMS codes and TOTP apps all authenticate the user, not the site. If the user is talking to a proxy, the proxy receives a perfectly valid session. Only authentication methods bound to the origin — FIDO2 security keys, passkeys, Windows Hello for Business and certificate-based authentication — refuse to complete on a look-alike domain.
Controls that work
- Require phishing-resistant MFA with Conditional Access authentication strengths, starting with administrators and high-value users.
- Require compliant or hybrid-joined devices for access to Microsoft 365. A stolen cookie replayed from the attacker's machine fails the device check.
- Enable token protection (token binding) for supported clients where licensing allows.
- Turn on risk-based policies so that anomalous token and sign-in risk detections force re-authentication or block access.
- Shorten sign-in frequency for privileged roles and sensitive applications.
Detection signals
| Signal | Where to look |
|---|---|
| Sign-in from a new ASN immediately after a successful MFA | Entra sign-in logs |
| Anomalous token / token issuer anomaly risk detections | Entra ID Protection |
| New inbox rules moving or deleting mail | Unified audit log (New-InboxRule) |
| New MFA method registered after a risky sign-in | Audit logs: User registered security info |
Check your own exposure
Start with the basics: confirm your domain's email authentication with our Email security check, and look for look-alike domains that could host a kit with the Typosquat finder.
