Where are my logs? A field guide to Microsoft 365 & Entra ID log sources
When you respond to an incident on Microsoft 365, the hardest constraint hits in the first ten minutes: do we still have the telemetry to trace what happened?
Unlike an on-premises network where you can pull a disk image or grab months of firewall logs off a local NAS, cloud forensics depends on four choices made long before anyone clicked a phishing link: which log categories were turned on, where they were exported, how long they are kept, and which license each user holds. If sign-ins rolled off after seven days or mailbox auditing was bypassed, no post-incident license upgrade will bring that history back.
This guide is the foundation for every investigation article on this blog. Every technique in the attack matrix points to a specific log source under Where to look—and every one of those log streams lives in one of the five planes below.
The five places where tenant telemetry lives
Keep one rule in mind whenever someone suggests buying E5 during an incident: Microsoft cloud log retention is never retroactive. Upgrading from Entra ID Free to P1/P2 today starts counting 30 days from today forward; it will not recover sign-ins from two weeks ago, and MicrosoftGraphActivityLogs only exist from the day you wire up a Diagnostic Setting4.
Deep dive by source (and the traps you hit in the field)
Entra ID collects several distinct log categories, and the biggest beginner mistake in an M365 incident is stopping at the first tab (User sign-ins (interactive)) in the Entra admin center5.
In modern attacks—AiTM phishing, device code phishing, ConsentFix, or Primary Refresh Token (PRT) replay—the victim often completes the initial interactive sign-in themselves (or hands over an OAuth code). After that, the attacker replays refresh tokens, session cookies, or app permissions silently. If you only check interactive logins, you see a clean login from the user's home IP and miss all the attacker's token refreshes in the Non-interactive sign-ins tab.
How to pivot across Entra ID logs
Because attackers split their footprint across login and API planes, knowing the join keys saves hours:
SessionId: Ties interactive and non-interactive sign-ins together for one session lifetime. In an AiTM attack, seeing the exact sameSessionIdswitch from the victim's ISP IP to an unfamiliar VPS or VPN IP minutes later is your smoking gun.UniqueTokenIdentifier→SignInActivityId: Links a specific token issuance inSigninLogsorAADNonInteractiveUserSignInLogsdirectly to the individual API calls made with that token inMicrosoftGraphActivityLogs(where the column is namedSignInActivityId).CorrelationId: Groups every related retry or step within a single authentication attempt or directory operation.AuthenticationProtocolandIncomingTokenType: Lets you filter instantly for anomalies—for exampleAuthenticationProtocol == "deviceCode"for device code phishing, orIncomingTokenTypeshowingprimaryRefreshToken/refreshTokenreplay from an unmanaged device.
Retention and portal blind spots
Exporting Entra categories to a Log Analytics workspace, Azure Storage Account, or Event Hub is configured under Monitoring & health → Diagnostic settings in Entra ID and requires the Security Administrator role alongside at least one Entra ID P1 or P2 license in the tenant4. Unlike SigninLogs, MicrosoftGraphActivityLogs has no built-in table view in the Entra portal: if you haven't created a Diagnostic Setting for it, no HTTP-level Graph telemetry is retained anywhere.
While Entra ID proves who authenticated and got a token, the Microsoft Purview Unified Audit Log (UAL) answers what they touched once inside: which emails were read, which inbox rules were created, which SharePoint files were downloaded or shared externally, and what prompts went to Copilot.
Two architectural facts govern UAL investigations:
- It is independent of Entra licensing. Standard UAL retention is 180 days (historical records prior to October 17, 2023 were kept 90 days)1.
- Premium retention follows the user's license, not the tenant. Audit (Premium) (included with Microsoft 365 E5 or the E5 Compliance add-on) extends Entra ID, Exchange, SharePoint, and OneDrive audit retention to one year—with a 10-year retention add-on available1. However, retention is stamped per acting user: unlicensed accounts, shared mailboxes without an E5-licensed actor, B2B guests, or frontline accounts on F1/F3 still fall under Standard rules.
Three traps you will hit in the field
-
Tenant auditing on ≠ every mailbox covered. Checking the org-wide switch in Exchange Online PowerShell is step one:
Get-OrganizationConfig | Format-List AuditDisabledYou want
AuditDisabled : False6. Even then, always check for mailbox-level bypasses (Get-MailboxAuditBypassAssociation | Where-Object { $_.AuditBypassEnabled -eq $true }), which attackers sometimes abuse to go silent. Also keep an eye on the three mailbox audit scopes—AuditAdmin,AuditDelegate, andAuditOwner: someAuditOwnerevents (likeMailboxLoginorHardDelete) are not always enabled by default depending on mailbox configuration and tenant age. -
The
MailItemsAccessedthrottling cliff.MailItemsAccessedis the critical audit operation that records whether a session performed a folderSync(desktop Outlook caching an entire folder—meaning Microsoft recommends treating the whole folder as compromised) or aBind(opening specific messages identified byInternetMessageIdin two-minute buckets)7. It is enabled by default for E3 and E5 users7, but Exchange Online throttlesBindlogging for 24 hours if a mailbox triggers more than 1,000Bindoperations in 24 hours, emitting a throttling indicator instead of every individual message ID. -
Move off synchronous
Search-UnifiedAuditLogon large queries.Search-UnifiedAuditLogin PowerShell breaks easily at 5,000 records per session and drops pages under timeouts. For real investigations, run asynchronous Purview Audit Search jobs inpurview.microsoft.comor automate them via the Microsoft Graph Audit Log API (security/auditLog/queries).
If a tenant runs Microsoft 365 Business Standard/Premium or Office 365 E3 without Defender for Office 365, you will not have EmailEvents or Threat Explorer in Defender XDR. Exchange Online Message Trace becomes your primary source of truth for mail flow:
- Standard Message Trace (
Get-MessageTraceV2in PowerShell or the Exchange Admin Center UI): near real-time query across the last 10 days of inbound and outbound mail flow. - Extended Message Trace (
Start-HistoricalSearchor EAC downloadable report): reaches back up to 90 days, exporting a CSV with connector routing, TLS status, sender IPs, and message IDs.
Crucially, Message Trace lives at the transport pipeline, not inside the mailbox: even when an attacker hard-deletes phishing replies from Sent Items and clears Recoverable Items, outbound trace records remain intact.
People often mix up the two retention windows inside the Microsoft Defender portal: alerts and incidents stay visible for 180 days, whereas Advanced Hunting (and Defender for Office 365 Threat Explorer) only keeps raw event tables for 30 days2. If a BEC occurred six weeks ago and nobody exported Defender tables, Advanced Hunting returns empty results even while old incidents still appear in the UI.
Each hunting table also depends on which Defender workload is licensed and active on the tenant8:
Special note
Microsoft removed AADSignInEventsBeta and AADSpnSignInEventsBeta from the Advanced Hunting schema in December 2025, replacing them with EntraIdSignInEvents and EntraIdSpnSignInEvents9. Any older KQL query copied from a repository or blog post referencing those *Beta names will fail until updated.
Because Entra ID and Azure RBAC use separate planes, M365 teams frequently forget Azure Monitor altogether. Yet every Azure subscription and management group emits AzureActivity logs with 90 days of free built-in retention—zero SIEM required to read them in the portal.
Whenever an attacker compromises a Global Administrator, toggles access elevation to grant themselves the User Access Administrator role at the root scope (/), grants themselves Owner on a subscription, reads Key Vault secrets, or wipes Azure backups and storage accounts (as documented in cloud extortion campaigns like Storm-0501), AzureActivity is where those subscription-level role assignments and destructive operations appear.
Think of Log Analytics / Microsoft Sentinel not as a primary telemetry generator, but as the consolidation layer where your Entra, Purview, Defender, and Azure logs sit side by side—and where you actually control retention beyond Microsoft's 7-to-30-day defaults.
Two nuances matter enormously for budget and coverage:
-
The "free
OfficeActivityconnector" trap. Connecting Microsoft 365 to Sentinel (OfficeActivity), ingestingAzureActivity, and ingesting Defender product alerts (SecurityAlert) are free of ingestion charges10. However, the Sentinel Office 365 connector only streams four UAL record types:Exchange,SharePoint,AzureActiveDirectory, andGeneral(including Teams). It does not ingestMailItemsAccessed—meaning you cannot determine which emails an attacker read fromOfficeActivityalone and must still query Purview UAL directly—nor does it include Copilot interactions (CopilotInteraction), Power Platform / Copilot Studio events, Purview DLP, or eDiscovery actions. -
Choosing the right Log Analytics / Sentinel table plan3:
- Analytics tier: includes 90 days of interactive retention when Sentinel is enabled on the workspace (extendable up to 2 years). Supports scheduled KQL analytics rules, fast joins, and UEBA.
- Basic / Auxiliary Logs tier: discounted ingestion for high-volume, chatty streams where you rarely need 5-minute scheduled alert rules—ideal candidates are
MicrosoftGraphActivityLogsand bulkAADNonInteractiveUserSignInLogsif budget is tight. - Archive / Sentinel Data Lake: low-cost cold retention up to 12 years for compliance and delayed incident response (e.g., investigating a fraud reported four months after the initial compromise).
- Defender XDR raw tables: unlike
SecurityAlert(free), streaming raw Defender XDR hunting tables into Sentinel incurs normal ingestion charges; keep their retention aligned with what you actually hunt past Defender's built-in 30 days3.
Which log to open first (mapped to the Attack Matrix)
Starting points for the key techniques covered in the attack matrix, along with the exact fields or events to inspect first.
My pre-incident readiness checklist
Before a crisis ever happens, these six checks are what I look at first during any tenant audit—drawn largely from Microsoft's incident response playbooks6 and field incidents where logs came up short:
- Confirm Unified Audit Log search and mailbox auditing are active (
AuditDisabled : False), and checkGet-MailboxAuditBypassAssociationto make sure no admin or service account quietly has bypass turned on. - Verify Entra Diagnostic Settings export—at minimum
SigninLogs,AADNonInteractiveUserSignInLogs,AADServicePrincipalSignInLogs,AADManagedIdentitySignInLogs, andAuditLogs—alongsideAzureActivityif the tenant runs Azure subscriptions. - Turn on
MicrosoftGraphActivityLogs(andAADGraphActivityLogs) export as soon as Entra ID P1/P2 is present, because zero history exists before you flip that switch. - Align retention with realistic detection time. In SMEs without a 24/7 SOC, BEC and dormant OAuth apps are frequently discovered 60 to 120 days later—a 30-day default leaves you blind.
- Pre-assign read roles (
Security Reader) on Entra ID, Microsoft Defender, Purview, and Log Analytics to the people who will triage incidents, rather than fighting PIM or MFA setup mid-breach. - Actually query every source once. I have seen too many workspaces with a broken connector or missing
MailItemsAccessedpermissions discovered only on the day an investigator needed them.
What I deploy in the field (by license and budget)
In practice, designing log collection comes down to a simple question: how far back do we want to be able to investigate without blowing up the Azure bill on high-volume tables? Here is how I set things up across the three customer profiles I see most often:
-
Business Premium or E3, without a SIEM (Entra ID P1 included) You don't need a full SIEM to avoid the 30-day cliff on identity logs. I deploy a standalone Log Analytics workspace (without enabling Sentinel, so you only pay basic Log Analytics ingestion/retention) or an immutable Azure Storage Account to collect the Entra ID logs (
SigninLogs,AADNonInteractiveUserSignInLogs,AADServicePrincipalSignInLogs,AuditLogs) alongsideAzureActivity. For the workload side, Purview Audit Standard gives you 180 days and Exchange Extended Message Trace covers 90 days of mail flow—for an SMB, the Azure bill stays at a few euros a month. -
M365 E3 / Entra ID P1–P2, with Microsoft Sentinel Start with the free connectors (
OfficeActivity,AzureActivity, andSecurityAlert). Keep the low-volume, high-signal identity tables (SigninLogs,AuditLogs,AADServicePrincipalSignInLogs,AADManagedIdentitySignInLogs) in the Analytics tier so you have 90+ days of hot retention and real-time KQL rules. The real budget question is what to do withAADNonInteractiveUserSignInLogsandMicrosoftGraphActivityLogs(plusAADGraphActivityLogs), which easily represent 80% of the volume: if the budget is tight, putMicrosoftGraphActivityLogsin Basic / Auxiliary Logs (with Archive for long-term retention) rather than turning it off, and remember thatMailItemsAccessedstill has to be queried in Purview UAL sinceOfficeActivitydoesn't ingest it. -
Microsoft 365 E5, with Defender XDR and Sentinel With E5, Purview Audit (Premium) already keeps Exchange (
MailItemsAccessed), SharePoint, OneDrive, and Entra audit records for a full year, and Defender XDR gives you 30 days of Advanced Hunting across all workloads. When you connect Defender XDR to Sentinel to keep hunting data beyond 30 days, E5 includes a 5 MB/user/day data grant on Defender XDR tables10—but watch out for two classic traps:- Don't ingest Entra sign-ins twice: if you already collect
SigninLogsandAADNonInteractiveUserSignInLogsthrough the Entra ID connector, do not also forwardEntraIdSignInEventsandEntraIdSpnSignInEventsfrom the Defender XDR connector into Sentinel. - Don't burn the 5 MB/user/day grant on raw endpoint noise: forwarding email, identity, and cloud app tables (
EmailEvents,UrlClickEvents,Identity*,CloudAppEvents) into Sentinel usually fits inside the E5 grant, whereas ticking raw endpoint tables likeDeviceNetworkEventsorDeviceProcessEventswithout filtering will eat the entire allowance and spike your bill.
- Don't ingest Entra sign-ins twice: if you already collect
If budget forces a compromise, never drop AADNonInteractiveUserSignInLogs and MicrosoftGraphActivityLogs completely—move them to Basic/Auxiliary logs or a Storage Account instead. They are the two noisiest tables in the tenant, and also the two you need first whenever an attacker replays a stolen token.
References
-
https://learn.microsoft.com/en-us/purview/audit-solutions-overview
-
https://learn.microsoft.com/en-us/defender-office-365/mdo-data-retention
-
https://learn.microsoft.com/en-us/graph/microsoft-graph-activity-logs-overview
-
https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-diagnostic-settings-logs-options
-
https://learn.microsoft.com/en-us/security/zero-trust/security-operations-playbook-phishing
-
https://learn.microsoft.com/en-us/purview/audit-log-investigate-accounts
-
https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-schema-tables
-
https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-schema-changes
-
https://learn.microsoft.com/en-us/azure/sentinel/billing#free-data-sources