Incident Response Governance: Building the Evidence Chain Regulators Require

Incident Response in M365: From Sentinel Alert to Evidence Pack

Incident response in cloud-first environments requires fundamentally different workflows from traditional on-premises incident response. There is no hard drive to image, no network tap to capture traffic, and no server room to physically isolate. Instead, the evidence exists in audit logs, API telemetry, and cloud service metadata. Microsoft Sentinel, combined with the Microsoft 365 Defender stack, provides an integrated incident response workflow - but only if it is correctly configured and the response team knows how to use it.

The Incident Response Workflow

A mature M365 incident response follows five phases: Detection, Triage, Investigation, Containment, and Evidence Collection. Each phase maps to specific tools and actions within the Microsoft security stack.

Phase 1: Detection - Sentinel Incident Creation

Microsoft Sentinel creates incidents from analytics rules. Each analytics rule is a KQL query that runs against one or more data sources on a schedule. When the query returns results, Sentinel creates an alert; related alerts are grouped into incidents.

For M365 environments, the critical analytics rules include:

• Identity-based: Impossible travel, anomalous token, mass file download, suspicious inbox rule creation, risky sign-in followed by sensitive operation
• Email-based: Phishing email delivered, malicious URL click, ZAP (Zero-hour Auto Purge) failure
• Data-based: Mass file deletion, external sharing spike, DLP policy match with high severity, sensitivity label downgrade
• Device-based: Malware detection, suspicious process execution, lateral movement indicators

Configure each rule with appropriate severity levels and entity mapping. Entity mapping is critical - it tells Sentinel which fields in the query results represent users, IP addresses, hosts, and files, enabling the investigation graph.

Incident grouping: Configure Sentinel to group related alerts into a single incident. Under Analytics > Rule > Incident settings, enable alert grouping and group by "Account" entity. This prevents alert fatigue by consolidating, for example, 15 alerts about the same compromised user into one actionable incident.

Phase 2: Triage - Severity Assessment

When a Sentinel incident is created, the SOC analyst performs initial triage:

1. Review the incident timeline: In Microsoft Sentinel > Incidents, select the incident and review the timeline of alerts. The timeline shows the sequence of suspicious activities and their timestamps.

2. Check entity details: Click on the user entity to see their Entra ID profile, recent sign-in activity, risk level, group memberships, and privileged roles. A compromised Global Administrator is a severity-critical event; a compromised standard user accessing only email is lower severity.

3. Assess blast radius: Use the Investigation graph (click "Investigate" on the incident) to visualise relationships between entities. Sentinel maps connections between the user, their devices, IP addresses, files accessed, and other users who may be affected.

4. Assign severity and owner: Based on triage, set the incident severity (High, Medium, Low, Informational) and assign it to an analyst. Sentinel integrates with ServiceNow, Jira, and other ITSM tools for ticket creation.

Phase 3: Investigation

The investigation phase determines the full scope of the incident. In M365, investigation leverages multiple data sources:

Unified Audit Log (UAL): The UAL is the single most important data source for M365 investigations. It records every user and admin action across Exchange, SharePoint, OneDrive, Teams, Entra ID, Power Platform, and more. Search the UAL in Microsoft Purview > Audit or via KQL in Sentinel (OfficeActivity and AuditLogs tables).

Key investigation queries:

All actions by the compromised user during the incident window:

OfficeActivity
| where TimeGenerated between (datetime(2025-11-15T10:00:00Z) .. datetime(2025-11-15T18:00:00Z))
| where UserId == "compromised.user@contoso.com"
| project TimeGenerated, Operation, ClientIP, ResultStatus, OfficeObjectId
| sort by TimeGenerated asc

File access and download activity:

OfficeActivity
| where TimeGenerated between (incidentStart .. incidentEnd)
| where UserId == "compromised.user@contoso.com"
| where Operation in ("FileDownloaded", "FileAccessed", "FileSyncDownloadedFull", "FileModified")
| project TimeGenerated, Operation, OfficeObjectId, ClientIP, SourceFileName

Email forwarding and inbox rule changes:

OfficeActivity
| where TimeGenerated between (incidentStart .. incidentEnd)
| where UserId == "compromised.user@contoso.com"
| where Operation in ("New-InboxRule", "Set-InboxRule", "Set-Mailbox", "New-TransportRule")
| project TimeGenerated, Operation, Parameters

OAuth app consent grants:

AuditLogs
| where TimeGenerated between (incidentStart .. incidentEnd)
| where OperationName == "Consent to application"
| where InitiatedBy.user.userPrincipalName == "compromised.user@contoso.com"
| project TimeGenerated, TargetResources, AdditionalDetails

Defender for Cloud Apps: Provides a richer view of file-level activity than the UAL alone. Navigate to Defender XDR > Cloud Apps > Activity log and filter by the compromised user. MDCA shows file downloads, sharing changes, and app-specific actions with additional context.

Phase 4: Containment

Containment actions must be executed rapidly and in the correct order to prevent the attacker from establishing persistence:

Immediate actions (execute simultaneously):

1. Revoke sessions: Entra ID > Users > [user] > Revoke sessions. This invalidates all active tokens. Note: with default token lifetimes, the attacker may retain access for up to 1 hour via cached access tokens. Enable Continuous Access Evaluation (CAE) to reduce this window to near-zero.

2. Reset password: Reset the user's password to a temporary value. Enable "Require user to change password at next sign-in."

3. Disable account (if warranted): For high-severity incidents, disable the account entirely until investigation is complete.

4. Block attacker IP: Create a Conditional Access named location containing the attacker's observed IP addresses and configure a policy to block sign-ins from that location.

Persistence removal (within 1 hour):

5. Remove inbox rules: Use Exchange Online PowerShell to list and remove suspicious inbox rules:

Get-InboxRule -Mailbox "user@contoso.com" | Where-Object {$_.Enabled -eq $true} | Format-List Name, Description, MoveToFolder, DeleteMessage, ForwardTo

6. Remove mail forwarding: Check for both inbox rules with forwarding and mailbox-level forwarding:

Get-Mailbox -Identity "user@contoso.com" | Select-Object ForwardingAddress, ForwardingSmtpAddress, DeliverToMailboxAndForward

7. Revoke OAuth grants: In Entra ID > Enterprise applications, review consent grants for the compromised user and revoke any suspicious application permissions.

8. Remove suspicious MFA methods: Check the user's authentication methods and remove any that were added during the compromise window.

Phase 5: Evidence Collection

For regulatory reporting (GDPR Article 33, NIS2, DORA), the evidence pack must be comprehensive and timestamped:

Evidence Pack Contents:

1. Incident timeline: Export the Sentinel incident timeline as a PDF or CSV, showing all alerts and their timestamps.
2. Audit log export: Export the complete UAL query results for the compromised user during the incident window. Include file access, email activity, and admin actions.
3. Sign-in logs: Export from Entra ID > Sign-in logs, filtered for the compromised user and the incident timeframe. Include IP addresses, locations, device information, and Conditional Access results.
4. Containment evidence: Screenshots or log entries showing when sessions were revoked, password was reset, and account was disabled. Include timestamps.
5. Data exposure assessment: List of all files accessed, downloaded, or shared during the compromise. Include file names, sensitivity labels, and sharing scope.
6. Remediation actions: Document all persistence removal actions taken, including inbox rule deletion, OAuth revocation, and MFA method removal.

Automated evidence collection: Use a Sentinel Playbook (Logic App) to automatically collect evidence when an incident reaches a certain severity. The playbook can:

• Query the UAL and export results to a secure Azure Blob Storage container
• Capture sign-in logs via Graph API
• Generate a formatted HTML report
• Email the evidence pack to the incident response team and legal counsel

Post-Incident Reporting

For regulatory bodies, the incident report should follow the framework's prescribed format. For GDPR:

• Nature of the breach
• Categories and approximate number of data subjects affected
• Categories and approximate number of personal data records affected
• Likely consequences
• Measures taken to address the breach and mitigate effects

For NIS2 (which requires 24-hour initial notification):

• Initial notification within 24 hours of awareness
• Incident assessment update within 72 hours
• Final report within one month

The evidence pack assembled from Sentinel, Entra ID, and Purview provides the raw material for these regulatory reports. The key is having the collection process documented and, ideally, automated before an incident occurs - not scrambling to figure out where the logs are during an active breach.