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. Label it as evidence - it contains the attacker's changes, so never restore from it.
- Run SharpHound. Capture the current attack path state so you can compare it against post-remediation.
Do not power off compromised machines. You will lose volatile memory, running processes, and network connections. Isolate them from the network instead. Disable the NIC or quarantine the VLAN.
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. The event logs don't record ticket lifetime, so look for the side effects instead: service ticket requests (4769) for an account with no matching TGT request (4768) from that host, tickets for disabled accounts, and RC4 tickets in a domain that otherwise uses AES. If the attacker ever had DCSync or a copy of ntds.dit, assume KRBTGT is compromised and plan the double reset regardless.
- 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 and timing matter. Credential resets only stick once the persistence from Step 2 is gone and the attacker's access is cut - otherwise they simply harvest the new passwords. Plan the resets as one coordinated window, starting with KRBTGT.
- Reset KRBTGT twice with a 10-12 hour gap between resets. AD accepts both the current and the previous KRBTGT key, so after the first reset the stolen key is still valid as the "previous" one. The second reset pushes it out. Only then are golden tickets made with it dead.
- Reset all compromised account passwords. Every account the attacker touched, plus every account they could have harvested via DCSync or Kerberoasting.
- Reset all service account passwords. Especially Kerberoastable accounts (those with SPNs).
- Reset computer account passwords for compromised machines.
- Rotate the Entra Connect credentials if hybrid: the on-prem
MSOL_connector account and the cloud sync account. If you use Seamless SSO, roll theAZUREADSSOACCKerberos key too. These are frequently forgotten and give the attacker a bridge back to the cloud - or straight back to DCSync.
KRBTGT reset timing: The 10-12 hour gap is critical. If you reset both immediately, every Kerberos ticket in the environment becomes invalid simultaneously. That means every user session, every service authentication, and a lot of services need restarting at once. Leaving at least the maximum ticket lifetime (10 hours by default) plus replication time between resets lets legitimate tickets expire and renew naturally. In an active eviction where the attacker is known to hold the key, some teams accept that disruption and reset twice quickly - make that a deliberate decision, not an accident.
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 path the attacker used - and any other short path to Tier 0 - should be closed.
- Verify replication health. Run
repadmin /replsummaryanddcdiag /von 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. Its on-prem MSOL_ account can DCSync if you use password hash sync, and its cloud account can change any synced user in Entra ID - including synced admins. Anyone who controlled the Connect server can walk back in through either side. Rebuild or verify the server, rotate both accounts, check Entra ID audit logs for changes made by the sync account, and make sure no privileged cloud roles are held by synced accounts.
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.
The measure of a successful eviction is not that the attacker is gone today. It is that they cannot return tomorrow. Every persistence mechanism must be found and removed. Every credential must be rotated. Every attack path must be closed. If you skip any of these, you are not evicting. You are hoping.