Azure Compute Restore Point Collections Deleted

  1[metadata]
  2creation_date = "2025/10/13"
  3integration = ["azure"]
  4maturity = "production"
  5updated_date = "2025/10/13"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies multiple Azure Restore Point Collections being deleted by a single user within a short time period. Restore
 11Point Collections contain recovery points for virtual machines, enabling point-in-time recovery capabilities. Mass
 12deletion of these collections is a common tactic used by adversaries during ransomware attacks to prevent victim
 13recovery or to maximize impact during destructive operations. Multiple deletions in rapid succession may indicate
 14malicious intent.
 15"""
 16false_positives = [
 17    """
 18    Planned decommissioning activities or large-scale infrastructure changes may result in legitimate bulk deletion of
 19    Restore Point Collections. Verify with the user and change management processes whether these deletions are
 20    authorized. Large-scale migration or cleanup projects should be coordinated and documented to avoid false positives.
 21    """,
 22]
 23from = "now-9m"
 24index = ["logs-azure.activitylogs-*", "filebeat-*"]
 25language = "kuery"
 26license = "Elastic License v2"
 27name = "Azure Compute Restore Point Collections Deleted"
 28note = """## Triage and analysis
 29
 30### Investigating Azure Compute Restore Point Collections Deleted
 31
 32Azure Compute Restore Point Collections are essential for disaster recovery, containing snapshots that enable point-in-time recovery
 33of virtual machines. The ability to quickly restore VMs from these recovery points is critical for business continuity and
 34incident response.
 35
 36Adversaries conducting ransomware attacks or destructive operations often target backup and recovery infrastructure to
 37prevent victims from recovering their systems without paying a ransom. Mass deletion of Restore Point Collections is a
 38key indicator of such activity and represents a significant threat to an organization's resilience.
 39
 40This rule detects when a single user deletes multiple Restore Point Collections within a short time window, which is
 41unusual in normal operations and highly suspicious when observed.
 42
 43### Possible investigation steps
 44
 45- Identify the user account responsible for the deletions by examining the `azure.activitylogs.identity.claims_initiated_by_user.name` or `user.name` field in the alerts.
 46- Review all deletion events from this user in the specified time window to determine the scope and scale of the activity.
 47- Check the `azure.resource.id` and `azure.resource.name` fields to identify which Restore Point Collections were deleted and assess their criticality to business operations.
 48- Verify whether the user account has legitimate administrative access and whether these deletions were authorized through change management or documented maintenance activities.
 49- Investigate the timeline of events leading up to the deletions, looking for other suspicious activities such as:
 50    - Privilege escalation attempts
 51    - Deletion of other backup resources (Recovery Services vaults, backup policies)
 52    - Unusual authentication patterns or geographic anomalies
 53    - Creation of persistence mechanisms or backdoor accounts
 54- Review Azure Activity Logs for any failed deletion attempts or access denied events that might indicate reconnaissance activities preceding the successful deletions.
 55- Check for related data destruction activities, such as deletion of virtual machines, disks, or storage accounts.
 56- Correlate with sign-in logs to identify any unusual login patterns or potential account compromise indicators.
 57
 58### False positive analysis
 59
 60- Large-scale decommissioning projects may involve legitimate deletion of multiple Restore Point Collections. Verify with change management records and create temporary exceptions during documented maintenance windows.
 61- Infrastructure migrations from Azure to another platform or between Azure regions may involve cleanup of old restore points. Confirm these activities are planned and documented before excluding them from monitoring.
 62- Automated cleanup scripts designed to manage storage costs by removing old restore points might trigger this alert. Identify the service accounts used for these operations and adjust the threshold or create exceptions as appropriate.
 63- Testing and development environments that are frequently rebuilt may see regular bulk deletion of resources. Consider excluding non-production environments or adjusting the threshold for these subscriptions.
 64- Review the threshold value (currently set to 3) and adjust based on your environment's baseline if legitimate administrative activities are frequently triggering false positives.
 65
 66### Response and remediation
 67
 68- Immediately isolate the affected user account to prevent further malicious activity. Reset credentials and revoke active sessions.
 69- Verify the legitimacy of the deletions with the account owner or their manager. If unauthorized, treat this as a confirmed security incident and activate incident response procedures.
 70- Check if any of the deleted Restore Point Collections can be recovered through Azure backup services, soft-delete features, or other recovery mechanisms. Time is critical as retention policies may limit recovery windows.
 71- Conduct a comprehensive review of all recent activities by the affected user account across the Azure environment to identify other potentially malicious actions or compromised resources.
 72- Assess the current disaster recovery posture and identify which VMs are now missing recovery points. Prioritize creation of new restore points for critical systems if they are unaffected.
 73- Review and strengthen access controls for Restore Point Collection management, implementing stricter RBAC policies and requiring multi-factor authentication for privileged operations.
 74- If ransomware activity is suspected or confirmed:
 75    - Activate the organization's ransomware response plan
 76    - Isolate affected systems to prevent spread
 77    - Search for ransomware indicators across the environment (encrypted files, ransom notes, suspicious processes)
 78    - Check for deletion of other recovery resources (Recovery Services vaults, backups, snapshots)
 79    - Do not pay ransom demands; engage with law enforcement and cybersecurity incident response teams
 80- Implement additional monitoring and alerting for related activities such as:
 81    - Deletion of Recovery Services resources
 82    - Modifications to backup policies
 83    - Unusual access to disaster recovery infrastructure
 84- Document the incident thoroughly and conduct a post-incident review to identify gaps in security controls and opportunities for improvement.
 85- Consider implementing Azure Resource Locks on critical recovery resources to prevent accidental or malicious deletion.
 86"""
 87references = [
 88    "https://www.microsoft.com/en-us/security/blog/2023/07/25/storm-0501-ransomware-attacks-expanding-to-hybrid-cloud-environments/",
 89]
 90risk_score = 73
 91rule_id = "d8f4e3b0-8a1b-11ef-9b4a-f661ea17fbce"
 92severity = "high"
 93tags = [
 94    "Domain: Cloud",
 95    "Domain: Storage",
 96    "Data Source: Azure",
 97    "Data Source: Azure Activity Logs",
 98    "Use Case: Threat Detection",
 99    "Tactic: Impact",
100    "Resources: Investigation Guide",
101]
102timestamp_override = "event.ingested"
103type = "threshold"
104
105query = '''
106event.dataset: azure.activitylogs and
107    event.action: "MICROSOFT.COMPUTE/RESTOREPOINTCOLLECTIONS/DELETE" and
108    event.outcome: (Success or success)
109'''
110
111
112[[rule.threat]]
113framework = "MITRE ATT&CK"
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.threshold]
126field = ["azure.activitylogs.identity.claims_initiated_by_user.name"]
127value = 1
128[[rule.threshold.cardinality]]
129field = "azure.activitylogs.resource.id"
130value = 3