Azure Diagnostic Settings Deletion
Identifies the deletion of diagnostic settings in Azure, which send platform logs and metrics to different destinations. An adversary may delete diagnostic settings in an attempt to evade defenses.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2020/08/17"
3integration = ["azure"]
4maturity = "production"
5updated_date = "2025/10/27"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies the deletion of diagnostic settings in Azure, which send platform logs and metrics to different destinations.
11An adversary may delete diagnostic settings in an attempt to evade defenses.
12"""
13false_positives = [
14 """
15 Deletion of diagnostic settings may be done by a system or network administrator. Verify whether the username,
16 hostname, and/or resource name should be making changes in your environment. Diagnostic settings deletion from
17 unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted
18 from the rule.
19 """,
20]
21from = "now-9m"
22index = ["logs-azure.activitylogs-*", "filebeat-*"]
23language = "kuery"
24license = "Elastic License v2"
25name = "Azure Diagnostic Settings Deletion"
26note = """## Triage and analysis
27
28### Investigating Azure Diagnostic Settings Deletion
29
30Azure Diagnostic Settings are crucial for monitoring and logging platform activities, sending data to various destinations for analysis. Adversaries may delete these settings to hinder detection and analysis of their activities, effectively evading defenses. The detection rule identifies such deletions by monitoring specific Azure activity logs for successful deletion operations, flagging potential defense evasion attempts.
31
32### Possible investigation steps
33
34- Identify the user or service principal responsible for the deletion by examining the associated user identity or service principal ID in the activity logs.
35- If this is a service principal, determine which application is associated with it and examine credential use with authentication sources to identify potential compromise.
36- Examine the resource group and subscription context to understand the scope of the deletion and whether it affects critical resources.
37- Check the timestamp of the deletion event to determine when the diagnostic settings were removed and correlate this with other security events or alerts around the same time.
38- Investigate the affected resources by identifying which diagnostic settings were deleted and assess the potential impact on monitoring and logging capabilities.
39- Review any recent changes or activities performed by the identified user or service principal to determine if there are other suspicious actions that might indicate malicious intent.
40- Assess the current security posture by ensuring that diagnostic settings are reconfigured and that logging and monitoring are restored to maintain visibility into platform activities.
41
42### False positive analysis
43
44- Examine the service principal or user account involved in the deletion to determine if it is part of an automated process or legitimate administrative activity.
45- Automated scripts or tools used for managing Azure resources might delete diagnostic settings as part of their operation. Review and whitelist these scripts if they are verified as non-threatening.
46- Changes in organizational policy or compliance requirements could lead to legitimate deletions. Confirm with relevant teams if such policy changes are in effect.
47- Test environments often undergo frequent configuration changes, including the deletion of diagnostic settings. Consider excluding these environments from the rule or adjusting the rule to account for their unique behavior.
48- Ensure that any third-party integrations or services with access to Azure resources are reviewed, as they might inadvertently delete diagnostic settings during their operations.
49
50### Response and remediation
51
52- Immediately isolate affected Azure resources to prevent further unauthorized changes or deletions. This may involve temporarily restricting access to the affected subscriptions or resource groups.
53- Review the Azure activity logs to identify the source of the deletion request, including the user account, service principal and IP address involved. This will help determine if the action was authorized or malicious.
54- Recreate the deleted diagnostic settings as soon as possible to restore logging and monitoring capabilities. Ensure that logs are being sent to secure and appropriate destinations.
55- Conduct a thorough investigation of the user account or service principal involved in the deletion. If the account is compromised, reset credentials, and review permissions to ensure they are appropriate and follow the principle of least privilege.
56- Escalate the incident to the security operations team for further analysis and to determine if additional resources or expertise are needed to address the threat.
57- Implement additional monitoring and alerting for similar deletion activities to ensure rapid detection and response to future attempts.
58- Review and update access controls and policies related to diagnostic settings to prevent unauthorized deletions, ensuring that only trusted and necessary personnel have the ability to modify these settings.
59"""
60references = [
61 "https://docs.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings",
62 "https://www.microsoft.com/en-us/security/blog/2025/10/20/inside-the-attack-chain-threat-activity-targeting-azure-blob-storage/",
63]
64risk_score = 47
65rule_id = "5370d4cd-2bb3-4d71-abf5-1e1d0ff5a2de"
66severity = "medium"
67tags = [
68 "Domain: Cloud",
69 "Data Source: Azure",
70 "Data Source: Azure Activity Logs",
71 "Use Case: Threat Detection",
72 "Tactic: Defense Evasion",
73 "Resources: Investigation Guide",
74]
75timestamp_override = "event.ingested"
76type = "new_terms"
77
78query = '''
79event.dataset:azure.activitylogs
80 and azure.activitylogs.operation_name:"MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/DELETE"
81 and event.outcome:(Success or success)
82'''
83
84
85[[rule.threat]]
86framework = "MITRE ATT&CK"
87[[rule.threat.technique]]
88id = "T1562"
89name = "Impair Defenses"
90reference = "https://attack.mitre.org/techniques/T1562/"
91[[rule.threat.technique.subtechnique]]
92id = "T1562.001"
93name = "Disable or Modify Tools"
94reference = "https://attack.mitre.org/techniques/T1562/001/"
95
96[[rule.threat.technique.subtechnique]]
97id = "T1562.008"
98name = "Disable or Modify Cloud Logs"
99reference = "https://attack.mitre.org/techniques/T1562/008/"
100
101
102
103[rule.threat.tactic]
104id = "TA0005"
105name = "Defense Evasion"
106reference = "https://attack.mitre.org/tactics/TA0005/"
107
108[rule.investigation_fields]
109field_names = [
110 "@timestamp",
111 "event.action",
112 "source.ip",
113 "azure.activitylogs.identity.authorization.evidence.principal_type",
114 "azure.activitylogs.identity.authorization.evidence.role_assignment_scope",
115 "azure.activitylogs.properties.entity",
116 "azure.activitylogs.identity.claims.appid",
117 "azure.resource.name",
118 "azure.resource.provider",
119]
120
121[rule.new_terms]
122field = "new_terms_fields"
123value = ["azure.resource.group"]
124[[rule.new_terms.history_window_start]]
125field = "history_window_start"
126value = "now-7d"
Triage and analysis
Investigating Azure Diagnostic Settings Deletion
Azure Diagnostic Settings are crucial for monitoring and logging platform activities, sending data to various destinations for analysis. Adversaries may delete these settings to hinder detection and analysis of their activities, effectively evading defenses. The detection rule identifies such deletions by monitoring specific Azure activity logs for successful deletion operations, flagging potential defense evasion attempts.
Possible investigation steps
- Identify the user or service principal responsible for the deletion by examining the associated user identity or service principal ID in the activity logs.
- If this is a service principal, determine which application is associated with it and examine credential use with authentication sources to identify potential compromise.
- Examine the resource group and subscription context to understand the scope of the deletion and whether it affects critical resources.
- Check the timestamp of the deletion event to determine when the diagnostic settings were removed and correlate this with other security events or alerts around the same time.
- Investigate the affected resources by identifying which diagnostic settings were deleted and assess the potential impact on monitoring and logging capabilities.
- Review any recent changes or activities performed by the identified user or service principal to determine if there are other suspicious actions that might indicate malicious intent.
- Assess the current security posture by ensuring that diagnostic settings are reconfigured and that logging and monitoring are restored to maintain visibility into platform activities.
False positive analysis
- Examine the service principal or user account involved in the deletion to determine if it is part of an automated process or legitimate administrative activity.
- Automated scripts or tools used for managing Azure resources might delete diagnostic settings as part of their operation. Review and whitelist these scripts if they are verified as non-threatening.
- Changes in organizational policy or compliance requirements could lead to legitimate deletions. Confirm with relevant teams if such policy changes are in effect.
- Test environments often undergo frequent configuration changes, including the deletion of diagnostic settings. Consider excluding these environments from the rule or adjusting the rule to account for their unique behavior.
- Ensure that any third-party integrations or services with access to Azure resources are reviewed, as they might inadvertently delete diagnostic settings during their operations.
Response and remediation
- Immediately isolate affected Azure resources to prevent further unauthorized changes or deletions. This may involve temporarily restricting access to the affected subscriptions or resource groups.
- Review the Azure activity logs to identify the source of the deletion request, including the user account, service principal and IP address involved. This will help determine if the action was authorized or malicious.
- Recreate the deleted diagnostic settings as soon as possible to restore logging and monitoring capabilities. Ensure that logs are being sent to secure and appropriate destinations.
- Conduct a thorough investigation of the user account or service principal involved in the deletion. If the account is compromised, reset credentials, and review permissions to ensure they are appropriate and follow the principle of least privilege.
- Escalate the incident to the security operations team for further analysis and to determine if additional resources or expertise are needed to address the threat.
- Implement additional monitoring and alerting for similar deletion activities to ensure rapid detection and response to future attempts.
- Review and update access controls and policies related to diagnostic settings to prevent unauthorized deletions, ensuring that only trusted and necessary personnel have the ability to modify these settings.
References
Related rules
- Azure Compute Restore Point Collection Deleted by Unusual User
- Azure Compute Restore Point Collections Deleted
- Azure Storage Account Deletion by Unusual User
- Azure Storage Account Deletions by User
- Azure Storage Account Blob Public Access Enabled