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.
A clean room, in recovery planning, is a network you build so that systems under suspicion and systems you hope to trust cannot reach the attacker and cannot reach production. The point of the room is negative. It exists to make common malware behaviour fail: fetching a command, leaking a key, or walking sideways into the next server. A VLAN with a reassuring name and a default route to the firewall is not that room.
The September 2023 #StopRansomware Guide is blunt about containment. If several systems or subnets look involved, take the network offline at the switch. Disconnecting every host one by one may be impossible in the moment. If you cannot drop the network, unplug the cable or drop the wireless link on the affected devices. Powering machines off is the last option, because it throws away volatile memory the responders may need. Do the isolation in a coordinated way. The guide says actors often watch to see whether they have been found, and a noisy partial shutdown can push them to move sideways or to detonate more widely before you finish.
NIST SP 800-61 Rev. 3 defines containment as preventing the incident from expanding, so that damage stays bounded and the response is not overwhelmed. It notes that tools can quarantine malware or move an endpoint to an isolated remediation network, and that handlers still need the authority to contain by hand. NIST SP 800-184, in its fictional ransomware scenario, puts infected machines on a different network on purpose, coordinated so the move itself does not alarm the attacker, and it lists a staging system whose job is to check recovered data before you trust the infrastructure again.
None of those documents hands you a switch configuration. This article stays at the pattern. It does not repair hosts, and it does not recover a directory.
Two networks, not one named VLAN
CISA's recovery paragraph draws a line that planning often smudges. When you create a VLAN for recovery, only clean systems go on it. Take care not to re-infect them. That sentence only makes sense if "the recovery network" is not also the place you parked the still-infected machines.
Plan two segments with no path between them except a method you can point at, such as a file you copied across a break you control.
Holding segment. Systems you believe are involved, or that you have not classified. They are here so they stop talking to the rest of the estate and, as far as you can manage, stop talking to the attacker. They may still be malicious. They are not candidates for the recovery segment. SP 800-61 Rev. 3's "isolated remediation network" fits here if the purpose is quarantine. It does not fit as the place you then restore the finance server beside them.
Recovery segment. Systems built from media you have already classified, or originals you have a reason to call untouched. CISA's rule is membership: only clean systems are added. A restore that is still being checked does not meet that bar. It stays on a staging attachment, which SP 800-184 describes as a place to validate recovered data before you instantiate trust in the infrastructure. Staging is a third attachment if you need it. It is not a shortcut onto the recovery segment, and it is not a bridge back to production.
Our recommendation, not a phrase in the guides: write the membership rule on the change ticket that creates the segments. "Isolated" is not a membership rule. "No system is added to recovery until the catalogue decision and the staging check for that system are recorded" is a membership rule. The catalogue decision is a separate piece of work. The network cannot invent it.
What "no phone home" has to deny
The CISA hunt list is a description of how crews actually leave and come back. It is not a block list you paste into a firewall and forget. The guide says actors have tunnelled SSH over HTTPS with tools such as Chisel, abused Cloudflare tunnels, used commercial remote-control software including Cobalt Strike, used unexpected remote-monitoring tools, and moved data with utilities such as Rclone, Rsync, file-hosting services, and FTP. It also says endpoint-to-endpoint traffic that you did not expect is itself a sign. A room that blocks only known-bad addresses leaves unlisted destinations available; other controls may still stop a technique, but that block list alone does not establish isolation.
The following restrictions are our planning pattern, not a vendor configuration or a universal NIST topology requirement:
- No unrestricted internet egress from holding, staging or recovery. Removing a default route is one possible control, but specific routes, proxies, tunnels and other interfaces must also be checked. Name the exceptions one by one, with an owner and an end time. "Patching" is not an exception until you name the patch source.
- No use of the production resolvers. Those resolvers may be where you still want logs, and they may also be how a host finds a command server or how a compromised resolver hands out the attacker's address. The room resolves only names you have listed, or it does not resolve. A host that cannot resolve can still be given a numeric address by malware that does not need DNS. Absence of DNS is not a complete control. It removes one easy path.
- No route to production subnets, to the identity systems, to the backup repositories, or to the hypervisor management plane, except the single path that presents the already-classified copy to staging. That path should not let staging open a session back into the repository's admin interface.
- No shared layer-2 between holding and recovery. A private VLAN, an access list, and a separate virtual switch are different mechanisms with the same goal. If the mechanism fails open when the control platform is unreachable, say so in the plan. During this incident the control platform may be one of the things you do not trust.
- Administration of the room comes from a jump point that does not depend on the directory you are treating as suspect. If the only way to configure the recovery switch is a login on that directory, the attacker who owns the directory owns the room's walls.
- IPv6, wireless, a second NIC, and a hypervisor "utility" network are in scope. A deny on the IPv4 default route does nothing for a protocol you forgot was on.
SP 800-61 Rev. 3's monitoring outcomes include watching for rogue networks inside facilities and for unexpected flows. The clean room is a network you intended. A second, accidental path is the rogue. Someone has to look for it after the room is built, not only draw it.
Switch-level cut versus a designed room
CISA's "offline at the switch" instruction is containment under time pressure. It may be justified when many systems are affected and continued connectivity risks further harm; incident leadership must account for safety-critical dependencies and the consequences of the cut. It is a poor steady state. A campus or a data centre taken offline at the core has also lost the path you needed for out-of-band coordination if that coordination was riding the same switches, which is why the guide pairs the cut with phone calls rather than with another email. SP 800-184's warning that email may be unwise once the network is compromised is the same constraint.
The designed room comes after that cut, when you deliberately reconnect a small set of links:
- Responders can reach the holding segment to collect what CISA still wants collected: images, memory if you did not power the host off, and logs. Collection is not the same as giving those hosts a route out.
- Staging can read one classified backup copy and nothing else.
- Recovery can later reach the business systems you have decided are allowed to return, in an order the plan already has. That return is a change, not the default.
SP 800-61 Rev. 3 allows that some organisations redirect an attacker into a sandbox to watch them, and it says to take legal advice first because the delay lets the attacker escalate or move. A clean room is the opposite choice. You are refusing the conversation. Do not mix a "watch them" segment into the recovery segment because both are "not production". The legal and the technical risks are different, and the guide's caution is there so the watch decision is conscious.
Patterns that look isolated and are not
These failures are ordinary. They are hypothetical patterns, not incidents from a named organisation.
- The recovery VLAN has no production routes and a default route "so analysts can update tools". Malware updates itself by the same route. If analysts need a tool, bring the tool in from media, or allow one named repository for one named hour.
- The hypervisor cluster is shared. A guest on the holding segment and a guest on the recovery segment can still talk through a mis-set port group, a shared storage network, or the host's management agents. SP 800-184 lists an authorised management tool whose agents remain installed as a way for an adversary to persist. Agents on the clean room are a path, even when the guest firewall is strict.
- The backup product's own service on the restored guest phones its vendor cloud to "validate the licence" the moment the interface comes up. A legitimate licence call is not itself malware command-and-control, but it still needs an approved egress exception and a trusted destination. The membership rule has to include agents, not only user processes. Whether you disable them is a platform decision for the runbook, tested before the incident. This article does not provide the disable steps.
- DNS from the room is "just internal". Internal DNS may reveal service addresses or involve a compromised resolver. A DNS answer does not create a route; assess resolver trust, DNS tunnelling and actual network reachability separately.
- A laptop on the wireless network, joined by someone trying to help, bridges the guest Wi-Fi to the recovery switch. CISA's unplug instruction exists because wireless is a path. The room needs a physical story: which ports are lit, who may patch a cable, and where laptops are forbidden.
What you record before you call the room ready
A room that has not been described will be widened by the first person who cannot reach a file. Record, before the incident if you can and immediately after the cut if you must:
- Which segments exist, and the membership rule for each.
- The complete list of routes, including those you believe are absent. "No default route" is a claim to check, not a label.
- Where administration of those routes comes from, and which directory that login depends on.
- The single path by which a classified copy is presented to staging, and who may change it. That person should be the recovery authority you already named, not anyone who can see the switch.
- Allowed exceptions, each with an owner, a reason, and a time after which it is removed. SP 800-61 Rev. 3 notes that containment measures have a duration: an emergency workaround of hours is not a temporary workaround of weeks. A recovery-room exception needs the same expiry.
- How you will notice a flow that violates the list. Denied-flow logs are useful evidence but are not the only test and do not prove every path is blocked. Combine configuration review, controlled connectivity checks and observations at relevant boundaries.
CISA asks you to prioritise restoration of critical services and the systems they depend on, and to keep a list of systems you do not think were hit so you do not waste the room on them. The network plan should say where those untouched systems live while you are still unsure. "Not perceived to be impacted" is not the same as "clean enough for the recovery segment". Leaving them on production while production is the crime scene is also a decision, and it belongs in the same note.
Risks and limits
- No switch, firewall, or hypervisor was configured for this article. A pattern is not a validated configuration. Vendor syntax belongs in a lab change, not in an untested paragraph.
- Taking a network offline stops business activity that was still healthy on that network. CISA presents the switch-level cut as a response when many systems appear involved, not as a casual drill. The decision sits with the authority already named in the incident plan.
- An isolated room cannot fetch patches, time, or revocation information unless you have named that path. Those dependencies are real and are easy to "fix" by restoring a default route. Fix them with a named exception, or accept that staging will not check revocation until later.
- Blocking callbacks does not remove malware from a disk. It reduces what that malware can do while you decide. Scanning and the decision to reattach are later gates.
- SP 800-184's network split is inside a fictional scenario. It illustrates the control. It is not a measured result.
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).
This article was originally published on .