Recovering After Ransomware: Clean-Room Build, Restore Order and Assessing Backup Trust

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 scan cannot prove a backup is safe. Collect independent evidence and limit the consequences of a mistaken trust decision. So build an isolated environment first, restore into it, test in layers, and connect nothing to production until identity has been rebuilt and the entry point has been closed.

Scan isolated copies; paths are examples.

Interpretations are editorial; no lab testing was performed.

Why it matters

Restoring quickly into a compromised network is how one incident becomes two. The UK National Cyber Security Centre warns that ransomware may have been in a network for some time and replicated into backups before anyone noticed. Its 2026 recovery guidance says investigation should, where possible, happen before systems are restored, and that rushing recovery before understanding the incident can significantly increase risk.

Attackers also target recovery. MITRE ATT&CK documents deleted volume shadow copies, deleted Windows backup catalogues, removal of ESXi virtual machine snapshots, and deletion of online backups. The NCSC says to assume backups may have been targeted and to seek assurance that they are immutable and uncompromised.

Coordinate technical recovery with responders, legal advisers and the insurer.

How it works

Step 1: contain without destroying evidence

The published advice differs here, and the difference matters.

• The NCSC sets out a choice. Disconnecting from networks limits spread and preserves forensic evidence, but may not stop activity already running. Shutting down may halt processes, but can lose evidence and make it harder to confirm the attacker has gone.
• The Australian Signals Directorate's steps page says to record details, turn off the infected device, then turn off other connected devices, starting with those most important such as NAS devices and servers, and change important passwords. Its ransomware playbook gives the same four steps for large organisations and critical infrastructure operators, so the difference from the NCSC is not confined to small audiences.

Our recommendation: if you have responders available, isolate at the network first and let them decide what to capture, even though that departs from ASD's order. If encryption is actively running and you have no specialist help, stopping it takes priority, and the ASD advice applies. Record the decision in a central record of what was found, when and who decided, using one time reference, as the NCSC suggests.

Disconnect the backup system from anything it does not need, and do not log in to it with credentials that may be compromised.

Step 2: build the timeline

The restore point sought is the newest usable one before the earliest known compromise, with additional margin for uncertainty, not the one before encryption started. Those can be weeks apart.

Microsoft's backup guidance says to review the incident timeline to identify a safe point in time, and to validate the backup again before restoring. The NCSC expects responders to establish how attackers gained entry, how they moved, what they did, and whether they kept access.

Expect a real trade-off. Microsoft's forest recovery guide describes it for domain controllers: a more recent backup recovers more data, but might increase the risk of reintroducing dangerous data. That guide also limits how old the backup can be. Backups are valid within the tombstone lifetime, and with Recycle Bin enabled the lifetime is the lesser of the deleted object and tombstone values. So a long intrusion can leave no usable domain controller backup, and forest recovery planning has to start from that.

Different systems will often need different restore points. That is where data reconciliation starts.

Step 3: build the clean room

"Clean room" is a working term rather than a defined standard. NIST SP 800-184 describes the components: a recovery network, an identity management system, a messaging system, and a staging system to validate the integrity of recovered data and establish trust in the infrastructure.

The following design is our recommendation:

• Separate hardware or a separate tenancy from the compromised environment, with no routed path to it.
• Two zones. A quarantine zone holds unverified candidates, and a clean zone holds rebuilt identity, administrator workstations and released systems. NIST lists staging as its own component. A suspect machine must not reach the new directory, the administrator workstations or the internet allow-list. A system moves to the clean zone only after passing the gate in Step 7.
• Hypervisors installed fresh from vendor media, with the media checksum verified. Do not restore a hypervisor configuration from the affected period without reviewing it, since ATT&CK records ESXi hosts being attacked directly.
• New administrator credentials, created in the clean room and never used in the old environment.
• Administrator workstations rebuilt from known media. The NCSC warns to connect backups only to known clean devices.
• Controlled internet access from the clean zone only, through an allow-list, for patches and signature updates.
• Out-of-band communications for the response team, because the corporate mail and chat systems may be watched or gone. NIST lists a messaging system for this reason, and the NCSC notes that trusted identity may have to be established in person.
• A scanning host that is not the backup server, so that malware being scanned has less to reach. Veeam's mount server defaults to the backup server or a repository, so it has to be assigned elsewhere deliberately, and Veeam says you may want a different server for security reasons.

Keep printed or offline copies of your recovery documents. Microsoft notes that attackers deliberately target procedures, configuration databases and network diagrams.

Bringing the backups into the room

Restoring needs more than a backup file. The NCSC says to review how far they will support the rebuild, including identity systems and trust services. Settle these in advance (our reasoning; details depend on your product):

• Backup server. Assume the existing one is compromised. Install a new one from vendor media in the quarantine zone and import the repository.
• Catalogue and configuration. If the import rebuilds the catalogue by scanning the repository, measure how long that takes. A configuration backup is a candidate like any other, and it can hold stored credentials and job settings.
• Repository access. There is no route to the old network, so move the data physically or present the storage directly to the quarantine zone, read-only where the platform allows.
• Keys. Backup encryption passwords and key-management access must be held offline and outside the affected directory.

Step 4: test the candidate in layers

No single tool can clear a backup. NIST SP 800-61 Revision 3 lists two separate outcomes: check restoration assets before use (RC.RP-03), and check restored assets afterwards for indicators of compromise (RC.RP-05). Treat them as two gates.

The table is our own synthesis.

Mount read-only. On Linux, use ro with noexec, nosuid and nodev. The mount manual warns that a read-only mount can still write to the device, since ext3 and ext4 replay the journal on a dirty filesystem. It suggests ro,noload or making the block device itself read-only:

blockdev --setro /dev/sdx1
mount -o ro,noload,noexec,nosuid,nodev /dev/sdx1 /mnt/candidate

noload belongs to ext3 and ext4. Other filesystems have their own option, so check that filesystem's manual. blockdev notes that --setro may not affect access already active on the device, so set it before mounting.

For Windows candidates, mount the exported disk read-only with Mount-DiskImage -Access ReadOnly or Mount-VHD -ReadOnly. Neither page promises that nothing else can write to the file, so work on a copy.

Scan with known signatures. ClamAV needs --recursive to walk directories. Watch the size limits: the documentation states that files over --max-filesize are skipped and assumed clean, which is the wrong assumption for a backup of database files and large archives. The Debian trixie manual gives a 100 MB default, and --alert-exceeds-max raises an alert on files over the limits instead of a silent pass. Update the signatures with freshclam first, in the clean zone.

clamscan --recursive --alert-exceeds-max=yes /mnt/candidate

Defender can scan a mounted path with a custom scan. -DisableRemediation makes the scan report without acting, and also means file exclusions are ignored and archives are scanned.

MpCmdRun.exe -Scan -ScanType 3 -File E:\candidate -DisableRemediation

Read the output, not only the exit code. Return value 0 covers both "no malware found" and "malware found and successfully remediated".

Scan for this attack. Responders will produce file names, hashes and strings from the investigation. YARA takes a rules file and a target, and -r recurses. It follows symbolic links by default, and an absolute link inside a mounted candidate resolves against the scanning host's own files, so use -N.

yara -r -N incident-rules.yar /mnt/candidate

Review persistence. Attackers commonly return through a service or scheduled task instead of the malware itself. Autorunsc can examine an offline Windows system using -z. The published usage line for v14.3 does not show the arguments -z takes, so read the tool's own help before you rely on it.

Avoid its -vs VirusTotal option, which uploads files not previously scanned. Sending incident files to a third party is the incident lead's decision.

Use vendor tooling where you have it. Veeam 13's Scan Backup can search for the last clean restore point using its Threat Hunter engine, third-party antivirus, or YARA rules. A clean result is only clean by that engine's criteria. Its Secure Restore applies a similar check at restore time, with limits that include only one antivirus product on the mount server, and no antivirus scan of Btrfs disks. The largest limit is on the Secure Restore page. Veeam "does not perform a malware scan for disks or volumes that cannot be mounted to the mount server". Its examples are Storage Spaces disks and ReFS volumes where the mount server's operating system lacks ReFS, and these are "restored in a regular way", with no scan at all. Check the job log for what was skipped. The antivirus must also be on the mount server and support a command-line interface.

Isolated test boots can use the same approach as routine restore verification. Veeam's SureBackup boots machines in an isolated virtual lab, and it also has a mode for integrity and content scanning only.

Step 5: restore in dependency order

Microsoft lists this priority order from its experience: identity systems, systems affecting human life, financial systems, product or service enablement, and minimum security systems. Microsoft says this backup list "also becomes your prioritized restore list". Its guidance is to restore the top business-critical systems first, not everything.

The NCSC adds a warning that matters to technical teams: business needs must drive prioritisation, not only IT considerations.

A planning sequence follows. Life safety and essential operational needs can override this order; incident leadership must adapt it to the dependency map and safe service requirements:

1. Clean room network, DNS, time, and logging.
2. Identity, rebuilt as in Step 6.
3. Monitoring and endpoint protection, so that the next steps are observed. Microsoft ranks "Security (minimum)" fifth, and moving it up is our choice.
4. Certificate services, secrets and key management if the applications need them.
5. Databases.
6. Application servers.
7. File data, after the attacker has been evicted.
8. End-user devices, rebuilt rather than restored where practical.

The ordering between databases and applications should come from your own dependency map. NIST's scenarios use the dependency map to determine restoration order.

Users restoring their own files is a real risk at step 7. Microsoft advises allowing it only after you are confident the attacker is evicted, and having a mitigation in place in case some malware comes back.

Step 6: treat identity as compromised

NIST explains why this comes first. If a directory is recovered but the adversary still has access to an account that manages it, they keep their access. It names service accounts with administrative rights, forgotten administrative accounts, authorised management tools with installed agents, and public key infrastructure components.

For Active Directory, full forest recovery is its own procedure and is covered in a separate article. Three points affect this plan:

• Microsoft's preferred scenario is recovering in isolation, with all writeable domain controllers shut down, so dangerous data cannot replicate back in.
• The krbtgt password is reset twice, and Microsoft says to wait 10 hours between resets, or longer if your maximum ticket lifetime has been raised. The procedure applies to writeable domain controllers, not read-only ones. If you plan to recover those, do not delete their krbtgt_<number> accounts.
• If the directory database was compromised, Microsoft says to create a new KDS root key and recreate group managed service accounts, depending on the compromise scenario. In production you wait 10 hours for the new key to become available, and the Key Distribution Service must restart on all domain controllers. Plan for both waits.

ASD's step of changing important passwords fits accounts outside the compromised directory, such as cloud storage and email, changed from a clean device. Inside the compromised directory, password resets achieve little while the attacker still has a route in. Cloud identity, federation and synchronisation accounts need the same scrutiny.

Step 7: release gates

Before anything joins production, NIST's scenarios variously describe confirmation from security staff, the incident response team and outside experts that the restored systems are free from the indicators, or not susceptible to the original weaknesses, followed by approval to restore network operations.

Turn that into a written gate per system:

• Restore point and reason recorded.
• All layers in Step 4 complete, with results kept.
• Entry point closed and patched.
• Credentials issued in the clean room only.
• Monitoring active and forwarding before connection.
• Named owner confirms the system works.

Reporting deadlines in Australia

These run alongside the technical work. This is a summary and not legal advice.

• Critical infrastructure, likely the first clock. Responsible entities must notify ASD's ACSC within 12 hours after becoming aware of a cyber security incident with a significant impact on the availability of their asset, and within 72 hours for a relevant impact.
• A ransomware or cyber extortion payment must be reported within 72 hours under section 27 of the Cyber Security Act 2024 by a reporting business entity. That covers a payment you made and one you are aware another entity made on your behalf. Section 27 starts the 72-hour period when the entity makes the payment or becomes aware that a payment was made on its behalf, whichever applies; it is not the incident-discovery clock. Confirm current obligations for the entity and incident. The form covers entities with turnover of $3 million or more and responsible entities for critical infrastructure assets under Part 2B of the Security of Critical Infrastructure Act 2018.
• Under the Notifiable Data Breaches scheme, organisations covered by the Privacy Act must notify affected individuals and the OAIC of an eligible breach likely to result in serious harm. Where you only suspect one, you must take all reasonable steps to complete an assessment within 30 calendar days of becoming aware of the grounds.
• The ASD strongly recommends not paying. It says there is no guarantee of regaining access, and that payments may contravene sanctions measures.

What to choose and why

Where you can, restore data onto freshly built systems instead of restoring whole system images. That separates content from executable state. Domain controllers are the exception. Microsoft says you shouldn't restore a system state backup to a different server, and that restoring one to a new Windows Server installation is not supported, and it points to full server backups instead. See the forest recovery article. NIST lists rebuilding systems from scratch alongside restoring from clean backups among the recovery actions.

Rehearse this before you need it. Microsoft recommends regularly testing a "Recover from Zero" scenario. The Australian Information Security Manual has ISM-1515, which requires restoration to a common point in time to be tested in disaster recovery exercises.

Risks and limits

• A clean scan proves little. It means the tools you ran found nothing. Say that plainly in status reports.
• Data can be the problem. Macros, scripts in file shares and poisoned application data can survive a rebuild.
• Restoration takes longer than expected. The NCSC says it can take considerable time. Plan bandwidth and storage for the clean room, and measure it during exercises.
• Firmware and hardware. NIST SP 800-61 Revision 3 notes that with a highly sophisticated actor whose full scope is unknown, it may be necessary to replace the hardware of compromised systems. Backup testing will not reveal that.
• Not covered: forensic acquisition method, negotiation, cyber insurance terms and Operational Technology.

Sources

Opened 2026-11-10.

• NCSC: Disruptive cyber attacks collection, What to do when cyber attacks disrupt your organisation (PDF), Mitigating malware and ransomware attacks
• NIST: SP 800-61 Revision 3, SP 800-184
• MITRE ATT&CK: T1490 Inhibit System Recovery
• Microsoft: Backup and restore plan against ransomware, Determine how to recover the forest, Reset the krbtgt password, Recover from a Golden gMSA attack, Autoruns, MpCmdRun, Mount-DiskImage, Mount-VHD
• Veeam Backup & Replication 13: How Scan Backup Works, YARA Scan for Scan Backup, Secure Restore, Antivirus scan limitations, SureBackup Job
• ClamAV scanning, clamscan manual, Debian trixie, YARA command line, mount(8), blockdev(8)
• Australia: ASD steps after a ransomware attack, ASD ransomware playbook, Report a cyber security incident, Ransomware payment reporting, OAIC Notifiable Data Breaches, OAIC data breach response, Part 4, ISM system management

This article was originally published on 10 November 2026.