Why backups fail during ransomware attacks and how to prepare for recovery

Backups are often described as one of the strongest defences against ransomware. That is true, but it can create a dangerous assumption: if the backup job completed successfully last night, the organisation can recover.

A successful backup is not the same as a proven recovery capability.

During a ransomware attack, threat actors may deliberately target backup infrastructure, compromise administrative accounts, alter retention settings or destroy backup data before attacking production systems. The UK’s National Cyber Security Centre (NCSC) specifically warns that attackers often target backups and supporting infrastructure early in destructive ransomware attacks because damaging them makes recovery harder and increases pressure on the victim.

There is another problem. Even where backup files survive, organisations can discover during incident response that restoring them is considerably more complex than expected. Recovery depends on much more than having copies of data. You need usable infrastructure, trustworthy credentials, known-good recovery points and a tested order in which critical systems can be brought back into service.

That distinction between having backups and being able to recover is where ransomware preparation needs to start.

If you are reading this because your organisation has experienced a cyber incident and is unsure how to respond, contact Zensec immediately.

Why ransomware attacks target backups

Modern ransomware is not necessarily an isolated piece of malicious software that encrypts files on one compromised machine. An attacker may gain access, escalate privileges, move through connected systems and steal sensitive data before encryption or other disruptive activity becomes visible.

Guidance from the US Cybersecurity and Infrastructure Security Agency (CISA) also recognises data theft and encryption as related threats. Its StopRansomware guidance describes “double extortion”, where malicious actors both exfiltrate information and disrupt access to systems, using the stolen data as additional leverage.

That changes the role of backups.

If threat actors can gain access to the backup console using compromised credentials, the backup environment can itself become a target. An attacker does not necessarily have to encrypt every backup file. Depending on their level of access and the architecture involved, destructive actions against backup systems, retention or associated infrastructure may be enough to undermine the recovery process.

The NCSC therefore recommends isolating backup solutions as far as reasonably practical, segregating management interfaces and using administrative accounts and credentials separate from those used to manage the wider network.

In other words, backup infrastructure needs its own security boundary. Treating it as simply another part of the production environment can create a common route from compromised production credentials to the systems intended to recover production.

The reasons apparently good backups fail

There is rarely one single explanation. Ransomware recovery tends to expose weaknesses across technology, identity, configuration and planning.

The backups are accessible from the production environment

A flat network architecture can make administration convenient, but it can also create access paths between systems that should have different levels of trust.

If production systems and backup storage are too closely connected, an attacker who compromises an administrative account may be able to reach both. Network segregation, restricted management interfaces and least-privilege access help reduce this risk. The NCSC also identifies physically disconnected backup media as one way of making backups harder for an attacker to reach.

Production and backup systems share credentials

The same principle applies to identity. Using production credentials or administrative accounts to manage backups means compromising one environment can provide an access path into another.

Multi-factor authentication is important, but it should sit alongside separate administrative identities, appropriate access control and tightly controlled privileged accounts.

The backup contains the problem

Backup does not establish that the data being copied is clean. If malicious activity began well before the ransomware became visible, recent backups could contain compromised configurations, malicious software or other unwanted changes. Restoring the most recent backup without understanding the incident can therefore introduce risk into the recovery environment.

The NCSC recommends that organisations retain the ability to restore an earlier version if later backups become corrupted. That is one reason the retention period matters. Recovery teams may need to go far enough back to establish a trustworthy recovery point, not merely the newest available copy.

The backups have never been restored at realistic scale

“Backup successful” confirms a process ran. It does not prove that critical data and applications can be restored within the time the business expects.

NIST recommends developing response and recovery procedures around backup systems, conducting exercises and testing both individual systems and, where possible, the wider operation. It also distinguishes the recovery time objective, how quickly services need to return, from the recovery point objective, essentially how much data loss the organisation can tolerate.

A recovery test therefore needs to answer practical questions:

• Can we restore data and verify its integrity?
• Can we rebuild the systems and dependencies needed to use it?
• Are the credentials and encryption keys needed for recovery available?
• How long does that process actually take?
• Could we perform it if our normal administrative environment were unavailable?

Those answers are much more meaningful than the number of successful backup jobs shown on a dashboard.

Immutable backups are important, but they are not the whole recovery strategy

Immutable backups have become an important part of ransomware protection because they are designed to prevent backup data being modified or deleted for a specified retention period.

That addresses an important risk, but immutability should not become shorthand for a complete ransomware recovery strategy.

Organisations still need to consider who can change backup policies, how administrative access is protected, whether attackers can interfere with the surrounding backup systems, how far back recovery points extend and whether data can actually be restored.

For on-premises systems, the NCSC’s principles include isolation and network segregation, resilience against destructive actions, the ability to recover earlier backup versions, robust key management and alerts for significant changes or privileged activity.

The practical lesson is that protecting backups requires several independent controls. Each should make it harder for the compromise of production systems to become a compromise of recovery capability.

Recovery is about systems, not just data

A file-level restore is very different from recovering business operations.

Consider a critical application. Its backup data may be intact, but the service could depend on operating systems, identity services, databases, DNS, network infrastructure, certificates, encryption keys and other connected systems. Restoring components in the wrong sequence can prevent the application working even when its underlying data has been recovered successfully.

That is why a recovery plan should identify critical systems and their dependencies.

For each priority service, organisations should know:

• what infrastructure the service requires;
• which backup data and configurations are necessary;
• an acceptable recovery point;
• the target recovery time;
• which system has to be restored first;
• where trusted installation media, credentials and keys are held; and
• how the restored environment will be checked before users reconnect.

This moves disaster recovery from “we can restore the files” towards “we know how to restore the business service”.

The recovery process should not simply recreate the compromised network

Once an incident has occurred, the objective is not to restore everything as quickly as possible regardless of risk. First, the organisation needs enough understanding of the incident to avoid restoring into an environment that remains under attacker control.

Affected systems may need to be isolated while incident response establishes how access was gained, which credentials were compromised, what systems were affected and whether there is evidence of data theft. Depending on the incident, passwords, administrative accounts and other credentials may need to be reset before important services return.

Recovery can then begin from trusted infrastructure and known-good backup data, with critical systems restored according to business priority. Validation matters here. Restored data needs to be checked for integrity and systems should be subject to appropriate security checks before returning to the production environment.

NIST stresses the importance of being able to trust the accuracy of recovered data following destructive events, not merely recovering something that resembles the original information.

This is also why the incident response plan and disaster recovery plan should work together. One determines what happened and how the threat is being contained. The other provides the route back to safe business operations.

What a ransomware-ready backup strategy looks like

There is no single backup solution that removes ransomware risk. A stronger approach combines different security measures so that an attacker has to defeat several independent controls.

For critical data and systems, organisations should consider:

• Isolation: Limit connections between production and the backup infrastructure. Restrict the locations from which the backup console and management interfaces can be accessed.
• Separate identities: Avoid relying on normal production administrative accounts for backup management. Protect privileged access with multi-factor authentication and appropriate access controls.
• Resilience to deletion and alteration: Use appropriate immutable backups, offline copies or other mechanisms that prevent an attacker from simply destroying every available recovery point.
• Useful retention: Keep recovery points for a period determined by operational, security and relevant legal requirements. If compromise remains undetected for some time, yesterday’s backup may not be the recovery point you need.
• Monitoring: Treat unexpected changes to backup configuration, retention policies and administrative permissions as security-relevant events, rather than routine IT activity. The NCSC recommends alerting when significant changes or privileged actions are attempted against on-premises backup systems.
• Recovery testing: Test whether backup data can actually be restored and whether critical systems can be brought back within the organisation’s recovery objectives.

These controls should form part of a wider security posture. Secure remote access, patching software vulnerabilities, restricting administrative privileges, endpoint security tools, network segmentation and strong authentication all reduce the opportunities an attacker has to reach the point where backups become the organisation’s last line of defence.

Test the recovery plan under ransomware conditions

A recovery exercise becomes much more valuable when normal assumptions are removed. Instead of asking the IT team to restore a deleted file, test a scenario in which several production systems are unavailable, some administrative credentials must be considered compromised and recent backups need investigation before they can be trusted.

Then work through the tested incident response plan and recovery plan.

Who can access the backup systems if normal admin accounts cannot be used? How will the organisation determine which recovery point is appropriate? Can identity and other foundational services be rebuilt securely? Which critical systems come back first? What must be checked before restored systems reconnect to the network?

Recording actual restore times during these exercises also exposes a common difference between recovery objectives and recovery reality. NIST’s backup guidance specifically recommends testing recovery planning and monitoring backup processes for failures and consistency.

Exercises should therefore test more than the storage media. They should test people, documentation, decision-making, dependencies and technical recovery as one process.

Recovery needs to be planned before the attack

When ransomware causes operational disruption, it is too late to discover that nobody knows the password for an isolated system, the retention period is too short or a critical application cannot be rebuilt without another unavailable service.

The preparation should happen while production systems are working normally.

That means maintaining a clear inventory of critical systems and data, establishing realistic recovery objectives, protecting the backup infrastructure separately from production and regularly proving that recovery works.

It should also form part of business continuity planning. Cyber insurance may provide valuable financial and specialist support depending on the policy, but it cannot substitute for a working technical recovery capability.

Ultimately, the most useful question for leadership is not “Do we have backups?”, it is “If threat actors compromised our production environment and tried to target our backups, could we still recover our critical systems safely, and have we proved it?”

An organisation that can answer that question with evidence from realistic recovery testing is in a significantly stronger position than one relying on a green status indicator in its backup console.

Building confidence in ransomware recovery

Ransomware resilience is not about guaranteeing that an attack will never succeed. It is about ensuring that one compromised machine, account or system does not have to become an organisation-wide crisis.

Backups remain a fundamental part of that defence, but their real value only becomes clear when they are protected, recoverable and connected to a practical recovery process.

For organisations reviewing their ransomware protection, the priority should therefore be to test the complete chain: protect the backups, understand system dependencies, validate data integrity, secure the recovery environment and rehearse bringing critical business services back online.

That is the difference between storing backup data and having a recovery capability you can rely on when it matters.

Useful Links

• National Cyber Security Centre (NCSC): Ransomware-resistant backups
• National Cyber Security Centre (NCSC): Principles for ransomware-resistant on-premises backups
• Cybersecurity and Infrastructure Security Agency (CISA): #StopRansomware Guide
• National Institute of Standards and Technology (NIST): Data Integrity: Recovering from Ransomware and Other Destructive Events
• NIST National Cybersecurity Center of Excellence: Protecting Your Data from Ransomware and Other Data Loss Events