Ransomware-Resistant Backup | Protecting Recovery Capability

Ransomware operators learned years ago that encrypting production systems is not enough. An organisation with working backups restores, refuses to pay, and treats the incident as an outage rather than an extortion.

So the backups go first.

By the time encryption begins, a competent attacker has usually spent weeks inside the environment. In that period they locate the backup infrastructure, obtain credentials for it, delete or corrupt the repositories, alter retention settings so older copies expire, and only then trigger the encryption. The organisation discovers its recovery capability is gone at the exact moment it needs it.

This changes what backup design has to achieve. Protecting data against hardware failure and accidental deletion is solved. Protecting recovery capability against an adversary who has administrative access to the environment is a different problem, and most backup architectures were never designed for it.

How the attack unfolds

Understanding the sequence explains why particular controls matter.

Initial access arrives through phishing, an exposed remote access service, or a compromised third party. Nothing about this stage is specific to backup.

Privilege escalation and reconnaissance follow, often over weeks. The attacker maps the environment, and backup infrastructure is a priority target precisely because it determines whether the extortion will work.

Credential harvesting targets backup service accounts specifically. These accounts are frequently over-privileged, rarely rotated, sometimes shared, and often members of domain administrator groups because it was easier to configure that way.

Backup destruction comes next. Repositories are deleted, retention policies shortened so historical copies expire on schedule, and in some cases the backup software itself is used to overwrite good copies with encrypted ones. Cloud backup targets are deleted through the same credentials that write to them.

Exfiltration typically precedes encryption, giving the attacker leverage even against an organisation that recovers successfully.

Encryption is the final step and the first one the organisation notices.

The design question is therefore simple to state. At the point where the attacker holds administrative credentials across the environment, what remains that they cannot destroy?

The controls that answer it

Immutability. Backup copies written in a form that cannot be modified or deleted for a defined period survive administrative access, because the restriction is enforced by the storage layer rather than by permissions. This is the single most valuable control available, and the retention period should exceed the realistic dwell time of an intrusion. A seven-day immutability window protects nothing against an attacker who has been present for six weeks.

Isolation. At least one copy should sit where the production environment cannot reach it. Physical air gap, a logically isolated network with no routed path from production, or an immutable cloud target under separate credentials all achieve this differently. The test is whether an attacker holding every production credential can reach the copy. If yes, it is not isolated.

Credential separation. Backup infrastructure should authenticate independently of the production directory. When backup service accounts are domain members, compromise of the domain is compromise of the backup. Separate authentication, separate privilege model, separate multi-factor requirement.

Backup infrastructure hardening. The backup servers are production systems in their own right and are frequently treated as appliances that need no attention. They need patching, access control, monitoring, and inclusion in the vulnerability management programme like anything else.

Monitoring the backup environment. Mass deletion, retention policy changes, unusual authentication to backup systems, and job failures across multiple repositories are high-fidelity indicators. Very few organisations alert on them, which means backup destruction happens silently.

Detection of anomalous change rates. A sudden spike in changed data across the estate can indicate encryption in progress. Backup telemetry sees this earlier than most detection tooling, because the backup system measures exactly that.

Restore capability is the part nobody tests

Backup success rates measure whether data was written. They say nothing about whether the organisation can restore a functioning environment under pressure.

Recovery testing should establish more than file retrieval. Can a full system be restored, and how long does it take. Do applications start in the correct dependency order after restoration. Are the credentials needed to perform a recovery available if the directory itself is unavailable. Does the recovery runbook exist in a form that survives the incident, or does it live on a file share inside the environment being restored.

That last question catches organisations regularly. A recovery plan stored only on the encrypted network is a recovery plan the team cannot read.

Restore speed also deserves honest measurement. An organisation that can restore two terabytes an hour and holds four hundred terabytes of critical data is looking at a week of restoration, whatever its recovery time objective states on paper. That arithmetic should be done before an incident, not during one.

Where this connects to regulatory obligation

Saudi cybersecurity control frameworks include backup management among their core defence measures, and organisations under these frameworks must evidence that the control operates rather than assert it exists.

The evidence set includes documented backup scope and frequency, retention configuration, restore test records with results and remediation, and demonstration that recovery objectives were validated rather than assumed. Organisations that run reliable backups and cannot produce restore test records are treated as having a gap, because from an assessor's position an untested backup and a broken backup are indistinguishable.

Frequently asked questions

Does cloud backup provide inherent protection? Not automatically. Cloud storage reachable with credentials held in the production environment can be deleted by an attacker holding those credentials. Immutability settings, separate authentication, and delete protection are what provide the resilience, not the cloud location itself.

How long should the immutability period be? Longer than the time an intrusion could plausibly remain undetected in the environment. Periods measured in days offer limited protection given that dwell times are commonly measured in weeks.

Is a physical air gap still necessary? It is one way of achieving isolation and remains highly effective. Immutable storage under separate credentials achieves a comparable outcome with better recovery speed, which is why most organisations now combine approaches rather than choosing one.

What is the most common gap? Backup service accounts holding domain administrator privilege. It makes deployment simpler and hands the attacker the entire recovery capability along with the environment.

How ITBuilders supports backup and recovery

ITBuilders designs and operates backup and recovery infrastructure for enterprise environments, covering immutability, isolation, credential separation, and structured restore testing. Because the same team builds the underlying data centre and cloud platforms, recovery design accounts for the dependency order and restore throughput the environment can actually deliver.

To discuss backup resilience, contact ITBuilders at 920-020-750 or itbuilders.com.sa