Backups that survive ransomware: immutable, offline and tested

Most organisations can say "yes, we have backups". Far fewer can say what would happen to those backups if an attacker had administrator access to the network for a week before anyone noticed. That second question is the one that matters, because it's exactly what a modern ransomware attack looks like.

Attackers delete or encrypt backups on purpose. The US Cybersecurity and Infrastructure Security Agency (CISA) says it plainly in its ransomware guide: many ransomware variants go looking for reachable backups so that restoring is impossible unless the ransom is paid. A backup the attacker can reach is, for this purpose, not really a backup.

Why ordinary backups fail

The usual setup looks fine on paper. A backup server copies everything nightly to a storage device on the same network, and maybe a copy goes to the cloud. The trouble is that all of it is reachable with the same few administrator passwords, and often from the same domain.

So the attacker takes the domain, logs in to the backup console, shortens the retention, deletes the restore points, and wipes the cloud copy using the credentials saved in the backup software. Then they run the encryption. The backups were real. They just weren't out of reach. Our article on Veeam backup server vulnerabilities shows how often the backup server itself becomes the way in.

3-2-1, and the two extra digits

The long-standing rule is 3-2-1: three copies of your data, on two different types of media, with one copy offsite. It's still a good rule. It just predates attackers who hunt for backups.

Veeam extended it to 3-2-1-1-0, and it's a useful checklist even if you don't use Veeam:

• 3 copies of your data, counting production.
• 2 different types of storage.
• 1 copy offsite.
• 1 copy that is immutable or offline, so it can't be changed or deleted from the network.
• 0 errors when you test a restore.

The last two are the ones that save you in a ransomware incident.

Immutable versus offline

An immutable copy is one that nobody can alter or delete until a set date, including an administrator. Examples include a Veeam hardened repository on Linux, where backup files are locked for a period you choose, and cloud object storage with object lock turned on, such as Azure Blob immutable storage or Amazon S3 Object Lock. The lock is enforced by the storage itself, so stolen backup credentials don't help the attacker delete the data.

An offline or air-gapped copy is physically or logically disconnected: tape that goes offsite, or a removable drive that's only connected during the backup window. It's old-fashioned and it works, as long as someone actually rotates it.

You don't need both, but you need at least one. Our view: for most organisations an immutable cloud or hardened copy is easier to run reliably than a manual rotation, because it doesn't depend on someone remembering on a Friday afternoon.

One caveat worth knowing: an immutable copy is only as good as its retention period. If you lock backups for seven days and the attacker was inside for three weeks, every locked copy may already contain their tools. Longer retention on at least one copy gives you somewhere clean to go back to.

Separate credentials

Immutability protects the files. Separate credentials protect everything around them.

1. Don't use your everyday domain administrator accounts to run backups. Give backup administration its own accounts, with multi-factor authentication.
2. Keep the backup server out of the production domain: in a workgroup, or in a management domain in a separate Active Directory forest. Veeam's own security guide recommends this.
3. Store the credentials for your offsite or cloud copy somewhere the backup server can't hand them over, such as single-use credentials for a hardened repository.
4. Limit who can reach the backup system on the network. Staff workstations have no business talking to it.

Test restores, not just backup jobs

A green tick on a backup job tells you data was copied. It doesn't tell you that you can bring a server back, in what order, or how long it takes.

Test at least a few restores each quarter, and a full recovery of one important system at least once a year. Time it, write down what went wrong, and fix the runbook. CISA also recommends keeping "golden images" of critical systems, meaning prepared templates you can rebuild from quickly, and storing the installers and licence details you'd need alongside your offline backups.

How this maps to the Essential Eight

Regular backups is one of the eight mitigation strategies in the Australian Cyber Security Centre's Essential Eight. At maturity level one, the model expects backups of data, applications and settings to be made and kept in line with how critical they are to the business, restoration to be tested as part of disaster recovery exercises, and ordinary (unprivileged) accounts to be unable to touch other people's backups or to change or delete backups at all.

The higher levels tighten who can reach the backups. By maturity level three, even backup administrator accounts are prevented from changing or deleting backups during their retention period, which in practice means immutable storage. So immutability isn't just good practice here. It's how you meet the top level.

Our explainer on Essential Eight maturity levels covers what each level means across all eight strategies. And if much of your data lives in Microsoft 365, read why Microsoft 365 retention isn't a backup as well.

A short checklist

1. List what you back up, and what you don't.
2. Confirm at least one copy is immutable or offline, and check its retention is long enough.
3. Separate backup credentials from production, with MFA.
4. Patch your backup software like any other internet-adjacent system.
5. Test a restore this month, and put the next one in the calendar.

Where Geidi fits

Backup and disaster recovery is part of Geidi's Managed IT & Support service, alongside patching and performance monitoring, with a 7-day service desk. If you'd like a second opinion on whether your backups would survive a ransomware attack, get in touch.

Sources

• CISA: #StopRansomware guide (opens in a new tab)
• Veeam: What is the 3-2-1 backup rule? (3-2-1-1-0) (opens in a new tab)
• Veeam: Hardened repository, user guide (opens in a new tab)
• Veeam: Security best practice guide, Workgroup or domain? (opens in a new tab)
• Microsoft Learn: Overview of immutable storage for blob data (opens in a new tab)
• Amazon Web Services: Locking objects with Object Lock (opens in a new tab)
• Australian Cyber Security Centre: Essential Eight maturity model (opens in a new tab)