Last reviewed:
How SOC teams can use Azure Activity Log telemetry to detect control-plane change, role assignment abuse and logging tamper without confusing audit evidence with identity sign-in evidence.
The Azure Activity Log records subscription-level control-plane events. It shows who requested an operation, which resource provider handled it, which resource changed, whether Azure accepted the request and which correlation id ties related operations together. That makes it a strong source for detecting management-plane change. It is not a record of every data-plane action inside a storage account, virtual machine or database.
SOC teams should keep the original Activity Log fields visible during review: operationName, category, status, subStatus, caller, claims, authorization, resourceId, resourceGroupName, subscriptionId, eventTimestamp, correlationId and properties. In Microsoft Sentinel, the AzureActivity table commonly exposes parsed columns such as OperationNameValue, CategoryValue, ActivityStatusValue, ActivitySubstatusValue, Caller, Claims_d, Authorization_d, ResourceId, ResourceGroup, SubscriptionId, TimeGenerated, CorrelationId and Properties_d. Detection notes should still point back to the Azure source field that made the alert possible.
The Activity Log sits beside Microsoft Entra ID audit and sign-in logs, not above them. Entra ID records identity directory events, application consent and sign-in behaviour. Activity Log records Azure Resource Manager operations. A strong investigation often needs both, but the coverage report should say which source supports each finding.
A long list of Azure operation names is a poor detection plan. Start with behaviour families that a SOC can review: privileged access change, managed identity and resource identity configuration, logging and diagnostic setting tamper, policy and network control change, and high-risk resource deletion. Keep Microsoft Entra application and service-principal directory changes in a separate Entra audit-log lane, then correlate them with Activity Log evidence when the same investigation needs both.
Privileged access change usually centres on Microsoft.Authorization operations such as roleAssignments/write and roleDefinitions/write. The useful context is the caller, target scope, role definition, assignee, subscription and whether the action matches an approved change window. A role assignment at management group or subscription scope deserves a different severity model from a narrow resource-group assignment.
Logging tamper should be treated separately. Changes to diagnostic settings, Activity Log export routes, policy assignments or monitoring configuration can reduce the evidence available after an intrusion. These events are rarely noisy enough to ignore, but they still need allowlisted deployment pipelines and break-glass processes recorded before the alert goes live.
Activity Log detections can support ATT&CK mappings, but the mapping should say what the log actually proves. A suspicious role assignment by a compromised administrator can support T1078.004 Valid Accounts: Cloud Accounts and T1098 Account Manipulation. A routine deployment pipeline changing the same assignment may be expected administration. The event name alone does not decide the technique.
Use evidence labels in the coverage model. Direct detection evidence means the Activity Log event and tenant context are enough to alert. Correlation context means the event matters only when paired with another signal, such as an Entra sign-in from a new country followed by subscription-scope role assignment. Posture context means the event describes exposure or readiness, not attacker behaviour by itself.
This labelling keeps Azure coverage honest. The SOC can still see that Activity Log supports Valid Accounts, Account Manipulation and some defence-evasion review, while the report avoids claiming that every administrative operation is a tested detection.
def azure_activity_evidence_kind(event):
if event.operation_name.endswith('/roleAssignments/write') and event.scope_is_broad:
return 'direct-detection:T1098'
if event.operation_name.endswith('/diagnosticSettings/delete'):
return 'direct-detection:logging-tamper'
if event.operation_name.endswith('/policyAssignments/write') and event.has_no_change_ticket:
return 'correlation-context:control-change'
if event.category == 'Administrative' and event.status == 'Failed':
return 'correlation-context:failed-management-operation'
return 'posture-context'
Many Azure SOC teams review Activity Log data in Microsoft Sentinel. The connector can bring Azure Activity records into the workspace, where queries often use tables and parsed columns rather than the raw JSON shape. That is fine, provided the rule note still maps the SIEM field back to the Microsoft source field.
For each detection, keep a small field map beside the query. It should record the Azure source field, the Sentinel column, whether the field is always present and which tenant, management group or subscription scope the query covers. This avoids a common failure mode: a query passes in the lab, but production data lands in a different workspace or misses the field that the rule expects.
CloudSigma belongs in the CVE and advisory-to-Sigma lane. For Activity Log programme work, operators should test their own Sentinel, Splunk, Elastic, OpenSearch or Google SecOps queries against tenant data, known deployment tools and emergency access procedures before counting the coverage as live.
Review Activity Log detections when a new subscription joins the tenant, when Microsoft changes resource-provider operations, after a monitoring architecture change or after an incident shows that an Azure operation was visible but unmapped. The review should include collection scope as well as query logic. A good rule cannot fire for a subscription whose Activity Log export never reaches the SIEM.
A quarterly Azure review should ask which broad-scope role assignments have no alert, which detections depend on Entra logs that are not retained long enough, which monitoring changes are performed only by named automation, and which ATT&CK mappings are still marked as correlation context. Those answers give the backlog a useful shape.
DCV records the technique mapping and evidence class beside the Azure source. The value is the gap list: subscriptions not covered by Activity Log export, rules that lack parser validation, and mapped techniques that need Entra ID, Defender for Cloud or resource-specific logs before they can be treated as direct detection evidence.