Ransomware and backup: why immutable storage makes the difference

How an attack unfolds today

The days when ransomware encrypted one PC and left a note are over. A modern attack takes days to weeks:

1. Getting in: a phishing e-mail, a leaked password, a vulnerability in a VPN or an unpatched server.
2. Looking around: the attacker explores the network, looks for administrator rights and above all: looks for the backups.
3. Neutralising the backups: the backup server gets encrypted, the NAS wiped, the cloud bucket emptied with the key that sat on the server, the retention set to zero.
4. Encrypting: only then are the production systems encrypted, often at night or over the weekend.
5. Extorting: paying for the key, and often also paying so that stolen data is not published.

Step 3 is why organisations with "a backup" still pay. The backup existed, but shared the fate of production.

The three weak spots

Reachable. A backup mounted as a network drive, or whose server sits in the same domain, is just another folder to the attacker.

Deletable. A cloud bucket or a backup repository whose key sits on the server can be emptied by that same server. And whoever has the administrator rights of your backup tool can shorten the retention to zero.

Invisible. Nobody notices that yesterday's backups are suddenly three times as large because everything is encrypted, or that the retention was changed last week.

What immutable storage does

Object lock in compliance mode on S3 storage gives every version of every object an expiry date. Until that date nobody can delete or overwrite the version: no administrator, no attacker with administrator rights, no storage provider. A deletion is only a marker; the data stays until the period is over.

That fixes the second weak spot, but only if it is set up properly:

• in compliance mode, not governance mode (which an administrator can lift);
• with versioning on, otherwise overwriting is still a loss;
• with a retention period longer than the time an attacker sits inside unnoticed, thirty days as a minimum.

The permissions of your backup software

You fix the first weak spot with the principle of append only. The software on your server gets a key that may write and read, but not delete. Pruning old versions is done by a separate system, with a different key, on a machine the attacker cannot reach. If they steal the agent's key, the most they can do is write more.

Zekura works that way: the agent cannot delete anything, a separate worker does the maintenance, and even that worker cannot get under the lock period.

Recognising an attack in your backups

The third weak spot, invisibility, is where backups become an unexpected weapon. Encryption has a signature: suddenly everything changes. A nightly backup that normally contains 2 % new data suddenly contains 90 %. Whoever measures that has an alarm that goes off before the attacker sends their note.

Zekura calls this anomaly detection: if the share of new data suddenly jumps, a critical alert is raised, it goes into the evidence chain, and a hold is put on pruning so that the snapshots from before the encryption are guaranteed to remain. In addition, Zekura counts the delete markers on the storage every day and compares that with what the chain accounts for; unexplained markers are an alarm.

What protects you against your own administrator

Not because you distrust them, but because the attacker can take over their account. Anything that weakens your protection (disabling a job, shortening retention, removing a system) must not take effect immediately. At Zekura a 72-hour waiting period applies: everyone is notified, the change is queued with a cancel button, and request and execution go into the chain. Three days is long enough to notice a hijacked account.

Checklist against ransomware

• Is at least one copy under object lock in compliance mode, for at least thirty days?
• Can the software on your server not delete? Do you know that for sure, or do you assume it?
• Is the backup encrypted before it leaves, and is the key not on the same server?
• Do you get an alarm when the amount of new data suddenly spikes?
• Does shortening a retention period only take effect after a waiting period?
• Is something really restored every week, so you know recovery works before you need it?

If you want to feel how that plays out: in RestoreRush the ransomware strikes the moment you think you are done.

Frequently asked questions

Isn't an offline tape safer than object lock?

A tape in a safe is truly unreachable, and that is strong. But it is rarely tested, slow to restore and requires discipline. Object lock in compliance mode gives the same "nobody can get at it" with daily automatic tests. Both together is excellent.

Does immutable storage also protect against data theft?

No. That is what encryption before sending is for, with a key only you hold. See the guide on zero knowledge.

What if the attacker has been inside for weeks?

That is why retention matters: you must be able to go back to before the break-in. Thirty days is the minimum; those who can afford it keep weekly versions for months.