MFA Satisfied, Geography Impossible

The most likely explanation is token theft through adversary-in-the-middle phishing or illicit OAuth consent, not a false-positive impossible-travel alert. The Lagos sign-ins are MFA-satisfied because the attacker is replaying a stolen session or refresh token, not prompting for MFA. The user saw no prompt, which fits token replay. The OAuth grant with Mail.Read and offline_access, followed six minutes later by a hidden inbox rule, is a classic business-email-compromise pattern.

Evidence to collect: sign-in logs with authentication method, token issuance time, IP/ASN, device ID and compliance state; audit logs for the consent grant, including consent actor and app owner; the inbox rule's creator and scope; mailbox audit events for mail access and forwarding; the app's service principal and any other users who consented; and endpoint logs from the user's device for phishing pages or suspicious browser extensions.

A password reset alone does not invalidate refresh tokens, which explains why Lagos activity continued. Same device ID is not proof of the legitimate device; it can be spoofed or copied with the token. Treat the account as compromised until revocation and rule removal are complete.

Contain the identity first, because the attacker holds a token that survives password resets.

1. Revoke the user's sessions and refresh tokens, and block sign-in temporarily if the organization's policy allows it.
2. Revoke the OAuth app's consent and disable the enterprise application; preserve its audit record first.
3. Remove the inbox rule and check for forwarding, delegation, and mailbox permissions.
4. Reset the password again after revocation, then require MFA re-registration if there is any sign of device compromise.
5. Hunt for other users who consented to the same app and for similar inbox rules across finance and wire-desk mailboxes.
6. Notify the finance director and wire desk so they can verify any payment-change requests out-of-band.

Order matters: removing the rule before revoking the token may tip off the attacker and allows re-creation. Disabling the app before preserving its configuration can destroy evidence. Password reset before token revocation gives false comfort. After containment, review conditional access for user consent and legacy authentication gaps, and add detections for consent grants plus inbox-rule creation within a short window.

Build a correlation rule across identity and mail audit logs. Data sources: cloud sign-in logs, audit logs for consent grants, mailbox audit logs, and endpoint browser/proxy logs.

Logic: alert when a new OAuth application consent is granted with mail-read or offline-access scopes, and within 60 minutes the same user creates an inbox rule that moves or deletes messages matching finance, wire, invoice, or payment terms. Enrich with whether the app is admin-consented, newly registered, or has a verified publisher. A second rule should flag MFA-satisfied sign-ins from a new ASN where the token was issued to a different device or IP, especially if the user reports no prompt.

The detection should not rely on impossible travel alone. Travel is a weak signal when tokens are replayed. Tune by allowlisting sanctioned applications and known automation, and route high-risk consent alerts to a 15-minute SLA. Also add a weekly report of all new consent grants for review. The goal is to catch the sequence, not a single event, because either event alone has legitimate explanations.