Soft delete off, backups gone: the alarm before Azure ransomware

Ransomware crews delete your backups first, because a backup is the thing that lets you say no. Soft delete is the buffer that gives you a second chance, so when you see it turned off and backups deleting, that is the alarm, not the aftermath.

How the attack works

With Backup Contributor or Owner scope, the attacker disables soft delete on the Recovery Services vault, removing the fourteen-day recovery buffer, then deletes the protected items for production VMs and SQL with backup data removed. They probe to strip resource locks and any immutable setting to clear remaining recovery options, and then mass encryption of production disks and shares begins with no restore path left. Because the vault contents themselves are gone, the record lives in the control plane: the Activity Log and vault audit events record the soft-delete disable and each delete with timestamp and calling identity, while the surviving inventory only shows what was spared. In ATT&CK terms this is T1490, Inhibit System Recovery, with T1485, Data Destruction.

Why it works

A single role could both disable soft delete and delete protected items, with no second-person check. One privileged identity held the whole anti-recovery path.

How to fix it

Do not open a low-priority ticket or wait to confirm it is really ransomware, because by morning the backups are gone. Treat it as a precursor now: revoke the actor’s backup or Owner role, apply a delete lock to the vault, re-enable soft delete, and invoke break-glass recovery readiness for what remains before encryption spreads. Afterward, enforce always-on soft delete with multi-user authorization so one identity cannot disable protection, put the backup-admin role behind PIM, and keep an immutable secondary copy isolated from the production tenant.

Practice it

We built this as a GraphLattice Range scenario so responders treat backup destruction as the trigger to act, not as something to investigate later.