Killing AWS Backup before ransomware: the anti-recovery move

A backup is the thing that lets you say no to a ransom, so capable attackers destroy your ability to recover before they touch your data. Deleting recovery points and weakening the backup vault is anti-recovery, and it is one of the clearest pre-ransomware signals you will see.

How the attack works

With AWS Backup permissions, an unexpected principal edits the vault access policy and lowers retention to weaken protection, then runs DeleteRecoveryPoint across the most recent clean backups for production databases and file systems. Once the vault is emptied, DeleteBackupVault is attempted to remove the restore surface entirely, and destructive encryption or wipe activity begins. CloudTrail records each deletion and policy change with the principal and timing, and AWS Backup history maps recovery points to the resources they protected. In ATT&CK terms this is T1490, Inhibit System Recovery, with T1485, Data Destruction.

Why it works

A single over-privileged principal could both manage and delete backups, and the vaults were not locked. Backups lived where the same identity that ran them could destroy them.

How to fix it

A password reset misses the active session, and deleted recovery points are generally unrecoverable, so waiting on support forfeits the window. Revoke the principal’s Backup and vault permissions, deny its session by aws:TokenIssueTime, and then make remaining recovery points immutable with AWS Backup Vault Lock in compliance mode, which prevents deletion even by root for the retention period. The non-obvious move is delegated-admin separation so no single compromised principal can both back up and destroy recovery. Afterward, enforce compliance-mode Vault Lock with minimum retention fleet-wide and alert on vault-policy and recovery-point deletions.

Practice it

We built this as a GraphLattice Range scenario so responders recognize the anti-recovery signature and lock the vault before the destructive stage.