MFA Was Satisfied, and Nothing Else Looked Wrong

The timeline contains several signals that individually are weak and together are decisive:

• A successful sign-in with no MFA event. At 09:31 the session authenticates with a cookie and produces no authentication method event. For a genuine user, MFA satisfaction is tied to an interactive authentication; a cookie replay skips it entirely. This is the strongest single indicator.
• Same cookie, different IP. One session token appearing from two addresses within minutes is not user behaviour - it is token replay.
• The MFA claim at 09:14 was satisfied by a previously registered method two minutes after the email click, which is the AiTM signature: the proxy relayed the push approval in real time while capturing the resulting session token.
• User-agent drift of a minor Chrome version plus a residential-proxy ASN in the user's own metro area. The proxy is chosen deliberately for this.
• Post-authentication actions: an inbox rule named . moving invoice and payment mail to RSS Feeds, and an OAuth consent with offline_access at 09:24 and 09:31. Rule creation and consent grants within 15 minutes of a sign-in are classic post-compromise behaviour.

Impossible travel failed because it is a distance-and-velocity heuristic. The proxy egressed in the same city, so there was no distance to measure - and a token replay from a nearby address is exactly what the control cannot see. Travel-based rules detect geography, not credential replay. The absence of an alert here is not a tuning gap in the rule; it is a category error in what the rule measures.

Order matters because several of these actions are undone by skipping earlier ones.

1. Revoke refresh tokens and sessions first for m.okafor (Entra: revoke sessions plus Revoke-AzureADUserAllRefreshToken). Without this, every other step is theatre - the stolen refresh token mints new access tokens after the password changes.
2. Reset the password and re-register MFA for the account, because the AiTM page captured the password and the push approval habit is now compromised.
3. Remove the inbox rule and any forwarding, and check Sent Items, Deleted Items, and the recoverable items folder for what the actor staged or sent.
4. Revoke the Mail Sync Pro consent and remove the enterprise app grant, and hunt for the same consent across all 4,000 users - consent phishing is rarely run against one person.
5. Block the lookalike domain and the proxy ASN at the mail gateway and egress proxy, and pull the mail gateway click data plus proxy logs for every other user who reached that domain. Those users need the same token revocation, not just a warning email.
6. Check for persistence outside the mailbox: new MFA methods, app passwords, delegate access, and rules created by other accounts signing in from the same ASN.

A password reset alone accomplishes very little: it does not invalidate the refresh token, does not remove the OAuth grant, does not remove the inbox rule, and does not stop the second sign-in. The user would reset her password and the actor would keep reading mail from the still-valid token. In AiTM, token revocation is the primary response and the password reset is secondary.

Rank by what breaks the attack chain we just observed, not by industry popularity.

1. Phishing-resistant MFA (FIDO2/passkeys) for all users, admins first. This is the only control that defeats AiTM at the root: the credential is cryptographically bound to the origin, so a proxy on tailsp1n-toys.example cannot obtain a usable assertion for login.microsoftonline.com. Push approval, which is what failed here, is precisely the method AiTM is built to relay. Highest reduction per unit of effort for the largest population.

2. Token protection / session binding, plus a compliant-device requirement for all users. FIDO2 reduces new compromises; token binding limits the damage when a token is stolen anyway, by tying the refresh token to the device it was issued to. Extending device compliance from administrators-only to everyone would have blocked an unmanaged-device session at 09:14 - but note it is a weaker control than it looks, because compliant devices can be phished too, and it will generate a large helpdesk load.

3. Conditional access to restrict legacy authentication and high-risk sign-ins, plus alerting on consent grants and inbox rule creation. This is detection and containment rather than prevention: it would not have stopped 09:14 but would have surfaced 09:19 and 09:24 within minutes, cutting dwell time from days to minutes.

Why this order: prevention that breaks the technique outranks containment that shortens the window, and controls that work regardless of user behaviour outrank ones that depend on device management coverage, which at 4,000 users is never complete.