Azure Compute Snapshot Deletion by Unusual User and Resource Group

  1[metadata]
  2creation_date = "2025/10/10"
  3integration = ["azure"]
  4maturity = "production"
  5updated_date = "2025/10/10"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies when an Azure disk snapshot is deleted by an unusual user in a specific resource group. Snapshots are
 11critical for backup, disaster recovery, and forensic analysis. Adversaries may delete snapshots to prevent data
 12recovery, eliminate forensic evidence, or disrupt backup strategies before executing ransomware or other destructive
 13attacks. Monitoring snapshot deletions is essential for detecting potential attacks targeting backup and recovery
 14capabilities.
 15"""
 16false_positives = [
 17    """
 18    Storage administrators may legitimately delete snapshots during routine maintenance, storage optimization, or
 19    cleanup of old backup data. Verify that the deletion was expected and follows organizational data retention
 20    policies. Consider exceptions for approved maintenance windows or automated retention management tools.
 21    """,
 22]
 23from = "now-9m"
 24index = ["logs-azure.activitylogs-*"]
 25language = "kuery"
 26license = "Elastic License v2"
 27name = "Azure Compute Snapshot Deletion by Unusual User and Resource Group"
 28note = """## Triage and analysis
 29
 30### Investigating Azure Compute Snapshot Deletion by Unusual User and Resource Group
 31
 32Azure disk snapshots provide point-in-time copies of managed disks, serving as critical components for backup strategies, disaster recovery plans, and forensic investigations. Snapshots enable organizations to restore data and reconstruct system states after security incidents. Adversaries aware of backup strategies may delete snapshots to prevent recovery, eliminate forensic evidence, or maximize impact before executing ransomware attacks. This detection monitors for snapshot deletion operations to identify potential attempts to compromise backup and recovery capabilities. This is a New Terms rule that looks for this behavior by a user and resource group that has not been seen in the last 7 days.
 33
 34### Possible investigation steps
 35
 36- Review the Azure activity logs to identify the user or service principal that initiated the snapshot deletion by examining the principal ID, UPN and user agent fields.
 37- Check the specific snapshot name in `azure.resource.name` to understand which backup was deleted and assess the potential impact on recovery capabilities.
 38- Investigate the timing of the event to correlate with any other suspicious activities, such as unusual login patterns, privilege escalation attempts, or other resource deletions.
 39- Examine the user's recent activity history to identify any other snapshots, disks, or Azure resources that were deleted or modified by the same principal.
 40- Verify if the snapshot deletion aligns with approved change requests, maintenance windows, or data retention policies in your organization.
 41- Check if other backup-related resources (backup vaults, recovery services) were accessed or modified around the same time.
 42- Review any related alerts or activities such as data encryption, VM modifications, or access policy changes that occurred before the deletion.
 43- Investigate if the account was recently compromised by checking for suspicious authentication events or privilege escalations.
 44
 45### False positive analysis
 46
 47- Legitimate cleanup of expired snapshots according to data retention policies may trigger this alert. Document approved retention management processes and consider creating exceptions for automated retention tools or scheduled cleanup activities.
 48- DevOps automation tools might delete temporary snapshots created during deployment or testing processes. Identify service principals used by CI/CD pipelines and consider time-based exceptions during deployment windows.
 49- Storage optimization initiatives may involve deleting old or redundant snapshots to reduce costs. Coordinate with infrastructure teams to understand planned optimization activities and create exceptions during documented maintenance windows.
 50- Disaster recovery testing may involve creating and deleting test snapshots. Work with business continuity teams to identify these patterns and create exceptions during scheduled DR testing periods.
 51
 52### Response and remediation
 53
 54- Immediately investigate whether the deletion was authorized by verifying with the account owner, backup administrators, or relevant stakeholders.
 55- If the deletion was unauthorized, disable the compromised user account or service principal immediately to prevent further damage.
 56- Check if the snapshot can be recovered through Azure backup services or soft-delete capabilities if enabled.
 57- Create new snapshots of critical disks immediately if the deleted snapshot was part of your backup strategy.
 58- Review and audit all Azure RBAC permissions to identify how the attacker gained snapshot deletion capabilities.
 59- Conduct a full security assessment to identify the initial access vector and any other compromised accounts or resources.
 60- Implement Azure Resource Locks on critical snapshots to prevent accidental or malicious deletion.
 61- Configure Azure Policy to restrict snapshot deletion permissions to only authorized backup administrators.
 62- Enable Azure Activity Log alerts to notify security teams immediately when snapshots are deleted.
 63- Review backup and disaster recovery procedures to ensure redundant backup mechanisms exist beyond Azure snapshots.
 64- Document the incident and update security policies and procedures to prevent similar incidents in the future.
 65"""
 66references = [
 67    "https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/",
 68]
 69risk_score = 21
 70rule_id = "c3d4e5f6-7a8b-9c0d-1e2f-3a4b5c6d7e8f"
 71severity = "low"
 72tags = [
 73    "Domain: Cloud",
 74    "Domain: Storage",
 75    "Data Source: Azure",
 76    "Data Source: Azure Activity Logs",
 77    "Use Case: Threat Detection",
 78    "Tactic: Impact",
 79    "Resources: Investigation Guide",
 80]
 81timestamp_override = "event.ingested"
 82type = "new_terms"
 83
 84query = '''
 85event.dataset: azure.activitylogs and
 86    azure.activitylogs.operation_name: "MICROSOFT.COMPUTE/SNAPSHOTS/DELETE" and
 87    azure.activitylogs.properties.status_code: "Accepted" and
 88    azure.activitylogs.identity.claims_initiated_by_user.name: *
 89'''
 90
 91[rule.investigation_fields]
 92field_names = [
 93    "@timestamp",
 94    "azure.activitylogs.identity.claims_initiated_by_user.name",
 95    "azure.activitylogs.identity.authorization.evidence.principal_id",
 96    "azure.activitylogs.identity.claims.appid",
 97    "azure.activitylogs.identity.claims.sid",
 98    "azure.resource.name",
 99    "azure.resource.group",
100    "azure.activitylogs.operation_name",
101    "azure.subscription_id",
102    "azure.activitylogs.tenant_id",
103    "source.ip",
104]
105
106
107[[rule.threat]]
108framework = "MITRE ATT&CK"
109[[rule.threat.technique]]
110id = "T1485"
111name = "Data Destruction"
112reference = "https://attack.mitre.org/techniques/T1485/"
113
114[[rule.threat.technique]]
115id = "T1490"
116name = "Inhibit System Recovery"
117reference = "https://attack.mitre.org/techniques/T1490/"
118
119
120[rule.threat.tactic]
121id = "TA0040"
122name = "Impact"
123reference = "https://attack.mitre.org/tactics/TA0040/"
124
125[rule.new_terms]
126field = "new_terms_fields"
127value = ["azure.activitylogs.identity.claims_initiated_by_user.name", "azure.resource.group"]
128[[rule.new_terms.history_window_start]]
129field = "history_window_start"
130value = "now-7d"