Ransomware groups worked out years ago that encrypting production is only half the job. If the victim can restore, they do not pay. So the modern playbook is to find the backup infrastructure first, delete or encrypt it, and only then trigger encryption on production.
This is why backup that merely exists is no longer sufficient, and why immutability has moved from a nice-to-have to the control that determines whether an incident is a bad week or an existential event.
What immutable actually means
An immutable backup copy cannot be modified or deleted by anyone, including the account that created it, until a defined retention period expires. Not by an administrator. Not by someone holding stolen domain credentials. Not by the backup software itself.
That last point is what makes it different from ordinary access control. Permissions can be changed by whoever holds sufficient privilege, and an attacker who has reached domain administrator holds exactly that. Immutability is enforced below the permission layer, so escalating privilege does not help.
What it stops
- An attacker with domain administrator rights deleting your backup repository
- Ransomware encrypting backup files alongside production data
- A malicious insider destroying records before leaving
- Accidental deletion by an administrator during routine work
- Retention being silently shortened to make old copies age out
What it does not stop
This is the part that gets skipped, and it matters more than the marketing usually admits.
- Immutability does not detect compromise. If an attacker was present in your environment for two months before triggering encryption, your immutable copies from that period faithfully preserve a compromised environment. You need recovery points reaching back far enough to predate the intrusion.
- It does not guarantee the backup is usable. An immutable copy of a corrupt or incomplete backup is a permanently preserved corrupt backup. Verification is a separate control.
- It does not protect what was never backed up. The workload nobody added to the schedule is not protected by anything, immutable or otherwise.
- It does not shorten recovery time. Knowing your data survived is not the same as being operational again, which is what disaster recovery addresses.
The retention window question
Because attacker dwell time is frequently measured in weeks, a seven-day retention window can leave you with only compromised recovery points. Industry incident data has repeatedly shown median dwell times long enough to outlast short retention schedules.
The practical guidance is to keep daily recovery points for at least thirty days, weekly points for several months, and monthly points for a year or more on critical systems. The storage cost of longer retention is trivial next to the cost of discovering that every available restore point contains the attacker.
How to verify yours is real
Do not take the console's word for it. Three checks settle the question:
- Attempt a deletion. Using an administrative account, try to delete a backup that is inside its immutability window. It should fail. If it succeeds, your backups are not immutable regardless of what the settings claim.
- Check the retention lock covers the whole chain. Some configurations protect full backups but leave incrementals deletable, which breaks the restore chain just as effectively.
- Perform a real restore from an immutable copy, not just a verification job. Restore to an isolated network, boot the system, and confirm the application actually works.
If your organisation cannot answer when those three checks were last performed, that is the finding. It is also a straightforward one to fix, and it is the highest-value hour of security work most organisations can do this quarter.
Written by the Techx4u, Inc engineering team. If you would like any of this looked at in your own environment, get in touch.