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.
Restoring a backup copies bytes onto a machine. Reattaching that machine lets those bytes talk to people, to other systems, and, if you have left a path, to the attacker. Those are different events, and they need different permission. The scan, broadly meant, is the work you do in between: look for the indicators you already have, look for accounts and tasks that should not be there, and confirm the copy is the one the catalogue said you were restoring. Staging is the network attachment where that work is allowed to happen without the system being "back".
NIST SP 800-61 Rev. 3 splits the checks in exactly this way. Before you use backups or other restoration assets, verify their integrity: indicators of compromise, file corruption, and other integrity problems. After the restore, check the restored assets again, remediate the root cause, and confirm the restore was correct and sufficient before the system is put online for production. NIST IR 8374r1 applies the first of those to ransomware in one line: verify backup integrity before you depend on it. NIST SP 800-184 names a staging system in the recovery plan, whose purpose is to validate recovered data and only then to place trust in the infrastructure. In the guide's fictional ransomware scenario, user systems are restored from backups that have already passed the playbook's acceptance criteria, and the team keeps recording indicators while that happens.
The September 2023 #StopRansomware Guide supplies the membership rule. Do not re-infect clean systems. If you built a VLAN for recovery, only clean systems are added to it. Find precursor malware before you rebuild from backups, because a rebuild that still contains the earlier intruder is how the incident continues. The guide also prefers rebuilds from pre-configured standard images where you can, with source or installers kept alongside offline backups because an image sometimes will not land on different hardware. An image is a restore too. It goes through the same gate.
This article does not name a scanning product, and it does not repair an operating system.
What the gate is deciding
Staging answers one question: is this system allowed to move from "bytes restored" to "allowed on the recovery segment"? It does not answer "is the business happy with the recovery point", and it does not answer "may this system rejoin production". The separate staging and release gates are this article’s recommended implementation of the NIST outcomes; the document does not prescribe a universal three-network sequence. Essential services come back in a defined order, owners confirm that what returned is the service they recognise, and someone watches whether the restored system actually performs. A malware scan that exits zero is not that confirmation.
Write the acceptance criteria before the incident, which is what SP 800-184 means by criteria in the playbook. A criterion you invent while the chief executive is asking for email is a wish. Useful criteria are observable:
- The catalogue row, the media, and the key match the point you meant to restore, and that point is still on the allowed side of the intrusion time you are using.
- The hunt's known indicators were searched for on the staged system, and the result is recorded, including "not found". Absence is a result only if you record what you looked for.
- Accounts, scheduled tasks, and services that the image or the baseline did not include are listed. The CISA hunt section treats unexpected scheduled tasks, unexpected new services, and unexpected installed software as signs worth pursuing. On a staged restore they are a reason to stop, not a reason to click through.
- The system has not been given a route to production or a default route to the internet while you look. If it has, you are no longer staging. You have reattached it by accident.
- A named person, not the same person who mounted the backup if you can avoid it, accepts the record and authorises the move onto the recovery segment.
Our recommendation, not a NIST control statement: fail closed. A check you could not run is a failed check, and the system stays off the recovery segment. SP 800-61 Rev. 3 allows you to change the plan when resources change. It does not allow you to mark a blank cell as a pass. If you consciously accept a gap, write the gap, the reason, and who accepted it. That is a different document from a pass.
What to look at, without turning it into a product
You will be offered a scanner. Use the one your incident plan already names, on software you have licensed and tested. This research did not run one, and it will not tell you which flags to set. The categories below are the ones the sources already treat as material. They can be covered by a scanner, by a human comparing the system to a baseline, or by both. The category is the requirement. The brand is not.
Indicators you already hold. Hashes, domains, file names, and account names from this incident, plus the precursor families the CISA guide tells you to look for before a rebuild. An unrestricted signature-update path conflicts with this article’s restricted-egress staging pattern; an explicitly approved, authenticated update path may be part of that pattern. Bring signatures in on media, or through the one exception you named and timed. A scanner with last month's signatures still has a job: it can find last month's intruder. It cannot promise to find this week's.
The restore itself. Corruption, truncated files, and a job that does not match the catalogue row are the "file corruption and other integrity issues" in RC.RP-03. Compare identity, not just a green tick from the backup console. A restore of the wrong volume that passes a malware scan is still the wrong restore.
Persistence that looks like administration. CISA describes living-off-the-land techniques: remote management tools, PowerShell, and commercial test tools used by crews, plus changes that disable recovery. On a staged server, a remote-management agent that the baseline does not include is a finding even if a malware engine calls it clean. SP 800-184's example of an authorised management tool whose agents remain installed is the same finding after you thought you had recovered. Agents that ship inside a golden image need a decision in the baseline, made before the incident: which agents are allowed to start while the system is still on the staging attachment. An agent that phones a vendor the moment the interface is up has left the gate without permission.
Accounts and identity debris. New local administrators, scheduled tasks running as a service account you do not recognise, and SSH keys or API tokens the baseline did not have. CISA includes password resets after clean-up and rebuild. That does not prohibit earlier containment of compromised credentials; responders must coordinate containment, revocation and final credential replacement. Staging is where you list which accounts those are. It is not where this article will tell you the directory commands. A forest rebuild is out of scope here. What is in scope is refusing to reattach a system that still contains an account the hunt has already called suspicious.
The image, not only the data. CISA recommends golden images of critical systems, maintained and updated, and it warns that some images will not install onto different hardware, which is why offline copies of source and licence material matter. An image that was maintained on the production network, or by the backup administrator's tooling, is a backup of a build process. If that process was reachable during the intrusion, the image is a candidate for the same time-line you applied to data jobs. Staging a data restore onto a poisoned image is how a clean database inherits a backdoor. Check the image against its own catalogue row.
What a scan will not settle
Say this in the criteria so nobody treats a vendor dashboard as RC.RP-05.
- A file-signature scan alone may miss abuse of legitimate tools; behavioural detections and incident-specific investigation can provide different evidence. The CISA guide spends time on that pattern because it is normal in these incidents, not exotic.
- Encryption hides content until an authorised inspection or restore process decrypts it. Some products can inspect decrypted backup content without a complete system restore. Scanning the backup file as a blob and scanning the mounted system are different tests. RC.RP-03 is about the asset you will use. Scan that.
- Firmware, the hypervisor, and the backup appliance are not inside the guest filesystem. SP 800-61 Rev. 3 says that when the actor is sophisticated and the scope of their methods is unclear, recovery may mean replacing hardware on the compromised systems. Staging a guest does not answer that. It tells you to escalate the question rather than to pretend the guest scan covered it.
- A system can be free of malware and still be the wrong recovery point, missing a day's transactions or containing the attacker's edits from before encryption. Business acceptance is the owner's confirmation in RC.RP-04, after the security gate, not instead of it.
- "Clean" expires. The CISA warning about re-infection is about what happens next. A system that passed staging and is then patched from a compromised management server, or joined to a directory that still has the attacker's account, does not stay at the standard you signed. SP 800-184 puts continued monitoring into the strategic phase for that reason. The gate is a moment. It is not a permanent label.
The move after a pass
Passing staging authorises one move: onto the recovery segment that accepts only systems with a recorded pass. It does not authorise a route to production, a join to the old directory, or a return of the backup agent to its old console.
SP 800-61 Rev. 3's RC.RP-04 then asks you to bring critical functions back in order, to have the owners confirm the service, and to watch performance. RC.RP-05's "before production use" is the moment those paths are added. Keep the authorisation separate from the staging signature so a busy team cannot treat them as one click. The person who signs the production join should be able to see the staging record, the catalogue row, and the list of accounts still waiting for the reset the CISA checklist places after the environment is cleaned. If those resets have not happened, production join is early.
Hypothetical, to show the gate holding: a file server restore passes a malware scan and a catalogue match. Staging also finds a remote-support executable that is not in the image baseline, dropped three weeks before the ransom note, which is inside the hunt's current time bound. The scan was not wrong. The gate fails. The system stays off the recovery segment until that file is explained or the restore is replaced with an earlier point that does not contain it. Shipping it because the phone is ringing is the failure CISA describes when unclean systems are added to the recovery VLAN.
Risks and limits
- No scanner was run, and no detection rate is claimed. A tool that was not in your last exercise is a poor thing to meet for the first time during the incident. IR 8374r1 says to exercise the response and recovery plan, including the people who will execute it.
- Comparing a live system to a baseline requires a baseline. If you do not have one, the criteria have to say what you will compare against, or the check is theatre.
- Staging a multi-terabyte restore takes time and space you may not have. Scope it the way SP 800-61 Rev. 3 suggests, toward the files and systems the business actually needs first, and record what you did not stage.
- Destructive cleaning steps, partition repairs, and directory rebuilds are outside this article. If the check says the system is not fit to move, the next action is a decision in the runbook, not a command invented here.
- SP 800-184's acceptance-criteria example sits inside a fictional scenario.
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 IR 8374r1 (June 2026).
- NIST SP 800-184 (December 2016).
This article was originally published on .