Rare Azure Activity Logs Event Failures

A machine learning job detected an unusual failure in an Azure Activity Logs message. These can be byproducts of attempted or successful persistence, privilege escalation, defense evasion, discovery, lateral movement, or collection.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2025/10/06"
  3integration = ["azure"]
  4maturity = "production"
  5min_stack_comments = "New job added"
  6min_stack_version = "9.3.0"
  7updated_date = "2025/12/08"
  8
  9[rule]
 10anomaly_threshold = 50
 11author = ["Elastic"]
 12description = """
 13A machine learning job detected an unusual failure in an Azure Activity Logs message. These can be byproducts of attempted or
 14successful persistence, privilege escalation, defense evasion, discovery, lateral movement, or collection.
 15"""
 16false_positives = [
 17    """
 18    Rare and unusual failures may indicate an impending service failure state. Rare and unusual user failure activity can
 19    also be due to manual troubleshooting or reconfiguration attempts by insufficiently privileged users, bugs in cloud
 20    automation scripts or workflows, or changes to IAM privileges.
 21    """,
 22]
 23from = "now-2h"
 24interval = "15m"
 25license = "Elastic License v2"
 26machine_learning_job_id = "azure_activitylogs_rare_event_action_on_failure"
 27name = "Rare Azure Activity Logs Event Failures"
 28note = """## Triage and analysis
 29
 30> **Disclaimer**:
 31> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
 32
 33### Investigating Rare Azure Activity Logs Event Failures
 34
 35This rule surfaces statistically rare Azure Activity Logs failures, pointing to control‑plane actions that break from typical patterns and may reflect reconnaissance, privilege changes, or defense evasion. A common attacker sequence is using a newly compromised identity to enumerate subscriptions and resource groups through the management API; repeated access denials during these discovery calls can occur as the adversary maps tenant scope and tests permissions before escalating.
 36
 37### Possible investigation steps
 38
 39- Classify the failing operations (discovery vs write/privileged) and tie them to the initiating principal and target scope to gauge intent and blast radius.
 40- Correlate with Entra ID sign-in telemetry for the same principal around the event window to assess geo/device novelty, MFA state, Conditional Access results, and identity risk flags.
 41- Check whether the identity recently had role assignments, group membership, PIM elevation, or app consent changes, and whether this is first-time access to the affected subscriptions or resource groups.
 42- Confirm whether Azure Policy denies, deny assignments, or resource locks explain the failures, and verify whether the principal should legitimately be exempt or granted access.
 43- If the actor is a service principal or managed identity, review recent credential changes (keys/secrets/certificates), app role assignment grants, and automation pipeline updates that could explain unexpected calls.
 44
 45### False positive analysis
 46
 47- A newly deployed automation or audit workflow attempts wide-scope resource discovery using a service principal or managed identity, encountering expected RBAC or policy denials that are rare for that caller.
 48- Recent governance changes such as Azure Policy deny effects, deny assignments, or resource locks cause routine management operations (e.g., writes or deletes) to start failing, creating an unusual failure pattern until baselines adjust.
 49
 50### Response and remediation
 51
 52- Immediately contain the initiating identity by disabling user/service principal sign-in, revoking refresh tokens, and applying a temporary Conditional Access block on Azure management endpoints, while placing deny assignments and resource locks on the impacted subscriptions/resource groups.
 53- Eradicate potential persistence by removing any newly created role assignments, app consent grants, policy exemptions, or management role changes identified in triage, and rotate keys/secrets/certificates for affected service principals or managed identities.
 54- Recover business operations by restoring access only to verified identities through PIM approvals, re-enabling known-good automation accounts/runbooks, and validating that expected management operations succeed without further rare failures on the targeted resources.
 55- Escalate to incident response immediately if rare failures are observed across multiple subscriptions or are followed by a successful privileged action (e.g., new Owner or User Access Administrator assignment, app consent grant, or resource lock removal) or originate from an unfamiliar geo/device, triggering tenant-wide containment.
 56- Harden going forward by enforcing MFA and Conditional Access (including workload identity policies) for Resource Manager access, restricting service principals to least privilege with certificate-based credentials or workload identity federation, implementing deny assignments/resource locks for crown-jewel resources, and centralizing Activity Logs in SIEM with detections for discovery bursts and denied write attempts.
 57"""
 58setup = """## Setup
 59
 60This rule requires the installation of associated Machine Learning jobs, as well as data coming in from Azure Activity Logs.
 61
 62### Anomaly Detection Setup
 63
 64Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).
 65
 66### Azure Activity Logs Integration Setup
 67The Azure Activity Logs integration allows you to collect logs and metrics from Azure with Elastic Agent.
 68
 69#### The following steps should be executed in order to add the Elastic Agent System integration "Azure Activity Logs" to your system:
 70- Go to the Kibana home page and click “Add integrations”.
 71- In the query bar, search for “Azure Activity Logs” and select the integration to see more details about it.
 72- Click “Add Azure Activity Logs”.
 73- Configure the integration.
 74- Click “Save and Continue”.
 75- For more details on the integration refer to the [helper guide](https://www.elastic.co/docs/reference/integrations/azure/activitylogs).
 76"""
 77references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
 78risk_score = 21
 79rule_id = "c17ffbf9-595a-4c0b-a126-aacedb6dd179"
 80severity = "low"
 81tags = [
 82    "Domain: Cloud",
 83    "Data Source: Azure",
 84    "Data Source: Azure Activity Logs",
 85    "Rule Type: ML",
 86    "Rule Type: Machine Learning",
 87    "Resources: Investigation Guide",
 88]
 89type = "machine_learning"
 90
 91[[rule.threat]]
 92framework = "MITRE ATT&CK"
 93
 94[rule.threat.tactic]
 95id = "TA0007"
 96name = "Discovery"
 97reference = "https://attack.mitre.org/tactics/TA0007/"
 98
 99[[rule.threat.technique]]
100id = "T1526"
101name = "Cloud Service Discovery"
102reference = "https://attack.mitre.org/techniques/T1526/"
103
104[[rule.threat.technique]]
105id = "T1580"
106name = "Cloud Infrastructure Discovery"
107reference = "https://attack.mitre.org/techniques/T1580/"
108
109[[rule.threat]]
110framework = "MITRE ATT&CK"
111
112[rule.threat.tactic]
113id = "TA0004"
114name = "Privilege Escalation"
115reference = "https://attack.mitre.org/tactics/TA0004/"
116
117[[rule.threat]]
118framework = "MITRE ATT&CK"
119
120[rule.threat.tactic]
121id = "TA0005"
122name = "Defense Evasion"
123reference = "https://attack.mitre.org/tactics/TA0005/"
124
125[[rule.threat]]
126framework = "MITRE ATT&CK"
127
128[rule.threat.tactic]
129id = "TA0008"
130name = "Lateral Movement"
131reference = "https://attack.mitre.org/tactics/TA0008/"
132
133[[rule.threat]]
134framework = "MITRE ATT&CK"
135
136[rule.threat.tactic]
137id = "TA0003"
138name = "Persistence"
139reference = "https://attack.mitre.org/tactics/TA0003/"
140
141[[rule.threat]]
142framework = "MITRE ATT&CK"
143
144[rule.threat.tactic]
145id = "TA0009"
146name = "Collection"
147reference = "https://attack.mitre.org/tactics/TA0009/"

Triage and analysis

Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

Investigating Rare Azure Activity Logs Event Failures

This rule surfaces statistically rare Azure Activity Logs failures, pointing to control‑plane actions that break from typical patterns and may reflect reconnaissance, privilege changes, or defense evasion. A common attacker sequence is using a newly compromised identity to enumerate subscriptions and resource groups through the management API; repeated access denials during these discovery calls can occur as the adversary maps tenant scope and tests permissions before escalating.

Possible investigation steps

  • Classify the failing operations (discovery vs write/privileged) and tie them to the initiating principal and target scope to gauge intent and blast radius.
  • Correlate with Entra ID sign-in telemetry for the same principal around the event window to assess geo/device novelty, MFA state, Conditional Access results, and identity risk flags.
  • Check whether the identity recently had role assignments, group membership, PIM elevation, or app consent changes, and whether this is first-time access to the affected subscriptions or resource groups.
  • Confirm whether Azure Policy denies, deny assignments, or resource locks explain the failures, and verify whether the principal should legitimately be exempt or granted access.
  • If the actor is a service principal or managed identity, review recent credential changes (keys/secrets/certificates), app role assignment grants, and automation pipeline updates that could explain unexpected calls.

False positive analysis

  • A newly deployed automation or audit workflow attempts wide-scope resource discovery using a service principal or managed identity, encountering expected RBAC or policy denials that are rare for that caller.
  • Recent governance changes such as Azure Policy deny effects, deny assignments, or resource locks cause routine management operations (e.g., writes or deletes) to start failing, creating an unusual failure pattern until baselines adjust.

Response and remediation

  • Immediately contain the initiating identity by disabling user/service principal sign-in, revoking refresh tokens, and applying a temporary Conditional Access block on Azure management endpoints, while placing deny assignments and resource locks on the impacted subscriptions/resource groups.
  • Eradicate potential persistence by removing any newly created role assignments, app consent grants, policy exemptions, or management role changes identified in triage, and rotate keys/secrets/certificates for affected service principals or managed identities.
  • Recover business operations by restoring access only to verified identities through PIM approvals, re-enabling known-good automation accounts/runbooks, and validating that expected management operations succeed without further rare failures on the targeted resources.
  • Escalate to incident response immediately if rare failures are observed across multiple subscriptions or are followed by a successful privileged action (e.g., new Owner or User Access Administrator assignment, app consent grant, or resource lock removal) or originate from an unfamiliar geo/device, triggering tenant-wide containment.
  • Harden going forward by enforcing MFA and Conditional Access (including workload identity policies) for Resource Manager access, restricting service principals to least privilege with certificate-based credentials or workload identity federation, implementing deny assignments/resource locks for crown-jewel resources, and centralizing Activity Logs in SIEM with detections for discovery bursts and denied write attempts.

References

Related rules

to-top