Restore Active Directory after a cyberattack: build a forest recovery plan

Restoring a DC is not a forest recovery plan

Restoring the latest domain-controller VM may boot a server, but it does not prove that Active Directory is trustworthy or that the attacker is gone. Forest recovery rebuilds a trusted identity authority: choose a backup from before compromise, restore in isolation, recover at least one writable DC per domain, rotate exposed secrets, and redeploy every other DC.

Microsoft presents its procedure as a template to customize. Write the plan before an incident, including owners, dependencies, recovery passwords, eligible backups and the exact order of operations. During a cyberattack, incident response must also decide whether a restored backup is sufficiently trustworthy or whether components need clean rebuilding.

• Microsoft — Active Directory forest recovery guide ↗
• Related — Active Directory security assessment →

Classify the incident before pressing Restore

Incident response, AD, backup, networking, security and business owners should make this decision together. Record the suspected compromise time, indicators, persistence and scope. A newer backup loses less data but may reintroduce the attacker; an older backup creates more objects and changes to reconstruct.

• Microsoft — determine how and what to recover ↗

Keep the recovery dossier outside Active Directory

Microsoft recommends a custom plan and at least annual practice, plus drills after Enterprise Admins or Domain Admins membership changes. A plan that has not been exercised describes intent; a timed drill produces a credible RTO.

• Map forests, domains, trusts, sites, subnets, DNS, writable DCs and RODCs; identify FSMO, GC, PDC Emulator and time sources.
• Name a preferred recovery DC per domain, including OS, IP, encryption, location, DNS/GC roles and last successful backup.
• Keep offline copies of the plan, installers, patches, drivers, licences, approved scripts and support contacts. Do not depend on SharePoint or a vault whose access needs the failed AD.
• Store DSRM and built-in Administrator credentials for every domain in an independent vault with tested emergency access and clean recovery identities.
• Inventory Tier 0 dependencies: Entra Connect, AD CS, ADFS, NPS, PAM, gMSA, KDS, backup, hypervisor, storage, EDR, PKI, VPN and AD-dependent applications.
• Define RTO/RPO and restoration order: root domain, child domains, DNS/time/GC, identity services, priority apps and remote sites.

• Microsoft — plan and practice forest recovery ↗
• Related — hybrid Windows LAPS →

Back up two writable DCs per domain—and prove restore

Regularly back up at least two writable DCs per domain so there are multiple trust points. An RODC backup cannot restore a writable DC. A preferred candidate has a full-server backup, DNS and a current OS, can be isolated and matches a tested configuration. Microsoft says recovery to different hardware needs a planned full-server recovery; restoring system state onto a fresh Windows installation is unsupported.

DC system state includes AD DS, SYSVOL, the registry and boot files. Also retain full-server backups for bare-metal recovery, immutable or offline copies, and a protected local copy for speed. A green Success state is insufficient: record the DC, time, backup type, integrity, encryption, restore point and last full restore test.

# Run in an approved elevated context; this does not start a restore.
wbadmin get versions
wbadmin get status
Get-WinEvent -LogName 'Microsoft-Windows-Backup' -MaxEvents 30 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

• Microsoft — select a trusted backup ↗
• Microsoft — wbadmin and system state ↗
• Related — immutable Veeam backups →

Export a pre-incident PowerShell inventory

Run a periodic read-only collection from an admin workstation and export it to protected storage outside the forest. It is not a backup; it provides names, roles and dependencies when normal consoles are unavailable.

This folder contains names, addresses and security details. Encrypt it, restrict readers, retain versions and test access without production AD or networking. In a multidomain forest, query every domain explicitly rather than assuming the local domain represents all of them.

Import-Module ActiveDirectory
$Out = 'D:\AD-Recovery-Inventory'
New-Item -ItemType Directory -Path $Out -Force | Out-Null
Get-ADForest | Format-List * | Out-File "$Out\forest.txt" -Encoding utf8
Get-ADDomain | Format-List * | Out-File "$Out\domain.txt" -Encoding utf8
Get-ADDomainController -Filter * | Select-Object HostName,Domain,Site,IPv4Address,OperatingSystem,IsGlobalCatalog,IsReadOnly,OperationMasterRoles | Export-Csv "$Out\domain-controllers.csv" -NoTypeInformation -Encoding utf8
Get-ADTrust -Filter * | Select-Object Name,Source,Target,Direction,TrustType,ForestTransitive | Export-Csv "$Out\trusts.csv" -NoTypeInformation -Encoding utf8
Get-ADReplicationSite -Filter * | Select-Object Name,DistinguishedName | Export-Csv "$Out\sites.csv" -NoTypeInformation -Encoding utf8
netdom query fsmo | Out-File "$Out\fsmo.txt" -Encoding utf8
repadmin /replsummary | Out-File "$Out\replication-summary.txt" -Encoding utf8
dcdiag /e /q | Out-File "$Out\dcdiag-errors.txt" -Encoding utf8

• Microsoft — inventory forest structure and DC functions ↗

Phase 1 — Contain and build a clean recovery zone

Isolation is a security boundary, not just a lab. Microsoft prefers shutting down all writable DCs before starting the first restored DC. An isolated virtual switch can retain IP addresses and reduce DNS mistakes, but also check management interfaces and agents that might call production.

• Declare the incident, preserve evidence and establish a timeline; do not blindly alter systems needed by investigators.
• Take all writable DCs offline where possible, especially FSMO holders. A compromised old DC must never replicate into the recovered forest.
• Build a truly isolated recovery network with controlled DNS, time, consoles and media, and no route to production or compromised tooling.
• Use clean admin workstations, new secrets and crisis accounts. Treat hypervisors, backup, storage and network appliances as suspect until validated.
• Transfer only approved backups and tools; keep originals immutable and preserve hashes under the evidence process.

• Microsoft — recover the forest in isolation ↗

Phase 2 — Restore one writable DC per domain

Start with the forest root because it holds Enterprise Admins, Schema Admins and the trust hierarchy. Restore one writable DC per domain from a known-safe point. For the first DC, Microsoft calls for a nonauthoritative AD DS restore and authoritative SYSVOL restore with an AD-aware product. Incorrectly making SYSVOL primary on multiple DCs creates conflicts; use the procedure for the specific backup product and OS rather than generic commands.

Validate each restore and reject the point if data appears compromised. Restore parents before children. Once first DCs share an isolated network, recover DNS, time, replication, the Global Catalog and trusts before applications.

• Microsoft — initial recovery and domain order ↗
• Microsoft — AD DS and SYSVOL procedures ↗

Phase 3 — Regain control of identity

Do not automate this entire list. Ordering depends on replication, domains, backup state and the investigation. Rotating too early can break services; incomplete rotation leaves paths back in.

• Reset administrative accounts before redeployment: Enterprise Admins, Domain Admins, Schema Admins, operators, privileged service accounts and other exposed identities.
• Complete the krbtgt reset procedure in every domain. Two password changes invalidate old tickets; honor replication and documented waiting time instead of making two immediate resets.
• Handle gMSAs and the KDS root key according to the compromise. Microsoft notes that a compromised writable AD database can require a new KDS root key and recreated gMSAs.
• Seize FSMO roles onto restored DCs, clean metadata for every other writable DC, then handle DNS, RID, DC machine accounts and trusts following the guide.
• Plan user password resets where appropriate and revoke affected sessions, certificates, keys, application credentials and hybrid secrets.

• Microsoft — accounts, FSMO, metadata, krbtgt and gMSA ↗
• Microsoft — reset and cleanup procedures ↗

Validate before reconnecting production

No output from dcdiag /q is useful but is not permission to reconnect. Have AD, security and plan owners approve the evidence and record exceptions, commands, times and operators. Microsoft recommends new backups of every restored DC once the forest is stable.

repadmin /replsummary
repadmin /showrepl * /csv
repadmin /viewlist *
dcdiag /e /v
netdom query fsmo
nltest /dclist:ad.example.com
Get-ADDomainController -Filter * | Format-Table HostName,Site,IsGlobalCatalog,OperationMasterRoles
Get-WinEvent -LogName 'Directory Service' -MaxEvents 100 | Where-Object LevelDisplayName -in 'Error','Critical'

• Microsoft — validate replication, DNS and Global Catalog ↗

Phase 4 — Redeploy; do not power on old DCs

After old DC metadata is removed, their backups cannot be reused. Reinstall and promote clean DCs, or use supported cloning/IFM where prerequisites are understood. Restore critical sites and apps first, then branches. Once stable, place FSMO and GC roles according to the target architecture, restore normal DNS, recreate objects lost since backup and reestablish outgoing trusts that do not return automatically.

• Reconnect in waves with success criteria and stop points; do not attach every site at once.
• Re-enrol Entra Connect, AD CS, NPS, ADFS, backup, monitoring and applications with new secrets under their own recovery plans.
• Hunt persistence in GPOs, scripts, scheduled tasks, delegations, ACLs, certificates, SPNs, service accounts and hybrid configuration.
• Preserve the compromised environment for investigation where required; never treat it as trusted configuration data.

• Microsoft — redeploy remaining DCs ↗
• Microsoft — post-recovery cleanup ↗
• Related — secure AD CS →

The annual drill turns a document into a capability

Exercise in an isolated network using copies of real backups, without exposing production secrets to observers. Time the work, capture gaps, update the plan and back up the recovered lab. Test the absence of a key person and loss of the backup server. The output should be a signed report with measured RTO/RPO, residual risks, actions, owners and dates.

• Microsoft — forest recovery drill frequency ↗

Reusable checklist

Forest recovery is rarely elegant. It succeeds through a clear order, backups of known age and trust, an isolated environment, and a team that has executed the procedure before. Without those, a backup is only a recovery hypothesis.

• Before: two writable-DC backups per domain, isolated copies, tested DSRM/RID-500 access, off-forest map and inventory, current owners and contacts.
• Decision: confirmed scope, known-safe point selected with investigators, accepted data loss, clean network and accounts ready.
• Recovery: root DC first, one DC per domain, correct SYSVOL handling, privileged/krbtgt/gMSA secrets addressed, FSMO seized and metadata cleaned.
• Validation: replication, DNS, time, GC, trusts, logs, pilot access and new backups approved before production.
• Return: new clean DCs, Tier 0 services re-enrolled, hybrid secrets rotated, missing objects recreated, enhanced monitoring.
• Improvement: annual drill, measured RTO/RPO, assigned gaps, updated printed and electronic plan.