AiTM phishing: when MFA is no longer enough to protect sessions

The principle: a proxy between the user and Microsoft

An AiTM kit does not imitate the sign-in page: it relays it. The user lands on a domain controlled by the attacker, which forwards every request to the real Microsoft service and returns every response to the victim. The user sees the usual page, possibly with their organisation's branding, types their password and approves MFA. From their point of view, everything works as normal.

But the proxy in the middle captures the password and, above all, the session cookie that Entra ID issues once authentication is complete. The attacker imports that cookie into their own browser and is signed in, without having to pass MFA again. Open-source tools of this kind have existed for years, and phishing-as-a-service offerings have put them within reach of unskilled attackers.

Why conventional MFA fails

Authenticator push, one-time code, SMS or phone call: all of these methods share one trait. The user proves they hold a factor, but nothing ties that proof to the site they are actually on. Number matching does not help here: the victim sees the number displayed by the relayed page and types it in good faith.

What happens after the compromise

The patterns we see in investigations are strikingly similar:

• inbox rules that move or delete messages containing certain keywords (invoice, payment, transfer);
• a new MFA method registered by the attacker to secure lasting access;
• reading financial correspondence in preparation for payment fraud;
• new phishing campaigns sent from the compromised mailbox to internal and external contacts.

Detection signals

Several clues can reveal a stolen session, provided someone is watching them:

1. Entra ID Protection detections: depending on your licence, detections such as "anomalous token", "unfamiliar sign-in properties" or the dedicated attacker-in-the-middle detection flag this scenario. Check which ones are available in your tenant.
2. Inconsistencies in sign-in logs: a successful authentication from one IP address, then use of the session a few minutes later from a hosting provider or a different country.
3. Post-sign-in activity: new inbox rules, a new authentication method registered, consent to an application, all shortly after the suspicious sign-in.
4. Mail signals: the original phishing URL, often visible in Defender for Office 365 detections if you have it.

Incident response: the password is not enough

Resetting the password is not enough. You also need to revoke the user's sessions and refresh tokens, remove authentication methods added by the attacker, delete malicious inbox rules, check application consents and mail forwarding, then look for the other recipients of the same phishing message. Continuous access evaluation speeds up how quickly compatible services honour the revocation.

The real fix: phishing-resistant MFA

FIDO2 security keys, passkeys, Windows Hello for Business and certificate-based authentication cryptographically bind the authentication proof to the site's origin. On the attacker's domain the authenticator produces nothing usable: the attack fails before a session is ever created.

In addition, Conditional Access can require a compliant or Entra-joined device for sensitive resources: the attacker's proxy cannot present the expected device proof. A realistic approach is to enforce these methods first for administrators and the most targeted groups (executives, finance, HR) through authentication strengths, then extend gradually.

What an audit checks

• The share of users, and administrators in particular, with a phishing-resistant method registered.
• Conditional Access policies requiring an authentication strength or a compliant device for sensitive access.
• Whether Entra ID Protection risk detections are enabled and acted upon.
• Protection of MFA method registration by a dedicated policy.
• Alerts on the creation of inbox rules and external forwarding.
• A response procedure that includes session revocation.