The recovery directory
The problem nothing else solves
After a domain compromise the organisation may hold clean backups. What it no longer holds is trusted identity: every account, certificate and token may have been tampered with.
Restoring data into a domain whose access you no longer control amounts to reopening the door. That is why rebuilding is counted in weeks, not hours.
Three components to prepare in advance
An isolated recovery directory. A separate forest or domain, administered with distinct accounts, with no trust relationship to production. It is useless day to day — which is precisely what makes it usable after compromise.
An offline certificate authority. Or, failing that, a documented procedure for reissuing certificates from an unexposed root.
A set of break-glass accounts. Physically recorded, outside the information system, with an escrow and rotation procedure. Their use must be detectable: a break-glass access outside a crisis is itself an incident.
The rebuild sequence
- Isolate the compromised domain, without destroying it — it holds the evidence.
- Establish a trusted foundation: recovery directory, PKI, secrets management.
- Restore the data from a backup predating the initial compromise.
- Reintegrate systems one by one, with verification before each connection.
- Reopen access progressively, watching for persistence signals.
Each step has a verification criterion. Skipping step 2 fails everything after it.
What can be tested
An annual partial rebuild exercise — one service, end to end, from a recovery directory — costs two days and systematically reveals at least one circular dependency nobody had seen.
Key takeaways
- Without trusted identity, no restoration can be validated
- A recovery directory is administered outside the production domain
- The rebuild is documented and tested like a failover