SC-200 Microsoft 365 Investigations: Purview Audit, Content Search and Graph Activity Logs

SC-200 names three Microsoft 365 investigation sources: Microsoft Purview Audit records what people and apps did, Content search in Microsoft Purview eDiscovery finds what content exists, and Microsoft Graph activity logs record which Graph API calls were made against your tenant. Choosing the wrong one is the commonest mistake: an audit search can't tell you whether a message body contains a phrase, and a content search can't tell you who downloaded a file.

The three are complementary. A typical business email compromise investigation uses audit search to find the attacker's sign-in session and inbox rules, MailItemsAccessed records to scope which mail was read, content search to find every copy of the phishing message, and search and purge to remove it. Alert triage in the Defender workloads belongs to the sibling topic on Defender alerts; this lesson is about the Microsoft 365 evidence behind them.

To search the audit log you need the Audit Logs or View-Only Audit Logs role in the Microsoft Purview portal, and auditing must be on for the tenant. Both roles allow searching and exporting; Audit Logs also allows turning auditing on or off, so View-Only Audit Logs is the least-privileged choice for analysts who only search.

Two places to assign the same roles

The portal and the cmdlets use different role systems. A role assigned in the Purview portal lets you search in the portal; to run Search-UnifiedAuditLog and the other audit cmdlets, the user needs Audit Logs or View-Only Audit Logs assigned in the Exchange admin center (Exchange Online RBAC). Portal access doesn't carry over to PowerShell: each role system needs its own assignment.

Checking and changing whether auditing is on

Auditing is on by default in Microsoft 365 organisations, but it can be turned off. Check and change it in Exchange Online PowerShell:

Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled
Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true

The same Get- cmdlet exists in Security & Compliance PowerShell, but there its UnifiedAuditLogIngestionEnabled value is always False, even when auditing is on. If portal searches return recent records, auditing is on; read the value in Exchange Online PowerShell before raising a change. Turning ingestion on captures activity from that moment; earlier activity is not backfilled.

Audit (Standard) keeps records for 180 days; Audit (Premium) keeps Exchange, SharePoint, OneDrive and Microsoft Entra ID records of E5-licensed users for one year by default, and custom audit log retention policies can set other durations, up to ten years with an add-on licence. (The Standard default rose from 90 to 180 days in October 2023.)

Who gets the one-year default

Two conditions must both hold. The user who performed the activity needs an Office 365 or Microsoft 365 E5 licence (or an E5 Compliance, Purview suite or eDiscovery and Audit add-on), and the record must come from one of the four workloads in the default policy: AzureActiveDirectory, Exchange, OneDrive, SharePoint. Records from other workloads, such as Teams, keep 180 days even for E5 users, and activity by non-E5 users and guest users keeps 180 days. So for the same E5 user, a OneDrive record outlives a Power BI record created the same day by about six months. The default policy can't be edited.

Custom audit log retention policies

• Role: creating or changing a policy needs the Organization Configuration role in the Purview portal. The audit search roles don't include it.
• Criteria: record types, activities and users; an empty Users field means every user. The Activities field appears only when you select a single record type; with several record types the policy covers all their activities.
• Priority: from 1 (highest) to 10000 (lowest). When several policies match a record, the one with the highest priority (lowest number) wins, regardless of how specific or how long it is. An organisation can have up to 50 policies.
• Custom beats default: any custom policy takes precedence over the default policy, even when it is shorter. For example, a 90-day SharePoint policy covering all users cuts the SharePoint records of E5 users from one year to 90 days.
• Not retroactive: a record's lifetime is set when it enters the audit pipeline, so a new or changed policy affects only records created afterwards.
• Ten years: needs the 10-Year Audit Log Retention add-on on the user who generates the record (not on the analysts who search), plus a ten-year policy covering that user. Licensing only the users in scope keeps the cost down. Any duration beyond one year (three, five, seven or ten years) needs that add-on, and every custom duration, including short ones such as 7 or 30 days, needs E5-level licensing.

Mailbox access records (MailItemsAccessed) use the record type ExchangeItemAggregated; SharePoint and OneDrive file activities such as FileDownloaded use SharePointFileOperation.

An audit search in the Purview portal is an asynchronous search job: you set a date range and filters, start it, and read the results from the search job dashboard when it completes. Jobs keep running after you close the browser, and completed jobs are kept for 30 days, so a long search can be started at the end of a shift and opened the next morning.

Limits that shape an investigation

Search criteria

• Activities - operations names must be the exact operation name, such as New-InboxRule or FileDownloaded. A description such as "New inbox rule" returns nothing. The Activities - friendly names list lets you pick activities by description instead.
• Record types and Workloads narrow by source; a workload filter on its own is tenant-wide.
• File, folder, or site takes part or all of a name or URL, with * as a wildcard at the end. https://fabrikam.sharepoint.com/sites/Projects* returns that site and everything beneath it.
• Keyword Search searches only the indexed common schema of the record, not the audit data content. Values that sit in an operation's parameters (an inbox rule's ForwardTo address, for example) are not found by keyword; filter on the operation, then read the parameters in the record details or export.

Administrative units

An admin assigned one or more Purview administrative units is a restricted admin: they can search and export only user-generated records within their units. Some operations, including Exchange Set-Mailbox, Set-MailboxPlan and SupervisionBulkEmailExclusion, are visible only to unrestricted admins (no unit assignment).

MailItemsAccessed is the mailbox audit action that records when mail is read or synced, and it is part of Audit (Standard): it is on by default for users with Office 365 or Microsoft 365 E3/E5 licences. An E3 organisation can therefore scope which messages an attacker accessed without buying an upgrade. Audit (Premium) adds intelligent insights such as extra properties (for example SensitivityLabel) on the records, not the event itself. The records are in the unified audit log, so portal search, Search-UnifiedAuditLog and the APIs all return them.

Sync versus Bind

De-duplication and separating attacker from owner

To control volume, duplicate records for the same bind within an hour are filtered out, unless the context differs: ClientIPAddress, ClientInfoString, ParentFolder, Logon_type, MailAccessType, MailboxUPN, User or SessionId. For example, a user who opens a message in Outlook on the web and, 40 minutes later, in the Outlook mobile app produces two records, because ClientInfoString and SessionId differ; opening it again in the same browser session within the hour adds nothing. The audit trail shows when each context first touched a message, not every repeat.

In a compromised account the attacker signs in as the owner, so the identity fields can't tell them apart. To separate them, compare SessionId (the sign-in session) and ClientIPAddress (the network), helped by ClientInfoString. Find the attacker's session in the sign-in data first, then filter MailItemsAccessed records to it.

Other mailbox evidence comes from the same audit log: inbox rules created with New-InboxRule or changed with Set-InboxRule, and mailbox forwarding set with Set-Mailbox.

Use Search-UnifiedAuditLog for ad hoc scripted searches, the Microsoft Graph audit log query for filtered searches over REST, and the Office 365 Management Activity API for a continuous feed into a SIEM. Microsoft's guidance for programmatically downloading audit data is the Management Activity API rather than a PowerShell script.

Management Activity API windows

When listing content, startTime and endTime must be no more than 24 hours apart, and the start no more than seven days in the past; older content can't be retrieved (error AF20051). Restarting a subscription gives access only to content from then on, it doesn't replay the past. A gap in the feed is therefore recoverable from the API only for its most recent seven days, in windows of 24 hours or less; anything older has to come from the audit log itself, which still holds it for at least 180 days. Audit (Premium) raises the API's bandwidth allocation.

Graph activity logs, covered below, are a different source: they describe calls made to Microsoft Graph, not Microsoft 365 workload activity.

Content search now means a search in the unified eDiscovery experience, either inside a case or in the organisation's built-in Content Search case, which is meant for searches not tied to a legal matter. Microsoft retired the classic eDiscovery experiences, including classic Content search, on 31 August 2025, so there is no standalone classic search page to use.

Permissions

To create and run searches, a user needs membership of the eDiscovery Manager role group or the Compliance Search role. Deleting messages is a separate right (see search and purge), so an organisation can control who searches mailboxes separately from who deletes. Audit roles and Organization Configuration belong to Purview Audit, not eDiscovery.

Building and checking a search

• Data sources: choose the mailboxes, OneDrive accounts, SharePoint sites and Teams locations to search, or tenant-wide sources.
• Condition builder or KeyQL editor: the condition builder adds condition cards (keywords, date, sender and so on). The KeyQL editor takes a written query; existing conditions are converted to KeyQL when you switch, and a KeyQL condition must stand alone, so further criteria such as a date range go into the KeyQL text joined with AND.
• Choose search results: Statistics shows estimated hit counts arranged by top indicators, optionally with the query keywords report (hits per term); Sample shows a representative selection with a chosen number of items per location. Together they let you check a query before you add results to a review set or export.

Keyword Query Language (KeyQL) is the query syntax for eDiscovery searches, and a few rules decide whether a query returns exactly the intended set or thousands of unrelated items.

Date ranges use two dots between the start and end dates. When a query returns far more than expected, check first for a missing uppercase AND and for unquoted multi-word values; the query keywords report shows which term is responsible.

Search and purge deletes the email found by an eDiscovery search from users' mailboxes, using New-ComplianceSearchAction -Purge in Security & Compliance PowerShell (or Microsoft Graph in a premium case). Purge actions need a search-only session: connect with Connect-IPPSSession -EnableSearchOnlySession using Exchange Online PowerShell module 3.9.0 or later, or the action fails. Where Microsoft Defender for Office 365 Plan 2 is available, Microsoft recommends its remediation (for example from Threat Explorer) instead; search and purge is the route for organisations without it.

Permissions

Purging needs the Search And Purge role or the Organization Management role group in the Microsoft Purview portal. Membership of Organization Management in Exchange Online doesn't count. Without the right, the cmdlet simply has no -Purge parameter, producing the error "A parameter can't be found that matches parameter name 'Purge'". Creating the search itself needs eDiscovery Manager or Compliance Search.

Soft delete or hard delete

Limits

• Items per location: in a case without premium features only PowerShell can purge, up to 10 items per mailbox per action; rerun the action to remove more. Premium (E5) cases can purge up to 100 items per location through Microsoft Graph (purgeData). Don't mix PowerShell and Graph purges for the same search.
• Mailboxes per search: a search used for a purge can cover at most 50,000 mailboxes, and the purge fails if it covers more, even when fewer contain matches. In larger tenants, split the mailboxes with temporary search permissions filters (by department, location and so on) and purge each subset.
• Scope: mailboxes and public folders only. Teams chat messages are removed through a separate process, and SharePoint or OneDrive files aren't purged this way. Unindexed items aren't purged, and when a mailbox is on litigation hold, purged items are kept in Recoverable Items rather than permanently deleted.

Microsoft Graph activity logs are an audit trail of every HTTP request made to Microsoft Graph for resources in your tenant, delivered through a Microsoft Entra diagnostic setting as the MicrosoftGraphActivityLogs category. They show what a compromised app, service principal or user token did through the API, which sign-in logs alone can't.

Turning them on

• Licence: Microsoft Entra ID P1 or P2 for the tenant. Purview Audit licensing plays no part.
• Role: Security Administrator is the least-privileged role that can create the diagnostic setting; Global Administrator works but is broader.
• Destination: a Log Analytics workspace (analysis in Azure Monitor or Microsoft Sentinel), an Azure Storage account (archive), or an event hub (streaming to a third-party SIEM), in an Azure subscription where the admin has permission to use it (for a storage account, the right to list its keys).
• No filtering in the diagnostic setting. To cut cost in a workspace, apply a workspace transformation to the table to drop rows (for example an internal inventory tool's routine reads) or columns. The Basic plan also lowers cost but limits how the table can be queried, so it suits tables kept for occasional investigation rather than ones that detections run against.
• Delivery and scope: most events arrive within 30 minutes, some take up to two hours. Logs exist only from when the setting is configured (no backfill), and they cover the resource tenant: calls a multitenant app makes into a customer's tenant appear in that customer's logs, not the publisher's.

Querying the logs

Key columns are AppId, ServicePrincipalId, UserId, RequestUri, RequestMethod, ResponseStatusCode, IPAddress, Roles, Scopes, ClientAuthMethod and SignInActivityId.

• Permission probing: refused requests show ResponseStatusCode 401 or 403; 429 is throttling and 5xx are service errors.
• App-only versus delegated: a call with application permissions has an empty UserId and its app roles in Roles; a delegated call carries the user's UserId and delegated permissions in Scopes. ClientAuthMethod is 0 for a public client, 1 for a client secret and 2 for a certificate.
• Linking a request to its sign-in: join SignInActivityId to UniqueTokenIdentifier in the sign-in table that matches the actor: SigninLogs or AADNonInteractiveUserSignInLogs for users, AADServicePrincipalSignInLogs for service principals, AADManagedIdentitySignInLogs for managed identities.

This query lists which apps and users changed service principals (for example by adding credentials) over the last week:

MicrosoftGraphActivityLogs
| where TimeGenerated >= ago(7d)
| where RequestUri has "/servicePrincipals"
| where RequestMethod in ("POST", "PATCH", "DELETE")
| where ResponseStatusCode between (200 .. 299)
| summarize Calls = count() by AppId, UserId, RequestMethod
| order by Calls desc

In Defender XDR advanced hunting, the equivalent data is the GraphAPIAuditEvents table (columns such as RequestUri, RequestMethod, ResponseStatusCode, ApplicationId, ServicePrincipalId and IpAddress). MicrosoftGraphActivityLogs exists only in a Log Analytics workspace, so an analyst without a workspace uses GraphAPIAuditEvents.