3.6 Microsoft Purview Audit: Standard vs Premium

Microsoft Purview Audit: Standard vs Premium

Introduction

The unified audit log is the most comprehensive record of activity in Microsoft 365. Every file opened, every email read (with Premium), every admin configuration change, every Teams message sent, every SharePoint permission modification — it is all recorded. For a SOC analyst, the audit log is the forensic backbone of post-compromise investigation. When you know an account was compromised at 09:14 and contained at 11:30, the audit log tells you exactly what happened during those 2 hours and 16 minutes.

The audit log exists in two tiers with fundamentally different capabilities. Audit (Standard) is included with E3 and provides 180-day retention with core activity logging. Audit (Premium) requires E5 and adds 365-day retention, the critical MailItemsAccessed event, and higher-throughput API access for large-scale investigations. The tier you have determines what you can investigate — and more importantly, what you cannot.

This subsection explains the architecture, compares the two tiers, covers the critical events for security operations, and prepares you for the hands-on audit investigation in subsection 3.7.

Audit log architecture

The unified audit log captures events from across the entire M365 ecosystem. Events flow from each service (Exchange, SharePoint, OneDrive, Teams, Entra ID, Azure, Power Platform) into a centralized log store. Each event includes a timestamp, the user or service account that performed the action, the action type (what they did), the target object (what they did it to), the IP address, and service-specific details.

Event ingestion latency varies by service. Most events appear in the audit log within 30-90 minutes of occurrence. Some events (particularly Entra ID sign-in events and Exchange mailbox audit events) can take up to 24 hours. This latency matters during active investigations — if you search the audit log for activity that happened 15 minutes ago, you may not find it yet. For near-real-time investigation, use Defender XDR Advanced Hunting (CloudAppEvents), which has lower latency than the audit log.

Audit log enablement is on by default for M365 E3 and E5 tenants. However, mailbox audit logging — which captures Exchange-specific events like MailItemsAccessed — requires explicit enablement per mailbox (or organization-wide via PowerShell: Set-OrganizationConfig -AuditDisabled $false). In new tenants, mailbox auditing is enabled by default, but older tenants that were created before Microsoft enabled it by default may have it disabled. Verify mailbox auditing is enabled in your environment before you need it during an investigation.

Standard vs Premium: the critical differences

The critical audit events for security operations

Hundreds of event types exist in the audit log. You do not need to memorize them. You need to know the 15-20 that are most relevant to security investigations.

Mailbox events (Exchange): MailItemsAccessed (Premium only) records every email opened or synced. This is the event you use to determine which emails the attacker read during a compromised mailbox incident. It distinguishes between Bind operations (user explicitly opened the email) and Sync operations (email client synced the mailbox, downloading email content). During an investigation, focus on Bind operations from unexpected IP addresses — these are the emails the attacker actively read.

Send (Premium only) records every email sent by the user. Unlike message trace (which records email delivery), Send captures the act of composing and sending from the mailbox. If the attacker sent phishing emails from the compromised account and then deleted the sent items, the Send audit event still records that the emails were sent.

New-InboxRule records inbox rule creation. Attackers who compromise mailboxes commonly create forwarding rules that send a copy of all incoming email to an external address. This event captures the rule creation with the rule parameters (forwarding address, conditions).

Set-Mailbox records mailbox configuration changes. Attackers may set SMTP forwarding on the mailbox itself (separate from inbox rules), change the mailbox language or regional settings, or enable external forwarding at the mailbox level.

File events (SharePoint/OneDrive): FileAccessed records when a file is opened (viewed) in SharePoint or OneDrive. FileDownloaded records when a file is downloaded to a local device. FileModified records changes. FileDeleted records deletions. FileCopied records copy operations. FileRenamed records name changes (which can indicate file staging for exfiltration — renaming sensitive documents to innocuous names).

SharingSet records when sharing permissions are changed — particularly when a file or folder is shared with external users. SharingInvitationCreated records when a sharing invitation is sent.

Admin events (Entra ID/Azure): Add member to role records when a user is added to an admin role (attacker escalating privileges). Add user records account creation. Update user records account modifications. Add application, Update application, and Add service principal record OAuth application registration changes (attackers creating backdoor OAuth applications for persistent access).

UserLoggedIn and UserLoginFailed record authentication events (these overlap with SigninLogs but are also available in the audit log for organizations that do not forward sign-in logs to Sentinel).

What you can and cannot investigate at each tier: a practical comparison

To make the tier difference concrete, consider the same investigation scenario at E3 vs E5.

Scenario: j.morrison’s account was compromised via AiTM for 3 hours. You need to assess the data exposure.

With E3 (Audit Standard): You can determine that the account was compromised (SigninLogs), that 5 emails were sent to external addresses (message trace/EmailEvents), that 12 files were downloaded from SharePoint (FileDownloaded audit events), that an inbox forwarding rule was created (New-InboxRule), and that admin changes were made (role assignment events). You cannot determine which of the 2,000 emails in the mailbox the attacker actually read. The data exposure assessment states: “The attacker had access to the full mailbox for 3 hours. We can confirm 5 emails were sent externally and 12 files were downloaded. The number of emails read is unknown.” The CISO’s response: “So you’re telling me you don’t know if they read the board’s acquisition strategy email?” Correct — with E3, you cannot answer that question.

With E5 (Audit Premium): Everything above, plus: MailItemsAccessed shows the attacker opened 47 specific emails, including 3 containing board strategy documents, 8 containing customer contracts, and 12 containing financial forecasts. SearchQueryInitiatedExchange shows the attacker searched for “acquisition,” “merger,” and “board confidential.” The data exposure assessment is precise: “The attacker read 47 emails. Of these, 23 contained confidential business data and 12 contained financial data. The attacker specifically searched for acquisition-related content.”

The difference is not academic. It determines whether your data breach notification says “unknown scope of email access” or “47 emails accessed, 23 containing confidential data.” Regulators, legal counsel, and the board receive a materially different risk assessment based on this capability.

Enabling Premium Audit for specific users

Premium audit events (MailItemsAccessed, Send, SearchQueryInitiated) are not automatically enabled for all E5 users. The audit license must be assigned to the user, and the specific Premium audit events must be enabled.

In most E5 tenants, Premium audit is enabled by default for all licensed users. To verify: run Get-Mailbox -Identity user@domain.com | Format-List AuditEnabled,AuditOwner in Exchange Online PowerShell. The AuditEnabled property should be True, and the AuditOwner property should include MailItemsAccessed.

If your organization has a mix of E3 and E5 users, only E5 users have MailItemsAccessed enabled. This creates a gap: if a compromised account is E3-licensed, you cannot determine which emails the attacker read, even if other E5-licensed accounts in the organization have Premium audit. Consider this when planning license assignments — accounts that handle sensitive data (executives, finance, legal) should have E5 licenses specifically for the investigation capability that Premium audit provides.

Audit log search: Purview portal vs Sentinel KQL

You can access audit data through two primary interfaces. Each has different strengths.

Purview portal audit search provides a dedicated search interface with pre-built filters for date range, activities, users, files, folders, and sites. It is designed for ad-hoc investigations where you know what you are looking for — “show me all file downloads by j.morrison between March 18 and March 19.” The interface returns results in a table format that can be exported to CSV for further analysis. The portal search is limited to the audit log retention period (180 days Standard, 365 days Premium).

Sentinel KQL via OfficeActivity and CloudAppEvents provides the full power of KQL against audit data that has been ingested into your Sentinel workspace. This enables advanced queries that the portal search cannot perform: cross-table joins (correlating audit events with sign-in events and endpoint events), aggregation (counting file downloads per hour to identify anomalous spikes), timeline reconstruction (building a unified timeline across audit, identity, and endpoint data), and custom detection rules (scheduling KQL queries that alert when specific audit patterns are detected).

For most security investigations, Sentinel KQL is the more powerful approach because it enables correlation with other data sources. The Purview portal search is useful for quick, focused queries when you need a specific answer fast and do not need cross-source correlation.

1
2
3
4
5
6

// Audit data in Sentinel — all activity by a compromised user
OfficeActivity
| where TimeGenerated > ago(48h)
| where UserId =~ "j.morrison@northgateeng.com"
| summarize EventCount = count() by Operation, bin(TimeGenerated, 1h)
| order by TimeGenerated asc, EventCount desc

Investigation scenarios where audit data is primary evidence

Scenario 1: Compromised mailbox — what did the attacker read? After confirming account compromise through sign-in analysis (Module 1), search MailItemsAccessed for the compromise window. The result shows every email the attacker opened, the IP address they accessed it from, and the client application they used. This is often the most important evidence in an AiTM or BEC investigation.

Scenario 2: Data exfiltration scope — how many files were downloaded? After a compromised account incident, search FileDownloaded events for the user during the compromise window. The result shows every file downloaded, from which SharePoint site or OneDrive folder. Cross-reference with the file names and sensitivity labels to assess the data exposure scope.

Scenario 3: Admin compromise — what configuration changes were made? After detecting unauthorized administrative access, search admin events (Add member to role, Update user, Add application) for changes during the compromise window. The result shows every administrative action the attacker took — role escalations, account creations, OAuth application registrations.

Scenario 4: Inbox rule manipulation — was email being forwarded? After any email compromise, search New-InboxRule and Set-Mailbox events. The result shows whether the attacker created forwarding rules to exfiltrate email to an external address. This is one of the first post-compromise actions in BEC attacks and must be checked in every compromised mailbox investigation.

Knowledge check