Active Directory Forest Recovery After Tier-0 Compromise
A health insurer runs a single Active Directory forest with two domains, 14 domain controllers, and 38,000 users. A tier-0 admin account was compromised through token theft. The attacker created a golden ticket and modified AdminSDHolder; containment removed the host but not the directory. Available backups: DC01 (PDC emulator) from 36 hours ago, DC07 from 9 days ago, and DC12 from 2 hours ago, but DC12 was itself restored from a month-old VM snapshot. Tombstone lifetime is 180 days. Three domain-joined applications use Kerberos constrained delegation. The CISO requires a 6-hour RTO for authentication and no reintroduction of attacker persistence. The recovery team proposes restoring DC12 and forcing replication to all DCs. The incident timeline shows the first suspicious AdminSDHolder change 11 days ago, but the exact initial access is unknown.
1. Which backup, if any, is safe to restore, and why? Address the 6-hour RTO and the no-persistence requirement.
Read the worked answer
None of the listed backups is provably safe. DC01 at 36 hours is after the first suspicious change at 11 days, so it may contain attacker persistence. DC07 at 9 days is also after that change. DC12 is the most suspicious: it was restored from a month-old VM snapshot, which could predate the incident, but it has since replicated and may carry the golden ticket or AdminSDHolder changes. The 2-hour age is irrelevant if the directory state is dirty.
Reasoning: AD recovery is not a VM restore race; it is a trust problem. Restoring DC12 and forcing replication would propagate whatever is in its database to every DC, including potential backdoors. The 6-hour RTO pushes toward speed, but the no-persistence constraint dominates. The team should perform an isolated forest recovery: restore the most promising candidate (DC12) into a non-production network, run offline semantic database analysis, inspect AdminSDHolder and krbtgt metadata, and compare against known-good indicators. If validation fails and no backup predates 11 days, rebuild the forest and re-provision trusts and delegation rather than risk reintroducing the attacker. The RTO is achievable only if validation and rebuild steps are pre-scripted.
2. How should the team handle the 9-day-old DC07 and potential lingering objects if it is ever reintroduced?
Read the worked answer
DC07 is within the 180-day tombstone lifetime, so replication would not automatically reject it for being stale. That is exactly why it is dangerous: objects deleted in the last 9 days on other DCs could reappear as lingering objects when DC07 replicates inbound. If DC07 is used at all, restore it in isolation, enable strict replication consistency on all DCs, and run lingering-object removal against DC07 before it connects to production. Also check that its replication metadata and USN rollback state are intact; a VM snapshot restore can create a USN rollback that silently breaks replication.
Safer judgment: do not reintroduce DC07 into the recovered forest. Seize any FSMO roles it held, perform metadata cleanup, and rebuild it as a new DC after the forest is clean. The only reason to keep it would be to recover a recent change not present elsewhere, which must be weighed against the risk of reintroducing deleted-object state and attacker persistence.
3. What identity-resilience controls should be added after recovery to reduce the chance of a repeat?
Read the worked answer
Treat tier-0 identity as a separate security zone. Add a tier-0 admin forest or at least dedicated tier-0 domain controllers and admin workstations; prohibit tier-0 credentials from logging on to tier-1 or tier-2 hosts. Enforce just-in-time privileged access with approval and session recording, and remove standing domain admin rights. Rotate krbtgt twice after recovery, reset all privileged account passwords twice, and invalidate existing tickets. Monitor AdminSDHolder, SIDHistory, and delegation changes with alerting. Add offline, immutable backups of system state and directory partitions, and test a forest-recovery runbook at least quarterly. Finally, validate that the three Kerberos constrained delegation applications are reconfigured with least privilege and that their service accounts are not over-privileged.