How to Discover New Audit Events in the Office 365 Audit Log (Including App Consents)

Many Different Audit Events Generated Across Microsoft 365

Following the publication of the article describing how to report the use of sensitivity labels by using audit events, a reader asked what’s the best way to discover if a feature generates an audit event. At the time of writing, a range of Microsoft 365 workloads create and store more than 1,600 different audit events in the audit log, so understanding every auditable operation is a massive task. New audit events appear in the audit log on an ongoing basis as Microsoft introduces new features, hopefully with an accompanying audit event, or backfills by updating features so that they generate audit events.

How We Look for New Audit Events

Our method to discover new audit events is simple. It depends on the fact that every audit event notes an operation, or action performed to generate the event. You can filter audit records by specifying the type of operations to see. For instance, to see who send email on behalf of a shared mailbox, you can look for audit events with the SendAs operation. Here’s what we do to find if a new feature is captured in an audit event.

  • First, use the new feature. Ideally, perform actions several times with different accounts.
  • Second, wait for at least an hour to allow the ingestion of audit events from the source workload and appear in the audit log.
  • Next, run a search to find all audit events for the current day and group and sort the results by operation. Make sure to specify the user principal name of the account which performed the accounts in the UserIds parameter.
$Records = Search-UnifiedAuditLog -StartDate (Get-Date -format dd-MMM-yyyy) -EndDate ((Get-Date).AddDays(1))  -ResultSize 2000 -Formatted -UserIds James.Ryan@office365itpros.com
$Records | Group Operations | Sort Count -Descending | Format-Table Count, Name

You should now be able to browse the sorted list of operations to find unfamiliar actions, such as Set-LabelPolicy (logged when someone updates a sensitivity label policy). You can take the same approach with the Audit search feature in the Compliance Center, but not all audit events show up there.

Investigating a New Audit Event

Typically, the new events appear at the end of the list. For instance, looking at a recent set, we see an event called Consent to application. This hadn’t come to our attention before:

    1 Consent to application.
    1 Get-DlpSiDetectionsReport
    1 New-Mailbox
    1 Set-TenantObjectVersion
    1 Set-AdminAuditLogConfig
    1 Get-ComplianceTag
    1 Send
    1 SoftDelete

Checking the event, we found that the event originated in Azure Active Directory and relates to granting OAuth consent (permission to access data) to an application. Due to recent problems like the SolarWinds attack, there’s been heightened sensitivity to the need to understand what access to data has been granted within an organization. If you don’t know who can access data, you can’t detect and remediate illicit consents which might have been secured by attackers. While other tools like the PowerShell script created by Microsoft (see this article) are better at enumerating and reporting consent grants for review, it’s interesting to find that Azure AD captures audit event for consents, In this case, an examination of the event data revealed that the consent was for the Microsoft Events app used for purposes like registering for the Microsoft Ignite online conference.

Checking the app registration in the Azure AD admin center, you can find the permissions assigned to the app. In this case, the app reads Azure AD to fetch details of people who register using their Azure AD account.

Checking app registration details in the Azure AD admin center
Figure 1: Checking app registration details in the Azure AD admin center

You can confirm that you’re looking at the same app by checking the application ID in Azure AD (e462442e-6682-465b-a31f-652a88bfbe51) with the details captured in the audit record:

{
                     "ID": "e462442e-6682-465b-a31f-652a88bfbe51;https://microsoft.onmicrosoft.com/aef17311-1f14-4e06-939b-42c0bcff5520",
                     "Type": 4
}

This example illustrates the value of checking for new audit events periodically. Now that we know that consent grants are auditable, it’s easy to create a script to report consent grants over the last 90 days (the time audit events are kept for E3 accounts). You can grab an example script from the Office 365 IT Pros GitHub repository. See the Cloud Architect GitHub page for more information about resisting consent grant attacks.

Microsoft Datacenter Operations

Searching the audit log to find new events also uncovers audit events logged when Microsoft updates tenant settings as part of their normal datacenter operations. For instance, Microsoft often updates OWA mailbox policies to introduce a control for a new OWA feature. When this happens, you’ll find audit events logged for a user called NT AUTHORITY\SYSTEM (Microsoft.Exchange.ServiceHost) for the policy updates.

You can do nothing about Microsoft configuration updates, but at least you can discover when they happen by poking around in the audit log.


Chapter 21 of the Office 365 for IT Pros eBook goes into how auditing works in great detail and describes several examples of how audit data answers important questions. If you’re running a tenant, you need to have this information!

One Reply to “How to Discover New Audit Events in the Office 365 Audit Log (Including App Consents)”

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.