Home › Blog › Root-cause investigation
Security · 24 October 2026 · 16 min read
The password was reset, the sessions were revoked, the user was told to be more careful, and the ticket was closed. Six weeks later a client calls about an invoice that was paid to the wrong account. What was missing in between is the investigation: the work that says how the attacker got in, what they read, what they left behind, who else was affected, and which setting now stops it happening again. This article is that work, step by step, with the Microsoft 365 logs each step reads.
Fourth and last in a series on how business email fraud works and what stops it. Earlier: how a mailbox is taken over with MFA on, invoice fraud through a hijacked thread, lookalike domains and spoofing, DMARC and Direct Send. No single company is described here.
Containment and investigation are different jobs. Containment is fast and mechanical: revoke the sessions, reset the password, remove and re-register the authenticators, block sign-in, find the inbox rules. It takes an hour and it stops the bleeding. The investigation is what comes next, and it is the part most often skipped, because it takes days, needs logs that may already be ageing out, and produces a document rather than a feeling of relief.
The cost of skipping it is paid later, by someone else. Without it there is no way to tell a client that their data was not touched, no way to know whether the attacker still has a way back in, no evidence for the insurer, no defensible decision on breach notification, and no reason to believe the same thing will not happen next month. “Root cause” is a short phrase for a long list of questions. Here they are, with where each answer lives.
Before the method, a frank observation from our own work. The most common response to a mailbox compromise is not a bad investigation; it is no investigation. The password is changed, the user says it will not happen again, and the company goes back to work. We see it in businesses of every size, and the reasons are always the same:
What that decision costs arrives later, in one of three forms. The attacker still has a way in: an authenticator they registered, a rule they left, an application they consented to, none of which a password reset touches, so the second compromise of the same account is quieter than the first. Or the damage was done during the first and surfaces weeks afterwards, as a client’s diverted payment or a supplier’s unpaid invoice, by which time the sign-in logs that would have explained it have aged out. Or the question is finally asked by someone with the power to insist on an answer, an insurer assessing a claim or a client’s data-protection officer, and the honest reply is that nobody looked.
The investigation below is cheaper than any of those. Most of it is reading logs the tenant already keeps.
Each is answered from a different log. Work in the order above, and write everything down in one time zone as you go; the timeline is the product.
The evidence sources, what each answers, and how long it lasts
| Source | Answers | Kept for |
|---|---|---|
| Entra sign-in logs interactive and non-interactive | Every authentication: time, address, network operator, country, client application, device, Conditional Access result, session identifier. The entry point and every return visit. | 7 days without Entra ID P1; 30 days with it (Business Premium, Microsoft 365 E3 and above) |
| Entra audit logs | Changes to the account itself: security-information registration, new devices, application consents, group and role changes. | 7 or 30 days, as above |
| Entra ID Protection | Risk detections already computed for you: anonymous address, unfamiliar sign-in properties, impossible travel, leaked credentials, token anomalies. | Entra ID P2 |
| Purview audit log | What the account did in Exchange, SharePoint, OneDrive and Teams: items accessed, searches, inbox rules, forwarding, delegates, files downloaded and shared, admin changes. | 180 days on Audit Standard; one year on Audit Premium, extendable |
| Message trace | Every message sent and received, with the real sending address, recipients and delivery result. | 90 days, every plan |
| Defender for Office 365 | The lure: where the phishing message came from, who else received it, who clicked. Threat Explorer and alerts. | 30 days in Explorer (Defender for Office 365 Plan 2); Real-time detections in Defender for Office 365 Plan 1 |
| The endpoint | Whether the credential or token was stolen from the device rather than through a phishing page: the device timeline in Defender for Business or Defender for Endpoint. | 30 days to six months by plan |
| The mailbox itself | Inbox rules, including hidden ones; sent items and deleted items; the Junk and RSS Feeds folders where rules hide replies. | Until someone changes it |
Two things to do on day one, before anything else: export the sign-in logs, which are the shortest-lived, and raise audit retention on the affected accounts (see licensing, below) so the next six months are kept at the higher tier. A policy created today keeps records from today; it does not recover what has already gone.
Start in the sign-in logs, filtered to the user, and read backwards from containment until the pattern breaks. What you are looking for:
Then the Entra audit log, same window: User registered security info is the attacker adding their own authenticator; Consent to application is a token that survives every password reset. If Entra ID P2 is licensed, the risk detections page has usually flagged the sign-in already, with the reason.
The technique follows from the pattern: a relayed session means an adversary-in-the-middle phishing page, and the lure is in Threat Explorer or message trace in the hours before the first anomalous sign-in; a valid password from a new device with a normal MFA prompt means the password was already known (an infostealer on the device, or reuse from a breach elsewhere); a non-interactive sign-in with no preceding interactive one means a token taken from the device. Each points at a different control.
This is the Purview audit log, searched by the user and the attacker’s addresses for the window from first entry to containment. Since Microsoft’s 2023 and 2024 logging changes these records exist on Audit Standard, not only Premium, which has changed what a small business can find out. The operations that matter:
Audit operations to search, by question
| Question | Operations | What they tell you |
|---|---|---|
| What was read | MailItemsAccessed | Which messages were opened or synchronised, in which folders, from which address. With a sync operation the attacker took a whole folder. This is the record that lets you tell a specific client whether their thread was touched. |
| What was searched for | SearchQueryInitiated | The search terms: “invoice”, “IBAN”, “payment”, a client’s name. It is the clearest statement of intent in the whole log. Note that for Exchange this event must be switched on per mailbox beforehand; it is not recorded by default. |
| What was sent | Send, SendAs, SendOnBehalf | Every message the attacker sent from the account, matched to message trace for the recipients. Includes messages they then deleted from Sent Items. |
| What was deleted | MoveToDeletedItems, SoftDelete, HardDelete | Their own sent copies, the client’s replies, the real supplier’s chasers. Recoverable from the mailbox for a time; recorded here regardless. |
| Which files | FileAccessed, FileDownloaded, FileSyncDownloadedFull | OneDrive and SharePoint. A full sync download of a document library is exfiltration, whatever the attacker intended to do with it. |
| What was shared | SharingSet, AnonymousLinkCreated, AddedToSecureLink | Links that still work after the password reset. |
The Purview search exports to CSV; a day of attacker activity is a few thousand rows, and it is worth putting them in a spreadsheet sorted by time and address rather than reading them in the portal.
A password reset closes the door the attacker came in by. It does not remove the keys they cut while inside. Each of the following survives a reset and must be found and removed individually:
New-InboxRule, Set-InboxRule and UpdateInboxRules in the audit log; also check the mailbox directly with PowerShell, because rules created from Outlook desktop can be hidden from the user’s own view. Look for rules that move mail to RSS Feeds, Archive or Conversation History, that delete, or that mark as read, especially on keywords.Set-Mailbox with a forwarding address, and rules that forward or redirect. Then the outbound spam policy, to confirm external auto-forwarding is now off tenant-wide.Add-MailboxPermission, Add-RecipientPermission, Add-MailboxFolderPermission. A delegate on the Inbox is a second way to read it.One compromised account is rarely the only target. Search the whole tenant’s sign-in logs for the attacker’s addresses and operators; search message trace for the lure’s subject and sender, to find everyone who received it and anyone who replied; and search for the attacker’s own sending addresses and any lookalike domain in both directions. Then the people in the mailbox: every client and supplier whose thread was accessed is on the list for a phone call, and the ones who replied to attacker-sent mail are at the top of it.
If the lure came from a partner’s genuine mailbox, that partner is compromised and usually does not know. Tell them.
At the end of questions 1 to 4 you should be able to write a sentence of this shape: “On [date] the user entered credentials and approved an MFA prompt on a phishing page reached from [lure]; the session token was replayed from [operator] at [time]; access continued for [n] days through [method of persistence]; it was possible because [the control that was absent].” The last clause is the root cause. In our experience it is one of a short list:
“The user clicked a link” is not a root cause. Users will click links; the question is why clicking one was enough.
An incident is closed when the control that would have prevented it is on, tested and evidenced, not when the ticket is. For each item the closure record should hold the setting, the date, who checked it and what the check showed. The usual list after a mailbox compromise:
Closure checklist, with the evidence for each item
| Control | Evidence that it is on |
|---|---|
| Sessions revoked, password reset out of band, MFA re-registered from scratch | Entra audit entries for each; the user’s method list shows only methods they recognise. |
| Persistence removed | The inbox-rule, forwarding, delegate, consent and device lists for the account, exported and empty of anything from the window. |
| Conditional Access requires a compliant or joined device for mail and files | The policy in report-only mode for a week, then enforced; the sign-in log shows it applied; a test from an unmanaged browser is refused. |
| MFA registration protected; phishing-resistant methods for finance and admins | The registration policy applied; authentication-strength policy for the named groups; a test registration from outside is refused. |
| Legacy authentication blocked | The policy enforced; the sign-in log shows zero legacy authentications in the following thirty days. |
| External auto-forwarding off; user consent to applications restricted | The outbound spam policy and the consent settings, exported. |
| Alerts routed to a person | New inbox rule, new MFA method, risky sign-in, unusual sending volume: each alert tested once and the test recorded. |
| Audit retention raised on the accounts that matter | Licences assigned; the retention policy created and dated. |
| Finance verification rule in writing | The one-page policy, signed by the finance lead, and the number-on-file list it depends on. |
| Affected parties notified; breach assessment documented | The call list with dates; the assessment and the decision, either way, with the reasoning. |
Each row is a thing a client, an insurer or a regulator can be shown. “We have improved our security” is not.
The investigation above depends on evidence that was being kept before anyone knew there was a problem. Three licence questions decide how much of it exists.
None of this can be bought afterwards for the incident that has already happened. All of it is cheap against the week described above.
The output is a written report, and its shape is always the same: a timeline in one time zone from lure to containment; the scope (accounts, mailboxes, files, external parties); what was accessed, with the operations as evidence; what was sent and to whom; what persistence was found and removed; the root-cause sentence; the controls now in place, with the evidence table; the breach assessment and the decision; and the residual risk, which is the honest list of what could not be established because a log had already aged out. Clients, insurers and supervisory authorities all ask for the same document, and a company that has it is treated very differently from one that has a closed ticket.
A compromise that ends with a password reset has not ended. The investigation is five questions, answered from logs that most Microsoft 365 tenants already have for 180 days, and it finishes with a sentence that names the missing control and a checklist that proves the control is now on. That is what “root cause” and “confirmed controls” mean, and a partner who cannot produce both after an incident has not finished the job.
This investigation, the containment that precedes it, the hardening that follows in report-only mode first, and the report at the end, are our incident response and hardening service. If the incident is live, call the number in the header. If it was six weeks ago and the ticket was closed, it is not too late to do the work while the logs still exist: contact us for an initial incident assessment and response estimate.
Yes, and that is the most common moment to skip it. The quiet phase of a compromise is designed to look like nothing happened. The questions are whether the attacker left a way back in, what they read, and which control was missing; none of those is answered by the absence of a complaint. The logs that answer them age out, so the cost of looking only goes up.
Contained, not over. A registered authenticator, an inbox rule, a delegate, an application consent or a sharing link all survive a reset, and nothing yet says how the attacker got in or what they read. The investigation answers those; without it the same thing happens again.
Usually, yes. The MailItemsAccessed operation in the Purview audit log records which messages were opened or synchronised, from which address, and is kept for 180 days on Audit Standard in every plan and a year on Audit Premium. It is what lets you tell a specific client whether their thread was touched.
Not for the audit log, which keeps 180 days, or message trace, which keeps 90. The sign-in logs are the problem: seven days without Entra ID P1, thirty with it. Start now, export everything, and raise audit retention on the affected accounts so the next six months are kept at the higher tier.
That is what the breach assessment decides, with your adviser. Under GDPR a notifiable personal-data breach is reported within 72 hours of becoming aware; the evidence of what was accessed is what makes that decision defensible either way. Clients whose threads were accessed, and anyone who replied to attacker-sent mail, should hear from you by phone regardless.
A written report: the timeline, the scope, what was accessed with the audit evidence, what was sent, what persistence was found and removed, the root cause in one sentence, the controls now on with evidence for each, the breach decision, and what could not be established. If what you received was a closed ticket, the investigation has not been done.