Which SIEM platforms have a THREAT-CloudBackup-SnapshotPurge detection rule?

df00tech provides THREAT-CloudBackup-SnapshotPurge (Cloud Backup Vault and Snapshot Deletion Prior to Ransomware Detonation) detection queries for 7 SIEM platforms: Microsoft Sentinel / Defender, Splunk, Elastic Security (EQL), IBM QRadar (AQL), Sumo Logic CSE, Google Chronicle / SecOps, CrowdStrike LogScale (CQL).

What severity and confidence is the THREAT-CloudBackup-SnapshotPurge detection?

The THREAT-CloudBackup-SnapshotPurge detection is rated critical severity with high confidence.

What are common false positives for THREAT-CloudBackup-SnapshotPurge?

Common false positives for THREAT-CloudBackup-SnapshotPurge include: Legitimate backup lifecycle/retention policy expiration — should already be excluded by the UserIdentityType/InvokedBy filter on the AWS side, but verify the filter matches your account's actual invokedBy value if using a custom automation Lambda that wraps the Backup service calls; Planned decommissioning of an environment (e.g. end-of-project cleanup) where an admin intentionally deletes backup vaults and recovery points in bulk — cross-reference against a change ticket; Cost-optimization projects that intentionally prune old EBS/RDS snapshots in bulk via a script run by an authorized engineer.

THREAT-CloudBackup-SnapshotPurge Google Chronicle · YARA-L

Detect Cloud Backup Vault and Snapshot Deletion Prior to Ransomware Detonation in Google Chronicle

Q: What data sources are required to detect Cloud Backup Vault and Snapshot Deletion Prior to Ransomware Detonation (THREAT-CloudBackup-SnapshotPurge)?

Detecting Cloud Backup Vault and Snapshot Deletion Prior to Ransomware Detonation requires the following data sources: AWS CloudTrail (management events, ingested via Microsoft Sentinel AWS S3 connector), Azure Activity Log, AWSCloudTrail table, AzureActivity table.

As organizations move backup targets from on-premises VSS/wbadmin to cloud-native services (AWS Backup, EBS/RDS snapshots, Azure Recovery Services vaults, Azure managed-disk snapshots), ransomware affiliates have adapted their recovery-inhibition step to match: rather than running vssadmin on an endpoint, the attacker who has obtained cloud administrative credentials calls the backup/snapshot service's own deletion APIs directly. Observed patterns include bulk deletion of AWS Backup recovery points and backup vaults (DeleteRecoveryPoint, DeleteBackupVault, DeleteBackupPlan, DeleteBackupSelection), direct deletion of EC2/RDS snapshots (DeleteSnapshot, DeleteDBSnapshot, DeleteDBClusterSnapshot), and — on Azure — first disabling the Recovery Services vault's soft-delete protection before deleting protected items or the vault itself (soft-delete exists specifically to survive this attack, so its removal is itself a strong signal), plus deletion of standalone managed-disk snapshots. This is functionally identical in intent to T1490's on-host VSS/BCD deletion but lives entirely in cloud control-plane audit logs (AWS CloudTrail, Azure Activity Log) rather than endpoint telemetry, and the key discriminator from legitimate lifecycle-policy cleanup is who/what made the call: automated retention-policy expiration is initiated by the backup service itself (e.g. CloudTrail invokedBy backup.amazonaws.com), while an interactive IAM user or role deleting many recovery points/vaults in a short window is anomalous and, combined with a soft-delete-disable step on Azure, should be treated as an active pre-encryption indicator.

MITRE ATT&CK

Tactic: Impact

YARA-L Detection Query

Google Chronicle (YARA-L)

yaral

rule cloud_backup_snapshot_purge {
  meta:
    author = "df00tech Detection Engineering"
    description = "Detects burst deletion of cloud backup vaults, recovery points, and snapshots consistent with pre-ransomware recovery denial"
    reference = "https://attack.mitre.org/techniques/T1490/"
    severity = "CRITICAL"
    priority = "HIGH"
    mitre_attack_tactic = "Impact"
    mitre_attack_technique = "T1490"
    false_positives = "Backup lifecycle expiration, planned decommissioning, cost-optimization pruning, vault migration"
    version = "1.0"

  events:
    $e.metadata.event_type = "USER_RESOURCE_DELETION"
    (
      (
        $e.metadata.vendor_name = "Amazon"
        re.regex($e.metadata.product_event_type, `(?i)(DeleteRecoveryPoint|DeleteBackupVault|DeleteBackupPlan|DeleteBackupSelection|DeleteSnapshot|DeleteDBSnapshot|DeleteDBClusterSnapshot)`)
        not re.regex($e.metadata.description, `(?i)backup\.amazonaws\.com`)
      ) or
      (
        $e.metadata.vendor_name = "Microsoft"
        re.regex($e.metadata.product_event_type, `(?i)(RECOVERYSERVICES.*BACKUPCONFIG|RECOVERYSERVICES.*PROTECTEDITEMS.*DELETE|RECOVERYSERVICES/VAULTS/DELETE|COMPUTE/SNAPSHOTS/DELETE)`)
      )
    )
    $identity = $e.principal.user.userid

  match:
    $identity over 30m

  condition:
    $e
}

critical severity medium confidence

Chronicle YARA-L 2.0 rule matching USER_RESOURCE_DELETION UDM events from AWS CloudTrail and Azure Activity Log. Fires on AWS Backup/EBS/RDS deletion calls not attributed to the backup service itself, and Azure Recovery Services soft-delete-disable, protected-item/vault deletion, or managed-disk snapshot deletion. Groups by calling principal over a 30-minute window to surface the burst pattern characteristic of a scripted recovery-denial operation.

Data Sources

Google Chronicle SIEMChronicle UDM (Unified Data Model)AWS CloudTrail and Azure Activity Log (via Chronicle feeds)

Required Tables

UDM Events (USER_RESOURCE_DELETION)

False Positives & Tuning

Backup lifecycle/retention expiration not fully attributed to the service identity
Planned environment decommissioning with bulk deletion
Cost-optimization snapshot pruning
Vault migration projects disabling soft-delete temporarily
Backup/DR testing in non-production environments

Other platforms for THREAT-CloudBackup-SnapshotPurge

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) CrowdStrike LogScale (LogScale) All platforms (combined) →

Testing Methodology

Validate this detection against 2 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

Test 1Simulate AWS Backup Recovery Point Deletion Burst
Expected signal: AWS CloudTrail management events: eventName=DeleteRecoveryPoint, eventSource=backup.amazonaws.com, three or more events from the same userIdentity.arn within a few minutes, with userIdentity.type NOT equal to AWSService.
Test 2Simulate Azure Recovery Services Soft-Delete Disable Then Protected Item Removal
Expected signal: Azure Activity Log entries: operationName=MICROSOFT.RECOVERYSERVICES/VAULTS/BACKUPCONFIG/WRITE (soft-delete disabled) followed within minutes by operationName=MICROSOFT.RECOVERYSERVICES/VAULTS/BACKUPFABRICS/BACKUPPROTECTIONCONTAINERS/PROTECTEDITEMS/DELETE, both with resultType=Success from the same caller.

Last updated: 2026-07-17 Research depth: deep

References (7)

Response Playbook

Triage

Identify the calling identity (UserIdentityArn on AWS, Caller on Azure): is this a human console/CLI identity, a CI/CD service principal, or an unrecognized/newly-created account? An interactive human identity bulk-deleting backup infrastructure outside a documented change window is the highest-priority scenario
On AWS, confirm the calls were NOT invoked by backup.amazonaws.com (routine lifecycle expiration) — check userIdentity.invokedBy and userIdentity.type in the raw CloudTrail record
On Azure, check specifically whether MICROSOFT.RECOVERYSERVICES/VAULTS/BACKUPCONFIG/WRITE (soft-delete disablement) preceded the deletion calls — this two-step sequence (disable protection, then delete) is a strong ransomware-actor signature since soft-delete exists specifically to survive accidental or malicious deletion
Enumerate exactly which vaults, recovery points, or snapshots were deleted and cross-reference against your backup inventory to determine blast radius — are these the only backups for a critical production workload, or one copy among several (e.g. an immutable/offline copy elsewhere)?
Correlate the calling identity's recent authentication history (console login, AssumeRole, service principal token issuance) to determine whether the identity itself shows signs of compromise (impossible travel, new MFA device, unfamiliar source IP)
Check whether the same identity or account also touched compute/storage resources for encryption or mass deletion in the same window (e.g. EC2 StopInstances/TerminateInstances bursts, S3 bulk DeleteObject calls, or endpoint-side T1486/T1490 activity) — this is very often paired with an active or imminent encryption event

Containment

Immediately revoke/rotate the credentials or session tokens of the identity that performed the deletions (disable IAM access keys, force sign-out and conditional-access block on the Azure identity, invalidate any active AWS STS sessions)
If any deletions are still in a recoverable state (AWS Backup recovery points and Azure Recovery Services items are often only soft-deleted for a retention window before permanent purge), initiate recovery/undelete immediately rather than waiting for full incident scoping
Lock down the IAM policy or Azure RBAC role that allowed this identity to call Delete*/BackupConfig write operations — restrict these actions to a small, MFA-gated break-glass role going forward
Check for and revoke any newly created backup vault access policies, cross-account grants, or service principal credentials that may have been added by the attacker as a foothold for a repeat attack
Alert the broader incident response team that recovery capability may be degraded — this materially changes the ransom-negotiation and recovery-time calculus if encryption is confirmed or imminent
Verify and, if necessary, isolate any offline/immutable/air-gapped backup copies (tape, Object Lock S3, immutable Azure vaults) that the attacker's cloud-API access could not reach, to confirm at least one clean recovery path survives

Evidence Collection

Full CloudTrail/Activity Log record for every Delete*/BackupConfig write call, including request parameters, response elements, source IP, and the complete userIdentity/caller block
CloudTrail/Activity Log history for the calling identity over the preceding 48-72 hours (console login, AssumeRole/token issuance, ListBackupVaults/ListRecoveryPoints or equivalent reconnaissance calls that typically precede bulk deletion)
AWS Config or Azure Resource Graph configuration history showing the before/after state of the affected vaults, recovery points, and snapshots
IAM policy/Azure RBAC role evaluation showing how the calling identity obtained permission to perform backup-deletion or soft-delete-disable actions
A complete backup/DR inventory snapshot (which workloads, which vaults, which retention state) taken immediately post-incident to support recovery planning and insurer/legal reporting

Escalation Criteria

!Soft-delete was disabled on an Azure Recovery Services vault immediately before protected items or the vault were deleted — this two-step sequence has no common legitimate use case outside of a documented, ticketed vault migration
!The calling identity does not match any known IaC/automation service principal and no corresponding change ticket exists
!Backup infrastructure deletion is observed in the same operational window as endpoint or hypervisor-level ransomware indicators (T1490 VSS deletion, T1489 ESXi VM kills — see THREAT-ESXi-HypervisorRansomware)
!Deletions span multiple accounts/subscriptions or multiple cloud providers within a short window, indicating a scripted, campaign-level recovery-denial operation rather than a one-off misconfiguration
!No offline/immutable backup copy can be confirmed to have survived the deletion activity

Investigation Guide

Related Techniques

T1490 — Inhibit System Recovery (this detection's parent technique; the cloud control-plane equivalent of on-host VSS/BCD deletion)T1486 — Data Encrypted for Impact (the encryption event this recovery-denial step is typically staged ahead of)T1489 — Service Stop (paired hypervisor/VM-level recovery denial — see THREAT-ESXi-HypervisorRansomware)T1078.004 — Valid Accounts: Cloud Accounts (the compromised credential used to call the deletion APIs)T1531 — Account Access Removal (attackers sometimes lock out legitimate admins from the backup console immediately after deleting recovery points, compounding the recovery denial)T1562.001 — Impair Defenses: Disable or Modify Tools (disabling Azure Backup soft-delete protection is conceptually the cloud-control-plane analogue of disabling a security/recovery feature)

Forensic Artifacts

>AWS CloudTrail event records for every DeleteRecoveryPoint/DeleteBackupVault/DeleteBackupPlan/DeleteBackupSelection/DeleteSnapshot/DeleteDBSnapshot/DeleteDBClusterSnapshot call, including full requestParameters and responseElements
>Azure Activity Log entries for BackupConfig write (soft-delete state change), protectedItems delete, vault delete, and snapshot delete operations, including the full HTTP request body in the Properties field
>AWS Config resource configuration timeline for affected backup vaults/plans showing the pre-deletion state
>Azure Resource Graph or Azure Policy compliance history showing the vault's soft-delete configuration state over time
>IAM credential report / Azure AD sign-in logs for the calling identity's authentication history around the incident window
>AWS Backup Audit Manager (if enabled) compliance framework findings, which specifically track unauthorized backup deletion against a defined resource-protection framework

Tuning Guidance

The single highest-value control is keeping the AWS 'service-initiated' exclusion (userIdentity.invokedBy == backup.amazonaws.com / userIdentity.type == AWSService) accurate and current, since routine lifecycle-policy expiration is by far the largest source of legitimate DeleteRecoveryPoint/DeleteSnapshot volume and would otherwise drown out true positives. On Azure, treat the BACKUPCONFIG/WRITE (soft-delete toggle) event as a standalone medium-severity alert even without a following deletion, since disabling soft-delete has almost no legitimate justification outside a documented vault migration. Maintain an allowlist of known IaC/automation service principal and CI/CD role identities that perform authorized bulk cleanup (cost-optimization jobs, environment decommissioning pipelines) and exclude them by identity ARN/object ID rather than by event name, since the event names themselves are identical between legitimate and malicious use. Cross-correlate any burst of backup-deletion activity with concurrent compute/storage-layer indicators (mass EC2 stop/terminate, S3 bulk delete, or the ESXi/endpoint-level T1490/T1489 detections) — recovery-denial rarely happens in isolation from the encryption event it is meant to protect.

Hunting Queries

30-day baseline hunt across both clouds for any non-service-initiated backup/snapshot deletion or soft-delete-disable call, establishing which identities routinely perform legitimate cleanup versus which show up only once or for the first time — a first-time caller performing a bulk deletion is significantly higher-suspicion than a recognized automation identity.

Hunting — KQL

kql

// Hunt: any backup-deletion or soft-delete-disable API call over 30 days, not initiated by the backup service itself, to baseline legitimate vs anomalous callers
union
  (AWSCloudTrail
  | where TimeGenerated > ago(30d)
  | where EventName in ("DeleteRecoveryPoint", "DeleteBackupVault", "DeleteBackupPlan", "DeleteBackupSelection", "DeleteSnapshot", "DeleteDBSnapshot", "DeleteDBClusterSnapshot")
  | where UserIdentityInvokedBy != "backup.amazonaws.com"
  | summarize Calls = count(), Events = make_set(EventName) by UserIdentityArn, RecipientAccountId),
  (AzureActivity
  | where TimeGenerated > ago(30d)
  | where OperationNameValue has_any ("MICROSOFT.RECOVERYSERVICES/VAULTS/BACKUPCONFIG/WRITE", "MICROSOFT.RECOVERYSERVICES/VAULTS/DELETE", "MICROSOFT.COMPUTE/SNAPSHOTS/DELETE")
  | summarize Calls = count(), Events = make_set(OperationNameValue) by Caller, SubscriptionId)
| sort by Calls desc

Hunting — SPL

spl

(index=aws sourcetype="aws:cloudtrail" eventName IN ("DeleteRecoveryPoint","DeleteBackupVault","DeleteBackupPlan","DeleteBackupSelection","DeleteSnapshot","DeleteDBSnapshot","DeleteDBClusterSnapshot") NOT userIdentity.invokedBy="backup.amazonaws.com"
  | stats count as Calls, values(eventName) as Events by userIdentity.arn, recipientAccountId)
append
[ search index=azure sourcetype="azure:activity" operationName IN ("MICROSOFT.RECOVERYSERVICES/VAULTS/BACKUPCONFIG/WRITE","MICROSOFT.RECOVERYSERVICES/VAULTS/DELETE","MICROSOFT.COMPUTE/SNAPSHOTS/DELETE")
  | stats count as Calls, values(operationName) as Events by caller, subscriptionId ]
| sort - Calls

Atomic Red Team Tests

Test 1 Simulate AWS Backup Recovery Point Deletion Burst

linux

Deletes three recovery points from a disposable test AWS Backup vault in rapid succession, simulating the burst-deletion pattern used to inhibit recovery before ransomware detonation. Use a throwaway test vault with synthetic recovery points only — never a production backup vault.

Command

bash

for RP in $(aws backup list-recovery-points-by-backup-vault --backup-vault-name df00tech-atomic-test-vault --query 'RecoveryPoints[].RecoveryPointArn' --output text); do aws backup delete-recovery-point --backup-vault-name df00tech-atomic-test-vault --recovery-point-arn "$RP"; done

Cleanup

bash

Recreate test recovery points via a fresh on-demand backup job against the test vault: aws backup start-backup-job --backup-vault-name df00tech-atomic-test-vault --resource-arn <TEST_RESOURCE_ARN> --iam-role-arn <BACKUP_ROLE_ARN>

Expected Telemetry

AWS CloudTrail management events: eventName=DeleteRecoveryPoint, eventSource=backup.amazonaws.com, three or more events from the same userIdentity.arn within a few minutes, with userIdentity.type NOT equal to AWSService.

Expected Detection

Alert fires once DeleteCount >= 3 within the 30-minute BurstWindow for the same UserIdentityArn/RecipientAccountId — CloudProvider=AWS.

Test 2 Simulate Azure Recovery Services Soft-Delete Disable Then Protected Item Removal

linux

Disables soft-delete on a disposable test Recovery Services vault, then stops protection with data deletion on a test protected item, simulating the two-step sequence used to permanently purge Azure backups. Use a throwaway test vault and test VM/disk only.

Command

bash

az backup vault backup-properties set --name df00tech-atomic-test-vault --resource-group df00tech-atomic-test-rg --soft-delete-feature-state Disable && az backup protection stop-protection --resource-group df00tech-atomic-test-rg --vault-name df00tech-atomic-test-vault --container-name <TEST_CONTAINER> --item-name <TEST_ITEM> --delete-backup-data true --yes

Cleanup

bash

az backup vault backup-properties set --name df00tech-atomic-test-vault --resource-group df00tech-atomic-test-rg --soft-delete-feature-state Enable

Expected Telemetry

Azure Activity Log entries: operationName=MICROSOFT.RECOVERYSERVICES/VAULTS/BACKUPCONFIG/WRITE (soft-delete disabled) followed within minutes by operationName=MICROSOFT.RECOVERYSERVICES/VAULTS/BACKUPFABRICS/BACKUPPROTECTIONCONTAINERS/PROTECTEDITEMS/DELETE, both with resultType=Success from the same caller.

Expected Detection

Alert fires once DeleteCount >= 3 within the 30-minute BurstWindow for the same Caller/SubscriptionId — CloudProvider=Azure. The BackupConfig/write soft-delete-disable event alone should also be flagged per tuningGuidance even below the burst threshold.

Related Detections

Tactic Hub

TA0040Impact

Detection Variants (1)

Different telemetry and tradecraft for the same technique — pick the one that matches the data you collect.

THREAT-Impact-VSSShadowCopyDeletionShadow Copy and Backup Catalog Deletion via vssadmin/wbadmin/wmic

Parent Technique

T1490Inhibit System Recovery

Related Techniques

T1490Inhibit System Recovery T1486Data Encrypted for Impact T1489Service Stop T1078.004Cloud Accounts T1531Account Access Removal T1562.001Disable or Modify Tools

Detect Cloud Backup Vault and Snapshot Deletion Prior to Ransomware Detonation in Google Chronicle

MITRE ATT&CK

YARA-L Detection Query

Data Sources

Required Tables

False Positives & Tuning

Other platforms for THREAT-CloudBackup-SnapshotPurge

Testing Methodology

Response Playbook

Triage

Containment

Evidence Collection

Escalation Criteria

Investigation Guide

Related Techniques

Forensic Artifacts

Tuning Guidance

Hunting Queries

Atomic Red Team Tests

Command

Cleanup

Expected Telemetry

Expected Detection

Command

Cleanup

Expected Telemetry

Expected Detection

Related Detections

Tactic Hub

Detection Variants (1)

Parent Technique

Related Techniques

Same Tactic: Impact

Popular Detections

MITRE ATT&CK

YARA-L Detection Query

Data Sources

Required Tables

False Positives & Tuning

Other platforms for THREAT-CloudBackup-SnapshotPurge

Testing Methodology

Response Playbook

Triage

Containment

Evidence Collection

Escalation Criteria

Investigation Guide

Related Techniques

Forensic Artifacts

Tuning Guidance

Hunting Queries

Atomic Red Team Tests

Command

Cleanup

Expected Telemetry

Expected Detection

Command

Cleanup

Expected Telemetry

Expected Detection

Related Detections

Tactic Hub

Detection Variants (1)

Parent Technique

Related Techniques

Same Tactic: Impact

Popular Detections

Get new detections in your inbox