After forty days of domain-admin access, do you restore the domain controllers or rebuild the forest?

## What you are actually trying to recover The instinct is to think of this as a server-recovery problem: controllers were compromised, restore or rebuild the controllers. That framing misses the point. Domain controllers are replaceable in an afternoon. What you cannot easily replace is confidence in the *contents* of the directory — who is in which privileged group, who holds which permissions on which objects, which accounts exist, what delegation is configured, what group policy applies where, and which certificate templates can issue what. Someone holding domain-level privilege for forty days had write access to all of that, and to the controllers that record changes to it. So the real question is: can you still make a defensible statement about the privileged object graph? ## Three options, not two **Remediate in place.** Enumerate every privileged object and compare it against a known-good reference: membership of the administrative groups, permissions on those groups and on the objects that protect them, delegation and rights on the directory root and on the controllers themselves, group policy objects linked at sensitive scopes, service accounts with elevated rights, accounts with unusual attributes or unexplained creation dates, and certificate templates and their enrolment permissions. Fix every difference. This is by far the cheapest option and it is defensible only if you can bound what they touched from evidence they could not curate — which, given they controlled the controllers, is a strong claim to make. It is most often the right call when the privilege window was short, well-instrumented, and corroborated by telemetry the intruder did not own. **Forest recovery.** Restore a single writable controller per domain from a system state backup predating initial access, in an isolated network; clean up the metadata of every controller you did not restore; then rebuild the remaining controllers by promoting fresh installations rather than by restoring more backups. This returns the directory to a state you can date. Its cost is that it also discards every legitimate change since that date — new employees, new machine accounts, group policy work, application service accounts — and much of that must be reconstructed by hand. It also depends on having a system state backup old enough and reachable enough to be trustworthy, which is exactly the question the backup platform's own trustworthiness decides. **Clean-source rebuild.** Stand up a new forest from installation media, build the tiered administration model properly this time, and migrate accounts, workstations and application trust into it with new credentials. Nothing is inherited, so nothing needs to be vouched for. The cost is measured in months and in every application that has a hard dependency on the old identity domain. Organisations choose it when the old directory's history is genuinely unknowable, or when the pre-incident administrative model was so flat that restoring it would just restore the conditions for the next intrusion. ## The tiered model is part of the recovery, not a follow-up A recurring finding in these incidents is that the estate had no working separation between administering the directory and administering ordinary workstations — the same accounts, or accounts whose credentials landed on the same machines. That is usually *how* forty days of domain privilege happened. Restoring the directory without changing that returns you to the pre-incident state, which is the state that failed. The governing idea is the clean source principle: a system's security depends on the security of everything that controls it, so a rebuilt, trusted directory must not be administered from, or built by, machines you have not also rebuilt. That constrains the recovery order — administrative workstations and the management plane come back before anything they will manage. ## The certificate authority is a separate decision A point that catches people out: restoring or rebuilding the directory does nothing to certificates an enterprise certificate authority already issued. If the CA was in reach, an intruder may hold certificates that authenticate as privileged accounts, or may have altered a template so they can obtain more. Those certificates remain valid until they expire or are revoked, and they do not care that the directory was rolled back. So the CA gets its own assessment: was its key material reachable, what was issued during the window, does the CA come with you or get rebuilt, and what has to be revoked or re-issued. ## How to argue the choice in an interview A strong answer does four things. It states that the object is the directory's contents, not the servers. It names the evidence that would let you bound the changes, and admits that the intruder's privilege undermines that evidence. It prices the options honestly — in-place remediation is hours to days but rests on a claim you may not be able to defend; forest recovery is days and costs the legitimate delta; clean-source rebuild is months and costs migration. And it treats the administrative model and the certificate authority as parts of the decision rather than as separate projects, because both determine whether the recovered directory is actually a clean one.