An attacker with Domain Admin is an attacker who can persist in your environment forever unless you do this right. This runbook covers the technical recovery — golden-ticket containment, KRBTGT double-reset, tier-0 rebuild — plus the often-skipped step of proving you're actually clean. Most AD-recovery efforts that fail fail at the proof step; the attacker comes back six weeks later from a persistence layer nobody checked.

1. Confirm the compromise level

Did the attacker reach Domain Admin / Enterprise Admin / Schema Admin?
Was KRBTGT credential extracted (golden ticket possible)?
Was the AD database (ntds.dit) accessed / extracted?
Were Domain Controllers' SYSTEM-level shells observed?
Were Cert Authority credentials / private keys accessed?
Were ADFS / federation services compromised?

Golden-ticket assumption.

If you cannot definitively rule out KRBTGT extraction within the attacker's window, assume golden-ticket capability. This drives the KRBTGT double-reset sequence (below) — without which the attacker can re-issue valid Kerberos tickets even after you've reset every other credential.

2. Tier-0 isolation — first 24 hours

Identify tier-0 assets: DCs, ADFS, AD Connect, CA, PAM vault
Physically + logically isolate tier-0 from tier-1/2
Block tier-1/2 endpoints from communicating with DCs except via jump-hosts
Disable any tier-0 service accounts identified as compromised
Force re-authentication for every tier-0 admin (cancel active sessions)
Snapshot all DCs + ADFS for forensics before any changes

3. KRBTGT double-reset sequence

KRBTGT is the Kerberos service account whose hash signs every TGT. If extracted, the attacker can issue valid TGTs at will (golden ticket). A single reset is insufficient — Kerberos retains the previous password for one rotation cycle. You must reset twice, with a wait window in between.

1. Reset KRBTGT password #1 via Reset-ADAccountPassword + replicate to all DCs (Repadmin /syncall)
2. Wait at least 12-24 hours (ticket-validity window) to ensure all valid tickets expire
3. Reset KRBTGT password #2 + replicate again
4. Verify replication health — every DC must have the second reset before validating clean state
5. Expect operational disruption — every Kerberos client re-authenticates; plan a low-traffic window

4. Credential reset sweep

Account class	Reset action	Priority
Domain Admins (humans)	Reset + smart-card / FIDO2 re-bind	1 — first 24 hours
Domain service accounts (incl. KRBTGT)	Rotate + lengthen + complexity	1 — first 24 hours
Privileged service accounts (SQL SA, backup-svc, etc.)	Reset + rotate connection strings	2 — first 72 hours
Server local-admin accounts	Reset (LAPS rotation if deployed)	2 — first 72 hours
End-user passwords (if forced password attack suspected)	Phased reset across population	3 — first 2 weeks

5. Persistence hunt — where attackers hide post-DA

GPO modifications — startup / shutdown scripts pointing to attacker-controlled UNC
AdminSDHolder ACL tampering (privilege re-grant mechanism)
DCSync rights on regular user (e.g., for password-hash extraction)
DPAPI master-key abuse — local + domain backup keys
Scheduled tasks on DCs running attacker code
WMI event subscriptions (persistence outside the file system)
Certificate templates modified for ESC1-8 escalation
Skeleton-key implants (LSASS-side persistence)
Hidden ACLs on Domain Controllers' computer objects
RID-500 (built-in Administrator) being used; should be disabled in modern environments

6. Tier-0 rebuild vs in-place clean — decision framework

An in-place clean is faster but assumes you've found every persistence mechanism. A fresh tier-0 rebuild is slower but provides cryptographic certainty. The choice depends on: how long the attacker dwelled, how broad their privilege, whether ADFS / CA / PAM was touched, and how much business risk you're willing to carry post-IR.

Indicator	Lean towards in-place clean	Lean towards rebuild
Dwell time	< 2 weeks	> 2 months
Tier-0 systems touched	Domain Controllers only	DCs + ADFS + CA
Persistence layers found	≤ 3, all in well-instrumented places	Unknown / multiple categories
Audit-log coverage during dwell	Complete; reviewed in detail	Gaps; logging was attacker-tampered
Attacker sophistication	Commodity / known TTPs	Nation-state / APT / unknown TTPs

7. Validating you're clean — the long-tail

30-day post-IR red-team validation — Macksofy or equivalent, scoped to test the same attack chain
BloodHound re-enumeration; compare attack paths before vs after
Sigma rules deployed for the specific TTPs the attacker used; monitor 90+ days
Threat-intel signal — attacker re-engagement attempts from same C2 / similar TTPs
User and Service-account behaviour baseline; alert on deviation from baseline
Quarterly purple-team validation through the first year post-IR

The hardest 5% of the work is the validation.

Most AD recoveries lose the attacker for a while, then have them come back through a missed persistence layer. Plan time and budget for 90 days of monitoring + 30-day red-team validation — that's where you actually win.

Engage Macksofy

Need this in production, not on paper?

Macksofy offers full-service engagements that map directly to this resource. Common starting points:

Or talk to a senior consultant — fixed-price proposal in 48 hours.