My colleague @SantasaloJoosua asked me last week: “Can you verify are changes made for Azure AD sign-in & audit logs export settings (known as diagnostics settings) audited in Azure Activity Log”? My first impression was, sure they are, but are they?
Disclaimer: Status at the time of writing (04/19/2021), tested in three (3) environments.
Imagine a scenario where you have Azure Sentinel (or 3rd party SIEM) deployed and it creates alerts/incidents based on the analytic rules. A bad actor get 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 Azure Sentinel are not created because the data newer arrives to the Azure Log Analytics.
Side note: If you establish data export configuration initially from Azure Sentinel it writes changes to the Azure AD diagnostics setting and creates own diagnostics settings resource. If you already have one in place it will be the target.
The Azure Activity Log schema contains event category for microsoft.aadiam provider and diagnostics setting activities but at the end of the day related events are not found from the Azure Activity Log.
Solution – Cloud App Security?
Once again I turned to my trusted fellow in matter of security monitoring – Microsoft Cloud App Security aka MCAS. If you have following pre-requisites defined you will receive necessary data to monitor the needed activity in this specific use case:
- Azure subscription connected through app connector
- MCAS receives rich information from the Azure management API (management.azure.com) of the activities performed in both, in Azure and Azure AD
With the following query you can find any changes made to microsoft.aadiam provider diagnostics settings (change your own tenant name to URI).
Events and raw data where you can verify the write operation to the resource.
If settings are changed alert would be nice. The following MCAS policy does a trick. It has only necessary parameters and fine-tune it based on needs. Easiest way to create a alert policy is to use URI above and use “select policy from search”.
If everything works as expected, at the end of the day you should have alert in MCAS.
And if inter-connections are properly configured, also in Azure Sentinel
This was tested in three (3) different environments and was behavior at the time of writing. It might be already tackled by MS but if it isn’t there is at least workaround available!
Until next time!