Domain controller recovery after ransomware: backups, forest recovery and restore order

How to recover domain controllers after ransomware

After ransomware, the directory service comes back before anything else, because most servers, applications and administrator sign-ins depend on it. Restore one writable domain controller per domain from a backup taken before the compromise, inside an isolated recovery environment. Reset the administrative passwords and the Kerberos ticket-granting account (krbtgt) there, before any further domain controller is installed. The other domain controllers are then installed fresh and replicate from the restored one; their old backups are not reused.

CISA’s #StopRansomware Guide (September 2023) warns that “Malicious actors often target and use DCs as a staging point to spread ransomware network wide.” The directory vendor’s forest recovery guide describes the mechanics, but states that it “doesn’t cover security recommendations for how to recover a forest that has been hacked or compromised”. After ransomware, the restore point therefore comes from the investigation’s timeline, the restored directory stays isolated until the attacker’s footholds are removed, and every secret the attacker may hold is reset. The order of work across the whole incident is in our guide to the first 72 hours of ransomware recovery; this guide covers the directory.

Backing up domain controllers for a forest recovery

The vendor’s forest recovery guide (page updated 10 July 2023) advises: “Back up at least two writeable DCs for each domain regularly so you have multiple backups to choose from.” The domain controller you plan to restore first must be writable, and the guide prefers one that runs DNS for the forest and domain zones, holds the global catalogue and has a good full server backup. A backup of a read-only domain controller cannot restore a writable one. The guide’s FAQ (22 October 2025) recommends full backups, which allow both a bare-metal and a system state restore.

The tombstone lifetime limits how old a usable backup can be. The vendor’s backup guidance (2 December 2025) says the backup age must not exceed it and gives 180 days as the default; read the configured value from the directory rather than assuming it. With the directory’s recycle bin enabled, the forest recovery guide sets the backup lifetime to the deleted object lifetime or the tombstone lifetime, whichever is less. Veeam’s KB2226 puts it the same way: “the useful life of a backup is equivalent to the tombstone lifetime setting for the enterprise.”

For domain controllers backed up at image level, Veeam’s KB2119 (modified 14 April 2026) explains that with application-aware processing enabled, the restored domain controller first boots into Directory Services Restore Mode (DSRM) and comes back non-authoritative. The KB covers vSphere VMs and physical servers, not VMs on the directory vendor’s own hypervisor, where the boot procedure is not changed. To sign in to that mode, keep the DSRM and administrator password history in a safe place, which the vendor advises for as long as the backups are valid.

A domain controller backup holds the password data of every account in the domain. For the case where such a backup “has been exposed to an external party”, the vendor’s guide lists resetting the passwords of users, computers, trusts and managed service accounts. The backup server and its repositories therefore belong in tier 0, as our guide to privileged access management sets out. Veeam’s best practice guide ranks a management domain or workgroup above the production domain for backup components and states that “a data protection system should not rely on the environment it is meant to protect in any way!”

The directory vendor’s forest recovery guide (10 July 2023 to 22 October 2025) and backup guidance (2 December 2025); Veeam KB2119 and KB2226; Veeam best practice guide; CISA #StopRansomware Guide (September 2023).

Our cyber resilience service sets up Veeam-based backup and runs regular test restores to verify backup integrity. Tell us how many domains and writable domain controllers you run and which of them are in a backup job today.

Choosing a restore point from before the compromise

The vendor recommends restoring “by using backups that were taken a few days before the occurrence of the failure” and describes the trade-off: a more recent backup recovers more data but “might increase the risk of reintroducing dangerous data into the restored forest.” After ransomware, the failure that counts is the start of the intrusion, which can lie well before the encryption. Where the time is unknown, the guide asks you to investigate further and identify backups that hold the last safe state of the forest.

The investigation supplies the cut-off: when the first account was compromised and when administrative group memberships, policy objects or delegations first changed. The vendor’s FAQ names its database mounting tool as a way to choose the backup to restore; the tool’s step-by-step guide says it opens a backup’s directory database read-only by default and can show several snapshots side by side. Comparing administrative group members, recently created accounts and changed policy objects across several restore points shows which one predates the attacker’s changes. Our guide to the isolated recovery environment covers where such comparisons run safely.

If no restore point inside the tombstone lifetime is clean, the alternative is a new forest, with accounts, groups and permissions recreated and every server and workstation joined again, a migration project of its own.

Authoritative and non-authoritative restore

The vendor’s backup guidance defines both modes. In a non-authoritative restore the domain controller receives updates from the others after recovery, and the guidance says that “For most scenarios, including rebuilding a domain controller, you should perform a nonauthoritative restore.” An authoritative restore replaces the data on all other domain controllers and recovers deleted objects while the rest of the domain keeps running.

The directory vendor’s backup guidance (2 December 2025) and forest recovery guide (initial recovery, 10 July 2023; redeploying DCs, 12 May 2025); Veeam KB2119.

In a forest recovery, the guide states that the first writable domain controller of each domain needs a non-authoritative restore of the directory and an authoritative restore of SYSVOL. Veeam’s default restore covers only the first part. For the case where all domain controllers are lost, KB2119 says “you must perform an authoritative restore” of SYSVOL on the first restored one and gives the steps for both SYSVOL replication methods. An authoritative restore of objects is done afterwards from DSRM with the vendor’s command-line tool. When every domain controller was compromised, the first restored one is the only copy left, so in our reading authoritative object restores play no part in the ransomware case.

Forest recovery order in the isolated environment

The steps below follow the vendor’s initial recovery procedure for the forest root domain. The vendor prefers to shut down all writable domain controllers before the first restored one goes into production.

1. Restore the first writable domain controller of the forest root domain from the chosen restore point into the isolated network, and verify its data; if the data is damaged, repeat with a different backup.
2. Reset the passwords of all administrative accounts, and plan user password resets if user accounts were compromised; the vendor completes the administrative resets before further domain controllers are installed.
3. Seize all operations master (FSMO) roles, clean up the metadata of every other writable domain controller in the domain and point the restored server’s DNS client at itself.
4. Raise the available RID pool by 100,000, so that no domain controller hands out a RID already used by an account created after the backup, and invalidate the current RID pool.
5. Reset the domain controller’s computer account password twice, reset the krbtgt password twice and, as the guide allows after a security breach, the trust passwords.
6. Re-create managed service accounts with a new root key where the database was compromised, as the guide advises.
7. Recover the other domains with the same steps, a parent domain always before its child.
8. Validate replication between the restored domain controllers on a common isolated network, then install the remaining domain controllers fresh, by promotion or cloning, and rebuild read-only domain controllers.

The vendor’s virtualisation chapter (1 November 2024) notes that cloning needs a hypervisor that supports VM-GenerationID. Install directory and DNS only on the new servers, since CISA’s guide asks for minimal software or agents on domain controllers.

Resetting secrets and removing attacker persistence

The krbtgt account’s password history holds two passwords. The vendor’s procedure (22 May 2025) says “You should perform this operation twice” and “You must wait 10 hours between password resets”, the default maximum lifetime of user and service tickets; with longer configured lifetimes, the wait grows to match. After the second reset, no key from before the recovery remains valid, and the recovery plan has to allow for the interval.

Resets do not remove what the attacker built into the directory. Accounts created in the intrusion, added memberships of administrative groups, changed policy objects that push scripts or scheduled tasks, new delegations and changed permissions on administrative objects all come back with a restore that contains them. CISA’s guide advises auditing the directory for excessive privileges on accounts and group memberships; on the restored domain controller, compare these items with the investigation’s findings and a pre-incident export before reconnecting. Hypervisors that host domain controllers need hardening of their own, as our guide to ESXi ransomware hardening describes.

Testing domain controller recovery before an incident

The vendor’s guide says: “You should practice your forest recovery plan at least once a year.” Its FAQ asks for practice in a simulated test environment of reasonable size, and the guide also suggests a drill when membership of the forest-wide or domain-wide administrator groups changes.

As an example, take a company of 1,500 staff with one forest, one domain, four writable domain controllers in two data centres and about 700 VMs. DC1 holds the operations master roles, DNS and the global catalogue, and DC2 runs DNS and the global catalogue. Both are in daily backup jobs with application-aware processing, with restore points reaching back 30 days plus monthly ones up to 150 days, inside a configured tombstone lifetime of 180 days. The yearly test restores DC1 into the isolated network, runs steps 1 to 8 with a test krbtgt reset, promotes one fresh domain controller from it and signs in to a restored application server. Each step’s time goes into the disaster recovery runbook, and the recovery of every system that depends on the directory can start only after this sequence.

Our disaster recovery service runs scheduled failover tests in an isolated environment, with a report after each one on what came up, how fast and what to fix. Describe how you would restore your forest today in the form below.

What we do

Under Cyber Resilience, our engineering partner Vixen.UNO audits infrastructure, access and backups and delivers a risk map and a prioritised action plan. The same service sets up Veeam-based backup with a recovery site in Baltneta’s Tier-3 data centres in Lithuania, checked by regular test restores, and writes the incident response plan with roles, actions and deadlines. Our disaster recovery service adds Veeam replication and scheduled failover tests in an isolated environment for systems that must run from a second site. Eurokommerz holds the contract; the first call is free of charge, and the price of the technical assessment is fixed before work begins. An active incident is handled separately; mention it when you write.

FAQ