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, Microsoft 365 workloads store more than 1,600 different events in the audit log, so understanding every auditable operation is a massive task, especially if you’re looking for something specific, like app consent events. New audit events show up 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 app consent events, 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.

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 app consent events are available to track new consents, 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.

If you want to distribute the report in other ways, you could:

• Format the content in HTML and send it via email (see this article for details).
• Create the report in a SharePoint document library (the basics of how to do this is explained here; the scenario is a script running in a Azure Automation runbook but the technique of using PnP cmdlets is the same in “regular” PowerShell).
• Post the report to a Teams channel or post a link to it in a message card created in a Teams channel using the inbound webhook connector. See this article for more information.

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!