Ransomware Backup Resilience: A Recovery Testing Program That Proves Your Backups Would Survive

Immutability means that backup data cannot be modified or deleted before its retention period expires, even by an account with storage-level administrative access. This is not the same as having read-only permissions on a share. A domain admin can change ACLs. Immutability must be enforced at the storage platform level, not the file system level.

For Veeam with a Linux hardened repository: deploy a dedicated Linux server running a minimal distribution. Do not join it to the domain. Create a local service account for Veeam to connect to the repository. Enable immutability in the Veeam repository settings under Storage > Immutability and set a retention period of at least 14 days longer than your longest backup retention policy. The immutability flag in Veeam hardened repositories uses Linux immutable file attributes (chattr +i) that cannot be removed even by root during the retention window. Verify this by testing: even with root access to the Linux server, you should not be able to delete files marked immutable.

For Azure Blob Storage: create a dedicated storage account for backups separate from your primary Azure subscription if possible. Enable immutable blob storage under the storage account settings: Data Management > Blob Service > Immutability policies. Set a time-based retention policy. Enable lock on the policy after testing; a locked policy cannot be removed even by a storage account owner until the retention period expires. Consider using a separate Azure subscription with a different tenant-level admin account for backup storage to prevent lateral movement from a compromised primary tenant.

For AWS S3 Object Lock: create a dedicated S3 bucket and enable Object Lock at bucket creation (it cannot be enabled after creation). Set the default retention mode to Compliance rather than Governance. Compliance mode means that not even the root account can delete objects before retention expires. Set a minimum retention period of 30 days. Enable MFA Delete on the bucket as an additional layer. Use a dedicated IAM role for backup write access that has s3:PutObject and s3:GetObject but never s3:DeleteObject or s3:PutObjectRetention.

The most common backup resilience failure is that the account used to manage the backup system is a domain admin, or is managed by a domain admin. When an attacker compromises domain admin, they get backup admin as a side effect.

For Veeam: the service account running Veeam Backup and Replication services should be a dedicated local account on the Veeam server, not a domain account. The account used to access backup targets should have only the permissions required to read and write backup data. The Veeam administrator account used by your backup team should be a separate local account with a password stored in your PAM solution under a different check-out policy than domain admin credentials.

For cloud backup targets: create a dedicated cloud account or subscription. The credentials for that account should not be stored anywhere accessible to domain admin. Use a hardware security module or your PAM vault's most restricted tier for backup account credentials. Rotate backup account credentials quarterly and verify that the rotation does not break backup jobs within the same maintenance window.

Test your isolation: document a scenario where your domain admin account is fully compromised. Walk through every path by which that compromised account could reach your backup infrastructure. If any path leads to the ability to delete or corrupt backup data, that is a gap to remediate before the next drill. Common gaps include backup software consoles accessible over RDP from domain-joined machines, backup storage mounted as network shares visible in Active Directory, and cloud backup accounts federated to your primary identity provider.

A restore drill that tests whether a backup job completed successfully is not a resilience test. The goal is to verify that you can restore specific systems to a usable state within your RTO, starting from a realistic adversarial scenario.

Scenario for your quarterly drill: assume that administrative credentials have been compromised and that the attacker targeted backup systems before deploying ransomware. Your on-premises Veeam server is inaccessible. Your Active Directory domain controllers have encrypted drives. Your file servers are encrypted. You have cloud-based immutable backups available. Your backup admin break-glass credentials are in the physical safe.

Drill steps: Step 1, retrieve break-glass credentials from their offline storage location. Time this; if retrieval takes 45 minutes, that is part of your actual RTO. Step 2, authenticate to your cloud backup console using the isolated backup admin account. Verify that the most recent restore point exists and is within your RPO. Step 3, initiate restore of a non-production replica of your primary domain controller to an isolated recovery network. Time from restore initiation to a functional login prompt. Step 4, restore a file server restore point to the recovery network and verify that a sample of 50 critical files are intact and accessible. Step 5, document actual elapsed time against your RTO target.

Do not run the drill with your most critical production systems if recovery failure would cause a service outage. Use exact replicas or secondary systems that mirror the production configuration. The drill must test the process, tooling, and credential paths, not just click through a wizard on a test VM.

Stated RTO and RPO values on paper mean nothing until they are measured under drill conditions. The stopwatch methodology forces you to actually time each step rather than estimate.

Before the drill, document your RTO and RPO commitments per system tier. Tier 1 systems (domain controllers, primary authentication, core ERP) might have a 4-hour RTO and 1-hour RPO. Tier 2 systems (file servers, secondary applications) might have 24-hour RTO and 4-hour RPO. Tier 3 systems (developer tools, test environments) might have 72-hour RTO and 24-hour RPO.

During the drill, assign one person as the timekeeper whose only job is to record timestamps on a shared document. Record: drill start time, time credentials were retrieved, time restoration was initiated for each system, time first successful authentication was achieved on each restored system, time each system was declared functionally restored, and drill end time.

After the drill, calculate actual RTO achieved per system tier and compare against the committed value. If actual RTO exceeded the committed value, document the specific steps that consumed the most time. Common time sinks include waiting for large backup transfers over limited bandwidth connections, manual approval workflows to authorize restores, and missing documentation that required the team to troubleshoot mid-drill.

Publish the RTO and RPO verification results to your executive team annually. If achieved RTO exceeds committed RTO, the remediation plan for closing the gap belongs in the same report. This prevents the common failure mode where RTO commitments are made based on vendor specs rather than tested reality.

This test answers the specific question: if a threat actor has full domain admin access to your primary environment, can they delete your backups?

Conduct this test in a controlled window with your backup team present. Log in with a domain admin account. Attempt the following actions and document whether each succeeds or fails:

Attempt 1: connect to the backup storage location (UNC path, Veeam console, cloud storage account) using domain admin credentials. If this succeeds, the backup storage is reachable from a compromised domain admin session.

Attempt 2: attempt to delete the most recent restore point through the Veeam console while authenticated as domain admin. If Veeam's own immutability allows deletion by the console admin, the architectural isolation is insufficient.

Attempt 3: attempt to modify or delete files in the hardened Linux repository directly using any account you can reach from the domain environment. If the Linux server is not domain-joined and SSH access requires a local key that is not stored in domain-accessible systems, this should fail.

Attempt 4: attempt to delete objects in your cloud backup bucket using any credentials accessible from the primary environment. If cloud credentials are stored in your primary secrets manager, attempt to retrieve and use them.

Document every attempt and its outcome. Any success is a remediation item. Repeat this test after remediation and document the retest result. The test log becomes evidence in your backup resilience audit that you have proactively verified adversarial path blocking.

The 3-2-1-1-0 rule is the modern evolution of the classic 3-2-1 backup rule, extended for ransomware resilience:

3: three copies of data exist. 2: two different storage media types are used. 1: one copy is offsite. 1: one copy is offline or air-gapped or immutable. 0: zero backup errors verified in the last restore test.

Use the following checklist annually to certify your program against this standard:

Three copies: name the three distinct backup copies in your environment. Identify the storage system, location, and account that holds each. Verify all three have a restore point within the last 24 hours for Tier 1 systems.

Two media types: document the media types used. On-premises disk backup counts as one type. Cloud object storage counts as a second type. Tape is a third. You need at least two distinct types represented across your three copies.

One offsite: identify which copy is geographically separate from your primary data center. For cloud-native organizations, the cloud backup is inherently offsite if the cloud region is separate from your primary office.

One immutable: identify which copy is protected by architectural immutability (Veeam hardened repo, S3 Object Lock Compliance, Azure locked immutability policy). Document the specific immutability setting and its configuration.

Zero errors: run a restore drill and document that at least one Tier 1 system was successfully restored within its RTO with no backup errors. Attach the drill stopwatch log as evidence.

For each checklist item, name a specific owner, record the last verification date, and schedule the next verification date. The checklist is not complete until all five items have documented evidence from the current year.