« AWS STS Role Assumption by Service Azure AD Graph Potential Enumeration (ROADrecon) »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.37

Azure Diagnostic Settings Deleted

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Azure Diagnostic Settings Deleted

edit

Identifies deletion of Azure diagnostic settings for a resource group that has not had this operation in the prior 7 days. Diagnostic settings send platform logs and metrics to Log Analytics, Event Hubs, or storage; removing them blinds monitoring and detection. This rule uses an ES|QL first-seen (new terms) approach keyed on the resource group so groups that constantly churn logging configuration are suppressed after the first occurrence, while a newly seen group still alerts.

Rule type: esql

Rule indices: None

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-7d (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Cloud
  • Data Source: Azure
  • Data Source: Azure Activity Logs
  • Use Case: Threat Detection
  • Tactic: Defense Evasion
  • Resources: Investigation Guide
  • Noise: Low
  • Performance: Normal
  • Profile: Recommended
  • Rule Type: ES|QL
  • Platform: Azure
  • Service: Azure Resource Manager

Version: 112

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Azure Diagnostic Settings Deleted

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 aggregating successful DIAGNOSTICSETTINGS/DELETE operations over a 7-day lookback and alerting when a resource group’s first delete in that window falls in the current schedule interval.

Possible investigation steps

  • Identify the user or service principal responsible for the deletion from Esql.principal_id_values and Esql.principal_type_values. Resolve the human-readable name from Esql.initiated_by_user_values.
  • If this is a service principal, determine which application is associated with it via Esql.appid_values and examine credential use with authentication sources to identify potential compromise.
  • Examine the resource group (azure.resource.group) and subscription (Esql.subscription_id_values) context to understand the scope of the deletion and whether it affects critical resources.
  • Check Esql.first_time_seen to determine when the diagnostic settings were removed and correlate this with other security events or alerts around the same time. Pivot on Esql.session_id_values, Esql.unique_token_id_values, and Esql.correlation_id_values.
  • Investigate the affected resources by identifying which diagnostic settings were deleted (Esql.resource_name_values, Esql.resource_id_values) 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. Review Esql.role_values and Esql.role_assignment_id_values.
  • 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.

Rule query

edit
FROM logs-azure.activitylogs-*
| WHERE data_stream.dataset == "azure.activitylogs"
    AND event.action == "MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/DELETE"
    AND event.outcome IN ("success", "Success")
    AND azure.resource.group IS NOT NULL
| STATS Esql.first_time_seen = MIN(@timestamp),
        Esql.last_time_seen = MAX(@timestamp),
        Esql.event_count = COUNT(*),
        Esql.event_action_values = VALUES(event.action),
        Esql.resource_name_values = VALUES(azure.resource.name),
        Esql.resource_id_values = VALUES(azure.resource.id),
        Esql.resource_provider_values = VALUES(azure.resource.provider),
        Esql.principal_id_values = VALUES(azure.activitylogs.identity.authorization.evidence.principal_id),
        Esql.principal_type_values = VALUES(azure.activitylogs.identity.authorization.evidence.principal_type),
        Esql.initiated_by_user_values = VALUES(azure.activitylogs.identity.claims_initiated_by_user.name),
        Esql.appid_values = VALUES(azure.activitylogs.identity.claims.appid),
        Esql.session_id_values = VALUES(azure.activitylogs.identity.claims.sid),
        Esql.unique_token_id_values = VALUES(azure.activitylogs.identity.claims.uti),
        Esql.correlation_id_values = VALUES(azure.correlation_id),
        Esql.role_values = VALUES(azure.activitylogs.identity.authorization.evidence.role),
        Esql.role_assignment_id_values = VALUES(azure.activitylogs.identity.authorization.evidence.role_assignment_id),
        Esql.role_assignment_scope_values = VALUES(azure.activitylogs.identity.authorization.evidence.role_assignment_scope),
        Esql.source_ip_values = VALUES(source.ip),
        Esql.source_country_values = VALUES(source.geo.country_name),
        Esql.source_as_number_values = VALUES(source.`as`.number),
        Esql.subscription_id_values = VALUES(azure.subscription_id)
        BY azure.resource.group
// new terms emulation: fire when this resource group's first_seen falls in the current interval
// (schedule + ingest-lag buffer), i.e. it was absent from the rest of the 7-day window
| EVAL Esql.recent_minutes = DATE_DIFF("minute", Esql.first_time_seen, NOW())
| WHERE Esql.recent_minutes <= 10
| KEEP azure.*, Esql.*

Framework: MITRE ATT&CKTM

« AWS STS Role Assumption by Service Azure AD Graph Potential Enumeration (ROADrecon) »