How to create a secure backup strategy that survives ransomware

Why attackers go after backups first

Backups are the reason a victim can refuse to pay, so removing them is part of the plan. The #StopRansomware Guide from CISA and its partners (September 2023 edition) warns that many ransomware variants try to find and then delete or encrypt accessible backups, which is why it tells organizations to keep offline, encrypted backups and to test them regularly.

Victims report the same thing. In a Sophos survey published in March 2024 of 2,974 IT and security professionals whose organizations had been hit by ransomware, 94% said the attackers tried to compromise their backups, and 57% of those attempts succeeded. Where the backups fell, the median ransom demand was $2.3 million, against $1 million where they survived. Mandiant's M-Trends 2026 describes the same shift in its 2025 investigations: ransomware groups, including those using Akira and Qilin, went after backup infrastructure, identity services and virtualization management, and deleted backup objects from cloud storage.

MITRE ATT&CK catalogues these moves as Inhibit System Recovery (T1490). In practice they fall into five groups:

• Local recovery points. Deleting Windows volume shadow copies and the Windows Backup catalog, and removing virtual machine snapshots on ESXi hosts.
• Online backups. Anything reachable over the network: backup shares on network storage, and folders that sync to cloud services.
• Cloud backups. Turning off versioning and backup policies, then deleting snapshots, database backups, machine images and earlier object versions.
• Warning signs. MITRE notes that attackers may disable recovery notifications first, so nobody sees the backups being corrupted.
• The backup server itself. CISA's Akira advisory (AA24-109A, updated November 13, 2025) describes the group exploiting unpatched Veeam Backup & Replication servers (CVE-2023-27532 and CVE-2024-40711) and using a PowerShell script that obtains and decrypts the accounts stored on Veeam servers. A backup server holds credentials for everything it backs up, which makes it a target in its own right.

Backups cannot fix data theft. In what the CISA guide calls double extortion, attackers also threaten to publish what they stole, and a restore does not un-leak it. An unencrypted backup copy is also a convenient package to steal, which is where the first control starts.

Encrypt every copy, and keep the keys somewhere else

Encryption protects backups against theft, both on the way to storage and once they are there. Send every transfer over TLS or the backup tool's own encrypted channel, and encrypt the stored data, ideally on the client before it leaves the server, so the storage provider and anyone who steals the storage account see only ciphertext. The open-source tool restic, for example, encrypts stored data with AES-256 in counter mode and authenticates it with Poly1305-AES.

The key is the weak point, in both directions. The NCSC's principles for cloud backups point out that an attacker does not need to delete encrypted backups if they can delete or change the key. And if you lose the key yourself, the backup is gone: restic's documentation states plainly that losing the repository password means the data is irrecoverably lost. So:

• Keep keys out of the systems being backed up, and out of any password vault that production admin accounts can open. A key stored next to the data protects nothing.
• Keep an offline copy of each key. The NCSC suggests an out-of-band key backup, such as the master key printed as text or a QR code and kept in a safe.
• Use separate keys for separate systems where the tool allows it. restic's threat model notes that a leaked key for a repository shared by several hosts exposes the backups of every one of them.
• Make key deletion slow and loud. AWS KMS requires a waiting period of 7 to 30 days, 30 by default, before it deletes a customer managed key. The key cannot be used while deletion is pending, the deletion can be cancelled, and scheduling it writes a CloudTrail entry you can alert on.
• Rotate after an incident. The CISA guide's recovery steps include updating customer-managed encryption keys once the environment has been cleaned.

Make at least one copy immutable

Immutable storage, also called WORM (write once, read many), accepts new data but refuses to change or delete what it holds until a retention date passes. It is the control for the case that matters most: the attacker already has admin rights. If the storage itself refuses the delete, stolen credentials are not enough. The CISA guide recommends delete protection or object lock on the storage ransomware targets, and the NCSC's on-premises principles suggest blocking deletion and alteration requests on backups, for example with WORM media.

Amazon S3 Object Lock: governance or compliance mode

S3 Object Lock works only on buckets with versioning, and protects each object version with a retention period, a legal hold (which lasts until someone removes it), or both. Once it is enabled on a bucket, you cannot disable Object Lock or suspend versioning for that bucket. The retention mode decides who can undo a lock:

Two details change how much governance mode is worth. The S3 console sends the bypass header by default, so anyone holding the bypass permission can delete governance-locked objects with a few clicks. And for compliance mode, AWS notes that the only way to delete a locked object before its date is to delete the AWS account, which makes the account itself the thing to protect (covered below). A default retention rule applies the lock to every new object written to the bucket:

{
  "ObjectLockEnabled": "Enabled",
  "Rule": { "DefaultRetention": { "Mode": "COMPLIANCE", "Days": 30 } }
}

Azure immutable blob storage

Immutable storage for Azure Blob Storage offers the same two tools: time-based retention policies and legal holds, set at container level or, with versioning, down to individual blob versions. A new time-based policy starts unlocked so you can test it, and Microsoft recommends locking it, typically within 24 hours. A locked policy cannot be deleted, and its retention can be extended but never shortened. Retention runs from 1 day to 146,000 days.

Locked backup vaults

Backup services apply the idea to a whole vault. AWS Backup Vault Lock has a governance mode and a compliance mode; in compliance mode, once a grace time of at least 72 hours ends, neither you nor AWS can change or remove the lock, and no recovery point can be deleted before its retention ends. The Azure Backup immutable vault blocks the operations that would lose recovery points, and can be locked so that nobody can switch immutability off again.

Keep a copy offline or air-gapped

Immutability stops deletion through the storage's own interface. An offline copy stops everything that needs a network path. NIST's glossary defines an air gap as an interface where two systems are not physically connected and any logical connection is not automated, so data crosses only manually, under human control. That is a stricter test than many products sold as "air-gapped" meet, so it helps to be precise about what each option isolates:

For physical media, the NCSC adds a practical point: choose the storage location with floods and fires in mind. For cloud copies, the CISA guide suggests considering more than one cloud for cloud-to-cloud backups, in case every account with a single vendor is affected. AWS's logically air-gapped vault is a middle ground: backups are stored in an account owned by the AWS Backup service, the vault comes with a compliance-mode Vault Lock, and with multi-party approval you can still restore from it if your own account is locked out or closed, until the post-closure period ends.

What does not count as offline: a network share mapped on every PC, a USB drive that stays plugged in, or a folder that syncs to the cloud. MITRE lists network storage and synced folders among the online backups attackers delete. On a single Windows PC, controlled folder access lets only trusted apps change files in protected folders, which can stop ransomware rewriting your documents, but it is not a backup; our guide to choosing antivirus software explains how to turn it on, and our guide to recovering deleted files on Windows covers the copies Windows and OneDrive can give back.

Give the backup system its own accounts and least privilege

The NCSC notes that in a ransomware attack it is common for attackers to gain access to enterprise admin accounts and move laterally with them. If the backup console accepts those same accounts, the backups fall with the rest of the network. Its on-premises principles ask for credentials used only for the backup system, MFA on any request to alter or destroy backup data, a management interface reachable only from controlled locations, and regular reviews of who has access, physical access to backup media included.

In practice:

1. Keep the backup console off the production directory. If it signs in through the same directory or single sign-on the attacker has just taken over, it is not separate. Use accounts that exist only for the backup system, from a dedicated admin workstation.
2. Use phishing-resistant MFA. The CISA guide asks for phishing-resistant MFA on accounts that access critical systems. CISA's fact sheet on phishing-resistant MFA (October 2022) names FIDO/WebAuthn as the only widely available form, with PKI-based smart cards as the other, and explains why push approvals and SMS codes fall to push bombing and SIM swapping.
3. Split the roles. A backup agent needs to add data, not delete it: the NCSC's cloud principles suggest forbidding destructive requests from every customer identity, backup agents included, and authorizing exceptions out of band. Operators run jobs and restores; changing retention or deleting data is a separate, rarer permission.
4. Require a second person for destructive changes. Azure Backup's multi-user authorization puts critical operations behind a Resource Guard owned by a different user, which can sit in a different subscription or tenant. Disabling soft delete and removing the protection are always guarded; deleting backup data and reducing retention are guarded by default.
5. Protect the account that owns the storage. The only way to delete a compliance-locked S3 object early is to delete the AWS account, and when an AWS account holding a locked backup vault is closed and not reopened within 90 days, AWS deletes the vault's contents. The NCSC's cloud principles add that an attacker should never be able to lock you out of your backups by disabling your accounts: agree a separate, out-of-band way in with the provider.
6. Patch the backup software early. The NCSC asks for backup appliances and software to be inside the normal patching regime and on a supported version. The Akira intrusions through unpatched Veeam servers show why a vulnerability in backup software deserves priority.

Make deletion slow and reversible

Where full immutability is not available, or not affordable for every copy, the next best thing is a delete that takes time and can be undone. The NCSC suggests three mechanisms: soft delete by default, so deleted data stays recoverable for a period from an area that users and administrators cannot purge; a delay on deletion or alteration requests, matched to how often you check; and an alert that reaches someone. Without the alert, soft delete only gives the attacker a timer: if everything is soft-deleted and nobody notices before the period ends, it is gone.

Azure Backup's soft delete keeps deleted backup data for 14 days by default, extendable to 180 days. Microsoft's secure-by-default change enforces it, so in the regions where that applies it can no longer be turned off. It has limits worth knowing: the disk and virtual machine snapshots kept for instant restores can be deleted directly before the soft-delete period ends. Treat them as a speed feature, not a safety copy. On object storage, the CISA guide recommends versioning, so an overwritten or deleted object can be recovered from an earlier version; versions can still be deleted by someone with permission, which is the gap Object Lock closes.

Retention policy matters as much as the lock. Keep backups for a fixed period of time, not a fixed number of copies. The NCSC explains the attack this prevents: run enough backups of corrupted data in quick succession, and a count-based policy pushes every good copy out. restic's threat model describes the same trick against its own forget retention command, with garbage snapshots created until the real ones are pruned. The NCSC also suggests an alert when backup storage approaches capacity, since flooding it is another way to force good data out.

Alert on failed, changed and deleted backups

Attackers try to work quietly. MITRE notes they may disable recovery notifications before corrupting backups, and the NCSC warns that they may act outside office hours. Its principles list the kinds of change that should raise an alert, whether or not the attempt succeeds. In practice:

Send these alerts to a channel that does not depend on the systems under attack. The NCSC suggests a security operations centre for larger organizations and an automated email to a monitored group mailbox for smaller ones; if that mailbox lives in the same tenant the attacker may control, add a second route. Azure Backup shows what good defaults look like: its built-in security alerts for deleted backup data or disabled soft delete fire as Sev 0 alerts and cannot be turned off, while job failure alerts are on by default. Also alert on silence: a system with no successful backup in its expected window is as urgent as a failed job.

On Windows endpoints, the CISA guide lists the built-in tools whose unusual use signals an attempt to impair recovery: bcdedit.exe, fsutil.exe (deletejournal), vssadmin.exe, wbadmin.exe and wmic.exe (shadowcopy or shadowstorage). These are MITRE's examples of what that looks like on a command line, and each one deserves a high-priority alert in your endpoint or SIEM tooling:

vssadmin.exe delete shadows /all /quiet
wbadmin.exe delete catalog -quiet
bcdedit /set {default} recoveryenabled no

Back up SaaS data, and limit what the backup app can reach

Software as a service does not remove the need for backups. Microsoft's shared responsibility model is explicit that for every cloud deployment type, including SaaS such as Microsoft 365, you own your data and identities. The CISA guide asks organizations to review that model for services like Microsoft 365 and to back up data often, offline or cloud to cloud.

There are two routes, and each has one account that matters most:

• The provider's own backup. Microsoft 365 Backup keeps restore points every 10 minutes for two weeks and weekly snapshots back to 52 weeks for OneDrive and SharePoint, and every 10 minutes for 52 weeks for Exchange Online, with a recovery window you can set between 3 months and 2 years (1 year by default). The data stays inside Microsoft 365, and the backups are immutable unless the Backup tool's administrator deletes them by offboarding the product. Protect that administrator role as you would the backup console.
• A third-party backup app. Most read your tenant with app-only access. Microsoft's permissions overview calls application permissions highly privileged: an app granted Files.Read.All as an application permission can read any file in the organization, and only a Privileged Role Administrator or Global Administrator can consent to it. The backup vendor's console is therefore a key to every mailbox and file you back up.

For either route, check which application permissions the backup app holds in Microsoft Entra ID and remove any it does not need, give the backup console the same separate accounts and phishing-resistant MFA as above, and ask the vendor where copies are stored, whether they are immutable and who can delete them. The CISA guide says that when a third party or managed service provider runs your backups, it should follow the same practices, written into the contract.

Test restores in an isolated environment

A backup is only proven by restoring it, and the restore is also when an attacker can come back. The CISA guide warns that the ransomware may be only the visible part of an intrusion: the dropper malware behind it has to be found before rebuilding from backups, and clean systems must not be re-infected, for example by adding only clean systems to a new recovery VLAN. Timing matters too. M-Trends 2026 puts the global median dwell time at 14 days in 2025, and 122 days in cyber espionage and North Korean IT worker cases, so the newest backup may already contain the intruder's tools, and retention has to reach back further than that.

A restore test that proves something:

1. Build the isolated environment before you need it: a separate network segment or cloud account with no route to production, no shared credentials and no trust with the production directory.
2. Pick the restore point deliberately. In a real incident, choose one from before the first sign of compromise, not simply the latest.
3. Scan before release. Veeam's Secure Restore checks restore points for malware, with its own engine, third-party antivirus or YARA rules, before a machine returns to production. Malware protection in AWS Backup uses Amazon GuardDuty to scan recovery points, and AWS recommends on-demand scans to find your last clean backup and a full scan before a restore.
4. Look for persistence as well as malware: admin accounts that should not exist (Akira operators have created new accounts and added them to the administrators group), scheduled tasks and remote access tools.
5. Check the data, not just the job status: the application starts, the database is consistent, files open and record counts match.
6. Time it and keep the evidence. AWS Backup restore testing runs scheduled restores, records how long each took, supports a validation step and then deletes the test resources. Whatever the tool, keep a dated record of what was restored, how long it took and what failed.

A secure backup checklist

Use this to review an existing setup. Each line should have an owner and a way to prove it:

If you would rather have this run for you, our hosting and maintenance service keeps three copies on two kinds of storage, one off-site and immutable, and runs restore drills that restore a recent backup into an isolated environment and record how long recovery took. Our security scanning reviews AWS and Azure accounts for public storage and snapshots, over-permissive IAM and stale keys, and checks websites for exposed files, panels and backups.