Unusual Azure Activity Logs Event for a User

A machine learning job detected Azure Activity Logs activity that, while not inherently suspicious or abnormal, is sourcing from user context that does not normally use the event action. This can be the result of compromised credentials or keys as someone uses a valid account to persist, move laterally, or exfiltrate data.

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 = 75
 11author = ["Elastic"]
 12description = """
 13A machine learning job detected Azure Activity Logs activity that, while not inherently suspicious or abnormal, is sourcing from
 14user context that does not normally use the event action. This can be the result of compromised credentials or keys as
 15someone uses a valid account to persist, move laterally, or exfiltrate data.
 16"""
 17false_positives = [
 18    """
 19    New or unusual user event activity can be due to manual troubleshooting or reconfiguration; changes in cloud
 20    automation scripts or workflows; adoption of new services; or changes in the way services are used.
 21    """,
 22]
 23from = "now-2h"
 24interval = "15m"
 25license = "Elastic License v2"
 26machine_learning_job_id = "azure_activitylogs_rare_event_action_for_a_username"
 27name = "Unusual Azure Activity Logs Event for a User"
 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 Unusual Azure Activity Logs Event for a User
 34
 35This rule flags an Azure Activity Logs event when a user performs an action they don’t normally execute, highlighting potential misuse of valid credentials. It matters because attackers often blend in by operating under legitimate identities to persist, escalate, move laterally, or exfiltrate without tripping simple allowlists. A common pattern is a compromised account creating a new role assignment to grant itself elevated rights, then using that access to enumerate resources and pull data from storage.
 36
 37### Possible investigation steps
 38
 39- Reconstruct the timeline by pivoting on the user and ±60 minutes to collect all related Azure Activity Log entries (including those sharing the same correlation ID) and map any subsequent privilege changes, resource modifications, or data access. 
 40- Validate identity context by reviewing Entra ID sign-in logs for IP/ASN, geolocation, device compliance, MFA outcome, authentication protocol, and client app to spot first-time usage or impossible travel. 
 41- Determine whether the caller is a human account, service principal, or managed identity and confirm legitimate need by checking current and recently changed role assignments and group memberships within the affected scope. 
 42- Correlate the activity with approved change records and CI/CD runs (e.g., Azure DevOps, GitHub Actions, Terraform) by matching service principal/user agent and verify the pipeline or requestor was authorized and correctly scoped.
 43
 44### False positive analysis
 45
 46- The user temporarily covered an admin role and performed uncommon RBAC changes or resource provider registrations that are legitimate but deviate from their historical baseline.
 47- A scheduled maintenance or setup task ran under the user’s credentials and invoked management APIs they rarely call, generating Azure Activity Logs that appear unusual for this identity.
 48
 49### Response and remediation
 50
 51- Immediately revoke the user’s refresh tokens and active sessions, force a password reset, and apply a temporary Conditional Access policy to block the source IPs and device observed during the unusual operation.
 52- Remove any RBAC role assignments or resource policy changes created by this identity during the event window (including Owner/Contributor grants on subscriptions or resource groups) and require approvals through Privileged Identity Management before restoring access.
 53- If a service principal or managed identity executed the action, rotate its client secret/certificate, invalidate issued SAS tokens and storage account keys, and delete any unauthorized app registrations or automation accounts created.
 54- Restore affected configurations to baseline by reapplying IaC templates and verifying Key Vault access policies, storage account firewalls, and NSG rules match approved standards before re-enabling routine operations.
 55- Escalate to incident response and notify cloud security leadership if the unusual action involved new role assignments granting elevated rights, access to Key Vault secrets, listing storage account keys, disabling logs, or activity across multiple subscriptions.
 56- Implement hardening by enforcing MFA with phishing-resistant methods, enabling risk-based Conditional Access, requiring just-in-time elevation via PIM, restricting management-plane access to approved network locations, and adding alerts for role assignment writes, secret reads, and key listings.
 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 = "81892f44-4946-4b27-95d3-1d8929b114a7"
 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 = "TA0001"
 96name = "Initial Access"
 97reference = "https://attack.mitre.org/tactics/TA0001/"
 98
 99[[rule.threat.technique]]
100id = "T1078"
101name = "Valid Accounts"
102reference = "https://attack.mitre.org/techniques/T1078/"
103
104[[rule.threat.technique.subtechnique]]
105id = "T1078.004"
106name = "Cloud Accounts"
107reference = "https://attack.mitre.org/techniques/T1078/004/"
108
109[[rule.threat]]
110framework = "MITRE ATT&CK"
111
112[rule.threat.tactic]
113id = "TA0008"
114name = "Lateral Movement"
115reference = "https://attack.mitre.org/tactics/TA0008/"
116
117[[rule.threat.technique]]
118id = "T1021"
119name = "Remote Services"
120reference = "https://attack.mitre.org/techniques/T1021/"
121
122[[rule.threat.technique.subtechnique]]
123id = "T1021.007"
124name = "Cloud Services"
125reference = "https://attack.mitre.org/techniques/T1021/007/"
126
127[[rule.threat]]
128framework = "MITRE ATT&CK"
129
130[rule.threat.tactic]
131id = "TA0003"
132name = "Persistence"
133reference = "https://attack.mitre.org/tactics/TA0003/"
134
135[[rule.threat]]
136framework = "MITRE ATT&CK"
137
138[rule.threat.tactic]
139id = "TA0010"
140name = "Exfiltration"
141reference = "https://attack.mitre.org/tactics/TA0010/"
142
143[[rule.threat.technique]]
144id = "T1041"
145name = "Exfiltration Over C2 Channel"
146reference = "https://attack.mitre.org/techniques/T1041/"

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 Unusual Azure Activity Logs Event for a User

This rule flags an Azure Activity Logs event when a user performs an action they don’t normally execute, highlighting potential misuse of valid credentials. It matters because attackers often blend in by operating under legitimate identities to persist, escalate, move laterally, or exfiltrate without tripping simple allowlists. A common pattern is a compromised account creating a new role assignment to grant itself elevated rights, then using that access to enumerate resources and pull data from storage.

Possible investigation steps

  • Reconstruct the timeline by pivoting on the user and ±60 minutes to collect all related Azure Activity Log entries (including those sharing the same correlation ID) and map any subsequent privilege changes, resource modifications, or data access.
  • Validate identity context by reviewing Entra ID sign-in logs for IP/ASN, geolocation, device compliance, MFA outcome, authentication protocol, and client app to spot first-time usage or impossible travel.
  • Determine whether the caller is a human account, service principal, or managed identity and confirm legitimate need by checking current and recently changed role assignments and group memberships within the affected scope.
  • Correlate the activity with approved change records and CI/CD runs (e.g., Azure DevOps, GitHub Actions, Terraform) by matching service principal/user agent and verify the pipeline or requestor was authorized and correctly scoped.

False positive analysis

  • The user temporarily covered an admin role and performed uncommon RBAC changes or resource provider registrations that are legitimate but deviate from their historical baseline.
  • A scheduled maintenance or setup task ran under the user’s credentials and invoked management APIs they rarely call, generating Azure Activity Logs that appear unusual for this identity.

Response and remediation

  • Immediately revoke the user’s refresh tokens and active sessions, force a password reset, and apply a temporary Conditional Access policy to block the source IPs and device observed during the unusual operation.
  • Remove any RBAC role assignments or resource policy changes created by this identity during the event window (including Owner/Contributor grants on subscriptions or resource groups) and require approvals through Privileged Identity Management before restoring access.
  • If a service principal or managed identity executed the action, rotate its client secret/certificate, invalidate issued SAS tokens and storage account keys, and delete any unauthorized app registrations or automation accounts created.
  • Restore affected configurations to baseline by reapplying IaC templates and verifying Key Vault access policies, storage account firewalls, and NSG rules match approved standards before re-enabling routine operations.
  • Escalate to incident response and notify cloud security leadership if the unusual action involved new role assignments granting elevated rights, access to Key Vault secrets, listing storage account keys, disabling logs, or activity across multiple subscriptions.
  • Implement hardening by enforcing MFA with phishing-resistant methods, enabling risk-based Conditional Access, requiring just-in-time elevation via PIM, restricting management-plane access to approved network locations, and adding alerts for role assignment writes, secret reads, and key listings.

References

Related rules

to-top