Microsoft Sentinel Platform: Audit Logs and Where to Find Them

*Thank you to my teammates Ian Parramore and David Hoerster for reviewing and contributing to this blog.*

With the launch of the Sentinel Platform, a new suite of features for the Microsoft Sentinel service, users may find themselves wanting to monitor who is using these new features and how. This blog sets out to highlight how auditing and monitoring can be achieved and where this data can be found.

What are Audit Logs?

Audit logs are documented activities that are eligible for usage within SOC tools, such as a SIEM. These logs are meant to exist as a paper trail to show:

1. Who performed an action
2. What type of action was performed
3. When the action was performed
4. Where the action was performed
5. How the action was performed

Audit logs can be generated by many platforms, whether they are Microsoft services or platforms outside of the Microsoft ecosystem. Each source is a great option for a SOC to monitor.

Types of Audit Logs

Audit logs can vary in how they are classified or where they are placed. Focusing just on Microsoft, the logs can vary based on platform. A few examples are:

-          Windows: Events generated by the operating system that are available in EventViewer

-          Azure – Diagnostic logs generated by services that can be sent to Azure Log Analytics

-          Defender – Audit logs generated by Defender services that are sent to M365 Audit Logs

What is the CloudAppEvents Table?

The CloudAppEvents table is a data table that is provided via Advanced Hunting in Defender. This table contains events of applications being used within the environment. This table is also a destination for Microsoft audit logs that are being sent to Purview. Purview’s audit log blade includes logs from platforms like M365, Defender, and now Sentinel Platform.

How to Check if the Purview Unified Audit Logging is Enabled

For CloudAppEvents to receive data, Audit Logging within Purview must be enabled and M365 needs to be configured to be connected as a Defender for Cloud Apps component.

Enabling Audit Logs

By default, Purview Auditing is enabled by default within environments. In the event that they have been disabled, Audit logs can be enabled and checked via PowerShell. To do so, the user must have the Audit Logs role within Exchange Online. The command to run is:

Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled

The result will either be true if auditing is already turned on, and false if it is disabled. If the result is false, the setting will need to be enabled. To do so:

1. Install the Exchange Online module with:
2. Import-Module ExchangeOnlineManagement
3. Connect and authenticate to Exchange Online with an interactive window
4. Connect-ExchangeOnline -UserPrincipalName USER PRINCIPAL NAME HERE
5. Run the command to enable auditing
6. Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true

Note: It may take 60 minutes for the change to take effect.

Connecting M365 to MDA

To connect M365 to MDA as a connector:

1. Within the Defender portal, go to System > Settings.

 

 

2. Within Settings, choose Cloud Apps.
3. Within the settings navigation, go to Connected apps > App Connectors.

 

 

4. If Microsoft 365 is not already listed, click Connect an app.
5. Find and select Microsoft 365.
6. Within the settings, select the boxes for Microsoft 365 activities.
7. Once set, click on the Connect Microsoft 365 button.

 

Note: You have to have a proper license that includes Microsoft Defender for Cloud Apps in order to have these settings for app connections.

Monitoring Activities

As laid out within the public documentation, there are several categories of audit logs for Sentinel platform, including:

1. Onboarding/offboarding
2. KQL activities
3. Job activities
4. Notebook activities
5. AI tool activities
6. Graph activities

All of these events are surfaced within the Purview audit viewer and CloudAppEvents table. When querying the table, each of the activities will appear under a column called ActionType.

Onboarding

 

For querying these activities, one example would be:

CloudAppEvents
| where ActionType == ‘SentinelLakeDefaultDataOnboarded’
| project AccountDisplayName, Application, Timestamp, ActionType

 

KQL Queries

There is only one type of activity for KQL available. These logs function similarly to how LAQueryLogs work today, showing details like who ran the query, if it was successful, and what the body of the query was.

 

For querying these activities, one example would be:

CloudAppEvents
| where ActionType == ‘KQLQueryCompleted’
| project Timestamp, AccountDisplayName, Application, RawEventData.Interface, RawEventData.QueryText, RawEventData.TotalRows

 

Jobs

Jobs pertain to KQL jobs and Notebook jobs offered by the Sentinel Platform. These logs will detail job activities as well as actions taken against jobs. This will be useful for monitoring who is creating or modifying jobs, as well as monitoring that jobs are properly running.

 

For querying these activities, one example would be:

CloudAppEvents
| where ActionType == ‘JobCreated’
| project Timestamp, AccountDisplayName, Application, ActionType, RawEventData.JobName, RawEventData.JobType, RawEventData.Interface

AI Tools

AI tool logs pertain to events being generated by MCP server usage. This is generated any time that users operate with MCP server and leverage one of the tools available today to run prompts and sessions.

 

For querying these activities, the query would be:

CloudAppEvents
| where ActionType == ‘SentinelAIToolRunStarted’
| project Timestamp, AccountDisplayName, ActionType, Application, RawEventData.Interface, RawEventData.ToolName

Notebooks

Notebook activities pertain to actions performed by users via Notebooks. This can include querying data via a Notebook, writing to a table via Notebooks, or launching new Notebook sessions.

 

For querying these activities, one example would be:

CloudAppEvents
| where ActionType == ‘TableRead’

 

Graph Usage

Graph activities pertain to users modifying or running a graph based scenario within the environment. This can include creating a new graph scenario, deleting one, or running a scenario.

For querying these activities, one example would be:

CloudAppEvents
| where ActionType == 'GraphQueryRun'
| project AccountDisplayName, IsExternalUser, IsImpersonated, RawEventData.['GraphName'], RawEventData.['CreationTime']

 

Monitoring without Access to the CloudAppSecurity Table

If accessing the CloudAppSecurity table is not possible in the environment, both Defender and Purview allow for manually searching for activities within the environment.

For Purview (https://purview.microsoft.com), the audit page can be found by going to the Audit blade within the Purview portal.

 

 

For Defender, the audit blade can be found under Permissions > Audit

 

To run a search that will match Sentinel Platform related activities, the easiest method is using the Activities – friendly names field to filter for Sentinel Platform.

Custom Ingestion of Audit Logs

If looking to ingest the data into a table, a custom connector can be used to fetch the information. The Purview Audit Logs use the Office Management API when calling events programmatically. This leverages registered applications with proper permissions to poll the API and forward the data into a data collection rule. As the Office Management API does not support filtering entirely within the content URI, making a custom connector for this source is a bit more tricky. For a custom connector to work, it will need to:

1. Call the API
2. Review each content URL
3. Filter for events that are related to Sentinel Platform

This leaves two options for accomplishing a custom connector route:

1. A code-based connector that is hosted within an Azure Function
2. A codeless connector paired with a filtering data collection rule

This blog will just focus on the codeless connector as an example. A codeless connector can be made from scratch or by referencing an existing connector within the Microsoft Sentinel GitHub repository. For the connector, an example API call would appear as such:

https://manage.office.com/api/v1.0/{tenant-id}/activity/feed/subscriptions/content?contentType=Audit.General&startTime={startTime}&endTime={endTime}

When using a registered application, it will need ActivityFeed.Read read permissions on the Office Management API for it to be able to call the API and view the information returned. The catch with the Management API is that it uses a content URL in the API response, thus requiring one more step. Luckily, Codeless Connectors support nested actions and JSON. An example of a connector that does this today is the Salesforce connector. When looking to filter the events to be specifically the Sentinel Platform audit logs, the queries listed above can be used in the body of a data collection rule. For example:

"streams": [
                    "Custom-PurviewAudit"
                ],
                "destinations": [
                    "logAnalyticsWorkspace"
                ],
                "transformKql": "source | where ActionType has_any (‘GraphQueryRun’, ‘TableRead’… etc)
                "outputStream": "Custom-SentinelPlatformAuditLogs”

Note that putting all of the audit logs may lead to a schema mismatch depending on how they are being parsed. If concerned about this, consider placing each event into different tables, such as SentinelLakeQueries, KQLJobActions, etc. This can all be defined within the data collection rule, though the custom tables for each action will need to exist before defining them within the data collection rule.

 

Closing

Now that audit logs are flowing, actions taken by users within the environment can be used for detections, hunting, Workbooks, and automation. Since the logs are being ingested via a data collection rule, they can also be sent to Microsoft Sentinel data lake if desired. May this blog lead to some creativity and stronger monitoring of the Sentinel Platform!