🔑 IAM

Identity Containment After Domain Controller Compromise: IAM Response for CVE-2026-41089 Post-Exploitation

If forensic investigation reveals CVE-2026-41089 exploitation occurred before patching, the identity response is as critical as the technical remediation. All credential material accessible from the domain controller must be treated as compromised. This guide covers the identity containment sequence for a confirmed Active Directory domain controller breach.

4 min read
#active-directory#identity-management#incident-response#domain-controller#golden-ticket#credential-rotation#ad-recovery

A confirmed domain controller compromise from CVE-2026-41089 exploitation is a full identity infrastructure incident. SYSTEM-level access to a domain controller means the attacker had access to all credential material stored on that DC: NTDS.dit (the Active Directory database containing all domain account hashes), the LSA secrets (service account passwords and cached credentials), and the Kerberos key material including the krbtgt account’s password hash.

Identity containment after DC compromise is a structured sequence. Performing steps out of order creates windows where attacker persistence survives the response.

The Core Problem: Golden Tickets and NTDS.dit

The two persistence mechanisms that survive most AD incident responses are Golden Tickets and direct NTDS.dit abuse.

Golden Tickets are forged Kerberos Ticket Granting Tickets (TGTs) signed with the domain’s krbtgt account key material. An attacker who has extracted the krbtgt hash can forge a TGT for any user in the domain with any group memberships, valid for any duration. These tickets are not stored in AD — they exist only in the attacker’s tooling. Rotating every user password in the domain does not invalidate a Golden Ticket. Only rotating the krbtgt account password twice (with 10+ hours between rotations) invalidates existing Golden Tickets.

NTDS.dit abuse means the attacker has a complete offline copy of the domain’s password database. They can crack password hashes offline at their leisure, continuing to gain credential access to accounts even after the immediate incident response. Rotating passwords is the remediation — but the priority order matters.

Identity Containment Sequence

Perform these steps in order. Do not skip steps or change the order.

Step 1: Isolate compromised domain controllers Take compromised DCs off the network before beginning remediation. Do not shut down — preserve memory for forensic analysis. Use network isolation (VLAN change or firewall policy) rather than power-off.

Step 2: Verify a clean DC exists (or restore from backup) Identify at least one domain controller that was not compromised (not reachable from the network path the attacker used, or verified clean through forensic investigation). All subsequent identity operations require a clean DC.

If no clean DC can be verified, proceed with AD Forest Recovery procedures — restore a DC from an offline backup taken before the compromise window.

Step 3: Rotate krbtgt password (first rotation)

# Reset krbtgt password — requires Domain Admin on a clean DC
Set-ADAccountPassword -Identity krbtgt -Reset -NewPassword (New-Object System.Security.SecureString)

Wait at least 10 hours (longer than the maximum Kerberos ticket lifetime) before the second rotation.

Step 4: Identify and disable attacker-created accounts Review accounts created during the compromise window and members of privileged groups added since the compromise:

$cutoff = Get-Date -Date "<compromise-start-date>"
Get-ADUser -Filter {WhenCreated -gt $cutoff} -Properties WhenCreated, Enabled | 
Where-Object {$_.Enabled -eq $True} | Select-Object SamAccountName, WhenCreated

Disable and quarantine any unrecognised accounts before enabling password rotation, to prevent attacker accounts from receiving new passwords they can use.

Step 5: Rotate all Tier 0 and Tier 1 account passwords Priority order:

  1. Domain admin accounts (all members of Domain Admins, Enterprise Admins, Schema Admins)
  2. Service accounts with DC access
  3. AD Connect service accounts (if Entra ID sync is in place)
  4. All other service accounts with privileged access
  5. Regular user accounts (can be forced via password expiry policy rather than manual rotation)

Step 6: Rotate krbtgt password (second rotation) After the minimum 10-hour wait from Step 3:

Set-ADAccountPassword -Identity krbtgt -Reset -NewPassword (New-Object System.Security.SecureString)

This second rotation ensures any Golden Tickets created using key material from the first rotation period are also invalidated.

Step 7: Rotate service account passwords and SPN credentials Identify all service principal names and rotate associated credentials:

Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName |
Select-Object SamAccountName, ServicePrincipalName

For each, rotate the password and update the service configuration on the application servers that use these credentials.

Step 8: Entra ID / Azure AD Connect (if applicable) If Microsoft Entra ID is synchronised from the compromised AD, the Entra ID tenant may have received compromised credential information:

  • Rotate the AD Connect service account credentials
  • Review Entra ID audit logs for unusual privileged operations during the compromise window
  • Consider a temporary Entra ID token revocation for high-privilege accounts: Revoke-AzureADUserAllRefreshToken

Step 9: Rebuild domain controllers Compromised domain controllers should not be returned to service — they should be decommissioned, cleaned, and rebuilt from scratch. A DC that was running while under attacker control may have persistent backdoors at the OS level that survive a credential rotation.

Share this article