Can backups be trusted after ransomware?¶
The practical answer¶
Backups should not be assumed safe simply because they exist or because they predate visible encryption.
The key evidential caution¶
The dangerous assumption is that restoring the latest available backup automatically returns the organisation to a clean state.
It may not.
Backups may contain:
Key points¶
- malware
- stolen credentials
- persistence
- modified configuration
- compromised accounts
- web shells
- remote-access tools
- corrupted data
- the same vulnerable software or settings
An offender may have been present for days or weeks before the disruptive phase.
What investigators should establish¶
Investigators should establish:
Key points¶
- when the earliest supported compromise occurred
- which systems and accounts were affected
- when each backup was created
- whether the backup environment was accessed
- whether backups were altered or deleted
- what validation was performed before restoration
A backup may be operationally usable while still containing artefacts relevant to the incident.
Preserve representative copies before overwriting or rotating them.
Practical interpretation¶
Where possible, restore into an isolated environment and test for compromise before returning systems to service.
Evidential limits¶
Do not assume one clean scan proves the backup is trustworthy.
The relevant malware may be unknown, inactive or absent while compromised accounts and configuration remain.
Backup trust also depends on the recovery process itself. Restoring into a compromised identity environment or through a hijacked management platform may immediately expose the recovered system again. Validate administrator accounts, recovery credentials, network routes and deployment tools as part of the restoration decision, not as a separate afterthought.
Operational takeaway¶
Assess backups against the incident timeline, preserve representative copies and validate systems, accounts and configuration before treating a restoration point as clean.