Establish a trusted response channel
Nominate an incident lead and an authorised tenant administrator. Confirm how they will communicate outside the suspected mailbox, who can approve disruptive changes and which business processes depend on the identity. Treat reports as indicators to investigate: a foreign IP address or unusual location alone does not identify an attacker or prove a breach.
Record the earliest known symptom, affected account identifiers, tenant, relevant devices and the timezone used. If a payment instruction is involved, have the authorised finance team contact its bank through a verified channel promptly. Do not continue verification inside the suspicious email thread. A technical investigation and a payment-recovery request are separate activities; neither establishes that funds can be recovered.
Contain access while documenting the changes
An authorised administrator should follow the current Microsoft response guidance to block compromised access, revoke relevant sessions and reset credentials through the authoritative identity system. Review registered authentication methods, privileged roles, application consent, delegation and forwarding. A password change alone does not address every persistence path.
Capture the observed state and an action log where feasible, but do not postpone necessary containment while waiting for a perfect evidence collection. Record who changed what, when and why. Session revocation is not a universal instantaneous switch: application-managed sessions, token behaviour and service integration affect when access ends. Verify the result in the affected services, and investigate separately if an application identity or administrator is also compromised.
Response decisions at a glance
- Coordinate
Verify the incident lead and a trusted communication route.
- Contain
Restrict compromised access and record the actions taken.
- Preserve
Secure available records before their retention window expires.
- Assess
Correlate scope, persistence and information exposure.
- Restore
Validate access, monitoring and recovery with the owner.
Preserve the evidence that can answer the question
Identify which Microsoft Entra, Microsoft Purview, Exchange, endpoint and network records actually exist. Retention, licensed features, collection settings and export permissions differ. Confirm the earliest available event for each source and preserve relevant records before expiry. A later licence upgrade or a newly enabled log does not necessarily recreate evidence that was never recorded.
Use controlled exports with a collection manifest: source, tenant, custodian, query, time range, timezone, export time, operator and tool or API version. Retain original exports, record integrity hashes and create working copies. Check pagination, errors and event-count reconciliation. A screenshot can document a finding, but often omits fields required for a reproducible investigation. Agree secure transfer and retention with authorised recipients.
Build a timeline across identities, messages and applications
Correlate account sign-ins and administrative changes with mailbox operations, message transport and file-sharing activity. Preserve original timestamps and explain any normalisation to UTC. Keep event time distinct from collection time. Test alternative explanations such as approved automation, shared network egress, delegated access or a legitimate travel event.
For an altered payment instruction, compare original message headers and content with the recipient’s copy and related transport records where available. For a suspected information leak, distinguish access, download, forwarding and proven onward disclosure. An IP address is a technical observation, not proof of the human operator. Missing records should be reported as a visibility limitation rather than evidence that no access occurred.
Check persistence and connected services
Mailbox review should extend to server-side forwarding, relevant inbox rules, delegated permissions and connected applications. Examine whether the same identity can reach SharePoint, OneDrive or other business systems. Separate user-delegated access from application permissions, and identify which owner can revoke each path.
Reassess the affected endpoint and recovery channels before returning the account to normal use. A malicious application grant, compromised recovery account or unmanaged device can undermine otherwise sound identity changes. Track each dependency with an owner, action and verification result; do not close the incident simply because the user can log in again.
An evidence request that can be checked
On a small screen, scroll the table sideways to compare all columns.
| Record set | Record with the collection | Question to test |
|---|---|---|
| Entra sign-ins and audit | Tenant, identities, UTC interval, export method and missing coverage. | Which sign-ins and administrative changes require explanation? |
| Exchange and message records | Mailbox identifiers, message IDs, routing evidence and relevant rule/delegate changes. | What was delivered or changed, and which recipients were affected? |
| Applications and permissions | Service principals, consents, grants and privileged-role changes. | Could access continue through an application or another identity? |
| Files and collaboration | Relevant file/site identifiers, activity types and source coverage. | What evidence supports access or sharing, and what remains unknown? |
Define a defensible restoration decision
Agree what must be demonstrated before access is restored: the suspected persistence paths addressed, authentication and recovery reviewed, relevant devices assessed, delegated access justified and business owners informed. Monitor for recurrence using available telemetry and an explicitly agreed observation period. Record any residual uncertainty and who accepts it.
A useful investigation report separates confirmed findings, supported interpretations, unresolved questions and untested areas. Deliver a timeline with evidence references, collection limitations, affected access paths and a prioritised remediation plan. Reporting or notification obligations should be assessed with the organisation’s legal and privacy advisers; technical severity alone does not settle every notification question.
Prepare a useful first enquiry
Tell TRUST-IT which type of account or system is involved, when the concern arose, whether activity appears ongoing and who can authorise work. A tenant administrator’s availability and the existence of retained logs help define the next step. Use the public enquiry form for a short description, not credentials, recovery codes, mailbox exports or confidential evidence.
We can scope email and cloud forensics, coordinate evidence preservation and examine related devices or payment-instruction activity where authorised. Access, response availability, reporting recipients, deliverables and retention are agreed for the engagement. For a deeper illustrative investigation, see our family-office payment-instruction technical example.
Further reading
- Microsoft — compromised account response
- Microsoft — emergency access revocation
- Microsoft — Entra log retention
- Microsoft — audit retention policies
- NIST — forensic techniques in incident response
Put the guidance to work
Investigations across Microsoft 365, Google Workspace and cloud environments, including business email compromise, access and data sharing.
Email & cloud investigations