Recovering a Domain After Ransomware Encrypts a DC

A full forest recovery is not automatically required - but it depends on whether DC2 holds clean, authoritative data.

DC2 was offline and has not replicated since Monday 18:00, which is before the Tuesday 02:00 encryption. That means DC2's database does not contain any changes the ransomware made to AD (if it made any). If the compromise was limited to file encryption on DC1/DC3 and did not alter AD objects, DC2 is a clean survivor and can be promoted as the authoritative source: seize the FSMO roles (especially PDC emulator, RID master, and Infrastructure master) to DC2, metadata-clean DC1 and DC3, then rebuild them and let them replicate from DC2. That is a domain/DC recovery, not a forest recovery, and fits the 4-hour window.

A forest recovery becomes mandatory if: DC2 is also suspect (e.g., it received malicious changes before going offline), the schema or configuration partition was altered, or no clean DC exists. In that case you restore the Sunday offsite System State to an isolated DC, set it authoritative, and rebuild the forest.

Decision rule: verify DC2's replication watermark and check for unauthorized AD changes; if clean, recover to DC2. If not, forest recovery from the Sunday offsite copy - which costs the Monday changes but is the only trustworthy baseline.

Ordered steps.

1. Isolate DC2 from the compromised network; confirm it is clean (check for rogue accounts, GPO changes, SYSVOL modifications).
2. On DC2, seize FSMO roles with ntdsutil → roles → seize (PDC, RID, Infrastructure, Schema, Domain Naming).
3. Metadata-clean DC1 and DC3 (ntdsutil → metadata cleanup), and remove their DNS records and replication links.
4. Reset the krbtgt password twice (two resets, separated by at least one replication cycle) to invalidate any Kerberos tickets the attacker may hold.
5. Rebuild DC1 and DC3 from clean media, join, promote, and verify replication and SYSVOL.
6. Restore business data from clean backups; rotate privileged credentials.

Risk of the Tuesday 23:00 tape. That backup was taken after the 02:00 encryption, so it likely contains the compromised state - restored DCs would reintroduce the attacker's persistence. It also lacks Monday's changes, so it is both less current and less trustworthy. The Sunday offsite copy predates the incident and is the safe baseline; the Tuesday tape should be treated as evidence, not a restore source.

Close the gaps that made recovery slow and uncertain.

• Add a clean, isolated DC. A DC that is offline or in a protected segment (not reachable from production) gives a known-good authoritative source without a restore. This alone can cut recovery to minutes.
• Shorten and verify backups. Daily 23:00 System State is fine, but the offsite copy is weekly (Sunday). Increase offsite frequency to daily and test restores quarterly - an untested backup is a hope, not a control.
• Protect the backup path. The Tuesday tape was written after encryption began, meaning the backup system was reachable from the compromised network. Put backups on immutable/offline storage and separate credentials so ransomware cannot overwrite them.
• Document and rehearse the forest-recovery plan. The 4-hour target fails on process time, not technology: seizing roles, cleaning metadata, and double-resetting krbtgt must be practiced.
• Monitor for AD changes. Alert on new Domain Admin accounts, GPO modifications, and krbtgt resets so tampering is caught before it becomes a recovery event.