If Your Microsoft 365 Tenant Were Breached Today, What Could You Prove?

In a Microsoft 365 incident, the first hours focus on containment: disable or secure accounts, revoke refresh tokens, reset credentials, remove malicious inbox rules, revoke suspicious OAuth grants, block forwarding, and close obvious access paths.

Then the harder work starts. You need evidence for questions such as:

• Which account was first compromised?
• Was multifactor authentication required, satisfied, failed, or bypassed through token theft or session abuse?
• Was the access interactive, non-interactive, legacy-auth based, app-based, or tied to a suspicious service principal?
• Which mailboxes, files, sites, chats, teams, or applications were accessed?
• Were inbox rules, forwarding, mailbox delegation, transport rules, or connectors changed?
• Were SharePoint or OneDrive files downloaded, synchronized, shared externally, or mass-accessed?
• Did the attacker create persistence through app registrations, consent grants, credentials, federated identity changes, Conditional Access changes, or privileged role assignments?
• Can you prove data exposure, or only suspect it?

Microsoft 365 produces useful telemetry, but telemetry is not the same as forensic readiness. Readiness requires the right logs, the right retention, the right licenses, and a practiced workflow that turns records into a defensible timeline.

The same gaps appear in many tenants after a compromise.

First, identity logs do not go back far enough. Microsoft Entra ID sign-in and audit log retention depends on licensing. Entra ID Free retains logs for a short period, while Entra ID P1/P2 extends portal retention. For longer investigations, logs must be exported to Microsoft Sentinel, Log Analytics, Event Hubs, or storage before the incident.

Second, mailbox evidence is misunderstood. Exchange Online mailbox auditing is enabled by default for most modern tenants, but investigation value still depends on which actions are audited, how long records are retained, and whether analysts know how to query them. Item-level mailbox access evidence, such as MailItemsAccessed, is associated with Microsoft Purview Audit (Premium) capabilities and is not a universal default for every tenant.

Third, Microsoft Purview audit retention is often treated as a compliance setting instead of an incident response control. Purview Audit (Standard) and Audit (Premium) have different retention and event capabilities. Audit (Premium) can provide longer default retention for eligible users and additional high-value events. Organizations that need more than the default retention must configure retention policies or export data to a security data platform.

Fourth, privileged activity is collected but not treated as urgent evidence. Role assignments, Privileged Identity Management activations, app registration changes, service principal credential additions, admin consent grants, federation changes, and Conditional Access policy edits are often the persistence mechanism. If these events are not monitored and retained, containment may be incomplete.

Fifth, workload logs are not correlated. A suspicious sign-in is more useful when matched to Defender for Endpoint alerts, device posture, risky user detections, mailbox activity, file access, and OAuth changes. Without correlation, analysts lose time deciding whether the event was benign instead of proving scope.

Consider a common attack path.

Day 0: A finance user enters credentials into a phishing page. The attacker captures a session token or manipulates the user into satisfying MFA.

Day 2: The attacker signs in through residential proxy infrastructure. The IP address is not on a known malicious list. The attacker searches the mailbox for invoice, wire, ACH, bank, vendor, and payment terms. They create an inbox rule that marks replies as read and moves them to a folder the user rarely checks.

Day 6: The attacker consents to or abuses an application, adds credentials to an existing app, or continues using stolen session material until it expires.

Day 13: The attacker sends a payment change request from the mailbox or uses mailbox intelligence to impersonate the user externally.

Day 21: IT is notified after a vendor or bank reports fraud.

Disabling the account is not enough. Investigators still need to know whether the mailbox was accessed, whether items were read, whether files in SharePoint or OneDrive were downloaded or shared, whether Teams-related files were touched, whether other users were targeted, whether OAuth or privileged persistence exists, and which messages were sent.

If identity, audit, and workload logs only cover the last few days, the organization may contain the visible fraud while missing the original access path and any durable access left behind.

Retention defines how far back your investigation can see.

A practical retention model should reflect detection reality. Business email compromise is often discovered after money moves. Insider activity may surface during HR, legal, or compliance review. OAuth abuse can persist quietly. Data exposure questions may arrive weeks or months after access occurred.

For many organizations, at least 90 days of searchable security evidence is a working baseline. Higher-risk environments should plan for 180 days to one year for critical trails: Entra ID sign-ins and audit events, privileged activity, Exchange Online mailbox and admin activity, SharePoint and OneDrive file activity, external sharing, Purview DLP and sensitivity label events, and Defender alerts.

This does not mean sending every event to expensive hot analytics storage forever. A sensible design separates hot detection data from lower-cost retained evidence. Decide which events must be searchable immediately in Microsoft Sentinel and which records can be retained for investigation, legal hold, or compliance review.

The key decision is explicit risk ownership: do not let default portal retention become your incident response strategy.

A forensically ready Microsoft 365 tenant should produce a defensible timeline quickly. The target is not a perfect answer in ten minutes. The target is enough evidence within hours to guide containment, legal assessment, and executive decisions.

Your team or provider should be able to answer:

• Identity: successful and failed sign-ins, authentication requirement and result, MFA details where available, Conditional Access result, device details, client app, user agent, IP, location, ASN, risk detections, and legacy authentication use.
• Privilege: role assignments, Privileged Identity Management activations, admin consent, app registration changes, service principal changes, credential additions, Conditional Access policy changes, federation changes, and break-glass account activity.
• Exchange Online: mailbox access indicators, inbox rules, forwarding, SendAs and SendOnBehalf activity, mailbox delegation, transport rules, connectors, message trace evidence, and suspicious mailbox configuration changes.
• SharePoint and OneDrive: file access, downloads, synchronization, sharing links, external sharing, permission changes, site-level changes, and mass access patterns.
• Teams: team, channel, guest, and meeting-related audit events; file activity traced through SharePoint and OneDrive; and collaboration events relevant to exposure. Teams audit logs do not replace eDiscovery or content review.
• Endpoint and browser context: Defender for Endpoint alerts, malware findings, suspicious browser activity, token theft indicators, device health, and timeline evidence around the user’s sign-ins.
• Data protection: Microsoft Purview DLP alerts, sensitivity label activity, information protection events, and access to repositories containing regulated or sensitive data.

The deliverable is not a log export. It is a timeline: user, source, authentication path, workload, action, object touched, result, and business impact.

Start with the incident scenarios most likely to damage the business: business email compromise, privileged account compromise, OAuth abuse, SharePoint or OneDrive data exposure, and malicious administrator activity.

For each scenario, define the evidence needed to prove or disprove it. Then verify that the logs exist, are retained long enough, and can be queried during an incident.

A practical plan:

1. Confirm audit coverage. Check Microsoft Purview audit, Exchange mailbox auditing, Entra ID sign-in and audit logs, SharePoint and OneDrive audit events, Defender XDR, and Purview DLP sources. Do not assume defaults meet your investigation requirements.
2. Map retention by evidence type. Identity, mailbox, file, privilege, endpoint, and DLP records have different retention rules and licensing dependencies.
3. Export high-value telemetry. Use Microsoft Sentinel or another SIEM to centralize Entra ID, Microsoft 365, Microsoft Defender XDR, and Purview signals that must survive portal retention limits.
4. Build detections around attacker behavior. Examples: suspicious sign-in followed by inbox rule creation; new OAuth consent followed by mailbox access; privileged role assignment from an unfamiliar location; service principal credential addition; mass file access followed by external sharing.
5. Test with evidence drills. Pick a user and ask: “If this account was compromised 37 days ago, what can we prove?” Run the queries. Record the gaps. Fix the retention or collection path.

Forensic readiness is not maximum logging. It is intentional evidence collection tied to realistic breach scenarios.

After containment, executives do not need a raw security score. They need scope: customers affected, employee data involved, regulated data exposed, money at risk, operations disrupted, and persistence removed.

If you cannot prove what was accessed, counsel may have to assume broader exposure. If you cannot prove when the attacker entered, the incident window expands. If you cannot prove whether files were downloaded or shared, notification decisions become harder. If you cannot prove that persistence was removed, recovery remains uncertain.

Forensic readiness affects legal strategy, insurance claims, regulatory response, customer communications, and board confidence. The organizations that handle Microsoft 365 incidents well are not breach-proof. They made logging, retention, monitoring, and response decisions before the incident forced the question.