Can You Recover From Ransomware Without Trusting the Compromised Environment?

Yes, but only if you built the means to do it before the incident. Recovery that depends on the compromised environment’s identity, network, hypervisors or backup platform inherits the attacker’s access. Recovery that runs in its own trust domain does not.

This guide sets out how to design that separate domain: what to separate, how to sequence the rebuild, and where the real trade-offs sit. It covers a typical enterprise estate of directory-based identity, virtualized servers, cloud workloads and a central backup platform. It is not product-specific.

Why trust is the problem

Backups are necessary and not sufficient. Mandiant’s latest M-Trends describes attackers who map backup storage and delete backup objects in cloud and local systems, unlink virtualization environments from backup platforms, and encrypt local recovery points. It also describes ransomware moving down the stack to encrypt hypervisor datastores, which can lock every server on a host at once, and attackers cloning virtual disks to extract the Active Directory database without touching the guest operating system. In some cases, M-Trends reports, attackers locked defenders out of their own emergency accounts during the crisis.

Each of these attacks the recovery path rather than the production workload. If the restore needs the same directory, the same hypervisor management plane and the same backup console, the attacker already holds the controls.

CISA’s guidance states the consequence: avoid reinfection during recovery, and add only verified clean systems to the recovery network.

Design principle

The recovery environment must not depend on anything in the compromised environment until that thing has been rebuilt or proven clean. That includes the obvious dependencies (identity, network, management plane, backup catalog) and the quiet ones (administrator workstations, DNS, encryption keys, and the channels the team uses to talk).

Trust boundaries

DEPENDENCY	WHY IT CANNOT BE ASSUMED CLEAN	DESIGN REQUIREMENT
Identity	Directory and administrator credentials are the main prize. M-Trends reports attackers locking defenders out of their own emergency accounts. Microsoft’s forest recovery guidance calls for resetting the krbtgt password twice during recovery.	A recovery identity path that does not rely on production directory services. Break-glass accounts held offline and tested. A documented plan to restore identity first.
Backup platform and catalog	Backup servers are an attack target. Recovery points can be deleted or unlinked.	Separate credentials and control plane for backups. At least one copy that production credentials cannot alter or delete. A catalog that can be recovered without production.
Hypervisors and management plane	Encrypted datastores take down all guests on a host. The management plane controls every virtual machine.	Management plane administered from a separate identity. A plan to rebuild hosts, not repair them.
Network and DNS	Reconnecting recovered systems to a flat network lets persistence move back in.	A recovery network with admission by verification only, as CISA advises.
Images and build templates	CISA advises rebuilding from pre-configured standard images and infrastructure-as-code templates. Both are useless if they were altered.	Images and templates stored in the vault, versioned and integrity-checked, outside production.
Administrator endpoints	Field judgment: an endpoint that was used for privileged work before the incident may hold harvested credentials.	Clean privileged workstations reserved for recovery operators.
Encryption keys	CISA lists updating customer-managed encryption keys as part of post-rebuild hardening. Recovery fails if the key material is unavailable or untrusted.	Key custody independent of the production identity. Rotation steps included in the recovery runbook.
Coordination channels	CISA advises out-of-band communication because attackers may be watching.	A communications path and a contact list that exist outside the primary environment.

Reference architecture

The design uses three zones and one gate. Production is treated as untrusted. The vault holds what recovery needs. The enclave is where recovery happens, and nothing returns to production without passing validation.

Figure: Recovery runs in an enclave fed by an isolated vault. Production is not trusted until validated.

Isolated backup vault. Holds immutable data copies, clean images and build templates, key material and runbooks. It has its own credentials and its own control plane. Field judgment: immutability should be enforced by the storage layer, not by permissions in the backup software that production credentials could change.
Recovery enclave. A network and management domain built and validated outside production. Identity is restored here first. Systems are admitted only after verification.
Out-of-band layer. Break-glass access, clean privileged workstations and separate communications. It must work when the primary environment does not.

Recovery sequence and gates

Each stage ends in a gate. The next stage starts only when the gate passes.

STAGE	WHAT HAPPENS	GATE TO PASS
0. Enter recovery mode	Evidence from affected systems is preserved. Scope of the intrusion is established well enough to choose restore points.	Evidence captured. Earliest credible intrusion time estimated.
1. Stand up the enclave	Recovery network, clean administrator workstations and the out-of-band channel are brought up.	Operators authenticate without any production dependency.
2. Restore identity	Directory services are restored first, in isolation.	Identity is validated in the enclave before any other system joins it.
3. Rebuild core services	DNS, management and backup services are rebuilt from clean images and templates.	Each service built from verified sources. Hosts reached through the enclave only.
4. Restore workloads and data	Applications and data are restored in business-priority order, as CISA advises.	Restored systems scanned and checked before admission.
5. Reconnect and monitor	Systems rejoin production in stages under heightened monitoring.	Closure criteria met. Incident declared over by the designated authority.

Restoring identity

Microsoft’s Active Directory forest recovery guidance is written for forest-wide failure, and it maps well onto ransomware cases where identity is untrusted. Treat the following as adapted, not as ransomware-specific Microsoft advice.

Recovering a forest means restoring at least one domain controller in every domain from backup. Recover the forest root first, and a parent domain before a child.
The restored domain controller needs a database that was not influenced by whatever caused the failure. Keep it off the production network until it is restored and verified, and shut down the other writable domain controllers first.
Reset the krbtgt password twice, because its history holds two passwords. Complete administrator password resets before installing additional domain controllers.
If user accounts may be compromised, plan a password reset for all users in the domain. If the database of a writable domain controller was compromised, create a new KDS root key and recreate group managed service accounts. Trust passwords may also need resetting after a security breach.
Perform the authoritative SYSVOL restore only on the first domain controller in the forest root. Doing it elsewhere causes replication conflicts.

Choosing the restore point

Microsoft recommends restoring from backups taken a few days before the failure, and states the trade-off directly: a more recent backup recovers more data and raises the risk of reintroducing dangerous data. If the failure time is unknown, it says to investigate further to find the last safe state, and calls that the less desirable case.

Ransomware makes the unknown case common. Mandiant reports a global median dwell time of 14 days across the intrusions it investigated. That figure covers all investigated intrusions, not only ransomware, so it is a reference point and not a prediction. It still shows that “a few days before” may fall inside an active compromise. Analysis, not instinct, should set the restore point. Keep several restore points, and mount them for inspection before choosing, as Microsoft’s tooling for browsing backup data allows.

Decisions and trade-offs

DECISION	OPTION A	OPTION B	JUDGMENT
Enclave readiness	Standing minimal enclave for identity and core services	Build on demand at incident time	Field judgment: keep the identity and management tier ready, and build the rest on demand. Standing cost is lower than a long outage of trust-critical services.
Host restoration	Restore the operating system from backup	Rebuild from clean image, restore data only	Rebuild for identity, management and backup hosts. Data-only restore limits what returns.
Restore point	Most recent backup	Older, verified-clean backup	Choose by evidence of intrusion start, not convenience. Accept data loss where the later copy cannot be shown clean.
Backup administration	Same identity as production	Separate identity and control plane	Separate. Shared identity makes the vault part of the blast radius.
Admission to production	Fast reconnection by priority	Staged admission after validation	Staged. CISA advises adding only verified clean systems.

Failure modes to design out

Restoring a backup that already contains the attacker’s persistence.
A recovery runbook that assumes single sign-on, DNS or the backup console are available.
A backup catalog stored only inside the environment it protects.
A management plane that is still compromised when guests are restored onto it.
Restoring a global catalog from a newer backup than other domain controllers, which can introduce lingering objects. Microsoft advises disabling the global catalog soon after the restore.
Key material that cannot be retrieved, or that was exposed during the incident.
A design that has never been exercised end to end.

Testing the design

NIST SP 800-184 sets out the discipline: build recovery planning into risk management, prioritize resources, develop playbooks, and test against realistic scenarios with metrics. Apply that to the points above. Rehearse an isolated identity restore. Measure how long it takes to produce a trusted domain controller, and how long to reach the first business-critical service. Confirm that recovery operators can sign in with no production dependency. Check that the vault copy survives a deletion attempt using production credentials.

NIST IR 8374 Rev. 1 maps ransomware outcomes to CSF 2.0, including recovery, and can serve as the checklist for readiness. Test results from these exercises are what turn a diagram into a capability.

NEXT STEP

Walk your recovery plan through the trust boundaries above and mark every dependency that sits inside production.

Sources

Google Cloud, Mandiant M-Trends (latest edition, executive edition). https://cloud.google.com/security/resources/m-trends-executive-edition
CISA and partners, #StopRansomware Guide. https://www.cisa.gov/stopransomware/ransomware-guide
Microsoft Learn, Active Directory Forest Recovery Guide. https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-guide
Microsoft Learn, AD Forest Recovery: Determine how to recover. https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-determine-how-to-recover
Microsoft Learn, AD Forest Recovery: Perform initial recovery. https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-perform-initial-recovery
NIST, SP 800-184: Guide for Cybersecurity Event Recovery. https://csrc.nist.gov/pubs/sp/800/184/final
NIST, IR 8374 Rev. 1: Ransomware Risk Management, A Cybersecurity Framework 2.0 Community Profile. https://csrc.nist.gov/pubs/ir/8374/r1/final

Can You Recover From Ransomware Without Trusting the Compromised Environment?

Why trust is the problem

Design principle

Trust boundaries

Reference architecture

Recovery sequence and gates

Restoring identity

Choosing the restore point

Decisions and trade-offs

Failure modes to design out

Testing the design

Sources

Ransomware Recovery

Keep reading

Playbook: Testing Ransomware Recovery

Ransomware Response Is More Than Malware Removal

Recovery Testing: Proving That Backups Are Actually Recoverable

Threat Intelligence Brief: Ransomware Operating Patterns