Why Ransomware Finds Your Backups First

Organisations often discover during an incident that their backups are gone, encrypted or incomplete, and treat it as bad luck. It usually isn't. A working backup is the single biggest reason a victim declines to pay, so finding and destroying backups is an early, deliberate step in most serious ransomware attacks rather than a side effect of one.

Attackers who have gained administrative access look for the same things every time: backup software consoles, mapped drives and network shares holding backup files, NAS devices reachable from the network, and cloud storage whose credentials are saved on the server. Backup software itself is a useful map, since its job is to know where every copy lives.

Shadow copies and built-in snapshots are usually deleted first, because they are quick to remove and would otherwise allow a fast local rollback. By the time files start being encrypted, the recovery options have often already been narrowed deliberately.

The most common structural weakness is that the account which manages backups is a domain administrator, or shares a password with one. Once that account is compromised, the backups are reachable by definition. A backup system that authenticates separately, with credentials that are not used anywhere else, is a meaningfully harder target than one protected only by network position.

An immutable backup is one that cannot be modified or deleted for a defined retention period, even by an administrator. That last part is what matters: the point is not to stop a careless user, it is to stop an attacker holding full admin rights. Many backup platforms and object-storage services offer this, sometimes under names like object lock or hardened repository. Where it is available, it is the single most effective control against this attack pattern.

A copy replicated to another site is protected against fire and flood, but if it is reachable over the network with the same credentials, it is not protected against ransomware. A copy that is genuinely offline, or immutable, or held in an account the production environment cannot authenticate to, is what survives. It is worth asking of each copy you hold: what would reach this if an attacker had domain administrator rights right now?

Attackers frequently sit in an environment for weeks before encrypting anything, and some quietly corrupt or alter data during that period. A backup set that only retains a few days can therefore contain the damage. Retention that spans well beyond typical dwell time gives you a point to recover from that predates the intrusion, not just the encryption.

A backup job reporting success means data was written. It does not establish that the data can be restored into a working system, in an acceptable time, by someone other than the person who built it. The only way to know is to restore something real and time it. This is the step most often skipped and most often regretted.

It is not automatically a total loss. Backup files are large, and large files are frequently only partially encrypted because fully encrypting them takes time attackers do not always spend. Do not delete encrypted backup files, and do not reformat the repository. What remains readable inside them is established by looking at the files directly, and we say what is realistic after an assessment rather than before it.