How Ransomware Attacks Neutralize Backups Before Encrypting Production Systems

When a ransomware group gets into an organization’s network, one of their most consistent priorities – after gaining a foothold and escalating privileges – is not to start targeting production data immediately. It’s to neutralize the backup infrastructure. To encrypt or destroy recovery copies prior to launching their main attack is the standard modus operandi of any competent ransomware actor, fundamentally changing the requirements of successful recovery from one such incident.

Understanding why they do it – and what you can do to mitigate the impact – is perhaps the most critical piece of information a business leader can possess when it comes to contemporary cyber risk.

The Last Line of Defence: Backups Under Attack

Recent statistics on backup targeting and attack success rates

When backups are gone, the economic situation changes quite a bit.

Sophos’s 2024 State of Ransomware report claims that attackers have attempted to compromise backup data in 94% of ransomware incidents, with 57% of such cases being successful. Even encryption alone is not a foolproof method – with 32% of incidents with encrypted data resulting in stolen information, as well.

In reality, an organisation which has its backups compromised has more than twice the chance of actually paying the ransom, and their recovery takes weeks – not days. Backup infrastructure has, in effect, become a highly proactive target, changing its role as nothing more than a passive safety net it had over many years.

The Evolution of Ransomware Tactics

Ransomware has changed dramatically since the early days of spray-and-pray encryption campaigns. Today’s attacks are structured, multi-stage operations run by organised criminal groups – and understanding how they have evolved is essential to understanding why backups have become their primary target.

Compared to initial spray-and-pray encryption efforts, ransomware has changed dramatically. Modern-day operations are complex, multi-stage, and operated by organised criminal enterprises.

Learning how this progression happened is key to understanding why backups have become a consistent high-priority target in the pre-detonation phase of modern ransomware operations.

The modern ransomware kill chain

Modern ransomware operations follow a specific, complex sequence of actions – one that differs significantly from the encryption campaigns of early ransomware:

1. Initial access – phishing, exposed credentials, or vulnerability exploitation
2. Privilege escalation – moving toward domain or backup admin rights
3. Disable logging – reducing the chance of detection and forensic recovery
4. Disable defenses – neutralizing endpoint protection and alerting
5. Disable backup application – stopping new recovery points from being created
6. Destroy or poison backups – eliminating or corrupting existing recovery points
7. Encrypt and/or exfiltrate – triggering the visible attack and establishing extortion leverage

Steps 3 through 6 commonly happen days or weeks before the victim is aware anything is wrong. By the time encryption begins – the attacker has often already ensured that recovery is severely limited.

From encryption‑only to double and triple extortion

Early ransomware was simplistic in its approach-it encrypted your files, then extorted you for a ransom to restore them. Modern operations are far more strategic.

With double extortion, the files are also copied by attackers prior to encryption, then published if a ransom is not paid. Triple extortion involves adding more pressure, perhaps through distributed denial-of-service attacks against the victim’s externally accessible services, or by contacting the victim’s customers and partners directly.

Backup destruction can easily fit into this rapidly escalating playbook. When backup restoration is no longer an option, the victim would be forced to either pay the ransom, or rebuild from scratch – which is extraordinarily expensive and takes weeks to complete (for companies that can afford it to begin with).

Cloud‑native extortion and targeting of snapshots and object storage

Widespread adoption of cloud services have certainly not improved backup safety, but it has opened additional attack vectors instead. Ransomware operators have been able to find and attack cloud snapshots, S3-compatible object storage and any management interfaces that can control them.

Just one compromised cloud administrator account could access an entire cloud account’s backup storage – an attack angle that doesn’t exist in the same way with traditional on-premises tape libraries (even if those have their own considerations in regards to physical access and management that will be discussed later).

Why Attackers Target Backups First

Eliminating the victim’s recovery option to force ransom payment

The business case is plain and simple here:

If you can recover your data – you don’t need to pay.

By deleting backups (which is typically done during the pre-attack reconnaissance phase) ransomware operators ensure that the victim’s only source of independence is eliminated. The same report from Sophos we mentioned earlier claims that in 2024, 56% of organisations whose data was encrypted paid the ransom to recover it (different article citing the same source) – yet the ransom itself was only the beginning of the financial damage.

Sophos found that the average cost of recovery, excluding the ransom payment, reached $2.73 million. There was also a different report from IBM (IBM Cost of a Data Breach report) stating that the average cost of a data breach is even higher – at $4.91 million across all sectors.

If there’s no guarantee for successful recovery – many businesses choose to pay simply because it is the least difficult option for them. This choice is particularly relevant to those bound by regulatory requirements, customer obligations, or patient welfare commitments.

Backups share the same control plane or credentials as production

The backup system is tied to the same Active Directory within most environments as production systems. It utilizes the same service accounts,and is managed via the same administrative console as production environments.

Compromising the domain admin account – a highly likely result after a phishing attack with lateral movement – gives an attacker the ability to access the backup infrastructure just as easily as any other part of the network. No isolation exists at the credential layer to allow a backup to be considered separate.

The level of separation that backups are supposed to offer is absent at the credential level.

Misconfigurations, credential compromise and weak identities

In addition to shared credentials, there are several common configurations of backup systems that lead to vulnerabilities. Among these are:

• an overprivileged API
• overly-privileged backup agents
• an internal-facing management interface lacking MFA
• lifecycle policies modifiable by any administrative account

These configuration issues are not particularly exotic, either. They are very common security review findings and the primary issues sought out by ransomware operators during their dwell time.

Case examples: HellCat, Akira, BlackCat/ALPHV and other incidents

The Akira ransomware group has made Veeam backup servers a signature target. A successful attack in June 2024 on a Latin American airline used CVE-2023-27532. This is a critical vulnerability on Veeam Backup & Replication that allowed the actors to retrieve the plaintext login credentials from the configuration database. The actors then created their own administrator user, exfiltrated critical data and deployed the ransomware payload.

In this particular instance, the patch for the vulnerability was released over a year prior and the server simply had not been patched in time.

BlackCat/ALPHV also ensures victims can’t recover their data by another equally systematic process. As part of the encryptor installation, it automatically deletes all Volume Shadow Copies using Windows-native utilities such as vssadmin and wmic; no matter how up to date they may be, victims won’t have any Windows backups to fall back on.

It’s also deployed with a tool that targets credential storage locations specific to Veeam backup data to steal those credentials too – creating a one-stop backup-wiping and data-stealing process.

HellCat, active since mid-2024, has built an entire playbook around a single insight – stolen credentials from Jira that are readily available on criminal forums and are rarely updated.

This is the approach the group used when targeting Schneider Electric, Telefónica, Orange Group, and Jaguar Land Rover in quick succession. In the JLR breach, the credentials that were stolen had been lying around for several years and still worked. Once inside a Jira system, the group begins to exfiltrate project data, source code and internal documentation before issuing demands for ransom, with the threat of public disclosure to back them up.

All these groups have two things in common – patience and planning. None of these were a random attack, all required prior reconnaissance and used a particular known vulnerability to their advantage. Most of them followed a particular step-by-step procedure designed to prevent recovery before the victim was even aware that they were compromised.

Attack Vectors Against Backup Infrastructure

Credential theft and privilege escalation

Phishing, credential stuffing and the vulnerability exploits all grant account access that an attacker can leverage to climb the permission escalation chain, up to that of a backup admin.

Once a threat actor has the Domain Admin or Backup Admin credentials – they can modify, destroy, or encrypt backup data using standard management tools and have the system think that it was an act of regular administration, complicating the detection process.

Abusing backup software APIs and admin tools

Contemporary backup solutions often provide extensive APIs to automate management. Such APIs present a valid operational benefit but are also a lucrative target to hackers.

Compromise of API keys or session tokens allows an attacker to call delete operations, disable backup jobs or export data without ever needing to connect directly to any production resources. Such actions can easily slip below the radar of security controls that are often hyper-focused on endpoint and network traffic.

Modifying lifecycle policies and wiping immutable copies

The object-lock and immutability settings guard your backups against deletion, but only if the settings themselves are beyond the reach of compromised accounts.

Accounts that break into cloud storage management consoles may be able to reduce the retention period, remove object-lock or alter storage class configurations in ways that destroy your data before the attack begins in the first place. Time-delayed policy modifications are especially dangerous, as they may only be revealed once a recovery process is attempted under crisis conditions.

Exfiltrating data via compromised backup agents

The original purpose of the backup agent is to access the entire data content of an organization. A compromised backup agent is also a convenient exfiltration tool. The backup infrastructure is ideal for attackers to conduct data theft from, since backup traffic is not generally subject to DLP controls and generates high volumes of data movement that is easily hidden amongst normal traffic.

Backup poisoning and delayed detonation

Not all backup attacks are immediately obvious and upfront. There are at least two increasingly common techniques that exploit the gap between when an attacker gains access and when encryption as a process is initiated: backup poisoning and delayed detonation.

Backup poisoning involves an attacker quietly corrupting or infecting backup data as time goes on – making sure that restore points are already infected with malware or damaged before the main attack begins. In these cases, the backups are already compromised by the time the victim attempts recovery.

Delayed detonation takes the above-mentioned concept further: attackers wait out the organization’s entire backup retention window before triggering an encryption sequence. Once all recovery points of the retention period are infected or corrupt – the victim has no clean data to restore from.

Both techniques make automated restore validation – referred to as healthy restore detection in some cases – a practically mandatory measure, since periodic verification of backup integrity is a lot more likely to catch corruption before the retention window is fully exhausted.

Consequences of Compromised Backups

Forced ransom payments and rising financial losses

With no backups, the economics shift completely. The ransom demanded normally equates to just over one-third of the overall cost impact of an attack, the rest of which is made up of:

• costs of incident response
• forensic analysis
• legal costs
• regulatory penalties
• lost business costs from the duration of the attack-induced outage

Companies with good, usable backups do not pay the ransom on most occasions. Those without usable backups, on the other hand, have to pay exorbitant rates purely because they have no other option.

Extended downtime, lost data and operational disruption

Even if an organization chooses not to pay – the backup failure means that the outage will be lengthy. Data re-entry by hand, reconstructing configurations, and other similar tasks take anywhere from a couple of weeks to several months. Hospitals, utilities and financial service organizations will experience far greater losses than mere money in that time period.

Legal, compliance and reputational implications

Regulators such as the GDPR, HIPAA and individual industry-specific regulations mandate the ability to recover personal data, as well as proving adequate security measures are being utilized. A single attack resulting in the destruction of production data as well as production data backups can trigger regulatory inquiries, forced data breach notifications, and civil litigation beyond the immediate business disaster.

Designing a Resilient Backup Strategy

Adopt a 3‑2‑1‑1‑0 approach: hot, warm and cold copies

The original 3-2-1 rule – as in, three copies of data being stored on two different media types and with one copy being stored offsite – has been extended over time, turning it into 3-2-1-1-0.

The 3-2-1-1-0 rule’s creation was made with ransomware in mind, with the new “1” being referred to as an offline or air-gapped copy, while “0” is the absence of errors in verified recovery tests.

As for the differences between hot, warm, and cold data copies – those represent the speed with which a copy can be turned into actual working data in production:

• Hot copies support rapid recovery and are the fastest to reach
• Warm copies provide a secondary option to consider when the original (hot) one is unavailable or compromised
• Cold (offline) copies are unreachable over the network and considered the last line of defense

Isolate backups with air‑gaps and dedicated control planes

A network-reachable backup is a vulnerable backup. Air-gapped copies – whether it’s tape in a shipping truck or data in logically-isolated cloud storage where there is no network path from production – will be able to endure attacks that wipe out everything else in the system. Equally as crucial is to separate a control plane; under no circumstances should backup administrators use the same login/console as production administrators.

WORM tapes and physical immutability

Immutability describes a policy in which data, once written, can neither be altered nor erased with usual methods for a specified retention period, even if an administrator attempts to do so. There are two primary approaches to immutability as a topic: WORM (Write Once, Read Many) tape and cloud object storage.

WORM (Write Once, Read Many) tape offers physical immutability – once written, the data cannot be altered or erased for the duration of the retention period. Tape’s offline nature also means it is unreachable over the network, making it resilient against attacks that operate entirely within the digital environment.

Unfortunately, physical immutability is not unconditional by its nature. Tape management software and robotic library controllers are both possible software attack surfaces that must be kept up-to-date and access-controlled. Physical access to storage facilities, transit custody, and the integrity of the management application all have to be accounted for as part of a comprehensive tape security posture.

Cloud object storage and logical immutability

Cloud object storage implementing S3 Object Lock (or an equivalent feature for other Object Storage technologies) with compliance mode provides logical immutability. This makes the backup data highly resistant to modification or deletion, even by privileged accounts, for the duration of the lock period. It’s important to note here that immutability can still be undermined by certain actions: account deletion, KMS key destruction, or backup poisoning prior to the lock period. As such, isolation and access controls across the full backup environment remain essential.

For cloud environments, immutability is most effective when backup data is stored in a dedicated account or tenant separate from production, managed by identities that have no overlap with production IAM roles. Even logging as a process should be made immutable – as in, written to an append-only destination. Cross-account replication adds a further layer of protection against single points of failure.

Immutability policies in both cases need to be configured correctly from the beginning, since it would be too late to set them up once a breach happens.

Encrypt data at rest and in transit

Encrypting backup data at rest reduces the value of stolen backup media – volumes that are exfiltrated but unreadable offer attackers less leverage for extortion. However, encryption doesn’t prevent exfiltration of production data, and a compromised backup application with restore capabilities may still expose its data in plaintext by virtue of having access to the decryption process itself. Backup encryption keys should not be stored in places reachable by the same accounts that access the backups, making separate management mandatory for those.

Enforce multi‑factor authentication and least‑privilege access

Multi-Factor Authentication (MFA) for all backup administrator accounts is the single highest-leverage control available. It breaks the most common attack path – credential compromise leading to backup deletion – regardless of how the credentials were obtained. Least-privilege access means backup agents run with only the rights they need, and administrative functions require separate, highly-protected accounts.

Verify backup integrity and conduct regular recovery tests

An untested backup is not a backup – it’s nothing more than a guess, an assumption. Only periodic restore tests with complete full system restore drills can verify that backups are undamaged, complete and restorable within acceptable time limits. So many organizations only find that their backups are corrupted, fragmented or rely on obsolete hardware that they no longer have when those backups are needed the most.

Monitor backup telemetry for anomalies and lateral movement

Security breaches can also manifest as:

• irregular backup job failures
• modifications in retention settings
• deleted files
• unusually large amounts of data being read from backup storage at unauthorized times

The backup telemetry must be routed to SIEM systems, which are configured with alerting policies that detect these types of events.

Develop and rehearse ransomware‑specific incident response plans

One generic incident response plan is no longer enough. Ransomware-specific plans should be set in stone prior to an attack, defining several key factors beforehand:

• Which decision makers will be authorized to isolate backup systems from an active incident?
• What will be the priority sequence for recovery operations?
• How will clean backup copies be detected and authenticated?
• What will the communications strategy be for regulators, customers and employees?

Decisions like these should be planned and accounted for beforehand, and not at 2 A.M. in the middle of a security breach.

Essential Capabilities for Secure Backup Solutions

Role‑based access control and multi‑person authorisation workflows

A robust enterprise backup solution will allow for fine-grained role-based access controls where operators, administrators and auditors only have access to what their respective roles permit. Two-party authorization, which involves two different accounts needing to authorize an action of high risk (such as deleting a backup repository), is vital to protect against insider threats and compromised credentials.

Comprehensive audit logging, reporting and SIEM integration

All activities affecting the backup infrastructure must be logged with a degree of detail that supports forensic analysis. Logs should be tamper-proof – preferably written to an append-only system and consumed by the organisation’s SIEM on a real-time basis, if only to ensure that anomalies trigger an alert instead of a post-mortem report.

Cross‑platform support and rapid, granular recovery options

The solution must also cater for the full breadth of your environment (physical servers, VMs, containers, databases, SaaS) and offer fine-grain recoverability (individual files, records within databases, individual objects in applications) in addition to total system recoverability. Rapid recovery of individual data elements can make the difference between a manageable incident and a drawn-out catastrophe.

Integration with threat intelligence and anomaly detection tools

When evaluating backup solutions, aim for native integration with threat intelligence feeds and anomaly detection engines if possible. The ability to identify suspicious trends in backup activity feeds – unexpected job failures, unusual data volumes, or unauthorized access attempts – is a particularly useful feature that may act as a differentiator between purpose-built enterprise backup platforms and basic solutions in the field.

How Bacula Enterprise Prevents Backup‑Focused Ransomware Attacks

The defensive measures mentioned above are only effective when implemented within a secure and robust platform. Bacula Enterprise is developed with backup-targeted ransomware as an explicit threat model; each of the principles above can be converted into verifiable and auditable functionality.

Immutable backups and air‑gapped storage configurations

Bacula Enterprise can utilize immutable backup targets such as WORM tape libraries, S3-compatible object storage with Object Lock, and air-gapped configurations with physical or logical isolation. That way, the critical backup copies are significantly harder to reach or tamper with, even in a heavily compromised production environment – provided account separation, key management and access controls are all maintained as part of a broader defensive effort.

Volume‑level and end‑to‑end encryption options

Bacula Enterprise allows encryption of backup volumes at rest and supports encrypted transport for data in transit (which is enabled by default). Backup volumes are not stored with keys; in the case of backup volume exfiltration, exfiltrated volumes will be unreadable without keys, drastically limiting attackers’ ability to pursue double extortion.

Anomaly detection, verify jobs and hash‑based malware scanning

Bacula Enterprise features verify jobs, which carry out a hash-based integrity check on the backup data, ensuring that the data corresponds to the source and has not been surreptitiously compromised. Its capabilities for anomaly detection indicate when unexpected behavior occurs – such as job failures, unauthorized account access, unexpected changes in the size or times of a given backup routine, or the transfer of abnormal data amounts.

Flexible access control, MFA and incident‑response workflows

Bacula Enterprise’s granular access control system provides role-based privileges and supports MFA for admin access. It will include multi-user approval for highly sensitive actions very soon. Incident-response workflows enable security staff to sequester the backup environment, maintain forensic data, and execute recovery through secure, auditable processes – even during active threat conditions.

Case studies demonstrating Bacula’s resilience under attack

Bacula Enterprise clients within the health services, financial and critical infrastructure sectors have already proven that these protections actually work in practice.

As evidenced by the recovery examples within published case studies, Bacula Enterprise has successfully been able to restore organizations from a ransomware attack in hours as opposed to weeks. This has been possible using a validated, immutable backup copy which was out of reach of the attackers and thus undamaged, no ransom had to be paid and disaster recovery and compliance requirements met without loss of data.

Conclusion

Ransomware attacks start by taking out backups because that is usually one of the most efficient ways for attackers to force businesses to pay ransom. The good news is that this is a well-known and well-understood attack and there are plenty of known defenses against it.

Combining immutable storage, air-gapped backups, strong identity controls, regular testing and purpose-built backup security capabilities significantly reduces the attack surface across the most common vectors ransomware operators tend to exploit. No single control or combination of controls eliminates risk entirely – defense-in-depth is about making attacks harder to complete and easier to recover from, not about achieving absolute protection.

Any organisation that takes backup security as seriously as endpoint or perimeter security will be on inherently stronger ground – not because an attack becomes impossible, but because recovery remains possible.

FAQ

How do attackers even discover where backups are stored?

During the dwell period after initial compromise – which for sophisticated ransomware operations can range from days to several weeks before the payload is deployed – attackers conduct systematic reconnaissance. They query Active Directory to find service accounts associated with backup software, scan internal IP ranges to determine open backup server ports, read configuration files and scripts located on the compromised system, and scan file shares for backup-related documentation. Discovery of backup systems can take minutes for an attacker having a foothold within the internal network.

Are cloud backups really safer than on-prem backups against ransomware?

Neither on-premises nor cloud backups are any more or less secure. It all depends on how the backups are set up. Cloud storage that has Object Lock enabled – where you access the storage using only separate MFA-protected dedicated accounts – can be highly resilient by itself. Cloud storage that uses the same accounts as production (with no Object Lock) will be compromised faster than physical tape. Architecture and control have far more importance than location in these situations.

Can ransomware still encrypt data if backups are immutable?

The nature of immutable backup means that ransomware cannot easily encrypt or delete them when configured properly – that is the whole point of immutability. Production data, however, is still vulnerable and can be encrypted by ransomware. The immutable backup by itself will survive the attack, but it will not stop an attack from happening to live systems. Immutability must be a part of the defense-in-depth approach, along with endpoint protection, network segmentation, and speedy detection/response capabilities.