Domain-level access you cannot account for

The hardest response to pace correctly. Acting too early tells the operator you are there and achieves nothing durable; acting too late means rebuilding. Scope first, then act once, completely.

Trigger. An unexplained Domain Admin, directory replication by something that is not a domain controller, or a ticket that does not match any authentication.

The first 180 minutes1 of 5 expire

01 02 03 04 05

090 min180

01
Establish scope before changing anything
by 30 min
Directory changes on every domain controller rather than one, recent additions to privileged groups, accounts that acquired service principal names, and replication requests from anything that is not a domain controller.
02
Find the path in, not just the account
by 60 min
A domain admin is an outcome. The question is which workstation or service account it came from, because that is the thing that still works after you reset the account.

Tell somebody

Executive, early, because forest recovery is a business decision and not a technical one
Whoever owns the backup estate, before anything is restored into a domain that may still be held
Outside assistance, if you have not run a domain-level eviction before

Drawn from

The documents these steps come from, so you can check one rather than take it on trust.

The evidence

What each source proves, and what it does not.

logon events

Collect it in one go

A read-only script that gathers most of the above in volatility order, with a hash manifest.

Triage collection

Make it yours

Replace the escalation list with real names, and the timings with what your change process actually allows. A playbook that assumes an authority you do not have will stall at the step that needed it.

Establish scope before changing anything

Find the path in, not just the account