Post-Compromise AD Recovery: The Eviction Playbook Nobody Gives You

Every AD compromise I work follows a predictable pattern in the first 48 hours. The attacker has domain admin. They have been in the environment for days, sometimes weeks. The client wants them out immediately. And the decisions made in those first two days determine whether the eviction sticks or whether the attacker comes back through a persistence mechanism nobody thought to check.

This is the playbook I follow. Not the sanitized vendor version. The actual sequence of decisions, in order, with the reasoning behind each one.

Before You Touch Anything: Preserve Evidence

The instinct is to start resetting passwords immediately. Resist it. Every action you take in the first hour either preserves or destroys forensic evidence. Before changing a single credential:

• Capture volatile memory on compromised systems. Once you reboot, it is gone. Use tools like Magnet RAM Capture or WinPmem.
• Pull Security event logs from all DCs before they roll over. Export 4624, 4625, 4672, 4768, 4769, 4776 at minimum.
• Snapshot the AD database. Take a system state backup of at least one DC so you have a point-in-time reference of current ACLs, group memberships, and GPOs.
• Run SharpHound. Capture the current attack path state so you can compare it against post-remediation.

Step 1: Identify What Was Compromised

Before you can evict, you need to know the scope. The attacker may have compromised more than what triggered the incident. Start with:

Map every account the attacker touched. Every machine they logged into. Every service account they may have Kerberoasted. This becomes your remediation scope.

Step 2: Check for Persistence Before Resetting Credentials

This is the step most guides skip and the reason most evictions fail. If the attacker planted persistence mechanisms and you reset passwords without removing them first, they just come back.

Check for these in order of severity:

• Golden Ticket capability: If the attacker has the KRBTGT hash, they can forge TGTs indefinitely. Check Event ID 4769 for TGS requests with abnormally long ticket lifetimes (default max is 10 hours, golden tickets often use 10+ years).
• DCSync backdoor ACLs: Check if unauthorized principals have Replicating Directory Changes / Replicating Directory Changes All rights on the domain root. This is how attackers maintain DCSync access without being in Domain Admins.
• AdminSDHolder ACL modifications: If the attacker modified AdminSDHolder, their permissions get re-applied to all protected accounts every 60 minutes by SDProp, even after you remove them from groups.
• Rogue GPOs: Check for GPOs that deploy scheduled tasks, startup scripts, or modify security settings on DCs.
• Skeleton Key: Check if the LSASS process on DCs has been patched in memory. A skeleton key allows authentication with any password.
• Rogue admin accounts: Check for newly created accounts in privileged groups or accounts with AdminCount=1 that should not have it.

Step 3: Reset Credentials in the Right Order

Order matters. If you reset user passwords before KRBTGT, an attacker with a golden ticket can just re-harvest the new passwords.

1. Reset KRBTGT twice with a 10-12 hour gap between resets. The first reset invalidates the current hash. The second reset invalidates the previous hash (AD keeps both). This kills golden tickets.
2. Reset all compromised account passwords. Every account the attacker touched, plus every account they could have harvested via DCSync or Kerberoasting.
3. Reset all service account passwords. Especially Kerberoastable accounts (those with SPNs).
4. Reset computer account passwords for compromised machines.
5. Regenerate the Entra Connect sync account password if hybrid. This is frequently forgotten and gives the attacker a bridge back to cloud.

Step 4: Clean and Verify

• Remove all persistence mechanisms identified in Step 2. Revert ACL changes, delete rogue GPOs, remove unauthorized group memberships.
• Rebuild compromised machines from clean media. Do not trust a compromised system that has been "cleaned." Wipe and rebuild.
• Run BloodHound again. Compare the post-remediation graph against the pre-remediation snapshot. Every attack path that existed before should be closed.
• Verify replication health. Run repadmin /replsummary and dcdiag /v on every DC. Credential resets can surface latent replication issues.
• Monitor aggressively for 30 days. Watch for the attacker attempting to return. Key indicators: new privileged logons from unexpected sources, new service accounts, DCSync attempts (4662 with Replicating Directory Changes), and TGT requests for recently-reset accounts from unexpected IPs.

What Gets Missed

The Entra Connect sync account. I see this missed in about half the evictions I review. If the attacker has the sync account credentials, they can reset cloud-only passwords, including Global Admin accounts that were never synced from on-prem. Check Entra ID sign-in logs for the sync account and verify no unauthorized password resets occurred.

Trust relationships. If the compromised domain has trust relationships with other domains, the attacker may have already pivoted. Check SID History for cross-domain privilege escalation.

Backup systems. If the attacker compromised backup infrastructure, they may have copies of the AD database (ntds.dit) that contain all password hashes. Rotate every credential, not just the ones you know were accessed.