Microsoft 365 Post-Incident Investigation and Report
When a Microsoft 365 account has been taken over — a phishing page that relayed the sign-in and captured the session, a stolen refresh token replayed for weeks from addresses nobody was watching, a mailbox used to send a few hundred phishing messages to your own customers and vendors — the password reset is the easy part. The hard part is the written account: what the attacker did, from which day, with which token, what they read and sent, whether the containment actually closed the door, and what has to change so it does not happen again. IT Partner reconstructs one incident from the tenant's own records — Microsoft Entra ID interactive and non-interactive sign-in logs and audit logs, Microsoft Entra ID Protection detections and risk history, Microsoft Defender XDR incidents, alerts and advanced hunting, Exchange Online message trace and mailbox configuration (inbox rules, forwarding, delegates, application consents), Intune and Defender device records where an endpoint is involved, and your own help-desk history — and delivers a post-incident report that your leadership, your cyber-insurance carrier and your auditor can read: incident at a glance, executive summary, scope, sources, method and limitations, attack narrative, a detailed timeline with a source for every entry, root cause and contributing factors, impact assessment, a containment and recovery status table with evidence, recommendations in immediate, 30-day and longer-term tiers, and appendices listing indicators of compromise, the recipients and blast radius of anything sent from the mailbox, and the user's legitimate baseline. We verify containment as part of the work — sessions revoked, password reset, MFA re-registered, inbox rules, forwarding and consents clean — and hand you the list of what is still open. The standard scope is one incident in one Microsoft 365 tenant of up to 500 users, covering up to three affected user accounts and one endpoint, for $1,950 per project, fixed, normally delivered within one week; larger or multi-tenant incidents are quoted in writing. The deliverable is the report: live containment, remediation and hardening are separate work, and Microsoft's metered charges — Microsoft Sentinel ingestion, Microsoft Purview Audit (Premium), Azure consumption — stay on your Microsoft bill, never inside our fee.
What this engagement is
An account takeover in Microsoft 365 is rarely a same-day event. In the redacted sample report on this page, the account was compromised through an adversary-in-the-middle phishing proxy on a Tuesday afternoon — the user typed a correct password and approved a genuine Authenticator push, and the proxy kept the session. Microsoft Entra ID Protection flagged the sign-in in real time and Microsoft Defender XDR opened a High-severity incident within the hour, but because the sign-in had 'passed' MFA the risk auto-remediated and was then dismissed. From that evening the attacker refreshed a stolen Outlook token about three times a day from a rotating pool of 88 residential IP addresses, one use each, for four weeks — 95 successful refreshes, zero new detections, and a directory search for payroll, HR and finance staff along the way. Then, one morning, an Outlook on the web session from a hosting provider harvested the contacts and sent two batches of a malware link to roughly 200 recipients. The admin revoked sessions ten minutes after the first batch; the second batch had already left. That is what the logs hold when somebody takes the time to read all of them together, and it is the story the password reset never tells. This engagement reads all of them together. The Entra ID interactive sign-in log shows the phishing proxy (a user agent claiming one platform while the operating system field records another, MFA 'satisfied by claim in the token' from a location the user has never used). The non-interactive sign-in log — the one most administrators never open — shows the token replay: the application ID that obtained the token, the resource it was redeemed for, and every IP address it came from. The Entra audit log shows what was changed and by whom: session revocations, password resets, security-info deletions, role assignments, risk dismissals. Entra ID Protection shows what was detected and how it was handled. Defender XDR incidents and advanced hunting supply the alert evidence, the Graph reconnaissance calls, mailbox and attachment access events, the Safe Links click and, where an endpoint is involved, the file written, the process launched and the antivirus verdict. Exchange Online message trace shows every message the mailbox sent, to whom, and whether it was delivered; the mailbox configuration shows whether rules, forwarding, delegates or consents were left behind. Your help-desk history shows who noticed what, when, and what was done about it. We build the user's legitimate baseline first — the office and home networks, the mobile carrier ranges, the registered devices, the normal client mix — so that every attacker sign-in is distinguished from the user's own by evidence rather than by suspicion. The output is a report written for two audiences at once. The executive summary and the 'incident at a glance' table are for the people who have to decide about notification, insurance and budget, and they say plainly what is proven and what must be assumed. The attack narrative, the sourced timeline, the root cause and contributing factors, the impact assessment and the containment and recovery status table are for the people who have to act, and every row cites the log it came from so a second reader can check it. The recommendations are tiered — what to do today, what to do in the next 30 days, what to plan — and each one is mapped to the factor that let this incident happen, not copied from a generic checklist: a phishing-resistant sign-in requirement where a proxied push was enough, token protection and continuous access evaluation where a revocation did not reach an open session, a detection for the token-refresh pattern that nobody was looking at, the removal of an administrator role from a day-to-day account, an outbound recipient limit where two hundred messages left in seven minutes. The appendices carry the indicators of compromise, the recipient list and its domain concentration, and the baseline, so that your team, your carrier or a forensics firm can pick the work up where we leave it. The tiered recommendations are the natural input to Trusted Device and Phishing-Resistant Access and Microsoft Entra PIM and Privileged Access Hardening, and to the rollout order we describe in our article on passkeys and phishing-resistant MFA in Microsoft 365. Who this is for: an organization whose IT team, or whose managed service provider, has already contained a Microsoft 365 account compromise — or believes it has — and now needs the written account for leadership, a cyber-insurance claim, an auditor, a customer who received the phishing message, or simply for the internal retrospective, because the incident is closed in the portal but the questions are not. It is also for the case where an incident was closed weeks ago and something still does not add up. Who it is not for: an attacker who is still inside — that needs containment first, which is Business Email Compromise Investigation and Recovery, from $4,950 and scoped per incident; ransomware or endpoint malware beyond the one device this scope allows; and litigation-driven forensics, where imaging and chain of custody belong to a forensics firm engaged through counsel. Our Security Managed Service: Incident Response, at $700, is the general infrastructure investigation — servers, workstations, network hardware, a crypto miner, malware on the company website — and its report is written at that level; this page is the Microsoft 365 identity-and-mail reconstruction, with the formal report structure shown in the sample. If you want to know in advance what your tenant could prove, our article on what a Microsoft 365 breach investigation can and cannot show walks through the same sources. The fee is $1,950 per project, fixed and quoted in writing before work begins, for one incident in one tenant of up to 500 users, covering up to three affected user accounts and one endpoint. If the reconstruction shows more accounts were touched, we tell you on the day we find it and quote the extension before continuing; a multi-tenant incident is quoted in writing from the start. You pay after you approve delivery.
Success criteria
What you receive
How the work unfolds
A 30-minute intake call: what was noticed, when, by whom; which accounts; what has already been done to them; whether money, data or customers are involved. We take the read-only, time-bound delegated access you approve and immediately export the sources that age out first — Entra sign-in logs are held for 30 days on Microsoft Entra ID P1 or P2 and Defender XDR advanced hunting for 30 days at the time of writing — so nothing the report needs is lost while the rest is collected.
Entra interactive and non-interactive sign-in logs, audit logs, directory role assignments and Identity Protection risk history for the accounts in scope; Defender XDR incidents, alerts and advanced hunting across the cloud-app, email, URL-click, alert and device tables; Exchange Online message trace for the mailbox, its rules, forwarding, delegates and consented applications; Intune and Defender records for the endpoint in scope; and your help-desk history. Where a second source can confirm a timestamp, we collect both.
We build the user's legitimate baseline first, then work through the record chronologically: initial access, the token that gave persistence, every replay and where it came from, reconnaissance, what was read, sent or changed, how it was detected, and what containment did and did not reach. Every event goes into the timeline with its source. If the evidence shows more accounts were touched than the scope covers, you hear about it the same day, with a written quote for the extension before we go further.
Each containment control is checked in the logs and the current configuration and marked Done, Partial or Not done with its evidence; the open items are listed with suggested owners. The impact assessment is written by category, stating what the events prove and what must be assumed where the events were not captured, and Appendix B is assembled from the message trace so the notification decision has a real list behind it.
The report is delivered as a PDF and walked through in a readout of up to 60 minutes with your IT lead and decision-makers: the narrative, the root cause, the open items and the tiered recommendations. One round of corrections and clarifications follows, the final PDF goes to a named recipient, and our delegated access is removed and confirmed.
Prerequisites
Who does what
IT Partner
- Run the intake, confirm the accounts and endpoint in scope against the standard cap, and take only the read-only delegated access the work needs.
- Preserve the time-limited sources first, then collect every source listed in the plan for the accounts in scope, with a second source for each key timestamp where one exists.
- Build the user's legitimate baseline and separate attacker activity from the user's own by documented criteria, stating the confidence of each attribution.
- Reconstruct the incident chronologically into a sourced timeline: initial access, persistence, reconnaissance, action on objective, detection, containment.
- Verify each containment control in the logs and the configuration, mark its status with evidence, and report any open gap to you on the day it is found.
- Write the impact assessment by category, separating what is proven from what must be assumed, and assemble the recipient and blast-radius appendix from the message trace.
- Write root cause, contributing factors and the tiered recommendations, each recommendation mapped to the factor it addresses.
- Deliver the report as a PDF, run the readout, apply one round of revisions, hand over the evidence set, and remove our access.
Your team
- Approve the read-only delegated access on day one and name a technical contact who can answer access questions during the week.
- Disclose everything known about the incident, including any cleanup already performed, any prior compromises and any work done by another provider.
- Make the affected users available for a short interview and confirm the baseline the report will rest on.
- Own every action on the open-items list: unresolved Defender incidents, purging phishing copies, isolating an endpoint, blocking indicators, and any containment gap we report.
- Decide and execute notifications — recipients of attacker mail, customers, vendors, your bank, your cyber-insurance carrier, counsel, regulators — using the recipient list and the factual record we provide; those decisions and the legal determinations behind them are yours and your counsel's.
- Review the report at the readout, provide the one round of corrections, and approve the final deliverable against the success criteria.
What's not included
Limitations & technical notes
Frequently asked questions
What is the Microsoft 365 Post-Incident Investigation and Report, and when do we need it?
It is a fixed-price, one-week, read-only reconstruction of one Microsoft 365 incident — an account takeover, business email compromise, adversary-in-the-middle phishing, token theft, mailbox abuse or a phishing campaign sent from one of your mailboxes — from the tenant's own Entra ID, Identity Protection, Defender XDR, Exchange Online, Intune and help-desk records, delivered as a written post-incident report with a sourced timeline, root cause, impact, containment status and tiered recommendations. You need it when the account has been contained but nobody can yet say, in writing, what actually happened: for leadership, for a cyber-insurance claim, for an auditor, for the customers who received the phishing message, or for the retrospective that decides what changes. If the attacker may still be inside, start with Business Email Compromise Investigation and Recovery instead; this report can follow it.
We already reset the password and the incident shows as resolved in the Defender portal. Why would we still need a report?
Because the reset tells you almost nothing about the four weeks before it. In the sample report on this page the account was compromised on a Tuesday, Identity Protection and Defender XDR both flagged it that day, the risk was dismissed, and the attacker then refreshed a stolen Outlook token about three times a day from 88 different residential IP addresses for four weeks before sending anything. Sessions were revoked ten minutes after the first phishing batch — the second batch had already left three minutes before that, and without token protection or continuous access evaluation the open Outlook on the web session could have kept working for up to an hour after the revocation. What the attacker read, whom they searched the directory for, which recipients got the message, whether the MFA methods were re-registered and whether the Defender incidents were ever actually resolved are all questions the reset does not answer. The report does, with a source for each answer.
Which sources do you use, and what does each one tell you?
Entra ID interactive sign-in logs show the initial access: the phishing proxy's IP address, a user agent that does not match the recorded operating system, MFA satisfied by a claim in the token rather than a fresh Authenticator interaction. The non-interactive sign-in log shows token replay — the application that obtained the token, the resource it was redeemed for, and every address it came from. The Entra audit log shows changes: revocations, resets, security-info deletions, role assignments, risk dismissals. Identity Protection shows the detections and how they were handled. Defender XDR incidents, alerts and advanced hunting supply the Graph reconnaissance calls, mailbox and attachment access events, Safe Links clicks, and for an endpoint the file written, the process launched and the antivirus verdict. Exchange Online message trace shows every message sent, to whom and whether it was delivered; the mailbox configuration shows rules, forwarding, delegates and consents. Intune supplies the device's compliance and enrolment state. Your help-desk history shows who noticed what and when. The report's scope section lists which of these were available in your tenant and for how many days.
Can you tell us exactly which emails the attacker read?
Sometimes fully, sometimes partly, and the report never pretends otherwise. Where the MailItemsAccessed, Send and SearchQueryInitiated audit events exist for the mailbox — Microsoft extended them to Purview Audit (Standard) during 2024, but their presence depends on licensing and mailbox-auditing configuration at the time — we list what was read, searched and sent. Where they are sparse, the impact assessment states the period of access and says 'assume exposed' for mail, calendar and contacts in that period, and the recommendations include the Purview audit search that would complete the picture. In the sample report that is exactly what happened: mailbox and attachment access on the first day was logged, the following weeks were not enumerable from the sources used, and the report says so.
How do you tell the attacker's activity apart from the user's own?
By building the user's legitimate baseline first — the office and home networks, the mobile carrier ranges, the registered devices, the clients they normally use — and then testing every sign-in against it with documented criteria: was MFA satisfied by a real Authenticator interaction or by a claim carried in a replayed token, was the device managed and compliant, was the location one the user has ever used, was the application one the user has ever used. In the sample, every attacker sign-in met three of those tests at once and none of the user's did. Appendix C of the report prints the baseline and the criteria so the separation can be checked, and every attribution in the timeline carries a confidence level.
How far back can the investigation go?
As far as the tenant's records reach. At the time of writing, Microsoft holds Entra sign-in and audit logs for 30 days with Microsoft Entra ID P1 or P2 (7 days without), Purview Audit (Standard) records for 180 days, Defender XDR incidents and alerts for 180 days but advanced hunting data for 30 days unless streamed to Microsoft Sentinel, and Exchange Online message trace for 90 days through historical search. That is why day one of the engagement is spent exporting the sources that age out first. An incident older than 30 days can still be reconstructed from the audit log, message trace and Defender incident record, and the report states precisely where each source's window closes and what that means for the findings.
What does the report actually contain?
The redacted sample on this page is the answer: a one-page 'incident at a glance' table; an executive summary; scope, sources and method with the limitations of the data; the attack narrative in stages (precursors, initial access, reconnaissance, persistence, action on objective, detection and containment, secondary compromise); a detailed timeline with a source abbreviation on every row; root cause and contributing factors; impact assessment by category; a containment and recovery status table with the evidence for each row; recommendations in immediate, 30-day and longer-term tiers; and three appendices — indicators of compromise, recipients and blast radius, and the user's legitimate baseline. Sixteen pages for the sample incident; yours will be as long as the evidence requires.
Do you fix anything while you are in the tenant?
No, and that is deliberate. The engagement is read-only through delegated access you approve; we revoke, reset, delete and block nothing, which is what keeps the evidence intact and the scope fixed. What we do is verify each containment control against the logs and the configuration and mark it Done, Partial or Not done with evidence — and if we find that the attacker still has a way in, you hear it the same day, so your team or a separately scoped containment engagement can act. Implementing the recommendations is separate work, and the report names the service or the internal task for each one.
How is this different from your $700 Security Managed Service: Incident Response?
That service investigates a general information-security incident — unauthorized employee access, a disclosure, viral activity, a suspected crypto miner, spam from employee accounts, malware on the company website — across servers, workstations and network hardware, and delivers a report with findings and recommendations at that level. This service is narrower and deeper: it is the Microsoft 365 identity-and-mail reconstruction, working through the Entra sign-in and audit logs, Identity Protection, Defender XDR advanced hunting, message trace and mailbox configuration, with the formal report structure shown in the sample — sourced timeline, root cause, containment verification with evidence, blast-radius appendix. If the incident lives in the tenant, this is the page; if it lives on a server or a website, that one is.
What does the $1,950 cover, and what changes the price?
The standard scope: one incident in one Microsoft 365 tenant of up to 500 users, covering up to three affected user accounts and one endpoint, including collection, reconstruction, containment verification, the report with all appendices, the evidence set, the readout and one revision, normally within a week of access. The price is quoted fixed in writing before work begins, and you pay after you approve delivery. What changes it: more affected accounts than the scope covers (we tell you the day we find them and quote the extension before continuing), several tenants, or an endpoint investigation that needs to go beyond the Defender and Intune records — each is a written, approved quote, never a surprise on the invoice.
Will our cyber-insurance carrier or auditor accept the report?
It is written with them in mind — a sourced timeline, a documented method with its limitations, an impact assessment that separates the proven from the assumed, and a containment record with evidence — and the evidence set is handed over so the findings can be re-run. What we cannot do is speak for a carrier or an auditor: some policies require a carrier-approved response panel, and some audit programmes require a certified forensic examination with chain of custody, which this is not. If your policy names a panel, engage the carrier first; our report can be handed to whoever they appoint, and it is often what makes their work faster.
Do we need Microsoft 365 E5, Sentinel or Purview Audit (Premium) for this to work?
No. Business Premium, E3 and E5 tenants all hold the interactive and non-interactive sign-in logs, the audit log, the message trace and the mailbox configuration the reconstruction rests on. What the higher tiers add is depth and reach: Microsoft Entra ID P2 gives the Identity Protection risk history and detections, Defender for Office 365 Plan 2 adds Threat Explorer and the email tables in advanced hunting, Defender for Business or Defender for Endpoint supply the device record, and Purview Audit (Premium) or Sentinel extend how far back the record reaches. The report's scope section states which sources your licensing provided; where a source was missing, the recommendations say what would have closed the gap, and any licence you then choose to add is billed by Microsoft or your CSP, not inside this fee.
What access do you need, and is it safe to grant during an incident?
Read-only, time-bound delegated access that you approve — at the time of writing Global Reader plus Security Reader cover the sign-in and audit logs, Identity Protection, the Defender portal, message trace, mailbox settings and Intune device records, and the exact roles are named in the quote. We never ask for Global Administrator for this engagement, we change nothing, and the access is removed and confirmed at the end of the readout. If you prefer, a named administrator of yours can run the exports alongside us instead.
How long does it take, and can it go faster?
Normally one week from the day access is approved: intake and preservation on day one, collection through day two, reconstruction through day four, containment verification and impact on day four, report and readout on day five. The pacing is set by the evidence and by the users' availability for their short interviews more than by our effort. Our published support commitment is first response within one business hour, so the intake call happens quickly; if you need the report sooner because a notification deadline or a carrier is waiting, say so at intake and we tell you honestly what can be compressed.
What happens after the readout?
You leave with the final PDF, the evidence set and an open-items list your team can start on immediately — unresolved Defender incidents to classify, phishing copies to purge, an endpoint to isolate, indicators to block, recipients to notify. The tiered recommendations each name the service or internal task that implements them: phishing-resistant authentication and device-bound access, a Conditional Access review, MFA coverage, privileged-role cleanup, detection tuning in Defender XDR, and the recurring risky-user review that is free for organizations buying their Microsoft licensing through us. Our article on why MFA alone is no longer enough, based on real Microsoft 365 attack paths explains the reasoning behind the first two of those, and none of them is a condition of this engagement.