Case Study 1 — The Invoice That Changed Its Bank Details

A $190,000 vendor payment lands in a criminal's account. There is no malware on any laptop, no breached firewall, nothing to seize. The entire intrusion happened inside Microsoft 365 — and the entire investigation is won from logs, by an examiner who froze the evidence on day one and read the audit trail the attacker forgot was running.

Background

A 240-person architecture firm runs everything on Microsoft 365: Exchange Online for mail, SharePoint and OneDrive for files, Teams for chat. On a Thursday, the accounts-payable clerk pays a long-standing structural-engineering subcontractor $190,000 against an emailed invoice that — the bank later confirms — routed to an account the firm had never used. The vendor says they were never paid and never sent new banking details. The firm's outside counsel engages you for incident response with one question: was the firm's email compromised, and if so, how, when, and what did the intruder touch? There is nothing physical to image. The mail flowed through Microsoft's data centers; the "scene" is a tenant, and the tenant is reservoir 2 — the firm owns it, so you collect with administrative access and no subpoena. Your very first act, before any analysis, is to stop the clock.

The investigation

Day one — preserve, because the clock is already running. Entra ID sign-in logs retain only about thirty days by default, and the Unified Audit Log (UAL) is bounded by license. Counsel places the relevant custodians on a Microsoft Purview eDiscovery legal hold — the cloud analogue of "the original is sacred," implemented as policy because you cannot attach a write-blocker to Exchange Online — and you immediately export the sign-in logs and the UAL before either erodes. You hash each export the instant it lands and record the chain-of-custody line: cmdlet, tenant, the principal and role you used, the UTC timestamp, the tool version, the record count, and the SHA-256.

Identity first — who logged in, from where. Entra sign-in logs for the AP clerk's account tell the story immediately:

Entra ID sign-in log (UTC) — ap.clerk@firm.example
Mon 13:02  Success  198.51.100.20   City A (HQ)   Browser/Win   MFA satisfied
Mon 22:47  Success  41.x.x.x        Country Z      Browser       MFA: "satisfied by token"
Tue 09:05  Success  198.51.100.20   City A (HQ)   Browser/Win   MFA satisfied

The 22:47 sign-in from another continent, hours after a normal HQ sign-in, is impossible travel — no human flew there. The "MFA satisfied by token" detail is the tell: the attacker did not defeat multi-factor authentication head-on; they replayed a stolen session token (an adversary-in-the-middle phishing kit), which is exactly why a cached token is so dangerous and why session artifacts matter. The source IP 41.x.x.x becomes the thread you pull through every other log.

What the intruder did inside the mailbox — the UAL. A Search-UnifiedAuditLog for the clerk, filtered to the compromise window, returns the attacker's whole playbook:

M365 Unified Audit Log (UTC) — ap.clerk@firm.example
Mon 22:48  MailItemsAccessed    41.x.x.x   (mailbox sync — bulk read)
Mon 22:53  New-InboxRule        41.x.x.x   name:" ."  move→RSS Feeds, markRead
                                conditions: from/subject contains "invoice","payment","bank"
Mon 23:10  Update               41.x.x.x   Sent Items: edited draft to vendor thread
Tue 02:20  MailItemsAccessed    41.x.x.x

The New-InboxRule is the heart of it. The attacker created a rule named with a single space or period — deliberately near-invisible in Outlook's rule list — that swept any message mentioning invoice, payment, or bank into the rarely-opened RSS Feeds folder and marked it read. That is how the genuine vendor's "we never changed our bank details" replies never reached the clerk: the rule hid them. MailItemsAccessed confirms the mailbox was bulk-read (it proves a sync occurred, not that a human read a specific message — a distinction you state carefully). The thread shows the attacker reading the legitimate invoice conversation, then sending the altered-banking-details message from the clerk's own account, so it carried perfect internal provenance.

Corroborate across workloads. Because Teams lives inside M365, you check it through the same UAL and find no chat exfiltration — the attack was mail-only. SharePoint and OneDrive operations for the account show nothing anomalous. The narrowness is itself a finding: this was financially motivated business-email-compromise (BEC), not a broad data theft. You cross-check the attacker IP 41.x.x.x against the sign-in logs for every other user and find one more account touched the same night — a second compromised mailbox you flag for containment.

Assemble the sourced timeline. Every line traces to a specific, hashed cloud export:

BEC TIMELINE (UTC) — firm.example, IR-2026-031
Mon 22:47  Token-replay sign-in from 41.x.x.x (impossible travel)   [Entra sign-in log]
Mon 22:48  Mailbox bulk-read                                        [UAL MailItemsAccessed]
Mon 22:53  Hidden inbox rule created (invoice/payment→RSS Feeds)    [UAL New-InboxRule]
Mon 23:10  Vendor thread reply sent with altered bank details       [UAL + Sent Items]
Thu 11:40  AP clerk pays $190k to fraudulent account                [bank record]
Fri 08:15  Vendor reports non-payment; firm engages IR              [intake]
Fri 13:00  Legal hold set; sign-in + UAL exported and hashed        [CoC worksheet]

You give counsel the actionable findings — the firm's email was compromised via session-token replay, the fraud was enabled by a concealment rule, a second account is implicated — and the containment steps that follow directly: revoke all sessions and reset credentials for both accounts, delete the malicious inbox rules, enforce phishing-resistant MFA, and hunt the attacker IP tenant-wide. You also name what the in-scope logs cannot tell you — the attacker's real-world identity behind 41.x.x.x, which may be a proxy — and reserve it for law enforcement, who can serve the SCA process on the upstream provider that you, in a corporate engagement, cannot.

The analysis

  1. Preservation is the first act, not a later step. Entra sign-in logs (≈30 days) and the UAL would have eroded while the matter was discussed. The day-one legal hold and immediate, hashed export are what made every later finding possible — in the cloud, evidence ages out by policy, and a week's delay can erase the case.
  2. The attack lived entirely in reservoir 2. Nothing was on a seizable device; the whole investigation was log-centric, collected with the client's own admin access. An examiner who could only work a laptop would have found nothing and concluded nothing happened.
  3. Identity logs turn "a login" into "an intrusion." Impossible travel plus "MFA satisfied by token" identified token replay, not a password guess — which changed both the finding and the remediation (revoke sessions, not just reset passwords). The source IP then stitched the separate logs into one actor.
  4. The malicious inbox rule is the BEC signature — and it convicts itself. New-InboxRule is logged with its name, conditions, and actions; the near-invisible rule name meant to hide the fraud is precisely what proved intent and method once read from the UAL.
  5. State what each event proves, and what it does not. MailItemsAccessed proves a mailbox sync, not that a human read a specific message; the source IP identifies a network endpoint, not a person. Naming those limits is what keeps a confident finding defensible.

Discussion questions

  1. The firm's only evidence lived in Microsoft's data centers. Walk through exactly what would have been lost — and which findings in this case would have become impossible — if counsel had waited three weeks to set the legal hold and export the logs.
  2. Distinguish what MailItemsAccessed, New-InboxRule, and the Entra sign-in record each prove on their own, and explain how correlating all three (plus the shared source IP) produces a finding stronger than any one of them.
  3. The attacker satisfied MFA "by token" rather than defeating it. Explain how a stolen session/OAuth token enables this, why it makes credential reset alone insufficient, and which browser artifact from the chapter is the on-endpoint counterpart to this cloud-side finding.
  4. ⭐ Suppose the firm had never enabled mailbox auditing and the UAL returned nothing for the period. Re-plan the investigation: which other M365 and identity logs might still bear on the question, what could you no longer prove, and how would you phrase the limitation honestly to counsel — connecting your answer to the fifth theme, know your limitations?
  5. The investigation identified the attacker's IP but not the human behind it. Explain why a corporate incident-response engagement (reservoir 2) cannot reach the upstream provider's subscriber records, which reservoir and legal instrument that would require, and why handing this thread to law enforcement is the correct boundary rather than a failure.