The conventional defence against ransomware has been the backup. Encrypt the production systems and the organisation restores from a copy, refusing to pay. Attackers have adapted, and the adaptation is straightforward: find the backups first and destroy them.
Modern intrusion sequences therefore spend considerable time on discovery. Before deploying encryption, the operators map the network, locate backup infrastructure and identify the accounts with permission to delete or modify it. Only then do they act.
Why backup systems are exposed
Backup software holds privileged credentials, because it must read everything. Those credentials are frequently stored in configuration files, in scheduled tasks or in a management console that is reachable from the same network as the workstations.
Many deployments were designed for reliability rather than security. A backup server joined to the domain, using a service account with broad rights, is convenient to operate and easy to compromise once an attacker has any foothold.
Immutability and the air gap
Two controls address this directly. Immutable storage prevents modification or deletion for a defined retention period, enforced by the storage platform rather than by policy. Object lock features offered by major cloud providers implement this, and appliance vendors offer similar guarantees.
A genuine air gap removes network connectivity entirely, with data moved by removable media or a one way link. It is effective and operationally painful, and it is the reason many organisations prefer immutability combined with separate credentials.
Separating the credential path
If the backup system authenticates with the same directory as everything else, one compromised administrator account can erase it. Using a separate identity source, with credentials that do not exist in the production domain, breaks that path.
Multi factor authentication on the backup console is necessary and insufficient, because attackers increasingly target the authentication infrastructure itself. Hardware tokens and offline recovery credentials reduce the exposure, and they must be tested.
Detection and monitoring
Backup infrastructure generates distinctive signals: a sudden drop in protected data, a spike in deletion events, a change in schedule, an authentication from an unexpected location. These are detectable, and few organisations monitor them.
Guidance from CISA’s StopRansomware programme lists these indicators alongside recovery planning advice. The practical step is to forward backup logs to a system that is not under the control of the same administrators.
Testing restoration honestly
An untested backup is a hypothesis. Restoration tests should be scheduled, should involve the people who would actually perform the recovery, and should measure how long a full restore takes, not just whether a single file can be retrieved.
The uncomfortable finding from many exercises is that restoring everything is slower than the business can tolerate. That result is valuable, because it identifies what needs to change before an incident rather than during one.
Negotiation, insurance and the decision to pay
Organisations that suffer an attack face a decision that is partly technical and partly financial. Paying is discouraged by law enforcement agencies and does not guarantee recovery, and in some jurisdictions payments to sanctioned groups are illegal.
Insurance has complicated the picture. Policies may cover restoration and negotiation support, and insurers increasingly require evidence that basic controls were in place before a claim is considered. An organisation that skipped multi factor authentication may find its cover reduced.
The pressure of an outage is what makes preparation matter. Decisions about whether to pay are made quickly and under stress, and having a documented position agreed in advance removes some of that pressure. Legal counsel, insurers and leadership should agree the approach before it is needed.
Third party and supply chain exposure
Attackers frequently enter through a supplier rather than the target. A managed service provider with access to many customers is an attractive starting point, and a compromise there can reach dozens of organisations at once.
Contracts rarely address this adequately. Buyers should ask how a supplier segments access, whether the supplier’s own backups are isolated and what notification commitments apply. The answers are more informative than a security questionnaire completed once a year.
A workable set of priorities
Make at least one copy immutable and keep it off the production network. Use credentials that do not exist in the domain. Monitor deletion events and alert on them. Test a full restore at least annually and record the time. Keep an offline copy of the recovery procedure, because the intranet may be unavailable.
None of this is exotic. The failures that make headlines are rarely caused by sophisticated attacks on well separated systems. They are caused by backups that shared credentials, networks and administrators with everything else, which is a design decision that can be reversed before an incident rather than after. The real test of a backup strategy is the last restore that was actually performed and timed, including the hours spent finding the credentials and the documentation that made it possible.
Image: Federal Bureau of Investigation · Public domain · via Wikimedia Commons.