Hunting the backup catalogue before you restore after ransomware

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

The backup catalogue is the index of recovery points: which system, which data, which start and finish time, which copy, and whether the job claimed success. After ransomware, that index is evidence. It is also a system the attacker may have edited, and it often lives on the backup server you are least sure of. Triage means deciding which entries are candidates, which are inside the intrusion window, and which you cannot trust yet, before anyone restores a machine.

NIST SP 800-61 Rev. 3 recommends verifying the integrity of backups and other restoration assets before they are used, including checks for indicators of compromise, file corruption, and other integrity problems. NIST IR 8374r1 repeats that for ransomware: verify backup integrity before you rely on it to recover. NIST SP 800-184 shows the shape of the work in its destructive-malware scenario, which the document labels as fictional. The team inventories every backup system and process, maps the storage devices, lists the available restore points, and, with the incident responders, records the time of infection so the matching backups can be identified and checked. Nothing in that sequence is a button labelled restore.

The September 2023 #StopRansomware Guide puts the same idea in incident order. Hunt before you rebuild. Look for precursor malware and for changes that impair backups. Only later does the recovery section say to restore from offline, encrypted backups, and to avoid putting unclean systems on the recovery network. A catalogue you have not read is not an input to that step.

This article stops at the decision the catalogue can support. It does not rebuild servers, repair disks, or recover a directory forest.

What you are trying to learn

Four questions decide whether a catalogue line is allowed to become a restore:

1. When did the attacker first have a way to change this data or this backup? Not when the ransom note appeared. The CISA guide says a ransomware event may be evidence of an earlier, unresolved compromise, that operators of dropper malware often sell access, and that ransomware is sometimes deployed to hide what happened before. The time you care about is the start of that access, as far as the hunt can see, and it is the earliest access demonstrated by current evidence, not proof that the intrusion began then. The real start may be earlier, and the working boundary must move if earlier evidence appears.
2. Was this recovery point taken before that time, and has it remained unchanged since?
3. Could the attacker reach the copy this record points at? A successful job written to a repository the attacker could delete is a different object from the same job also written to a copy they could not reach. The record has to say which copy, or it is not yet a decision.
4. Do the catalogue, the storage, and the keys agree? A row that points at media you cannot find, or at data you cannot decrypt because the key was on the encrypted backup server, is not a candidate. It is a gap.

Until those four have answers, the honest status of the line is "not yet a restore". SP 800-61 Rev. 3 also says recovery actions should weigh timeliness, precision, and reliability, and it gives the example of restoring only the affected files rather than every file. Catalogue triage is how you earn the right to be precise. Restoring an entire environment from the newest green job is fast and often wrong.

The fields that matter

You do not need every column the product can display. You need the columns that can falsify a restore. For each candidate point, record:

Our recommendation, not a product manual: keep this triage table outside the backup server, on a machine or a paper set the responders can read while that server is isolated. SP 800-184's scenario has the team map storage devices and enumerate restore points as a deliberate inventory, not as a glance at the last successful job. CISA tells you to keep an offline copy of the incident plan for the same reason. The catalogue extract is part of that kit. If the only copy of the extract is on the platform under investigation, you will be tempted to log in as the backup administrator you may no longer trust.

Use the hunt to draw a line through the jobs

The CISA guide's detection section gives a practical list of things that should move your line earlier, or that should mark backup infrastructure as in play. It is a hunt list, not a set of commands to type. Among the items it names for enterprise environments:

• New directory accounts, or unexpected activity on privileged groups.
• Endpoint changes that may impair backups, shadow copies, disk journals, or boot configuration. The guide names misuse of built-in Windows tools, including bcdedit.exe, fsutil.exe with a delete-journal action, vssadmin.exe, wbadmin.exe, and wmic.exe aimed at shadow copies, as a common way to inhibit recovery. Seeing those names in logs is a reason to treat backup protection as attacked. This article does not tell you to run the tools.
• Unexpected remote-management software, including tools that were not installed in the usual way.
• Signs of credential dumping and of data leaving the network.

Any one of those, if it is credible, becomes a time marker on the triage table. Jobs of the affected data after that marker stay in the "untrusted until checked" column even if they are green. Jobs before the marker are only cleaner if the copy they sit on was not reachable afterwards. SP 800-184's fictional team updates the playbook with the time of infection specifically so the corresponding backups can be checked for integrity. Do the same with a real time, and write down that the time may move.

There is a second marker the catalogue can generate for the hunt, rather than only receive from it. Retention changes, disabled jobs, new backup credentials, and a sudden drop in stored size are themselves indicators. Feed them back to the incident handlers. SP 800-61 Rev. 3 treats logs as important to detection, response, and recovery, and CISA says to keep logs from critical systems, for a year if you can, in a central place. Backup-audit logs belong in that set. A catalogue with no history of who changed retention is a picture of the present, not a record of the attack.

What a passed check still does not mean

RC.RP-03 is a gate in front of use, not a certificate of innocence.

• A write-time checksum alone does not verify a later read. Comparing independently read bytes with a trustworthy saved checksum provides evidence against corruption within that check’s scope; attacker-editable bytes and checksums cannot authenticate each other. It does not prove those bytes were free of a web shell, a new account, or a document the attacker encrypted last week and that the job then faithfully saved. Integrity of the backup object and cleanliness of the business data are different questions. SP 800-61 Rev. 3 lists both indicators of compromise and file corruption because both matter.
• A point taken before your current earliest marker is only as good as the marker. The CISA guide's warning about sold access exists so you do not treat the ransom note's timestamp as the start.
• An offline copy of a job that was already bad is a well-preserved bad job. Disconnection protects the bytes from later deletion. It does not rewrite history.
• A catalogue the attacker could edit can hide the good point or advertise a bad one. Where you can, match the row to an independent trace: media labels, storage-system snapshots of the repository, or an export taken before the incident and kept with the offline plan. If you have no independent trace, say so in the table. Guessing a match is how the wrong point gets restored.

SP 800-61 Rev. 3's recovery notes also say that where the actor is sophisticated and the scope of their methods is not known, recovery may have to go as far as replacing hardware on compromised systems. Catalogue triage does not make that call. It stops you from feeding those systems a backup you have not classified.

A workable order

This is a decision order for the people already named in the incident plan. It is not a software procedure, and it was not executed for this article.

1. Freeze interpretation. Export or photograph the catalogue state you have, including failed jobs and recent admin changes, before anyone cleans the backup server. CISA warns that powering a machine off can destroy volatile evidence, and it prefers isolation when you can still collect. The catalogue database is the evidence you came for. Do not rebuild the backup server as a first move.
2. Draw the time bound from the hunt, label it provisional, and mark every point of in-scope data after that bound.
3. Split each remaining point by copy. A candidate is a readable copy tied to a suitable pre-bound consistency point whose later integrity can be established. Do not automatically choose the oldest point: compare security evidence, dependencies and acceptable data loss. Newer data may require a separately approved selective salvage plan into rebuilt systems, rather than a whole-system restore. If the only pre-bound copy is unreadable because the key is gone, that fact is the result. Report it. Do not substitute a later online job because it mounts.
4. Check the candidate for corruption and for indicators the hunt already has, and record the result against RC.RP-03. Who checks, and with which tools, belongs in the runbook you tested. This article does not name a scanner or a command.
5. Hand the classified point to the people who will restore onto a network reserved for systems you are willing to call clean. CISA's recovery step is explicit that a recovery VLAN should receive only clean systems. A catalogue decision is an input to that step, not a substitute for it.
6. If the time bound moves earlier, stop and reclassify. A restore already in progress from a point now inside the window is a mistake you can still halt. SP 800-61 Rev. 3 allows planned recovery actions to change when needs and facts change.

Hypothetical, so the order is visible: the newest database job finished at 01:10 and is green. Privileged-group changes start at 18:40 the day before. A job at 17:00 finished cleanly and also exists on media that left the building at 17:30. The 01:10 job is not the candidate, even though it is newer and more convenient. The 17:00 copy is a candidate only after the key is available and the integrity check is recorded. If the hunt later finds a dropper at 09:00 that morning, the 17:00 copy drops out and you say so. Convenience is not one of the four questions.

Risks and limits

• Catalogues differ by product. This article does not map fields to any vendor's screens, and it does not validate export formats.
• A full read of every recovery point can take longer than the business will tolerate. SP 800-61 Rev. 3's precision point cuts the other way: checking everything badly is worse than checking the candidate you might actually use. Say which points you did not check.
• The fictional scenario in SP 800-184 is an illustration of planning, not evidence that inventory finds every encrypted backup. The document says the scenarios are not exhaustive.
• Tool names from the CISA guide are indicators for hunters. Running them yourself on a live system can destroy the recovery points you are trying to classify. No such command was run for this article.
• Choosing among several candidates that all pass is a later decision. Triage can leave you with more than one surviving point, or with none.

Research and verification

This article was drafted with AI assistance on 11 November 2026 and independently reviewed against public sources on 13 November 2026. It is source research, not a lab-validated recovery procedure or evidence of a NetLeverage product capability. No article commands or recovery operations were executed.

Sources

Independently reopened 13 November 2026.

• CISA, FBI, NSA, and MS-ISAC, #StopRansomware Guide (September 2023). Live official page independently reopened 13 November 2026.
• NIST SP 800-61 Rev. 3 (April 2025).
• NIST SP 800-184 (December 2016). The destructive-malware walkthrough is a fictional scenario in that guide.
• NIST IR 8374r1 (June 2026).

This article was originally published on 13 November 2026.