« Azure Compute Restore Point Collection Deleted by Unusual User Azure Compute Snapshot Deletion by Unusual User and Resource Group »
Elastic Docs ›Elastic Security [8.19] ›Detections and alerts ›Prebuilt rule reference

Azure Compute Restore Point Collections Deleted

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

Azure Compute Restore Point Collections Deleted

edit

Identifies multiple Azure Restore Point Collections being deleted by a single user within a short time period. Restore Point Collections contain recovery points for virtual machines, enabling point-in-time recovery capabilities. Mass deletion of these collections is a common tactic used by adversaries during ransomware attacks to prevent victim recovery or to maximize impact during destructive operations. Multiple deletions in rapid succession may indicate malicious intent.

Rule type: threshold

Rule indices:

  • logs-azure.activitylogs-*
  • filebeat-*

Severity: high

Risk score: 73

Runs every: 5m

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

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Cloud
  • Domain: Storage
  • Data Source: Azure
  • Data Source: Azure Activity Logs
  • Use Case: Threat Detection
  • Tactic: Impact
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Azure Compute Restore Point Collections Deleted

Azure Compute Restore Point Collections are essential for disaster recovery, containing snapshots that enable point-in-time recovery of virtual machines. The ability to quickly restore VMs from these recovery points is critical for business continuity and incident response.

Adversaries conducting ransomware attacks or destructive operations often target backup and recovery infrastructure to prevent victims from recovering their systems without paying a ransom. Mass deletion of Restore Point Collections is a key indicator of such activity and represents a significant threat to an organization’s resilience.

This rule detects when a single user deletes multiple Restore Point Collections within a short time window, which is unusual in normal operations and highly suspicious when observed.

Possible investigation steps

  • 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.
  • Review all deletion events from this user in the specified time window to determine the scope and scale of the activity.
  • 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.
  • Verify whether the user account has legitimate administrative access and whether these deletions were authorized through change management or documented maintenance activities.
  • Investigate the timeline of events leading up to the deletions, looking for other suspicious activities such as:
  • Privilege escalation attempts
  • Deletion of other backup resources (Recovery Services vaults, backup policies)
  • Unusual authentication patterns or geographic anomalies
  • Creation of persistence mechanisms or backdoor accounts
  • Review Azure Activity Logs for any failed deletion attempts or access denied events that might indicate reconnaissance activities preceding the successful deletions.
  • Check for related data destruction activities, such as deletion of virtual machines, disks, or storage accounts.
  • Correlate with sign-in logs to identify any unusual login patterns or potential account compromise indicators.

False positive analysis

  • 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.
  • 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.
  • 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.
  • 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.
  • 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.

Response and remediation

  • Immediately isolate the affected user account to prevent further malicious activity. Reset credentials and revoke active sessions.
  • 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.
  • 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.
  • 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.
  • 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.
  • Review and strengthen access controls for Restore Point Collection management, implementing stricter RBAC policies and requiring multi-factor authentication for privileged operations.
  • If ransomware activity is suspected or confirmed:
  • Activate the organization’s ransomware response plan
  • Isolate affected systems to prevent spread
  • Search for ransomware indicators across the environment (encrypted files, ransom notes, suspicious processes)
  • Check for deletion of other recovery resources (Recovery Services vaults, backups, snapshots)
  • Do not pay ransom demands; engage with law enforcement and cybersecurity incident response teams
  • Implement additional monitoring and alerting for related activities such as:
  • Deletion of Recovery Services resources
  • Modifications to backup policies
  • Unusual access to disaster recovery infrastructure
  • Document the incident thoroughly and conduct a post-incident review to identify gaps in security controls and opportunities for improvement.
  • Consider implementing Azure Resource Locks on critical recovery resources to prevent accidental or malicious deletion.

Rule query

edit
event.dataset: azure.activitylogs and
    event.action: "MICROSOFT.COMPUTE/RESTOREPOINTCOLLECTIONS/DELETE" and
    event.outcome: (Success or success)

Framework: MITRE ATT&CKTM

« Azure Compute Restore Point Collection Deleted by Unusual User Azure Compute Snapshot Deletion by Unusual User and Resource Group »