Can Attackers Reach Your Backups? Why Immutable Storage Is Not Enough
Table of Contents
Immutable storage answers one question: can this object be changed? It does not answer the question that decides most ransomware recoveries. That question is who can reach the systems that write, mount and delete the data. This article looks at backup protection through that lens: attacker reachability. An isolated recovery environment is a separate copy of backup data with tight access control, which production credentials and networks cannot reach.
Attackers rarely fight the storage layer. The Sophos State of Ransomware 2026 report found that 79% of ransomware attacks started with an identity-based approach. It put the average recovery cost at $1.7 million, up 11% year over year. An attacker with valid credentials does not need to break a retention lock. The attacker only needs to reach whatever controls it.
The sections below show where immutability stops, how identity-first and AI-driven attacks use the gaps, and how to audit a design for reachability. For the restore side, including how to scan, verify and promote systems safely, see our guide to clean room recovery and a ransomware-proof restore path.
What Immutable Backup Solutions Actually Guarantee
Immutable backup solutions stop a stored object from being changed or deleted until its retention period ends. The method may be WORM retention on a file system. This guide to setting up immutable file-level WORM covers it. Another is Object Lock on AWS-compatible S3 object storage.
The guarantee is real: it stops ransomware from encrypting good restore points. It stops a script or a compromised account from deleting them early. It also stops overwrites. Government guidance agrees: the CISA advisory on Akira ransomware recommends backups that are “encrypted, immutable (i.e., cannot be altered or deleted), and covers the entire organization’s data infrastructure.”
The newer CISA advisory on Gunra ransomware, issued in August 2026, goes further. It tells defenders to “implement and test offline, immutable backups stored in a physically separate, segmented location.” CISA does not stop at immutable. It also asks for offline, separate and segmented.
The reason is scope. Immutability covers the stored object and nothing around it. It does not cover:
- The backup server and its console. Whoever holds them decides what is written, mounted and restored.
- The service accounts the backup software uses. These decide who can act on the store.
- Retention settings. A shorter retention period quietly shortens the protection window.
- Network access. A store that stays online is a store an attacker can reach.
- The cleanliness of data written before the attack began. An immutable store keeps a bad copy as faithfully as a good one.
Protect Backups From Ransomware: How Attackers and AI Reach Them
To protect backups from ransomware, start from the attacker’s route. Do not start from the vendor’s feature list. That route begins with identity. Sophos also points to multi-factor authentication gaps at VPNs and firewall consoles. The Gunra advisory tells defenders to require MFA on accounts that reach critical systems.
Kerberoasting shows how the next step works. Service accounts in Active Directory are tied to service principal names. Any signed-in domain user can request a service ticket for such an account and crack it offline. The target system raises no alert for the ticket request. Backup service accounts often hold broad rights, so they are prized. The Akira advisory names Kerberoasting as a way to steal credentials. It also notes that the encryptor uses PowerShell to delete Volume Shadow Copy Service copies.
Backup systems are a chosen target, not collateral damage. Mandiant’s M-Trends 2026 report, as covered by Help Net Security, says operators have shifted toward “systematically denying organizations the ability to recover, targeting identity services, virtualization management planes, and backup infrastructure.” In one case, attackers compromised backup management servers and took credentials from configuration databases. They then wiped millions of backup objects from cloud storage, along with dozens of local backups. The Gunra advisory records a similar pattern. Actors deleted backup data at both the primary data center and the disaster recovery center. A recovery site that trusts the same credentials is redundant. It is not isolated.
The same Mandiant coverage reports that the median time from first access to hand-off to a second group was over eight hours in 2022. By 2025 it was 22 seconds.
AI-driven tooling pushes the same way. Sysdig’s threat research team describes JADEPUFFER, published on 1 July 2026, as the first documented case of agentic ransomware. A large language model ran the full extortion operation from start to finish. Attackers got in through a flaw in Langflow. A Cloud Security Alliance research note on JadePuffer quotes Fenix24 CISO Heath Renfrow as saying that agentic threat actors “compress what previously took a skilled human operator hours to accomplish into minutes”.
AI does not invent a new path to backups. In the JADEPUFFER case it shortened the time between foothold and damage, so any defense that relies on a person noticing and reacting has less time to work.
Why Immutable Backup Solutions Alone Leave a Reachability Gap
Sophos reports that backup-based recovery was used in 66% of encrypted-data cases, up 12 percentage points from the previous year. When recovery depends on backups surviving, how attackers reach them becomes the central design question. These limits are not product defects. They apply to any immutable store that stays reachable:
- Control-plane compromise. The backup application holds the settings, retention policies and store definitions. An attacker who takes over the console can change retention, remove a store, or stop jobs. No stored object needs to change. Backup software needs patches too, as the Canadian Centre for Cyber Security advisory on Veeam shows for versions prior to 13.0.3 and 13.1.2.
- Poisoned restore points. Malware or tampered data written before detection is kept exactly as written. Immutability keeps the bad copy intact, which is a restore-side problem covered in the clean room guide linked above.
- A store that stays online. If the store is always mounted and reachable from the backup network, stolen credentials and a path to the storage are enough to abuse whatever the interface allows.
A design therefore needs immutability for the stored data and isolation for the path to it.
What an Isolated Recovery Environment Adds Beyond Immutability
What Is an Isolated Recovery Environment?
Google Cloud Threat Intelligence describes an isolated recovery environment as a secure enclave that stores immutable copies of backups. It shares no logins, tools or standing network links with production, and it admits data only after checks. From a reachability view, the parts that matter are:
- No trust relationship to production Active Directory, no shared accounts, and independent identity services.
- Phishing-resistant MFA for administration, no day-to-day access, and documented break-glass access.
- One-way replication from production, so nothing in the enclave can be pulled back toward production.
How to scan, verify and promote restored workloads is a separate topic, covered in our clean room recovery guide. The foundational NIST guidance on recovering from ransomware and other destructive events also stresses fast recovery together with checks that restored information is accurate.
How Isolation Levels Compare
Isolation is a spectrum. A stronger boundary leaves stolen credentials less to work with.
| Approach | What it blocks | What it leaves open | Recovery effort |
|---|---|---|---|
| Immutable only, store online | Alteration, overwrite and early deletion of stored objects | Console takeover, retention changes, store removal, bad restore points | Lowest, because the store is already attached |
| Logical isolation | Day-to-day access from production accounts and networks | A software path that still exists and can be reached with the right credentials | Low to moderate |
| Physical isolation with policy-controlled connectivity | Remote access to the copy outside approved job windows | Exposure only while a job or recovery event has the copy attached | Moderate, because an approved step brings the copy online |
Logical isolation cuts exposure and is a sound step. Physical disconnection is stronger. A path that is disconnected cannot be reached with stolen credentials.
A Reachability Checklist for Backup Design
Each item below maps to a failure mode described earlier, so the list works as an audit of an existing design.
- Separate identity domain for backup administration. Backup accounts should not trust production Active Directory or share accounts with it. This closes the Kerberoasting path to the backup console.
- MFA and role-based access control on the backup console. Use phishing-resistant MFA for administrators. Follow the CISA Gunra guidance and require MFA on accounts that reach critical systems.
- Attachment only during approved jobs. The isolated copy should be available only while a backup or restore job runs. It is detached afterwards, so exposure lasts only as long as a job.
- Immutable retention and deletion protection. Keep immutable retention inside the isolated copy. Add a storage-level safeguard against volume deletion that does not depend on backup application permissions.
- Inline anomaly checks before commit. Scan backup activity for ransomware signs as data is written, so suspicious data is flagged before it reaches the protected store.
- Restore testing. Test restores on a schedule using the workflow in the clean room guide linked above.
Apply the 3-2-1-1-0 rule by asking, for each copy, what an attacker holding stolen admin credentials could do to it. The on-site copy sits on the production network, so assume it is reachable. The off-site copy is reachable if it trusts the same identity or a cloud account the same administrators control. The offline or air-gapped copy is the one that counts, and it only counts if the connection is closed outside approved jobs. The immutable copy resists change but not a reachable control plane. Zero errors after recovery tests then confirms that the copy you could not reach is also one you can use.
How StoneFly Closes the Reachability Gap With Air-Gapped Vault®
The gap described above is a store that is immutable but still reachable. StoneFly addresses it with Air-Gapped Vault®, patented automatic air-gapped and immutable storage. Its Always On-Air® Gapping feature works at the job level. During an approved backup or restore operation, Veeam triggers StoneFly controls that make the needed Air-Gapped Vault® resources available. When the operation ends, the store, controller or node is detached and returned to its air-gapped and immutable state. Protected backup storage is therefore exposed only for the length of a job.
Air-Gapped Vault® supports physical or logical isolation and immutable storage with WORM retention. When a node is isolated, compromised backup or production credentials cannot reach it through the disconnected network.
Two StoneFly products put this into practice, depending on where an organization starts:
- StoneFly DR365VIVA adds Air-Gapped Vault® and immutable storage to an existing Veeam environment without replacing it. It is a physical appliance. Its network and power controls limit when the protected node is reachable. It is more than an immutable store that stays connected.
- StoneFly DR365V is a Veeam Ready air-gapped and immutable backup and disaster recovery solution with threat detection and response, plus volume-deletion protection beyond backup-application permissions.
Sites that want central monitoring and automatic incident workflows can look at the Veeam Ready backup and disaster recovery appliance with threat detection. StoneFly Smart Protect adds co-managed help with setup and recovery testing schedules.
Actual recovery time depends on workload, data volume and design. An appliance supports a compliance strategy. It does not guarantee compliance on its own.
Conclusion: Decide What Attackers Can Reach
Immutable backup solutions remain a necessary layer. But identity-first attackers and AI-driven tools reach the systems around the storage first, and they rarely test its retention lock. Isolation limits what they can reach, and a tested restore proves the copy is usable.
To protect backups from ransomware, ask three questions. Where does backup administration trust production identity? Which stores stay online? Which copy could an attacker with stolen admin credentials not touch? Then design around those answers.
For a second opinion on that design, contact StoneFly for an architecture review. For the storage layer, the guide to immutable file-level WORM setup and best practices is a useful next read, and the restore side is covered in our clean room recovery guide.