Active Directory backup: preparing a forest recovery before you need one
In a ransomware attack, Active Directory is often both the target and the prerequisite for any rebuild. Without the directory there is no authentication, and often no access to the backup console either. A forest recovery plan has to be prepared in calm conditions, and tested.
What to back up
Restoring a domain controller relies on a system state backup, which contains the NTDS database, SYSVOL, the registry and boot files. A full virtual machine backup can work if the tool handles domain controllers correctly (VM-GenerationID support in particular), but system state remains the reference in Microsoft's procedure.
- At least two domain controllers per domain backed up, ideally those holding FSMO roles.
- At least a daily backup for those domain controllers.
- Every domain in the forest, including a root domain that is often "empty" but essential.
wbadmin start systemstatebackup -backupTarget:E: -quiet
Copies the attacker cannot reach
Ransomware groups explicitly target backups. A copy reachable with an account from the compromised domain should be considered lost. You need at least one offline or immutable copy, and a backup infrastructure that does not depend on the directory it protects: local admin accounts or a separate directory, MFA on the console, a separate management network.
Tombstone lifetime
A deleted object is kept as a tombstone for the tombstone lifetime, 180 days by default in recent forests (60 days in some older forests that were never changed). A backup older than that value cannot be used for recovery: it would reintroduce objects already purged elsewhere. Check your forest's actual value (the tombstoneLifetime attribute) against your backup retention.
DSRM passwords
Restoring a domain controller goes through Directory Services Restore Mode, which uses a local administrator account specific to each DC. That password is set at promotion and then frequently forgotten. It must be known, stored in a vault outside the domain, and changed regularly with ntdsutil ("set dsrm password").
A simple question. If all your domain controllers were encrypted tonight, who knows the DSRM password, where is the latest clean backup, and which account gives access to it?
Test in isolation
Microsoft's forest recovery guide describes a long procedure: restoring one writable domain controller per domain, an authoritative SYSVOL restore, metadata cleanup of the other DCs, seizing FSMO roles, rotating the krbtgt password twice, raising the RID pool, resetting sensitive accounts. None of this can be improvised in the middle of a crisis.
A yearly test in a fully isolated network validates the backups, measures the real recovery time and keeps a written, printable procedure up to date, usable without access to the information system.
The ransomware scenario
In this scenario, the most recent backup may contain the attacker's persistence: added accounts, modified GPOs, granted replication rights. Recovery must therefore be followed by a review of sensitive objects and ACLs before any reconnection to the production network.
What an audit checks
- The age of the latest system state backup for each domain.
- The tombstone lifetime value versus backup retention.
- Independence of the backup infrastructure from the domain.
- When DSRM passwords were last changed, and whether a recovery test is documented.