Active Directory Forest Recovery Runbook Template: Restoring AD After Ransomware Step by Step

When ransomware operators have held Domain Admin, no domain controller in the forest can be trusted, and recovery fails when the team works out the restore order for the first time on the night itself. This template gives [Organisation] a fill-in runbook for recovering an Active Directory forest after ransomware or another forest-wide compromise, following the phases in Microsoft's AD Forest Recovery Guide (which covers Windows Server 2016 to 2025 and describes its own steps as a template to customise). Strategy, backup design and the choice between restore and rebuild are covered in the Identity Recovery Guide; this page is the step list with owners, checkboxes and validation evidence. It is written for directory engineers, incident managers and backup owners. Replace every [bracketed] placeholder and rehearse it in an isolated lab at least once a year.

How to use this template

• Fill it in before an incident: the domain list, the chosen restore DC per domain, backup locations and DSRM password vault entries in section 6.2 must be completed and printed. If the forest is encrypted you will not be able to look them up.
• Run it under the main incident plan: declare the incident under the Ransomware Playbook Template or Active Directory Domain Compromise Response Playbook, then hand the forest workstream to the Directory Recovery Lead using sections 3 to 6.
• Keep the order: Microsoft's procedure starts in the forest root domain and recovers parent domains before children. Skipping ahead (for example adding DCs before the krbtgt reset) undoes the security value of the recovery.
• Record evidence as you go: every step in section 6 has an evidence column. The post-incident review and any insurer or regulator will ask for it.
• Owner and review: [Head of Identity], reviewed every [12] months, after each lab rehearsal and after any change to domain count, DC operating system or backup product.

1. Scope and triggers

1.1 This runbook covers recovery of the [forest name] Active Directory forest, comprising [list domains], when the directory itself cannot be trusted or used. Recovery of a single domain controller, a single deleted object or Microsoft Entra ID configuration is out of scope; use [normal restore procedure] and the IdP configuration backup and restore guidance.

1.2 Triggers. Microsoft lists the kinds of forest-wide failure that justify forest recovery. Any one of the following, confirmed by the Directory Recovery Lead, opens this runbook:

1.3 Exposure without modification. Microsoft notes that if a DC or its backup was exposed but the leaked credentials were not used to change AD data, a full restore may not be needed; resetting passwords for users, computers, trusts and (g)MSA accounts may be enough. The Incident Manager records which path was chosen and why.

2. Roles and contacts

2.1 Decision rights. Only the Incident Manager can authorise reconnecting any restored DC to a production network. Domain Recovery Owners may stop a restore and select an older backup without escalation.

2.2 Communications. Assume email, Teams and any AD-integrated chat are compromised or down. Use [out-of-band bridge, Signal group, phone tree]. CISA's ransomware guidance recommends out-of-band communication, such as phone calls, during response.

3. Detection and triage

1. Confirm the trigger from section 1.2 and record the time, the evidence and who confirmed it.
2. Establish the compromise window: the Forensic Lead gives the earliest confirmed attacker activity on any Tier 0 system. Backups from after that time are suspect.
3. Inventory DCs and backups: for each domain, list every DC, its roles (FSMO, global catalog, DNS), its state (running, encrypted, unknown) and the newest backup taken before the compromise window.
4. Check backup age against tombstone lifetime: a backup older than the forest's tombstone lifetime ([value, commonly 180 days]) must not be used.
5. Decide restore or rebuild with the Incident Manager, using the criteria in the Identity Recovery Guide, and record the decision.

4. Containment

1. Isolate all DCs: disconnect every existing DC from the network (or shut down virtual DCs after the Forensic Lead captures memory and disk where required). A surviving compromised DC replicating into the restored forest reintroduces the attacker.
2. Cut trust paths: disable external and forest trusts at the partner side where possible, and stop Microsoft Entra Connect or Cloud Sync servers so compromised objects and passwords do not sync to the cloud.
3. Preserve evidence: keep at least one compromised DC image and its security, Directory Service and System logs for the investigation.
4. Build the recovery network: an isolated segment with no route to production, a clean admin workstation built from known-good media, and access to the backup repository only.

5. Eradication

5.1 Eradication in a forest recovery is mostly credential work, done on the restored DC before any other DC joins. Microsoft states that when an attack is suspected the administrative and krbtgt resets must happen before additional DCs are installed. The checklist in section 6.3 carries those steps.

5.2 Remove persistence found by the investigation from the restored database: unknown members of Domain Admins, Enterprise Admins, Schema Admins and Administrators; rogue Group Policy Objects or scheduled tasks; unexpected AdminSDHolder permissions; unknown service principal names or delegation settings. See the Golden Ticket, Silver Ticket and DCSync Guide.

5.3 Non-human credentials: list every service account, gMSA, trust and integration account whose secret lived in the directory, and schedule its rotation (section 6.4). See the Recovering IAM and PAM After Ransomware or Domain Compromise guide.

6. Recovery

6.1 Order. Forest root domain first, then each child domain in parent-to-child order: [Root domain] then [Child 1] then [Child 2].

6.2 Pre-filled restore plan (complete before an incident):

6.3 First writable DC in each domain. Steps follow Microsoft's "Perform initial recovery" procedure. Tick and record evidence for each:

6.4 Reconnect and expand. Connect the restored DCs to each other on the isolated network and verify replication. Add the global catalog to a forest root DC and confirm event ID 1119 in the Directory Service log, or HKLM\System\CurrentControlSet\Services\NTDS\Parameters "Global Catalog Promotion Complete" = 1. Take a new backup of each restored DC. Then build additional DCs as fresh promotions from clean media, reset "Perform Initial Synchronizations" to 1 once the forest is fully recovered, and rotate the service and integration credentials listed in 5.3.

6.5 Go and no-go gate before production reconnection (Incident Manager signs):

• [ ] Replication healthy across all restored DCs, no lingering object warnings
• [ ] Privileged group membership matches the approved list in [reference]
• [ ] krbtgt reset twice in every domain; trust passwords reset
• [ ] Tier 0 admin workstations rebuilt; old DCs and admin hosts remain disconnected
• [ ] Monitoring live on all DCs (security log forwarding, identity threat detection)
• [ ] Entra Connect or Cloud Sync rebuilt from clean media with new credentials before resuming sync

7. Communication and notification

1. Internal: status every [2] hours to the executive bridge with current phase, next gate and expected time to authentication for [critical services list].
2. Users: scripted message on password resets and when to expect sign-in, issued through [out-of-band channel]. Warn that attackers often exploit reset periods with phishing.
3. Regulators and law enforcement: the Privacy Lead assesses whether personal data was affected (for example the GDPR Article 33 72-hour notification) and the Incident Manager reports to [national CERT, police, CISA or NCSC as applicable].
4. Insurer and partners: notify [insurer hotline] and partners whose trusts were reset.

8. Post-incident review

• Timeline: time from trigger to first restored DC, to production reconnection and to full service.
• Backup quality: how many backups were rejected and why (compromised, damaged, beyond tombstone lifetime).
• Root cause and gaps: how Tier 0 was reached, and which tiering, monitoring or backup isolation control would have stopped it. See the Tiered Administration and Enterprise Access Model Guide.
• Runbook changes: update this template, the restore plan in 6.2 and the rehearsal schedule within [30] days.

Implementation guidance

Prepare the prerequisites. Keep at least two recent system state or full server backups of one writable DC per domain, stored where domain credentials cannot delete them. See the Backup Identity Isolation Guide. Store the DSRM password for each restore DC in an offline vault, and record the tombstone lifetime and RID consumption rate.

Rehearse in an isolated lab. Restore the root domain DC from production backups into a fenced network once a year and time each step. Microsoft's human-operated ransomware guidance stresses verifying backups through a restore exercise; a backup never restored is an assumption.

Small versus large forests. A single-domain forest skips the global catalog removal and child-domain steps and can often finish the first DC in hours. Multi-domain forests need one Domain Recovery Owner per domain working in parent-to-child order, and the RID and GC steps matter more.

Framework mapping. NIST SP 800-53 CP-9 System Backup, CP-10 System Recovery and Reconstitution and IR-4 Incident Handling; NIST CSF 2.0 RC.RP-01 (recovery plan executed), RC.RP-03 (backup integrity verified before restoration), RS.MI-02 (incidents eradicated) and PR.DS-11 (backups created, protected and tested); ISO/IEC 27001:2022 Annex A 5.29 Information security during disruption and 8.13 Information backup.

References. Microsoft: Active Directory Forest Recovery Guide · Microsoft: AD Forest Recovery, Perform initial recovery · Microsoft: Reset the krbtgt password · Microsoft: Human-operated ransomware · CISA: #StopRansomware Guide · NIST: SP 800-184 Guide for Cybersecurity Event Recovery

Related NHI Mgmt Group resources: Identity Recovery Guide · Active Directory Domain Compromise Response Playbook · krbtgt account · Recovering IAM and PAM After Ransomware or Domain Compromise · Ransomware Playbook Template