Impossible Travel With a Clean Endpoint
At 10:05 UTC the identity team escalates an alert: finance analyst m.chen signed in to Microsoft 365 from Lagos at 09:12 and from Chicago at 09:40, and both sessions satisfied MFA. Chen insists she has been in Chicago all week. EDR shows nothing unusual on her laptop and no malware quarantined in 30 days. Mailbox audit logs show an inbox rule created at 09:21 that moves any message containing 'invoice' or 'wire' to the RSS Feeds folder and marks it read. Three days earlier Chen consented to a third-party app called eDocSign requesting Mail.Read and offline_access. The tenant has 2,400 users; 40 show the same app consent. Conditional access enforces MFA but does not restrict countries or legacy authentication.
1. What is the most likely attack path, and which two pieces of evidence would most strongly confirm or refute it?
Read the worked answer
Most likely path: illicit consent grant leading to refresh-token replay.
The reasoning that matters is the combination of signals, not any single one:
- The Lagos session passed MFA. Password guessing does not pass MFA, so either the user approved a prompt (MFA fatigue) or a previously issued token was replayed. The app requests
offline_access, which is exactly the scope that yields a durable refresh token. - The endpoint is clean. That is consistent, not exculpatory: OAuth abuse never touches the host. A clean EDR result should not lower your confidence here.
- The inbox rule lands 9 minutes after the Lagos sign-in and targets payment keywords. Rule creation is a classic post-compromise step to hide vendor-invoice fraud.
Evidence to pull first:
- The sign-in log entry for the Lagos session, specifically whether it was an interactive sign-in or a token refresh, and the client app ID. If it is the eDocSign service principal, the token theft path is confirmed.
- The service principal's consent grant record (who granted, when, what scopes, publisher verification status).
What would refute it: a corporate VPN or cloud-proxy egress in Lagos, or an interactive sign-in with a new MFA method registered from an unknown device, which would point to session theft on the endpoint instead. Check the Chicago session against known egress ranges before you treat the geography as genuine.
2. Order your containment actions for the next two hours and name one action that feels urgent but would destroy evidence.
Read the worked answer
Order matters because revocation is not reversible and evidence is.
- Export before you delete. Pull the unified audit log filtered to Chen and the app ID, the full inbox rule definition (including hidden rule parameters), the sign-in logs, and the consent grant record. Do this in parallel with step 2, but before anyone deletes the rule or the app registration.
- Revoke sessions and refresh tokens for Chen (revoke sign-in sessions, not just a password reset). A password reset alone leaves the stolen refresh token valid until natural expiry.
- Disable or remove the eDocSign enterprise app and block future consent grants of that publisher through the consent policy.
- Reset credentials and re-register MFA for Chen, then verify no new MFA methods or devices were added.
- Hunt the other 39 consenting users for inbox rules, forwarding, and outbound mail to newly registered domains.
The trap: deleting the malicious inbox rule or the app registration first. Both are urgent-feeling and both erase the artefacts you need for scope, for the fraud investigation, and for any regulatory report. Wiping or reimaging Chen's laptop is the same mistake for no benefit.
3. How do you scope the other 39 users efficiently, and what do you run first?
Read the worked answer
Start from the app, not from the users.
The service principal ID is the pivot: it appears in every consent event and in the sign-in logs of every session the app created. One query against the unified audit log for consent-to-application operations and for New-InboxRule/Set-InboxRule/Add-MailboxPermission/Set-Mailbox (forwarding) over 30 to 90 days gives you the population in a single pass.
Then rank the 39 by consequence rather than treating them as a block:
- Users whose consent included
Mail.SendorMail.ReadWriteare higher risk than read-only grants, because they can be used for internal phishing or invoice fraud. - Users with an inbox rule that hides or forwards mail are almost certainly already used.
- Users with no rule and no anomalous sign-in are still exposed but not yet leveraged; they can wait a few hours for remediation.
Do not scope by asking users or by trusting the app's stated purpose. Also check whether exfiltrated mail contained regulated data before you decide this is an IT-only incident; if customer or financial records left the tenant, privacy and legal get involved and the clock starts on notification analysis.