In this section
Cloud Evidence Landscape: M365 Log Sources, Retention, and Investigation Value
Scenario
Legal counsel calls on day 35 of an investigation. The regulator wants evidence that the attacker didn't access the CEO's mailbox. You need MailItemsAccessed records for the compromised session. But your tenant runs E3 without Sentinel ingestion. Native sign-in logs expired after 30 days. The Unified Audit Log has the MailItemsAccessed records — but only because Microsoft expanded MailItemsAccessed to Audit Standard in late 2024. Two years earlier, this evidence wouldn't exist on E3 licensing at all. The investigation just became a licensing conversation. This section maps every evidence source so you know what exists, what doesn't, and what's about to expire before you go looking for it.
Estimated time: 45 minutes.
Figure IR0.2. Cloud evidence lives in four domains, each with multiple log sources and different retention periods. Identity evidence expires first (30 days native). Email and file evidence lasts longer (180 days to 1 year). Without Sentinel ingestion, the 30-day identity evidence gap is the single biggest investigation risk.
The evidence problem cloud investigators face
Cloud investigation evidence is not like endpoint evidence. A hard drive retains everything written to it until the sectors are overwritten or the drive fails. Cloud audit logs have retention policies. When the retention period expires, the evidence is gone — not degraded, not harder to find, but deleted. You can't recover an expired sign-in log the way you can carve a deleted file from unallocated space.
This creates a race condition that every cloud investigator faces. The attacker operated at 14:32. The SOC detected the activity at 15:47. Legal counsel requested the investigation at day 3. The regulatory notification is due at day 30 (GDPR) or day 4 (SEC). The sign-in logs that prove initial access expire at day 30 unless Sentinel is ingesting them. If the investigation starts late, or if evidence preservation isn't part of the first-hour checklist, the evidence may not exist when the investigator needs it.
This section maps every evidence source you'll use across the twelve modules of this course. For each source, you'll learn what it proves, what it can't prove, where it lives, how long it lasts, and what disappears first.
Identity evidence: the 30-day problem
Entra ID sign-in logs are the starting point for most cloud investigations. They prove who authenticated, from where, with what method, and whether Conditional Access policies were evaluated and satisfied. Four log tables cover different authentication types.
SigninLogs records interactive user sign-ins — the events where a human entered credentials or completed MFA. This is where you find the initial compromise: the AiTM session, the password spray that succeeded, the sign-in from an anomalous location.
AADNonInteractiveUserSignInLogs records token-based and background authentication — the events where an application refreshed a token without user interaction. This is where you find the attacker's ongoing access after the initial compromise. Token replay attacks produce non-interactive sign-ins because the attacker is using a stolen token, not entering credentials.
AADServicePrincipalSignInLogs records service principal authentication — the events where an application authenticated using a client secret or certificate, not a user identity. This is where you find the persistence mechanism. If the attacker created a service principal with a client secret, its ongoing authentication appears here, not in the user sign-in logs. Most analysts never check this table.
AuditLogs records administrative changes to the directory — role assignments, app registrations, Conditional Access policy modifications, group membership changes, service principal credential additions. This is where you find what the attacker changed in the directory to maintain access.
All four tables have 30-day native retention in Entra ID. After 30 days, the records are gone from the native logs. If Sentinel ingests these tables (via the Entra ID diagnostic settings connector), the retention extends to whatever you've configured in the Sentinel workspace — typically 90 days to 2 years.
Anti-Pattern
Starting a cloud investigation on day 28 without checking whether sign-in logs are ingested into Sentinel. If they're not, you have 2 days of evidence left. The first action is always to verify whether Sentinel has the sign-in and audit log data. If it does, you have the full retention window. If it doesn't, you need to export whatever remains from the native Entra ID logs immediately — before the 30-day window closes — and accept that anything older is unrecoverable.
The 30-day gap is the single biggest evidence risk in cloud investigation. Module 1 covers the sign-in log architecture in depth. Module 9 covers evidence preservation procedures for the first hour of an incident.
Email evidence: MailItemsAccessed and the throttling problem
Email evidence tells you what the attacker did with the compromised mailbox: what emails they read, what rules they created, what emails they sent, what forwarding they configured.
MailItemsAccessed is the critical evidence source. It logs every time a user or application accesses an email item. After the Storm-0558 incident in 2023, Microsoft expanded MailItemsAccessed availability from Audit Premium (E5) to Audit Standard (E3+), with the rollout completing in late 2024. This means MailItemsAccessed is now available to most M365 organizations, not just those with E5 licensing.
MailItemsAccessed produces two operation types. Bind operations record individual email accesses — the attacker opened a specific email. Sync operations record folder synchronizations — the attacker synced the inbox, downloading all messages. The distinction matters for scoping: bind operations tell you which specific emails were read; sync operations tell you which folders were accessed but not which individual messages within them.
The throttling problem is real. When a mailbox generates high volumes of MailItemsAccessed events in a short window, Microsoft aggregates multiple operations into fewer log entries grouped by SessionId. This doesn't eliminate the evidence — it compresses it. But it means the log may show 3 records where the attacker actually performed 50 individual email accesses. Module 3 teaches how to interpret the throttled records and accurately scope the email exposure.
This is what a MailItemsAccessed bind record looks like in the Unified Audit Log. The bind operation proves the attacker opened a specific email:
Compare this with a sync operation, which proves the attacker synced an entire folder but doesn't identify which individual messages were read:
The bind record tells you which specific email was opened. The sync record tells you a folder was synced and how many items were included, but not which specific messages the attacker read. For the regulatory notification, this distinction determines whether you can say "the attacker accessed 12 specific emails containing PII" or "the attacker synced a folder containing 340 emails, any of which may have been read."
OfficeActivity (in Sentinel) records Exchange operations including inbox rule creation (New-InboxRule), mailbox permission changes (Add-MailboxPermission), and mail forwarding configuration (Set-Mailbox). These are the manipulation events that distinguish a BEC attack from simple email reading.
EmailEvents (in Defender XDR) records email delivery, sending, and receipt. Advanced Hunting retention is 30 days for this table. If you need email event data older than 30 days, you need the UAL or Sentinel OfficeActivity.
The Unified Audit Log stores Exchange audit records with the standard retention period: 180 days for Audit Standard (E3), 1 year for Exchange/SharePoint/Entra ID records on Audit Premium (E5). Custom retention policies can extend this further on E5.
File evidence: SharePoint, OneDrive, and Teams
File evidence tells you what data the attacker accessed, downloaded, shared, or exfiltrated through M365 collaboration services.
OfficeActivity (SharePoint operations in Sentinel) records file access, download, upload, deletion, sharing link creation, and permission changes. Operation names are descriptive: FileDownloaded, FileAccessed, AnonymousLinkCreated, SharingSet. The Sentinel table preserves these records for the configured workspace retention period.
CloudAppEvents (in Defender XDR) provides similar file activity data through the XDR Advanced Hunting surface. The schema differs from OfficeActivity — field names and structures are different even when they record the same underlying event. Module 4 covers both schemas and when to use which.
The Unified Audit Log stores SharePoint and OneDrive audit records at the same retention tiers as Exchange: 180 days for E3, 1 year for E5 (SharePoint/OneDrive records). File versioning in SharePoint and OneDrive provides an additional evidence dimension: if the attacker modified or deleted files, version history may preserve the original content indefinitely (until version limits are reached or an administrator purges versions).
Directory evidence: the persistence audit trail
Directory evidence tells you what administrative changes the attacker made to Entra ID — the persistence mechanisms that survive password resets, session revocation, and user-level remediation.
This is the evidence domain most investigations miss. The audit log records every change to the directory: application registrations, service principal credential additions, OAuth consent grants, Conditional Access policy modifications, role assignments, group membership changes, federation trust configurations. Each of these can be an attacker persistence mechanism.
The problem is the same 30-day retention window as sign-in logs. If the attacker created a service principal credential on day 1 and the investigation starts on day 35, the audit log entry that proves the creation is gone from native Entra ID logs. Sentinel extends the retention if it's ingesting AuditLogs. Without Sentinel, you can still discover the persistence mechanism itself (the service principal credential still exists in the directory), but you can't prove when it was created or what account created it.
Module 5 covers Entra ID investigation in depth — every audit log operation type that matters for investigation, how to find persistence mechanisms that the attacker created, and how to determine whether they're legitimate or hostile.
Four query surfaces, four different schemas
Cloud evidence is queryable through four different surfaces, each with its own tables, schemas, query languages, and retention periods.
Sentinel (KQL) is the primary investigation surface for organizations with a Sentinel workspace. Tables: SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs, AuditLogs, OfficeActivity, SecurityAlert, SecurityIncident. Retention: configured per workspace (90 days to 2 years typical). Query language: KQL.
Defender XDR Advanced Hunting (KQL) provides investigation across the Defender product family. Tables: CloudAppEvents, EmailEvents, EmailUrlInfo, EmailAttachmentInfo, IdentityLogonEvents, IdentityQueryEvents, IdentityDirectoryEvents, AlertEvidence. Retention: 30 days for most tables. Query language: KQL (slightly different functions than Sentinel KQL).
Unified Audit Log (PowerShell) is the native M365 audit log, queryable via Search-UnifiedAuditLog cmdlet or the Purview compliance portal. Contains the raw audit records that Sentinel and Defender XDR ingest and transform. Retention: 180 days (E3) or 1 year for core workloads (E5). The UAL is often the evidence source of last resort when Sentinel retention has been exceeded.
Graph API (REST) provides programmatic access to sign-in logs, audit logs, risky users, service principals, and directory objects. Useful for bulk evidence collection and automation. Subject to the same 30-day native retention as the Entra ID portal. The Graph API returns the same data as the portal — it doesn't extend retention.
The same underlying event often appears in multiple surfaces with different field names. A sign-in event exists in SigninLogs (Sentinel), IdentityLogonEvents (Defender XDR), and the UAL (PowerShell) — but the field names, data types, and level of detail differ across all three. Module 1 covers cross-source correlation: how to join evidence across surfaces using common identifiers like UserId, SessionId, CorrelationId, and IPAddress.
What this course covers module by module
The twelve modules of this course follow the evidence through the four domains. Module 1 teaches the evidence architecture in depth — every log source, every schema, every retention edge case. Modules 2–6 teach investigation across identity (M2), email (M3), files (M4), directory persistence (M5), and the Defender XDR platform (M6). Modules 7–8 teach two complete investigation scenarios: BEC and insider threat. Modules 9–10 teach cloud containment and cloud IR reporting. Module 11 is the capstone — a full multi-domain cloud investigation.
Section 0.3 covers the investigation methodology you'll apply across all twelve modules.