How do I protect backups from ransomware?

A ransom only works if the victim can't restore. So before encrypting anything, attackers who get into a network go looking for the backups and destroy them first. Protecting backups means assuming the network is already compromised: at least one copy that can't be changed, credentials the attacker doesn't have, and restores that need a person to approve them.

Why does ransomware go after the backups first?

Because a clean backup lets the victim rebuild and ignore the ransom note. Attackers who have got into a network commonly:

• delete Windows Volume Shadow Copies, for example with vssadmin delete shadows /all /quiet;
• encrypt or wipe backup files on any share they can reach;
• sign in to backup consoles with stolen administrator passwords to delete backup history or shorten retention.

Anything the attacker's account can reach, the attacker can destroy. If the backup system uses the same credentials as the domain or the servers it protects, those credentials open the backups too. Treat any storage a compromised server can write to as within the attacker's reach.

What makes a backup ransomware-proof?

No single setting does it. You need all of these:

• One copy the network can't change: immutable storage or an offline copy.
• Separate credentials for that copy, not the domain admin and not the server's own accounts.
• A write-only backup agent. It can add new backups but can't read, change or delete existing ones, so taking over the server doesn't give the attacker the history.
• Restores a person approves, with two-factor sign-in, not something the server can trigger.
• Enough retention to reach back to before the attacker got in.
• Alerts when backups fail or stop, so a quiet change doesn't go unnoticed.
• Restore tests, so the first restore isn't during the incident.

Encryption protects confidentiality: a stolen backup can't be read. It doesn't stop an attacker deleting the backup files or encrypting them again. You need both encryption and immutability.

Is a NAS on the same network enough?

No. A NAS joined to the domain, or a backup share mapped as a drive letter on the server, is reachable with the credentials the attacker already has. Ransomware looks for every drive it can see, mapped network drives included. If the server can delete files on the share, so can ransomware running on that server.

A local NAS copy is still worth having: restores from it run at LAN speed. It just isn't ransomware protection on its own. Don't map the backup share as a drive, don't use domain admin credentials for it, and keep a second copy somewhere the network can't change.

What is immutable backup storage?

Storage that refuses to change or delete an object until its retention period ends. On Amazon S3 this is Object Lock, and it has two modes.

In governance mode, users with a special permission (s3:BypassGovernanceRetention) can still delete a locked object or shorten its retention. That is flexible, and it is a hole if those credentials are stolen. In compliance mode, nobody can delete the locked version or shorten its retention before the date, including the account's root user.

For backups meant to survive a stolen admin account, compliance mode is the right default. The trade-off is that you can't clean up early, to save space or for any other reason, so choose the retention period deliberately.

Who should be able to delete a backup?

As few accounts as possible, and never the one that runs the backups. Separate the accounts that write backups from the ones that can delete them. Put two-factor sign-in on the backup console and review who has administrator rights.

A deletion or a retention change should be rare and visible. If an attacker steals one set of credentials, they shouldn't be able to erase weeks of history with it. Every extra step they have to take is time for you to notice.

How far back do you need to keep backups?

Weeks, not days. Attackers are often inside a network for some time before they encrypt anything: moving between machines, taking data, setting up their tools. If you only keep a few days of backups, every one of them may already contain the attacker's changes. Keep enough history that you can pick a point from before the intrusion. The right length depends on the client, but it has to reach past the attacker's first day.

How do you restore after an attack?

1. Rebuild the server, or use a clean one. Don't restore onto the compromised server: the attacker's tools may still be on it.
2. Keep the rebuilt server off the production network until you've checked it.
3. Pick a restore point from before the compromise, not simply the latest night.
4. Check the restored data before you rely on it.
5. Change every credential the attacker may have seen before you reconnect anything.

Backups taken after the compromise may contain damaged files or the attacker's tools. The ones from before are the ones you trust.

How does MoorNest protect backups from ransomware?

MoorNest is built around these rules. The agent on each server can only add new backups: it can't read, change or delete the ones already stored. Nothing is overwritten, and in MoorNest Cloud, S3 Object Lock in compliance mode means no one can delete a backup early, including us. Restores start in the console with your password and an authenticator code, never from the server.

If ransomware takes over a server, the backups from before the attack stay out of its reach and you restore a night from before it. The limit is the same as everywhere else: backups taken after the compromise can contain damaged files. The security page has the details.