Verifiying Backups After a Ransomware Attack

How to Verify Backups After Ransomware

A backup is not verified merely because the backup job reported “successful.” After a ransomware attack, you need to establish three separate things: the copy is from before the compromise, the data is intact and complete, and the organisation can restore and use it without reintroducing the attacker.

The safest sequence is to isolate affected systems, identify the last known good restore point, check the backup’s integrity and scope, and test a restoration in a clean, isolated environment before reconnecting production systems. CISA recommends isolating impacted systems and restoring from offline, encrypted backups while taking care not to reinfect clean systems.

Start with containment, not restoration

Follow your approved incident-response plan first. Disconnect affected hosts or segments as directed by your response team, protect backup infrastructure from compromised credentials, and use out-of-band communications if the incident may still be active. Do not mount a backup on a system that has not been declared clean simply because it is convenient.

Preserve relevant logs and incident timestamps before changing systems. Your team needs an approximate timeline for the initial access, lateral movement, encryption, data exfiltration, and detection. If the timeline is uncertain, treat the earliest plausible compromise time as the lower boundary for selecting a restore point. A backup created after the attacker gained access may contain encrypted files, altered configurations, stolen credentials, or persistence mechanisms.

Find the last known good backup

Create a short inventory of available copies. For each one, record its creation time, storage location, retention status, encryption status, backup job result, and whether it was reachable from the affected network. Include snapshots, removable media, cloud copies, database backups, SaaS exports, virtual-machine images, and configuration backups where they are relevant to recovery.

Then compare each candidate with the incident timeline. Prefer a copy that is offline or otherwise protected from unauthorised modification and that predates the earliest credible compromise. NIST’s data-integrity guidance describes the importance of identifying the last known good version; it also warns that automated backups taken after ransomware runs can preserve encrypted data, even though older versions may remain available.

Do not select a restore point only because it is the newest one. Recency matters for data loss, but trustworthiness comes first. If no clean point can be established, pause and involve incident-response or forensic specialists rather than guessing.

Check integrity and completeness

Verification should combine several checks because no single result answers every question.

First, inspect backup logs and alerts. Look for failed jobs, skipped files, changed retention settings, disabled protection, unusual deletion activity, and unexpected administrator actions. A green job status shows that a process completed; it does not prove that every required file is present or that the content is unaffected.

Second, compare the backup inventory with the data that must be recovered. Confirm that critical directories, databases, identities, configuration files, encryption keys, application dependencies, and licensing information are included. For databases, use the platform’s consistency checks and transaction-log procedures rather than treating a file-level copy as a complete database backup.

Third, use checksums or cryptographic hashes where you have a trusted reference. A SHA-256 comparison can show that a recovered file is byte-for-byte identical to the file used to create the reference. It cannot show that the file is safe, truthful, or free of malicious code. A malicious or encrypted file can also have a perfectly valid hash. Keep the reference outside the compromised environment and document the algorithm, value, file path, and time of each check.

CISA recommends scheduled recovery tests to verify backup integrity, identify possible compromises, and improve recovery objectives. It also advises testing both full and partial restoration and ensuring that critical files can be accessed when the network or internet is unavailable.

Prove the backup can actually be restored

Integrity checks are necessary, but restoration is the decisive test. Restore a representative sample first, then perform a broader recovery exercise in a clean, isolated network or recovery environment. The test environment should not share unrestricted credentials, network paths, or administrative trust with the compromised production environment.

Check whether:

• files open in their expected applications;

• databases mount, pass consistency checks, and contain the expected records;

• permissions and ownership are correct;

• services start without contacting suspicious infrastructure;

• dependencies, integrations, and scheduled jobs work as expected;

• endpoint security scans find no indicators of compromise

• the recovery meets the organisation’s recovery time and recovery point objectives.

A clean-room or isolated restore is stronger than checking a few filenames. It tests whether the recovery set is operational, not just readable. For critical systems, rehearse the order of restoration and record the time, people, tools, decisions, and failures. Fix the procedure before the live recovery.

Only after the recovery team has confirmed that the restored environment is clean and functional should it be connected to production. Continue monitoring after reconnection. The incident may involve compromised accounts or persistence that is not contained by restoring files alone.

Preserve a clear verification record

Create a recovery record that another qualified team member can understand without relying on memory. Include the incident timeline used for selection, each candidate backup, the selected restore point, integrity-check results, malware-scan results, restore logs, functional-test results, exceptions, approvals, and the time production recovery began.

Keep the original backup and test outputs preserved where your retention and legal-hold policies require them. Do not overwrite the only copy during testing. If a file is re-saved, converted, or modified during recovery, treat it as a new version; its bytes and SHA-256 fingerprint may change even when the visible content appears unchanged.

For particularly important files or manifests, an independently verifiable timestamp can add a narrow evidence layer. Certelo calculates a SHA-256 fingerprint locally in the browser, does not need the original file to be uploaded for the normal certification workflow, and anchors the resulting fingerprint to the Electra Protocol blockchain. A later check can confirm whether the exact file matches the recorded fingerprint and time through Certelo’s verifier or the relevant hash and certificate information.

That record should be described precisely. It can support a statement that a particular fingerprint existed at or before the recorded blockchain time. It does not prove that the backup was clean, that the data was not already encrypted, that the system could be restored, or who created the file. Certelo’s own compliance page says its proof does not establish authorship, ownership, identity, or universal legal admissibility.

A concise verification checklist

Before restoring production, confirm that your team has:

1. Isolated affected systems and protected the backup environment.

2. Established an incident timeline and selected a restore point that predates plausible compromise.

3. Preserved the original backup without overwriting it.

4. Reviewed backup logs, retention changes, deletion events, and skipped data.

5. Confirmed that critical files, databases, configurations, and dependencies are included.

6. Performed integrity and malware checks using trusted tools and references.

7. Restored a sample and then tested the required systems in an isolated environment.

8. Verified permissions, application behaviour, monitoring, and recovery objectives.

9. Documented the evidence, exceptions, decisions, and approvals.

10. Reconnected production only after the recovery environment was judged clean and functional.

A resilient backup strategy is built before the incident. CISA recommends offline, encrypted backups and regular tests of their availability and integrity. NIST likewise frames backup work as an ongoing practice of conducting, maintaining, and testing backups rather than a one-time installation. The practical lesson is simple: a backup you have never restored is an assumption, not a recovery capability.