A recent Cohesity REDLab test detonated 53 ransomware strains against live backup infrastructure – and its own findings show why not all snapshots are immutable backups, and why the difference matters. Get it wrong, and one mistake carries dire consequences.
As ransomware increasingly targets backup systems, questions swirl around how an organization can truly protect and preserve its critical data to render minimal disruption and maintain operational continuity as well as preserve its reputation.
Cohesity, a data security and backup provider, set out to stress test that question with evidence instead of assumption. Between January 2025 and May 2026, it detonated 53 ransomware families in an air-gapped test environment against production-grade backup deployments, mapping the attacks to the MITRE ATT&CK framework.
The results make one thing clear: attackers are no longer hitting backups by accident.
REDLab reported one of three ransomware outcomes resulted in an immediate failed backup or the backups remained intact but with ransomware-encrypted or corrupted data. The third outcome was the backup was unaffected. The study notes with “high confidence” that ransomware operators now treat enterprise backup infrastructure as a primary target, not a secondary objective.
The report headline, according to Amol Sarwate, director of security research for Cohesity, is not that the first backup failed and data was encrypted. Rather, he said, it’s the second attack that succeeded, while quietly preserving backups containing ransomware-encrypted or corrupted data. The victim oblivious to the bad backups, until it’s too late.
Cohesity points out that a completed backup job can look fine on a dashboard even when it’s boobytrapped with ransomware malware or the backup image is scrambled and impossible to recover from.
That gap – between a backup that exists and a backup that’s actually recoverable – is where this gets complicated. It’s also where the industry’s loose use of the word “immutable” starts to matter. Couple that with ransomware groups focusing more on backups and its a recipe for a data disaster.
The Problem with Snapshots
A snapshot captures the state of a dataset at a single point in time. It’s the mechanism Cohesity leans on for its own headline mitigation: “enforcement of snapshot immutability.”
The report backs that up directly: “REDLab observed no mutations of immutable snapshots by any strain in the dataset. No account reachable from the workload plane should be able to shorten retention, delete snapshots, or invoke an override of any kind.”
Immutable vs. Immutable
While snapshots of critical operational data (note, data is hierarchal) can be useful, beware that treating snapshots as a comprehensive cyber recovery strategy can be inadequate in today’s active threat environment. Cautiously speaking, a snapshot is often still part of the same storage environment an attacker can compromise.
Rule of thumb: before you trust the word “immutable” on a spec sheet, read the fine print. Ask your provider what specific mechanism it’s describing. Is it a read-only flag, a retention lock, a WORM policy, some combination? Question whether that protection holds up against someone holding valid administrator credentials, not just against accidental deletion.
Cohesity splits “immutable” into two layers. Snapshots are read-only by default, baked into the file system. REDLab’s own mitigation language covers one layer: a compromised workload can’t reach in and touch a snapshot. It says nothing about a compromised admin credential – someone already inside the backup console.
That’s where DataLock comes in: Cohesity’s WORM feature, which its own documentation says blocks deletion “by anyone, including administrators,” once enabled. Whether base immutability alone holds against an admin credential, or only does once DataLock is on, isn’t spelled out. That’s the point – “immutable” on a spec sheet doesn’t say which layer you’re getting.
How a vendor defines “immutable” is a fair question to put to any backup vendor, Cohesity included. Currently there is no single definition of immutable. NIST offers a fuzzy definition of immutable. Its’ definition includes locking data against modification or deletion once it’s written. But NIST doesn’t spell out whether the lock must survive a compromised administrator credential-based attack.
That leaves vendors to freely apply “immutable” to whatever layer of its own architecture it chooses. It’s on the buyer to figure out which layer that is.
What a Snapshot Can and Can’t Do
Snapshots aren’t useless. They’re fast, cheap – and they preserve an attack as evidence. REDLab caught its worst-case outcomes only because the snapshot faithfully preserved the damage, which is what let anomaly detection and threat scanning find it after the fact. Don’t disable snapshots. Harden them.
REDLab spells out what hardening actually takes. Keep the workload from reaching into the backup tier. Keep backup credentials separate from workload credentials. Route anomaly signals into the same console security teams already monitor, instead of a siloed one nobody checks. Make scan-before-restore mandatory, not optional.
Get those four right, and “immutable” stops being a marketing word. REDLab’s own dataset backs that up: across all 53 detonated strains, zero immutable Cohesity snapshots were successfully mutated.
The downside of snapshots is that they are exactly what they purport to be: a state of data at a specific point in time. Malware may have already corrupted the snapshot, or the files may have been tampered with – so the snapshot, faithfully, preserves the compromise.
Snapshots often live on the same storage, array, or admin domain as the production data they protect. Compromise that environment, and both go down together. Retention windows compound the risk. Sophisticated attackers can sit undetected for weeks or months. So, if snapshots only go back a few days, there’s no clean recovery point left by the time anyone notices.
What ‘Immutable’ Actually Requires
A recovery strategy should account for how data will be restored to a clean, rebuilt environment, not simply how a snapshot can be mounted. Organizations need to regularly test that protected data can actually be recovered. Can applications be reconstructed? Will the restored environment be operational?
A snapshot is a point-in-time copy. An immutable backup is a protected recovery asset. Fenix24 CTO Brandon Williams frames the stakes of that gap as “recovery over resistance” — the argument that guaranteed recovery, not stronger defenses alone, is what actually determines whether an attack becomes a catastrophe.
A layered backup strategy – primary, secondary, and tertiary copies, isolated, locked down, offsite and offline – is your last and best line of defense. The attacker may have your data. You still have it too, and that’s what lets you keep operating.
That’s the bar “immutable” has to clear: locked out to everyone, including root and administrator credentials, until retention expires, not a read-only flag someone with the right access can quietly reverse. When evaluating managed backup solutions, press the vendor on how immutability is actually enforced and not just claimed.
WORM storage (write once, read many) is one thing to ask about by name. Multi-party approval is another: can any single administrator, acting alone, alter or delete a protected copy? The vendors worth trusting require sign-off from more than one admin before a change goes through. That’s a control that closes off both the malicious-insider scenario and the garden-variety fat-fingered mistake.
Therefore, if preservation of data is the desired frontline cyber defense, consider partnering with a service provider steeped in the acumen and experience of immutable data technology.
