> For the complete documentation index, see [llms.txt](https://www.iblue.team/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.iblue.team/general-notes-1/independent-investigations-bec.md).

# Independent Investigations - BEC

Business Email Compromise is usually discovered by the MSP or MSSP responsible for the mailbox that was compromised. It's then, routinely, investigated by that same MSP or MSSP. The analyst who missed the malicious inbox rule, or didn't catch the failed MFA alert, is often the same person writing the report on what happened.

I've written this article to set out why that arrangement is a problem on its own terms, separate from how good the analyst is, what fit-for-purpose acquisition and eDiscovery tooling actually looks like in a BEC matter, and the chain of custody, integrity, reporting, and display practices that separate a defensible investigation from an internal job ticket.

**TL;DR - get an independent investigator involved in any BEC matter with financial loss, notification obligations, cyber insurance involvement, or a realistic chance of litigation. The MSP/MSSP still has a role. It's preservation and triage, not the investigation itself.**

#### The conflict of interest is structural, not personal

This isn't a competence argument. Most MSP/MSSP staff doing this work are capable. The problem is who they're investigating and who they answer to.

<table><thead><tr><th width="209">Issue</th><th>Why it matters</th></tr></thead><tbody><tr><td>Self-preservation bias</td><td>A finding that the SIEM/EDR/tool should have caught this, or that a client's conditional access policy wasn't configured the way it was supposed to be, is a finding against the investigator's own employer.</td></tr><tr><td>Report audience</td><td>An MSP incident summary is written for the client relationship and the ticket queue. Not for a court, an insurer, or a regulator.</td></tr><tr><td>Independence</td><td>An expert report carries weight partly because the author has no stake in the outcome. An MSP reporting on its own environment can't say that.</td></tr><tr><td>Incentive to close, not preserve</td><td>MSPs are measured on ticket resolution. An investigation that needs things preserved, hashed, and held pending legal review runs against that incentive by design.</td></tr></tbody></table>

None of this means the MSP/MSSP necessarily did something wrong at the point of compromise. It means they're the wrong party to be the sole source of truth about what happened afterwards.

#### Acquisition: fit-for-purpose tooling vs ad hoc pulls

BEC evidence lives in the mailbox, the identity provider, and the unified audit log. How it gets pulled out is what determines whether it holds up later. Brief summary of sources based on a typical Microsoft/Office 365 BEC incident.

<table><thead><tr><th width="206">Source</th><th>Independent investigator / eDiscovery platform</th><th>Typical MSP/MSSP self-investigation</th></tr></thead><tbody><tr><td>Mailbox content</td><td>Content Search or eDiscovery (Premium) export to PST/native .msg, or Graph API export preserving headers and metadata</td><td>Analyst logs into OWA, reads the email, screenshots the rule or the message</td></tr><tr><td>Unified Audit Log</td><td>Search-UnifiedAuditLog / Graph API pull, exported in full with the query parameters recorded</td><td>Portal search, filtered view, copy-pasted into the ticket</td></tr><tr><td>Sign-in / identity logs</td><td>Entra ID sign-in and audit logs exported via API, ahead of retention expiry</td><td>Reviewed once in the portal and not exported at all</td></tr><tr><td>Inbox rules / forwarding</td><td>Rule XML captured via Get-InboxRule / mailbox forwarding properties, before removal</td><td>Rule deleted as part of "remediation" before anyone documents it</td></tr></tbody></table>

The last row does the most damage. Removing a malicious inbox rule is correct containment. Removing it without capturing it first is the most common way BEC evidence gets destroyed, and it's usually the team doing the "investigation" that destroys it.

#### Chain of custody applies to mailbox access, not just devices

There's no device to seize in most BEC matters. Chain of custody still applies, it just applies to who touched the mailbox, the tenant, and the logs.

* Record every account used to query the mailbox or tenant, and what privilege level it held.
* Record the actual query or search run, UAL parameters, Content Search syntax, time range, not just the result it produced.
* Log access to the compromised mailbox itself. Logging in to "have a look" generates new MailItemsAccessed events that then sit inside the evidence you're reviewing, and can quietly overwrite read/unread state that mattered.
* Hash exports at the point of collection, PST, CSV, Graph API JSON output, and record the hash in the report.

An independent investigator working off a compliance search or eDiscovery hold is reading a preserved copy. An analyst logged into the live mailbox is altering the thing they're trying to prove happened.

#### Integrity: native format over derived summary

Same principle as log-based civil matters. A summary is not the source.

<table><thead><tr><th width="285">Practice</th><th>Risk if skipped</th></tr></thead><tbody><tr><td>Preserve native .msg/.eml with full headers</td><td>Screenshots and copy-pasted email bodies can't be checked against SPF/DKIM/DMARC or the originating IP later.</td></tr><tr><td>Export the UAL in full, not a filtered subset</td><td>A filtered export can't answer "what else happened in that session" when it's challenged.</td></tr><tr><td>Retain the original inbox rule syntax</td><td>"It forwarded emails to an external address" is a description. The rule XML is the exhibit.</td></tr><tr><td>Preserve before remediating</td><td>Password resets, rule removal, mailbox restores all change the state you're trying to document. Acquire first, remediate second, wherever containment allows it.</td></tr></tbody></table>

Advanced Audit and the UAL generally are retention-limited too. Standard licensing sits around 90 days, and BEC matters routinely surface weeks after the actual compromise. Export it early, because the source data has a habit of ageing out right before someone realises they need it.

#### Reporting and displaying: built for scrutiny, not just for the ticket

"Malicious rule found and removed, user password reset" is a fine remediation note. It isn't an investigation report.

A report meant to support an insurance claim, a notification, or litigation needs a stated methodology (what was acquired, from where, with what tool, and when), findings tied to the underlying exhibit rather than paraphrased from memory, native-format evidence rather than PDF printouts or screenshots that strip the metadata out, and a clear line between what was observed and what's being concluded from it.

Displaying evidence matters as much as acquiring it. A screenshot of an email in a report is a derived artefact, the reader can't independently verify it. The same email sitting in an eDiscovery platform, headers intact, hash on record, is something a second reviewer can actually check.

#### Governance controls

**Pre-authorise independent engagement.** Cyber insurance policies frequently require a panel forensic provider. Using an unapproved MSP investigation instead can put coverage at risk. Sort this out before an incident, not during one.

**Acquire before remediating, wherever it's safe to.** Isolate the account and block the forwarding action, but capture the rule, the sign-in logs, and the audit trail before touching them.

**Treat audit log retention as a standing control, not a reactive one.** A UAL sitting on 90 days of retention doesn't leave much runway once you're already eight weeks into an investigation that hasn't started yet.

**Route engagement through legal counsel** where privilege may need to attach to the resulting report.

**Put the MSP/MSSP's role in writing.** Detection, containment, preservation. Not root-cause investigation, and not the report that goes to the insurer or the regulator.

#### Internal/MSP vs Independent Investigator

**What the MSP/MSSP should handle**

* Detection and initial containment, disabling the account, blocking the forwarding rule once it's captured
* Preservation, triggering the eDiscovery hold, extending log retention, isolating the mailbox from further changes
* Initial triage, working out the scope of accounts and timeframe potentially affected

**What should go to an independent investigator**

* Acquisition and analysis intended to support an insurer, regulator, or court
* Root-cause findings, especially any finding that touches the adequacy of the MSP/MSSP's own controls
* The report itself, where independence of the author is part of what gives the finding its weight

#### Summary

A BEC matter investigated solely by the MSP/MSSP that missed the compromise is being investigated by an interested party, however well the work is done. Fit-for-purpose acquisition, native-format preservation, documented chain of custody over mailbox and log access, and a report built to survive scrutiny are what separate a defensible investigation from a closed ticket. Detection, containment, and preservation belong with the MSP/MSSP. The investigation and the report belong with someone who has no stake in what it finds.