Most ransomware operators don’t bother trying to break into a backup system. They go after whoever already has the keys.
That’s not a new problem. In the 1870s, bank robbers found the same shortcut. You didn’t necessarily have to defeat a vault. You needed the person who knew how to open it.
The answer was the time lock, a mechanism that could prevent the vault from opening during a defined period, even when someone had the correct combination. The interesting part wasn’t that the vault had become harder to break. The rule had moved below the person operating the lock, out of reach of anyone standing in front of it with a gun, a grudge, or a convincing story.
Modern backup infrastructure has the same weak point, and the rest of this piece follows it the way an attacker would. Let’s assume the attacker already won the first step, a phished credential, a leaked token, whatever got them in. The interesting part isn’t how they got in. It’s how far that one credential can travel from there.
That credential doesn’t stop at production. In most environments, whatever identity provider governs production also governs the backup console, and the console rarely gets the same monitoring attention EDR and SIEM tooling give production systems. It’s usually the quietest part of the environment to move through. Once there, the real test starts, can that credential actually delete anything.
The First Door: Can the Attacker Delete the Backup?
This is the point where a lot of ransomware operations actually stall, and it’s worth being precise about why. An attacker with valid backup administrator credentials can authenticate to the console without tripping anything, because nothing about the login looks wrong. They can see the repository. They can issue a deletion request through the same interface a legitimate administrator would use. Storage rejects it anyway, not because the request looked suspicious, but because it fell outside the retention window, and the retention window doesn’t care who’s asking.
That’s what immutability is supposed to do. Done right, it means the storage layer itself won’t let a write be changed or deleted before a set retention period ends, regardless of how valid the requesting credentials look. Most of what gets marketed as immutable backup protection is actually a setting inside the backup application, a toggle a sufficiently privileged attacker can flip back. WORM, write once read many, predates all of this by decades. The idea is simple: once something’s written, nothing can touch it again until its retention period runs out. Older systems enforced that with literal write-once media. Most platforms today do it in software, through retention metadata the storage layer checks before honoring any delete or overwrite request.
The credential is real. The request is legitimate. Storage still says no. So the attacker looks for another way in, one that doesn’t involve deleting anything at all.
The Backup Is Immutable. So Why Can the Attacker Still Reach It?
Air-gapping controls reachability, immutability controls mutability, and ransomware attacks both. Offline tape is genuinely disconnected, but if someone can reconnect it, authenticate with a privileged account, and rewrite the data before the next cycle, the air gap never provided the protection it looked like it provided. Object storage with Object Lock enabled is the opposite case, immutable but still reachable over the network, it just can’t be altered once written.
Any air-gap diagram that doesn’t show who’s allowed to reconnect the copy is missing the part that actually matters.
Now the attacker has hit a second wall. The copy isn’t just immutable, the network path to it is gone. But offline creates a problem that rarely shows up on architecture diagrams: someone still has to bring it back eventually, and that someone answers to an authority worth naming.
Who Controls the People Who Control the Backup?
Most attention in backup security goes to the repository. That’s the wrong place to look. Above it sits a management server that can start and stop jobs, change retention, and initiate deletion, and if the same identity controls that console, the repository underneath may be technically immutable while the recovery architecture around it stays wide open.
The mistake I keep seeing is teams separating the repository but leaving the authority attached to production. A domain admin account, a backup admin group, and a storage admin account can be three logins that all trace back to one identity provider. Three credentials don’t automatically create three authorities. There has to be an emergency path too, tightly controlled and rarely used, never a permanent super-admin shortcut.
Now imagine the attacker has gone one step further and stolen the backup administrator’s credentials specifically. They authenticate. They see the repository. They request deletion. The workflow stops and asks for a second, independently authenticated administrator before anything actually happens.
The stolen credential is valid. It just isn’t sufficient. On paper, the architecture already looks secure. There’s only one problem left, whether the copy actually works.
The Repository Is Healthy. The Application Is Still Down.
This is where backup dashboards get dangerously reassuring. The repository is healthy. The backup completed. Checksums match. Replication succeeded. Then someone tries to actually start the application. DNS doesn’t resolve. A database log is missing. A certificate has expired. A secret isn’t available. The backup was healthy. The recovery wasn’t.
A backup answers do we have the bytes. A restore test answers can we turn those bytes back into a working service. Most teams stop at the first question and call it done. That’s really what the “0” in 3-2-1-1-0 is supposed to fix. It’s not asking for a green dashboard, it’s asking for proof that something actually came back. The only way to get that proof at any real scale is to automate it, spin the backup up somewhere isolated on a schedule and check whether the application itself starts, not just whether the job finished. Manual checks might cover the handful of systems you really care about. They won’t cover everything ransomware is willing to touch.
That’s the shift that matters here. A protected file is still just a file, sitting wherever it was written, waiting to be pulled if anyone ever needs it. A recovery system is different, it’s the whole path behind that file: who can reach it, what they’re allowed to do once they do, and whether pulling it actually gets you a working application instead of a pile of intact data. Everything from here is really about naming that path.
The Recovery Boundary
I think of it as the recovery boundary: the point where a compromised production identity stops being able to control the recovery copy. Here’s what that boundary actually looks like once you trace it end to end:
· A phished credential reaches production, then the backup console, same as it would in any environment without one.
· From there it hits the wall: immutable storage, governed by an authority separate from whatever just got compromised.
· Past that sits the offline or air-gapped copy, reachable only through its own reconnection process, under its own authority.
· The last step is a restore test, proving the copy isn’t just present but usable.
We didn’t stop the attacker at production. We made every credential they picked up along the way insufficient for the next step.
What the Recovery Boundary Costs
None of this is free, and it’s worth saying plainly rather than glossing over it. Air-gapped and offline copies take longer to bring back online than a live target, and a vault that only opens on a scheduled window won’t meet a recovery time objective measured in minutes. Retention windows carry a real cost too, data sits in place for the length of the lock even if storage needs or vendors change later, which shows up as a line item, not just a security decision. The less obvious cost is operational: every independent authority, every approval step, every offline copy is one more thing someone has to manage, document, and actually rehearse, and the administrators living with that extra friction day to day are usually the first to push back on it. A perfectly isolated vault nobody knows how to retrieve from isn’t resilience. It’s an inaccessible copy, and an unrehearsed one is arguably worse than having no plan at all, because it creates confidence nobody’s tested.
The Vault Doesn’t Care Who’s Asking
The attacker started with one credential. The question the rest of this piece has been chasing is how far that credential could travel. It reached production. It reached the backup console. From there it should have run out of road, unable to alter an immutable recovery point, unable to reach the offline copy, unable to authorize its own reconnection. Even after all of that held, the organization still had to prove the copy could become a working service again, because a boundary that stops deletion but not recoverability has only solved half the problem.
That’s really the test worth applying to any backup architecture, immutable label or not: not whether it survived an audit, but whether a stolen credential runs out of authority before it runs out of targets. Most environments fail this quietly, not because the technology is missing, S3 Object Lock and Azure’s immutable storage aren’t rare or expensive, but because the identity separation around them never gets built with the same care. The storage gets hardened. The people and systems still allowed to touch it don’t.
It’s the same rule the old vault makers eventually landed on: a boundary is only real if it doesn’t care who’s asking. Worth going and checking which identity in your own environment is still allowed to reach every layer at once. If there’s an answer, that’s where the next incident starts. If there isn’t, you’ve built something closer to a recovery boundary than most organizations ever get to.
Click Here For The Original Source.
