Microsoft is clearly moving toward a more unified security operations experience within the Defender portal. Over the last few years, we have seen Microsoft bring more security capabilities together under the Defender platform. Instead of working with completely separate portals for endpoint, identity, email, cloud applications, and other security controls, the goal is to give security teams a more integrated SecOps experience.
As a security administrator, I want to investigate an incident, understand what happened, take action, and follow the complete investigation from one place.
But there is another side to this story that is becoming increasingly important.
What about auditing the actions performed by security administrators and privileged users?
A unified portal is not the same as unified visibility
The Defender portal is becoming the central place for security operations. That means more and more operational activities can be performed from the same Defender experience.
For example, an administrator might investigate an incident and then change a security configuration. Another administrator might modify a Defender setting, while an Intune administrator changes a policy that affects thousands of devices, or Sentinel workspaces can be disconnected.
From the operational perspective, the change might be completely legitimate. But from an audit perspective, I want to know exactly what happened.
- Who performed the action?
- When?
- What was changed?
- What was the previous value?
- What is the new value?
- Why was the change made?
This becomes even more important when the change affects a large part of the environment.
Example: Tamper Protection
Let’s take a simple example: Microsoft Defender Tamper Protection.
Tamper Protection is an important security control because it helps prevent security settings from being modified or disabled by unauthorized users or malicious software. I generally consider this a setting that should be carefully controlled and monitored.
Now imagine that an administrator or malicious actor changes a global Defender configuration related to Tamper Protection. Is it visible, maybe when you check the portal. By default, Microsoft is not generating an alert when global settings are changed. Similar for automation accounts and remediation levels within Defender.
Intune policies are another good example
The same problem exists with Microsoft Intune.
Intune contains a huge number of security-related configuration options. Endpoint security policies, configuration profiles, compliance policies, security baselines, Defender settings, firewall configuration, attack surface reduction rules, and many other settings can have a significant impact on an environment. Imagine someone changes an Intune policy assigned to all corporate Windows devices.
When troubleshooting the situation, one of the first questions will normally be:
Who changed the policy?
The second question is:
What exactly did they change?
And then:
What was the previous configuration?
This is where audit visibility becomes extremely important. Is there default alerting from Microsoft Intune/ Defender on settings? Nope. The only way to detect the change natively is via Exposure Management or the lowering score in Secure Score.
This is the interesting part of Microsoft’s move toward a unified Defender SecOps model. The more capabilities Microsoft brings together, the more important it becomes to provide a correct audit experience.
What are the auditing options within Defender?
There are a couple of auditing options available within the Defender console and portal. I will mention the most important auditing options for both security and Microsoft Intune.
Purview/ Defender audit log
Defender audit activities are stored in the Unified Audit Log. Some of the audited activities include:
- Assign user to an incident
- Changes to data retention settings
- Changes to advanced features
- Creation of indicators of compromise
- Isolation of devices
- Add\edit\deletion of security roles
- Create\edit custom detection rules
Microsoft Defender uses the Microsoft Purview auditing solution. Before you can look at the audit data in the Microsoft Defender portal, you need to turn on auditing in the Microsoft Purview portal, or sometimes it works directly from the Defender portal.
For a list of all the audit log activities, see: Audit log activities. The audit log is not only focused on Defender for Endpoint. It includes other sources, like Defender for Identity, to report when sensors are getting removed/ disabled, or the deployment key is downloaded. All of the audit log activities are explained on the above page.
Permissions
To view the activities in the Unified Audit Logs, you will need to have one of the following roles. For the Advanced Hunting part, different permissions are needed. More on that later.
- Global Administrator
- Compliance Administrator
- Organization Management
Enable Defender auditing in Defender portal
To allow auditing activities to flow into the Unified Audit Log you might need to change the configuration. The first step is to enable Unified Audit Log integration in Defender for Endpoint. This can be completed via System ->Settings -> Endpoints -> Optional Features and enabling the Unified Audit Log. When the integration is enabled, all audit activities will change in the Unified Audit Log.
Update: Since end of 2025 the auditing capability is by default enabled and no configuration is required. The feature in Optional Features is removed.
Ways to search in the audit log?
Go to the Microsoft Defender portal’s Audit page. You can also open the Purview compliance portal and select Audit. If you have the right permissions, the Audit menu item is available in the Microsoft Defender portal. In the audit log search, you can filter for specific workload activities as explained earlier in the audit log activities overview.
In the audit log, you can search for Defender activities or related activities:
When performing a search, it will be queued; after some time, the data is visible.
How to create detections and move data to Advanced Hunting?
The power of operational visibility is the ability to create detection rules and alerts based on the dataset. Directly in Purview, there is no option to generate alerts, and data is not by default visible in the Advanced Hunting schema. One of the benefits of Defender unified secops is the integration with Defender for Cloud Apps.
Via Defender for Cloud Apps, it is possible to extract the Unified Audit Logs data and forward it to the CloudAppEvents table in Defender. If data is available in one of the tables in Defender XDR, custom detection is possible. Another benefit of the CloudAppEvents table is that you don’t need the high permissions needed for Purview.
The logs are collected via the Microsoft 365 connector in Defender For Cloud Apps, if you have a Defender for Cloud Apps license, it is sufficient for the environment, and no additional cost is involved (except if you stream data to Log Analytics or Sentinel; all this is not needed anymore with Unified SecOps).
Go to Settings -> Cloud apps -> App Connectors
Make sure that the Microsoft 365 app is connected. When connected confirmed that all activities are selected in the configuration. For audit activities, the Microsoft 365 Activities component is important. It is recommended to enable all components.
After some time, the connector is connected, and data is directly visible in the Advanced Hunting schema. All audit data will be routed to the CloudAppEvents table. The schema explanation is well explained here.
In the table, you can easily search for Defender workloads or other workloads, as explained in the earlier Microsoft Learn docs from Microsoft. With the following query, you can search all events where the workloads contain “Defender”
CloudAppEvents
| extend WorkLoad = tostring(parse_json(RawEventData).Workload)
| where WorkLoad contains "Defender"As shown in the image below, the activities and action types are clearly visible. The image highlights changes to the advanced features, including an update to the status of the custom detection rule.
The dataset can be used to create detection, good example is later in this blog.
Microsoft Intune diagnostic logging
Another important source of security audit data is Microsoft Intune. Intune is especially interesting from a security perspective because it contains many configuration controls that can directly affect the security posture of managed devices.
Think about:
- Endpoint security policies
- Microsoft Defender policies
- Attack Surface Reduction rules
- Firewall policies
- Antivirus configuration
- Security baselines
- Compliance policies
- Configuration profiles
- Application deployments
- Device actions
- Privileged Endpoint Management
- Cloud PKI configuration
A change to one of these configurations can potentially affect hundreds or thousands of devices. The Intune audit logs can be accessed from the Microsoft Intune admin center. However, for a SOC, manually opening the Intune portal every time you want to investigate a change isn’t ideal.
This is where the integration with Azure Monitor becomes interesting.
Send data to Sentinel/ Log Analytics
Microsoft Intune now provides Diagnostics settings that allow Intune logs to be routed to Log Analytics Workspace.
For audit monitoring, the most interesting option is:
Intune → Reports → Diagnostics settings → AuditLogs
The AuditLogs category can be sent to:
- Azure Storage
- Azure Event Hubs
- Log Analytics
When the Log Analytics workspace is integrated with the Unified SecOps portal, data becomes visible in the same Defender Unified SecOps portal.
Select the following categories for sending audit data to the Log Analytics Workspace.
- AuditLogs
- OperationalLogs
The data is visible in Microsoft Defender
All data and the related policy/ changes values are part of the additional details and the properties field.
Custom detections in Defender
With this additional data, you can create custom detections. Good examples include:
- Offboarding Package Downloaded
- Live Response File Collection
- Custom Detection Deletion
- Change of advanced features
Change of advanced features
With the following query, you can track changes in the advanced features.
CloudAppEvents
| where RawEventData.Workload =~ "MicrosoftDefenderForEndpoint"
| where ActionType =~ 'SetAdvancedFeatures'
| extend SettingName = RawEventData.SettingName
| extend UserPrincipalName = RawEventData.UserId
| extend Setting = RawEventData.SettingName
| extend ChangedTo = RawEventData.SettingsNewValue
| project TimeGenerated, Timestamp, ReportId, ActionType, Setting, ChangedTo, UserPrincipalName, AccountId, IPAddress, RawEventData
The changeTo value is visible, which explains that the value is changed from true to false.
In this blog, I will not explain all the queries; check the source of Bert-Jan Pals for some good queries: Hunting-Queries-Detection-Rules/Defender XDR at main · Bert-JanP/Hunting-Queries-Detection-Rules · GitHub
When needed, you can use the Advanced Hunting query in a custom detection. With this, I’m able to generate alerts in the Defender portal. Useful when, for example, Tamper Protection or other critical features are getting changed and alerts need to be created in the portal of Defender.
POC: Intune auditing via GitHub
Below is still in concept and evaluating whether this works. Just to share some ideas.
Recently I created a small POC via GitHub, where GitHub is the source of truth for Intune policies. Every policy Defender AV, Attack Surface Reduction rules, exclusions lives as a JSON file in a repository. Changes only happen through a pull request, get reviewed, and are then synced to Intune automatically via the Graph API.
That part solves the change management problem. But it does not, on its own, solve the audit problem described above. Someone can still open the Intune portal and change a setting directly, bypassing the entire process; however, the policies are getting changed after some minutes after the initial GitHub action sync.
Closing the native auditing gap
As covered earlier, Intune has no default alerting when a policy setting changes. You either build a Log Analytics pipeline, or you accept that drift goes unnoticed until something breaks or a Secure Score drop points you in the right direction after the fact.
The GitHub-based approach adds a much lighter alternative: a scheduled job that treats GitHub as the expected state and Intune as the observed state, and simply checks whether the Intune policy is similar compared with the source in GitHub.
The result is a GitHub Issue with all the information:
In the explanation of the policy drift, you can easily see the difference between the GitHub value (source) and Intune/ Defender value.
Tenant Configuration Management APIs
This is one of the topics I will explore next time.
Microsoft is also introducing the Tenant Configuration Management (TCM) APIs in Microsoft Graph, which provide another interesting approach to managing and monitoring configuration across Microsoft 365 workloads.
The APIs currently cover several Microsoft 365 workloads, including:
- Microsoft Defender
- Microsoft Entra
- Microsoft Exchange Online
- Microsoft Intune
- Microsoft Purview
- Microsoft Teams
This is particularly interesting from an auditing and configuration-drift perspective because it moves the discussion from simply asking “Who changed this setting?” to also asking “Does the tenant still match the configuration we expect?”
The monitoring APIs can help identify configuration drift, while snapshot APIs provide a view of the current configuration. This makes TCM particularly interesting for security teams that want to move beyond audit logs and continuously verify that the tenant remains desired.
Microsoft Learn: Tenant Configuration Management APIs
Conclusion
Microsoft’s move toward a unified Defender SecOps experience brings clear benefits for security operations, but it also makes audit visibility increasingly important. As more security and configuration activities are brought together, security teams need to be able to answer a simple but critical question: who changed what, when, and from which previous state? A unified portal without unified auditing can still leave important gaps in visibility.
This blog explains a couple of ideas for how to perform additional audit logging for Defender activities. With the Unified Audit Log and Intune diagnostic logging, you can create additional detection use cases in the Defender portal.
Auditing Microsoft Defender and Intune Configuration Changes
