Auditing of data ingestion (audit trail) to security solutions, especially to SIEM, is crucial to have defensive mechanisms working as expected. This blog post contains information on how you can detect activity when Azure AD diagnostic settings are changed and there is a possibility that the adversary has stopped sending audit data to your security solution.

Disclaimer: Status at the time of writing (05/30/2022), tested in two (2) environments.

MITRE ATT&CK Framework

This adversary action is mapped to the following TTP:

Description of the sub-technique – Disable Cloud Logs

An adversary may disable cloud logging capabilities and integrations to limit what data is collected on their activities and avoid detection.

Cloud environments allow for the collection and analysis of audit and application logs that provide insight into what activities a user does within the environment. If an adversary has sufficient permissions, they can disable logging to avoid detection of their activities

Background

Imagine a scenario where you have Azure Sentinel (or 3rd party SIEM) deployed and it creates alerts/incidents based on the ingested audit data & analytic rules. A bad actor gets access to the environment and makes changes to Azure AD diagnostics export settings. This leads to the situation where Azure AD Sign-in & Audit logs are not exported from Azure AD and alerts/incidents in the SIEM solution are not created because the data newer arrives in there. In my example I’m using Microsoft Sentinel and Azure Log Analytics to simulate the scenario.

Events

The Azure AD audit log doesn’t contain any event of the activity.

Azure Activity Log schema contains the event category for ‘microsoft.aadiam’ provider and diagnostics setting activities but any related events are not found in the Azure Activity Log.

Side note: If you establish data export configuration initially from Microsoft Sentinel it writes changes to the Azure AD diagnostics setting and creates its own diagnostics settings resource.

Solution – MDA, Sentinel or M365D

Earlier I used Defender for Cloud Apps (MDA) to detect the activity but now, it’s possible to ingest MDA raw data (Activity Log) through the M365 Defender (M365D) data connector into Sentinel the detection mechanism can be built in Sentinel instead of Defender for Cloud Apps.

There is one prerequisite – you need to have the Azure subscription connected to MDA through the app connector.

Side note: MDA receives rich information from the Azure management API (management.azure.com) of the activities performed in Azure and Azure AD.

The Query in MDA

With the following query, you can find any changes made to ‘microsoft.aadiam’ provider diagnostics settings (change your own tenant name to URI).

https://<domainname>.portal.cloudappsecurity.com/#/audits/?service=eq(i:12260,)&activity.eventType=eq(12260:EVENT_AZURE_GENERIC:microsoft.aadiam%2FdiagnosticSettings%2Fwrite,)&activityObject=eq(%2Fproviders%2Fmicrosoft.aadiam%2FdiagnosticSettings%2Fazureaddiaglogs,)

Raw data and events are provided by the MDA where you can verify the write operation to the resource.

Policy in MDA

If Sentinel is not used the detection can be built in MDA or even in ‘M365 Defender’. in MDA, the following MDA policy does a trick. It has only necessary parameters and some fine-tuning might be needed based on your needs. The easiest way to create an alert policy is to use URI above and use “select policy from search”.

Sentinel

As mentioned above, integration between Sentinel & M365 Defender makes it possible to ingest ‘Defender for Cloud Apps’ raw data to Sentinel. When ingested, you have the possibility to create detections based on the raw data provided by Defender for Cloud Apps.

Data flow: MDA -> M365D – Sentinel

Data flow is configured and enabled in Microsoft Sentinel data connector settings.

Detection Query & Rule Settings

To create an incident from the event here is KQL I used to create the detection rule

CloudAppEvents
| where ApplicationId == '12260'and Application == 'Microsoft Azure'
| where ActivityObjects[1].Name contains 'microsoft.aadiam/diagnosticSettings'
| where ActionType contains 'Write DiagnosticSettings' or ActionType contains 'Delete DiagnosticSettings'
| where ActivityObjects[4].Name == "Operation status"
| where ActivityObjects[4].Value == "Succeeded"
| extend Id_ = tostring(ActivityObjects[0].Id)
| extend Name_ = tostring(ActivityObjects[1].Name)
| extend scope_ = tostring(parse_json(tostring(RawEventData.authorization)).scope)

The whole analytics rule with settings is found on GitHub.

Incident

If pre-requisites mentioned above are configured as needed, and someone makes a change to Azure AD diagnostic settings, you will receive an incident at the end of the day in Sentinel.

M365 Defender

The same query works in M365D than in Sentinel and can be found on GitHub.

Summary

I tested the scenario in two (2) different environments and the behavior was identical, with no sign of an audit event in native logs.

If you are using 3rd party SIEM but Defender for Cloud Apps this detection can be established by creating a detection policy on the MDA side which will be synced to the M365 Defender incident & alerts queue.

Until next time!