The first priority is to assume the environment is no longer trustworthy and move to a full rebuild path, not a simple cleanup. If domain admin rights are in attacker hands, they can hide, persist, and move anywhere in the forest. Recovery planning should treat the directory as poisoned, with restoration from a known clean baseline and a deliberate reestablishment of trust relationships.
Why the First Move Is Rebuild, Not Cleanup
When domain admin access is confirmed or strongly suspected, the directory must be treated as compromised at the trust layer, not just at the account layer. The practical consequence is that routine remediation, password resets, and ad hoc hunting are insufficient on their own. The first organizational decision is whether recovery will follow a controlled rebuild path, with a clean trust root and staged restoration, or whether the team will keep operating on assumptions the attacker may already control.
A compromised domain admin position can alter group membership, delegation, replication trust, service account behavior, and recovery tooling itself. In other words, the blast radius is not limited to one account. For that reason, Active Directory and Entra ID hardening guidance is most useful here as a reminder of how deeply privileged relationships shape the rebuild plan, especially where tiering, privileged groups, and hybrid trust paths are involved.
A rebuild-first stance also helps avoid a common failure mode: partial cleanup that leaves attacker persistence hidden in Group Policy, replication artifacts, delegated admin paths, certificate services, or forgotten admin equivalents. The goal is not to “make the directory look clean,” but to re-establish a trust base that can actually be defended and verified.
What a Clean Recovery Path Has to Restore
The rebuild path should start from a known clean baseline, because the objective is to recover trust, not just functionality. That usually means identifying authoritative sources for identity data, deciding which directory objects and configurations can be trusted, and mapping which systems depend on the compromised forest before any restoration begins.
In a fully compromised environment, restoration also has to account for credentials and privilege relationships that outlive the visible breach. The directory may contain stale privileged groups, overused service accounts, legacy delegation, and long-lived credentials that remain valid even after the obvious admin account is reset. NHI lifecycle management guidance is relevant here because recovery depends on more than rotation, it depends on knowing what must be reissued, reowned, or retired before trust can be reintroduced.
At the operational level, this means validating the rebuild sequence against the business dependency graph: domain controllers, certificate services, authentication paths, application trusts, and any integrations that can authenticate through the directory. If those dependencies are not mapped before restoration, the organization may reintroduce compromise while trying to recover availability.
Which Privileged Paths Must Be Re-Controlled Before the Forest Is Trusted Again
Once domain admin access has been lost, the organization should assume every standing privileged path is suspect until proven otherwise. That includes emergency access accounts, break-glass access, admin workstations, and any delegated route that could still reach the forest. The first rebuilding step is therefore to reassert control over privileged access itself, because that is what decides whether the attacker can regain foothold during recovery.
That is why privileged access management and time-bounded elevation matter even during incident recovery. Privileged Access Management guidance helps frame the recovery priority: remove standing privilege, reissue only what is necessary, and keep high-risk admin actions observable while the trust base is being rebuilt.
Recovery teams should also treat privileged session oversight as part of the rebuild, not as a later hardening task. If sessions are not brokered, recorded, and reviewed during the restoration window, attackers can blend into recovery work or abuse overlooked admin channels. Privileged session management guidance supports that control point by making admin activity auditable while trust is being reestablished.
Risk and Threat Considerations
A fully compromised domain admin position creates a recovery problem as much as an attack problem. The main risk is that any “cleanup” which reuses the same trust root can restore attacker access, because the adversary may have already planted persistence in directory objects, replication relationships, delegated rights, or admin credentials that were not fully discovered.
Failure mechanism: the attacker uses privileged control to hide access, weaken recovery accounts, or alter the very controls the defender relies on for restoration, so the organization cannot reliably distinguish clean state from manipulated state.
Impact: the forest can remain effectively owned even after visible accounts are reset, which raises the chance of reinfection, failed recovery, and repeated business interruption.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Compromised domain admin recovery depends on replacing and controlling privileged authenticators. |
| AC-6 — Least Privilege | Recovery requires removing standing admin power and reestablishing minimal necessary access. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Post-compromise rebuild needs review of privileged activity and administrative changes to validate trust. | |
| Recommendation — Rotate and reissue privileged authenticators from a clean recovery path before restoring trust. Limit recovery access to the minimum roles needed during rebuild and validation. Review privileged activity logs to validate recovery actions and detect persistence. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Compromised admin access often leaves orphaned privileged paths and unreclaimed access. |
| NHI-05 — Overprivileged NHI | Domain admin compromise is an extreme privilege-abuse condition requiring privilege reduction. | |
| NHI-07 — Long-Lived Secrets | Directory recovery must account for secrets that remain valid after visible account resets. | |
| Recommendation — Revoke all lingering privileged access paths and reissue only explicitly approved accounts. Reduce standing privilege and reintroduce admin access only through controlled elevation. Replace long-lived secrets and certificates before reusing directory trust paths. | ||
| MITRE ATT&CK | T1068 — Exploitation for Privilege Escalation | Domain admin compromise typically results from or enables privilege escalation and deep control. |
| T1098 — Account Manipulation | Attackers with domain admin access can manipulate accounts, groups, and delegated rights. | |
| Recommendation — Map privilege escalation paths and close the ones that enabled administrative compromise. Hunt for manipulated accounts, groups, and delegated admin rights before restoring trust. | ||
Practitioner Guidance
What to prioritize: treat trust reestablishment as the first workstream, ahead of account-by-account cleanup. If the team cannot prove a recovery source is clean, it should not be used to restore privileged access or directory authority.
What to verify: confirm which systems, identities, and administrative paths can still issue privileged changes, and require evidence that the recovery baseline is independent of the compromised forest before you resume normal operations.
Practitioner takeaway: the first decision is not how to disinfect the directory, but how to rebuild a trust anchor the attacker no longer controls.
Related resources from NHI Mgmt Group
- How should organisations modernize Active Directory when legacy domain services still underpin core access?
- Why does Active Directory create security risk when organisations keep using static group membership and domain-admin patterns?
- How should organisations evaluate Azure Active Directory alternatives for access governance?
- When should organisations keep Active Directory instead of moving fully to Entra ID?