Active Directory Compromise: The Hardest IR You Will Ever Run

Cybersecurity

AD compromise IR end-to-end. Kerberoasting and AS-REP roast detection, KRBTGT double-rotation, golden and silver ticket invalidation, ntds.dit credential reset, BloodHound for blast radius, and when rebuilding the forest is genuinely the only answer.

By Arjun Raghavan, Security & Systems Lead, BIPI · July 11, 2024 · 9 min read

Active Directory compromise is the hardest incident response work in enterprise security because the platform is fundamentally a trust-by-design system and once the attacker has Domain Admin, every clean assumption you make can be wrong. The decision tree splits between contain and rebuild, and the cost of getting it wrong is measured in months of recurring incidents from credentials you did not realise the attacker still owns.

Detection: what the attack actually looks like

Kerberoasting is the cheap reconnaissance everyone runs. An attacker with any domain user requests service tickets for accounts with SPNs, then cracks them offline. The detection is event ID 4769 with ticket encryption type 0x17 (RC4) from a single source against many service accounts in a short window. Modern environments should have most service accounts on AES, so any RC4 ticket request is suspicious to begin with.

AS-REP roast targets accounts with Kerberos pre-authentication disabled. The detection is event ID 4768 with pre-auth-not-required and RC4 encryption. Both Hayabusa and Chainsaw, run against EVTX collections, have rules that surface these patterns out of the box. If you are watching Sentinel or Defender for Identity, the alerts are wrapped in human-readable names but the underlying events are the same.

BloodHound: knowing the blast radius

Once you suspect compromise, the next question is how bad it is. BloodHound, run from a non-privileged collector account, will map every shortest path to Domain Admin from any starting node. The query you run first is, given the compromised account, what does it have GenericAll, WriteDACL, or AddMember rights to. The second query is the inverse: which accounts can reach this one. The graph that comes back tells you whether you are looking at a contained incident or an unrecoverable one.

Golden and silver tickets

A golden ticket is a Kerberos TGT forged with the KRBTGT account's hash. With it, the attacker can impersonate any user in the domain for the lifetime of the ticket, which defaults to ten years. A silver ticket is a forged service ticket for a specific service, requiring only that service account's hash. Both are essentially invisible in default logging because they look like normal Kerberos traffic to the KDC.

Detection is indirect: tickets with unusual lifetimes (years instead of hours), tickets used to access services from source hosts that should not have access to them, and tickets that bypass account-disabled state (a disabled account whose old ticket is still being used). Defender for Identity flags ticket-lifetime anomalies and improbable Kerberos activity; without it, you are reading raw event logs and hoping.

The KRBTGT double-rotation

If you believe KRBTGT is compromised, the only fix is to rotate it. Twice. Because Active Directory keeps both the current and previous KRBTGT password to allow ticket validation across the password change, a single rotation leaves the old hash still valid. The recommended procedure: rotate KRBTGT, wait at least 10 hours (or the maximum ticket lifetime in your domain), then rotate again. Microsoft publishes a script (New-KrbtgtKeys.ps1) that handles this correctly. Do not do it by hand.

Every golden ticket forged before the second rotation becomes invalid. Every legitimate Kerberos ticket also becomes invalid, which causes user logon issues, application failures, and helpdesk volume. Plan the rotation for a maintenance window if you can; if you cannot, do it anyway because the alternative is a persistent attacker.

Resetting credentials at scale

Assume the attacker exfiltrated ntds.dit. That means every user password hash, every computer account, and every service account is potentially in their hands. Reset, in this order: KRBTGT (twice), tier-0 admin accounts, service accounts (especially those with SPNs), then tier-1 admin accounts, then all user accounts. Force password change at next logon for the user population; for service accounts, do it as a coordinated change with the application owners because forgotten service accounts will break things.

Computer accounts also have passwords, and they rotate automatically every 30 days by default. After a full compromise, forcing a domain-wide computer account password reset is reasonable, but it is operationally heavy. Most organisations skip it and rely on the automatic rotation to age out attacker knowledge over the following month.

When to rebuild the forest

The hardest call. Rebuilding the AD forest from scratch is a 6-to-18 month project that costs millions and disrupts everything. You do it when the alternative is a permanent compromised state. Triggers I have used: evidence the attacker had DCSync or DCShadow capability for an extended period, evidence of skeleton key or DSRM persistence, schema modifications you cannot fully audit, and the political reality that the executive team has lost trust in the existing forest.

The middle path is a parallel forest with a one-way trust, where you migrate workloads gradually. It is slower than a clean rebuild but less disruptive, and it is the path most large enterprises actually take when forced into this decision. The original forest stays around until it can be retired, with progressively narrower trust.

What this incident leaves behind

Tier-0 isolation that should have existed all along. Privileged Access Workstations for domain admin work. Tiered admin model so a workstation compromise cannot turn into a domain compromise. LAPS for local administrator passwords. Protected Users group for tier-0 accounts. Disabled NTLM where you can, reduced where you cannot. Every AD compromise IR ends with the same blueprint, and the only question is whether you implement it during the incident or use the incident as the political moment to make it happen.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.