How to Test Whether Your Ransomware Backups Will Actually Work Before You Need Them
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Backup design and backup reliability are different things. You can have a documented backup strategy, configured backup jobs, and a green status light in your backup console — and still discover, at the moment you need recovery, that ransomware encrypted your backup repository three days before it deployed on your endpoints, or that your VSS snapshots were deleted by the ransomware payload in its first 60 seconds, or that a full system restore from your backup takes 8 days rather than the 4 hours your recovery plan assumed.
This guide focuses specifically on the failure modes that ransomware creates for backup systems — not the general backup hygiene issues that DR testing guides cover, but the targeted, intentional backup destruction that modern ransomware operators execute as a standard part of their playbook.
Why ransomware specifically targets your backups first
Ransomware operators understood early that backup infrastructure was their primary obstacle to extracting ransom payment. Organizations with clean, accessible backups could restore and decline to pay. The response was to incorporate backup destruction into the standard ransomware attack chain.
Modern ransomware operations — including the major RaaS groups — spend their first hours after initial access conducting reconnaissance specifically to locate backup infrastructure. They look for: Veeam, Acronis, Commvault, and similar backup agent processes; network shares with names containing 'backup,' 'archive,' or 'recovery'; shadow copy schedules in Windows registry; and cloud backup connector processes and credentials stored in browser history or credential managers.
Once backup infrastructure is identified, pre-encryption activity includes: deleting VSS shadow copies (vssadmin delete shadows /all /quiet is in virtually every ransomware script), stopping and disabling backup agent services, encrypting or deleting the backup repository if it is reachable from the compromised network, and exfiltrating backup catalog data to understand what recovery points exist.
The practical implication: if your backup destination is reachable from any endpoint in your network under any credential available to an attacker who has compromised a privileged account, it is at risk.
Test 1: Verify offline or immutable backup integrity
The first test is whether you actually have backups that ransomware cannot reach.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Test 2: VSS and shadow copy survival test
Volume Shadow Copy Service (VSS) snapshots are the fastest recovery mechanism for individual files and system states on Windows. They are also the first target of virtually every ransomware payload.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Test 3: Full recovery time measurement
Recovery time objective (RTO) figures in disaster recovery plans are often aspirational rather than measured. The gap between documented RTO and actual recovery time is the most common surprise in a real ransomware incident.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Test 4: Backup agent and credential exposure
Backup agents installed on production systems run under service accounts that typically have high privileges — they need access to everything they back up. These credentials are a specific target in advanced ransomware operations.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
The bottom line
The backup configuration that looks correct in your management console and the backup that will actually recover your environment after ransomware are frequently different things. The gap is revealed by these tests in a controlled environment — or by ransomware in a real incident. Organizations that run a complete backup reliability test quarterly — including offline backup reachability, immutability verification, VSS survival, and full recovery time measurement — have the data they need to make honest claims about their recovery capability. Those that rely on backup status indicators without testing discover the gap at the worst possible time.
Frequently asked questions
How often should ransomware backup recovery tests be conducted?
Full recovery tests (restoring a critical system end-to-end) should be conducted at minimum annually and ideally quarterly. Component tests (verifying immutability, checking VSS existence, testing backup agent stop attempts) should be part of a monthly operational checklist. After any significant infrastructure change — adding a new backup destination, changing service account credentials, or upgrading backup software — rerun the relevant component tests.
Does object lock (S3 WORM) actually prevent ransomware from deleting cloud backups?
Yes, when correctly configured. Object Lock with Compliance mode prevents deletion by any user including the root account during the retention period. Governance mode prevents deletion by most users but allows root account deletion — choose Compliance mode for ransomware protection. The critical verification: bucket versioning must be enabled before Object Lock can be activated. Buckets with Object Lock enabled but versioning not confirmed are a documented configuration failure.
What is the 3-2-1-1-0 backup rule?
The 3-2-1-1-0 rule is an extension of the classic 3-2-1 rule for ransomware resilience: maintain 3 copies of data, on 2 different media types, with 1 copy offsite, with 1 copy offline or immutable (air-gapped or WORM), and 0 unverified backups (every backup is tested). The additional 1 (offline/immutable) and 0 (tested) elements address the ransomware-specific failure modes that the original 3-2-1 rule predates.
Can ransomware delete backups in the cloud?
Yes, when it has access to the credentials or sessions used to connect to cloud backup services. Ransomware that has compromised a workstation where a backup portal is logged in through a browser, or that has found cloud backup API keys in configuration files, can delete cloud backup repositories. Defense: use dedicated workstations for backup administration, enforce MFA on backup portal access, rotate backup API keys regularly, and enable Object Lock with Compliance mode on backup storage.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.