When Backups
Become the Target

“We have backups” is reassuring during a ransomware incident because it gives your organisation a way to restore affected data and systems. That reassurance rests on an important condition: the copies, the means of accessing them and the environment into which they will be restored must still be usable.

An attacker can target that condition. They may try to delete accessible copies, interfere with backup jobs or compromise the accounts and consoles used for restoration. Production systems could be encrypted only after the intruder has attempted to weaken the route your recovery team expects to use.

The question for your executive and infrastructure teams is therefore whether recovery can proceed if the attacker has deliberately targeted the recovery arrangements themselves.

Backups give your organisation options after equipment failure, accidental deletion, corruption or malicious encryption. They remain an essential part of responsible operations and can reduce dependence on an attacker’s decryption offer.

Restoring after a deliberate intrusion introduces a different condition from replacing a failed server. The person causing the damage may also be seeking access to the copies and systems intended to repair it. Your recovery plan has to account for an adversary trying to obstruct the plan.

Consider a repository whose data remains intact while the backup management server is disabled and the recovery administrator’s account is compromised. There is still a valuable copy, but additional work is needed to establish authorised access and a suitable restoration environment. The distinction is operational: protecting the copy preserves an option; exercising the whole recovery route establishes how that option can be used.

Immutability can prevent a protected backup file or object from being altered or deleted for a defined period. Correctly implemented protection can withstand attempts made through compromised backup-management credentials. An accepted administrator login does not automatically remove an enforced retention lock.

The protection depends on the storage design, configuration and the copies to which it applies. Veeam’s documentation, for example, distinguishes a backup job’s retention setting from an immutable period during which protected files cannot be deleted. The important question is which copies retain that protection, and for how long.

An immutable copy still needs a usable restoration route. The control does not, by itself, establish that all required data was included, that the chosen restore point predates compromise or that the accounts and target systems used for recovery are safe to use.

Offline copies, separation of administrative access and tested restoration arrangements add protection in different ways. Their combined value should be demonstrated against the recovery conditions your organisation may face.

If an attacker has copied sensitive information outside your organisation, restoring systems does not withdraw the information from the attacker. Availability can improve while the consequences of disclosure continue.

Your incident team still needs to investigate what was taken, while legal and communications teams assess the applicable notification requirements and the information that affected people or organisations need. Extortion over stolen data may continue even if operational recovery is successful.

The distinction matters when reporting progress. “The service has been restored” describes an operational result. It does not establish that the information was never accessed or that copies held outside your organisation have been destroyed. Data exposure needs its own investigation and response.

A meaningful recovery exercise follows an essential service far enough to show that its data, accounts, infrastructure and operating dependencies can be brought together. The result should identify the conditions under which recovery succeeded and any dependencies that remained unresolved.

For your executive team, five questions make that evidence useful:

• Which copies remain protected if a production or backup-management account is compromised, and which changes could that account still make?
• Can the recovery team reach and use those copies if its usual console, identity service or production environment is unavailable?
• What evidence supports the choice of restore point and the decision to reconnect the restored systems?
• Which essential service has been restored in an exercise, with its dependencies, and how long did that take?
• If information has already been stolen, which separate investigation and communication responsibilities remain after restoration?

Our contribution is containment of specific harmful activity alongside your backup, identity, investigation and recovery arrangements. Ransomware Containment is our platform. It agentlessly monitors file activity in the protected data environment and isolates the responsible user, session or device when illegitimate encryption begins.

Additional Server Intrusion Protection (SIP) and Virtual Server Protection (VSP) features run on our platform. SIP detects and contains compromised server access, while VSP protects supported hypervisor environments against attacks directed at that layer.

Containing encryption, compromised server access or attacks against supported virtual infrastructure can help limit the extent of damage your recovery team has to address. Backup immutability, usable restore points, recoverable management systems and safe reconnection still require their own protection and validation.

Our remote ransomware resilience assessment demonstrates one defined capability. In an agreed, isolated test environment, we run controlled file-encryption scenarios with your existing security controls active, first without Ransomware Containment enabled and then with it enabled.

The comparison shows how active encryption is handled within the agreed test scope. It does not test backup survivability or restoration, clean restore points, SIP, VSP, lateral-movement interruption, data-exfiltration prevention, decision authority or wider business continuity. During the session, we definitively explain the additional features and discuss broader requirements separately. Request a ransomware resilience assessment