[Rule Tuning] Azure Diagnostic Settings Deletion (#5253)

* [Rule Tuning] Azure Diagnostic Settings Deletion
Fixes #5252

* updated tags and linted

* linted again

Author: terrancedejesus

rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml

@@ -2,7 +2,7 @@
 creation_date = "2020/08/17"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/09/30"
+updated_date = "2025/10/27"
 
 [rule]
 author = ["Elastic"]
@@ -25,25 +25,23 @@ license = "Elastic License v2"
 name = "Azure Diagnostic Settings Deletion"
 note = """## 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 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
 
-- Review the Azure activity logs to confirm the deletion event by filtering for the operation name "MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/DELETE" and ensuring the event outcome is marked as Success.
 - 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
 
-- Routine maintenance activities by authorized personnel may trigger the rule. Ensure that maintenance schedules are documented and align with the detected events.
+- 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.
@@ -52,26 +50,35 @@ Azure Diagnostic Settings are crucial for monitoring and logging platform activi
 ### 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 and IP address involved. This will help determine if the action was authorized or malicious.
+- 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 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.
+- 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.
-
-## Setup
-
-The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
-references = ["https://docs.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings"]
+"""
+references = [
+    "https://docs.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings",
+    "https://www.microsoft.com/en-us/security/blog/2025/10/20/inside-the-attack-chain-threat-activity-targeting-azure-blob-storage/",
+]
 risk_score = 47
 rule_id = "5370d4cd-2bb3-4d71-abf5-1e1d0ff5a2de"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Azure", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
+tags = [
+    "Domain: Cloud",
+    "Data Source: Azure",
+    "Data Source: Azure Activity Logs",
+    "Use Case: Threat Detection",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
 timestamp_override = "event.ingested"
-type = "query"
+type = "new_terms"
 
 query = '''
-event.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/DELETE" and event.outcome:(Success or success)
+event.dataset:azure.activitylogs
+    and azure.activitylogs.operation_name:"MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/DELETE"
+    and event.outcome:(Success or success)
 '''
 
 
@@ -92,8 +99,30 @@ name = "Disable or Modify Cloud Logs"
 reference = "https://attack.mitre.org/techniques/T1562/008/"
 
 
+
 [rule.threat.tactic]
 id = "TA0005"
 name = "Defense Evasion"
 reference = "https://attack.mitre.org/tactics/TA0005/"
 
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "event.action",
+    "source.ip",
+    "azure.activitylogs.identity.authorization.evidence.principal_type",
+    "azure.activitylogs.identity.authorization.evidence.role_assignment_scope",
+    "azure.activitylogs.properties.entity",
+    "azure.activitylogs.identity.claims.appid",
+    "azure.resource.name",
+    "azure.resource.provider",
+]
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["azure.resource.group"]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-7d"
+
+