What a Microsoft 365 Post-Incident Report Should Contain: Lessons From a Business Email Compromise Case
A post-incident report turns "we reset the password" into a record a board, an insurer, a bank or an auditor can act on. We recently published a redacted sample: an executive assistant's Microsoft 365 account taken over through an adversary-in-the-middle phishing proxy, held four weeks with a stolen refresh token, then used to mail malware to about 200 contacts. Here is that report section by section, and the questions yours must answer.
Why the report exists, and why contained is not closed
A post-incident report has four jobs: record what the evidence shows, with times and sources, before retention deletes it; separate done from open; explain root cause and contributing factors so the fix reaches past one account; and give insurer, bank and counsel something to rely on.
The sample shows why the second job matters. The account was contained within about two hours of the mass mailing. The open list still read: two Defender XDR incidents unassigned, 13 phishing copies in internal inboxes, the laptop that ran the payload not isolated, 187 external recipients not notified, a second user's risk not remediated, the URL not blocked. "Contained" without that list is how the next incident starts.
IT Partner now offers a fixed-price post-incident investigation and report engagement; it is in review and not yet listed. The redacted sample report (PDF) shows the deliverable and is the structure below.
The front page: incident at a glance, then the executive summary
Page one is a header and a one-page table. The header carries the incident reference (ticket and Defender XDR incident numbers), the incident window, the report date, a version number, classification and distribution, the sources and the time zone. Version 1.0 ships with open items; 1.1 records their closure.
"Incident at a glance" answers seven questions: the incident in one sentence; the account and its roles (an executive assistant who also held Helpdesk Administrator); initial compromise (when, from where, how); persistence (a stolen "Microsoft Outlook" refresh token replayed about three times a day from 88 residential-proxy addresses, 95 refreshes in four weeks); action on objective (two batches of roughly 100 recipients seven minutes apart, 202 unique recipients, 187 external, linking to a VBS downloader); secondary impact (an internal recipient ran the script three hours later; Defender Antivirus quarantined it); containment and overall status.
The executive summary retells it in plain language: what recipients saw, that the mail came from the real mailbox, that it was not a same-day event, which detection fired on day one and why nothing happened, and root cause in a sentence.
Scope, sources and method: what you looked at, and what you could not see
This section makes the report defensible. It names the accounts and window (one account, 30 days, the retention of the sources) and each source with a count: interactive (236 events) and non-interactive (1,530 rows) sign-in logs; the audit log (360 events) and roles; Identity Protection history; Defender XDR incidents, alerts and advanced hunting; message trace (675 rows) and forwarding configuration; and the help-desk ticket history.
Then the time zone and its pitfalls. The sample uses UTC with local time in parentheses; the portals displayed a third zone during collection, and the message-trace grid labeled one offset while its values ran an hour ahead of the Defender EmailEvents record. Name the authoritative source, or readers will argue over a ten-minute gap that was really seventy.
Finally, limitations. Mailbox-level events (MailItemsAccessed, Send) surfaced only sparsely, so what the attacker read cannot be enumerated; the report recommends a Purview Audit search on the attacker addresses. A limitation stated on page four is a finding; the same one found by an insurer is a problem. What could you prove if breached today? covers the retention decisions behind this section.
The narrative, the timeline and the root cause
The narrative is written in phases with subheadings:
- Precursors: 16 look-alike phishing domains in the contact cache and three self-service reset notifications in the prior 24 hours.
- Initial access: correct password; a user agent claiming mobile Safari while Entra recorded Windows 10; a push approved 21 seconds later; "MFA requirement satisfied by claim in the token". Identity Protection flagged it in real time; a High incident opened within the hour.
- The missed opportunity: about 90 minutes later the administrator dismissed the user risk, which had auto-remediated to Low because the user "passed" MFA. A stolen-token alert and a Graph search for payroll accounts followed; all stayed unassigned for 28 days.
- Persistence: 95 refreshes from 88 addresses, none repeating, each with a valid MFA claim. Stolen refresh tokens shows the log.
- Action on objective, day 28: Outlook on the web from a hosting provider on an unmanaged device, Token Protection Unbound, Continuous Access Evaluation No.
- Containment: sessions revoked about ten minutes after the first batch; the second had already left, and the web session survived the revocation.
- Secondary compromise: three hours later an internal recipient ran the VBS; Defender Antivirus quarantined it; the help-desk ticket closed as "run an antivirus scan".
The timeline is a table of time (UTC), event and source, with abbreviations defined once (SI, NI, AU, IDP, XDR, AH, MT) so anyone can re-pull a row.
Root cause is one paragraph and a control gap, not a person: push MFA was enforced, but nothing required it to be phishing-resistant or device-bound, so a relayed approval minted a long-lived session whose every later use carried an MFA claim. Contributing factors are bullets with evidence: alerts dismissed instead of remediated; no ticket for the AiTM detection because the risk state was already remediated; nobody watching non-interactive sign-ins; Helpdesk Administrator on a daily-use account. Why MFA is not enough anymore describes the path.
Impact, containment status, tiered recommendations and the appendices
Impact is written per asset, with assumptions stated where evidence ends: the mailbox (read access for 28 days, later reads not enumerable, so assume everything exposed); the directory (everyone matching the payroll, HR and finance search needs a warning about payroll diversion); third parties (187 external addresses received malware from a legitimate mailbox); the endpoint (not forensically reviewed).
Containment and recovery status is a table of action, status and evidence. Done rows cite the audit event: the revocation, the admin reset, 100 "Admin deleted security info" events and 27 Windows Hello for Business credentials removed. Verified rows say where: forwarding off, only benign inbox rules, no new consents. Not-done rows are the point: 13 copies not purged, endpoint not isolated, incidents not resolved, notification partial.
Recommendations come in three tiers, each item owned and dated. Immediate, the first 24 hours: isolate the laptop; purge the internal copies and block the URL; resolve both incidents as true positive and confirm the user compromised rather than dismissed; notify all 202 recipients from a different mailbox; remove Helpdesk Administrator from the daily account. Thirty days: phishing-resistant MFA through an authentication strength (our rollout order); Token Protection and strict Continuous Access Evaluation; compliant devices for Outlook; risk-based policies, which need Microsoft Entra ID P2 for the people in scope (the Plan Optimizer prices it); tickets for High incidents regardless of risk state; a detection for distinct addresses per user per day. Longer term: Privileged Identity Management, Audit (Premium) and longer retention.
Three appendices close it: A, indicators of compromise, defanged, noting that block-listing 88 single-use addresses is low value because the pattern is the indicator; B, every recipient with delivery status (withheld in the public sample); C, the user's legitimate networks and the three attributes every attacker sign-in shared: MFA by claim, an unmanaged device, an out-of-state location.
Frequently asked questions
Who writes it, the provider or the customer?
Whoever holds the logs and ticket history, usually the provider, with the customer supplying business context.
How soon after containment?
While retention still holds the evidence. The sample was written the day of the mailing, four weeks after the compromise; a week later, day one would have been gone.
Does it need the attacker's addresses and domains?
Yes, defanged, in an appendix; insurers, banks and peers who received the campaign will ask.
Can we share it with our insurer or bank?
Write it so you can: personal data goes in appendices that can be withheld, and the header states classification and distribution.
What if we do not have the logs?
Say so under limitations; it is a finding with its own recommendation. Defender XDR Incident Readiness and Risky Users and Risky Sign-ins Monitoring exist to shorten that section next time.
Sources
- IT Partner: the redacted sample report (PDF), /samples/ITPWW540SECOT/post-incident-report-sample-bec-aitm.pdf
- IT Partner blog, content/blog/new/: if-your-microsoft-365-tenant-got-breached-today-what-evidence-would-you-have, why-mfa-is-not-enough-anymore-based-on-real-attack-paths, passkeys-phishing-resistant-mfa-microsoft-365-rollout-order, entra-id-p1-vs-p2-conditional-access-pim-identity-protection-compliance
- IT Partner service pages, content/services/: ITPWW220MSPOT, ITPWW330SECOT, ITPWW520SECOT, ITPWW060SECOT, ITPWW305IMPOT
- IT Partner subscription page: content/subscriptions/CFQ7TTC0LFK5__Commercial.json (Entra ID P2)
- IT Partner engineering notes, September 2026
- Microsoft product behavior as observed in the sample case; verify on Microsoft Learn.
| Question the report must answer | Where | Evidence to cite |
|---|---|---|
| How and when did they get in? | Narrative, timeline | Interactive sign-in log |
| Did MFA fail, or was it satisfied through the attacker? | Root cause | Authentication details: MFA by claim in the token |
| How long, and from where? | At a glance, persistence | Non-interactive log by app, IP and day |
| What did they read, search or export? | Impact, limitations | Mailbox audit events, or a stated limitation |
| What did they send, to whom, and who clicked? | Action on objective, Appendix B | Message trace, EmailEvents, UrlClickEvents |
| What fired, and what happened to it? | Timeline, contributing factors | Identity Protection history, incident status, tickets |
| What is done, what is open, with proof? | Status table | One audit event per row |
| What would have stopped it, and who fixes it by when? | Recommendations | Tiered list, owner and date |
| What could you not see, and why? | Scope and method | Retention windows, audit tier |
Key takeaways
- A post-incident report records evidence with times and sources before retention deletes it, separates done from open, and states root cause as a control gap.
- Page one is the incident at a glance and an executive summary; then narrative, timeline, root cause, impact, status and recommendations.
- State scope, sources with counts, the time zone and the limitations; a 30-day retention window is itself a finding.
- Contained is not closed: the sample account was handled within two hours while two incidents, 13 internal copies, an infected laptop and 187 recipients were still open.
- Recommendations come in immediate, 30-day and longer-term tiers with an owner and a date each; the report is versioned until the open list is empty.
If an account has been taken over, Business Email Compromise Investigation and Recovery contains the attacker, builds the timeline from the Entra and Purview logs and hunts persistence, from $4,950 and scoped by incident; for a suspected incident that needs a documented investigation, Security Managed Service: Incident Response is a $700 fixed-price, one-week engagement. Before either is needed, the Microsoft 365 Security Assessment, at no charge to clients, shows where the same gaps sit in your tenant.
Questions this article didn’t answer?
Thirty minutes with Mike — our CEO, not a sales rep. Bring the hard version of the question.