Active Directory Compromise Response

What This Playbook Covers

• This playbook handles confirmed or suspected AD compromise. “Confirmed” means you have evidence that an attacker has gained Domain Admin privileges, extracted the AD database, or forged Kerberos tickets.
• It covers the four most common AD compromise scenarios: golden ticket, DCSync, Kerberoasting with privilege escalation, and ACL abuse. Each has distinct detection signatures and response procedures.
• The krbtgt password reset procedure (Section 5) is the most critical technical action in AD recovery. It invalidates all existing Kerberos tickets — including forged golden tickets.
• MITRE ATT&CK maps the impact phase to T1558 (Steal or Forge Kerberos Tickets) and T1003 (OS Credential Dumping) for DCSync.

Phase 0: Determine the AD Compromise Type (0-15 minutes)

Before executing response actions, confirm which type of AD compromise you are dealing with.

Golden Ticket Detection

A golden ticket is a forged Kerberos TGT (Ticket-Granting Ticket) that grants Domain Admin access. The attacker creates it offline using the krbtgt account’s password hash — they do not need to be on the network to forge it.

Detection indicators:

SPL query — detect golden ticket via extended TGT lifetime:

index=windows EventCode=4768
| eval ticket_hours = (TicketEndTime - TicketStartTime) / 3600000
| where ticket_hours > 12
| eval alert = "CRITICAL — TGT with lifetime " . round(ticket_hours, 1) . " hours — possible golden ticket for " . Account_Name
| table _time, Account_Name, TicketStartTime, TicketEndTime, ticket_hours, alert
| sort - ticket_hours

SPL query — detect RC4-encrypted TGT (non-AES):

index=windows EventCode=4768
| search TicketEncryptionType!="0x12" AND TicketEncryptionType!="0x17" (AES256/128 check)
| eval alert = "HIGH — TGT with non-AES encryption (" . TicketEncryptionType . ") — possible golden ticket for " . Account_Name
| table _time, Account_Name, TicketEncryptionType, TicketOptions, alert

DCSync Detection

DCSync replicates the AD database from a Domain Controller to a requesting entity. Only Domain Controllers need this right. When a non-DC system requests AD replication, it is likely an attacker trying to dump all password hashes.

Detection indicators:

SPL query — detect replication request from non-DC:

index=windows EventCode=4662
| search AccessMask="*DS-Replication-GetChanges*"
| search SubjectUserName!="*$"
| eval alert = "CRITICAL — DCSync from non-computer account " . SubjectUserName . " — AD database replication"
| table _time, SubjectUserName, ObjectName, AccessMask, alert
| sort - _time

Kerberoasting Detection

Kerberoasting requests a Kerberos service ticket for a service account, extracts the encrypted ticket, and cracks the service account password offline.

Detection indicators:

SPL query — detect kerberoasting via multiple 4769 events:

index=windows EventCode=4769
| stats dc(ServiceName) as unique_services, count as total_requests by Account_Name, IpAddress
| where unique_services > 5
| eval alert = "HIGH — " . total_requests . " service ticket requests for " . unique_services . " different services from " . Account_Name . " — Kerberoasting"
| table _time, Account_Name, IpAddress, unique_services, total_requests, alert
| sort - total_requests

ACL Abuse Detection

ACL abuse occurs when an attacker with compromised AD permissions modifies ACLs to gain additional access — adding themselves to a privileged group, changing user passwords, or modifying object ownership.

Detection indicators:

SPL query — detect privileged ACL modifications:

index=windows EventCode=5136
| search ObjectDN IN ("*Domain Admins*", "*Enterprise Admins*", "*Schema Admins*", "*Administrators*", "*AdminSDHolder*")
| stats count by Account_Name, ObjectDN, AttributeValue
| eval alert = "CRITICAL — ACL modification on " . ObjectDN . " by " . Account_Name
| table _time, Account_Name, ObjectDN, AttributeValue, alert
| sort - _time

Phase 1: Immediate Containment (15-30 minutes)

Critical Actions — Do These First

• Disable the compromised user account(s) — Disable-ADAccount -Identity "CompromisedUser"
• Reset the compromised user’s password — Set-ADAccountPassword -Identity "CompromisedUser" -Reset -NewPassword (ConvertTo-SecureString "NewP@ssw0rd!" -AsPlainText -Force)
• Remove compromised user from privileged groups — Remove-ADGroupMember -Identity "Domain Admins" -Members "CompromisedUser"
• Revoke all Kerberos tickets for compromised user — Get-ADUser -Identity "CompromisedUser" | Revoke-ADAuthenticationPolicy (or wait for automatic expiration)
• Block network access from compromised systems — Block at firewall or isolate at switch level
• Enable enhanced audit logging on all DCs — auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enable
• Capture memory from affected DCs — Do NOT reboot. Use dumpit.exe or winpmem to capture memory for forensic analysis.

What NOT to Do

Phase 2: Evidence Preservation (30-45 minutes)

What to Capture

Phase 3: Investigation — Determine Blast Radius (45-90 minutes)

Questions to Answer

Cross-Correlation Query

KQL query — build timeline of all AD-related changes during compromise window (run in KQL-enabled Sentinel):

// Create a timeline of all critical AD events
let knownEvents = dynamic(["4624", "4625", "4648", "4768", "4769", "4662", "5136", "4728", "4732", "4720"]);
SecurityEvent
| where TimeGenerated between (datetime(2026-05-15) .. datetime(2026-05-23))
| where EventID in (knownEvents)
| project TimeGenerated, Computer, EventID, Account, Activity
| order by TimeGenerated asc

Phase 4: krbtgt Password Reset — The Emergency Recovery Step

The krbtgt account is the most important account in any AD domain. Its password hash is used to sign all Kerberos tickets — including golden tickets. If the attacker has the krbtgt hash, they can forge unlimited golden tickets until the hash is changed.

When to Reset krbtgt

krbtgt Password Reset Procedure

The krbtgt password must be reset twice in succession to invalidate all existing Kerberos tickets. A single reset does not invalidate tickets created before the reset — only the second reset fully invalidates them.

# STEP 1: Verify current krbtgt password age
Get-ADUser krbtgt -Properties PasswordLastSet, PasswordExpired

# STEP 2: Reset krbtgt password — First reset
$newPwd = ConvertTo-SecureString -AsPlainText "New-36-Character-Random-Password@2026!" -Force
Set-ADAccountPassword -Identity krbtgt -NewPassword $newPwd -Reset

# Wait 30 minutes (or until all DCs have replicated the new password)

# STEP 3: Reset krbtgt password — Second reset
$newPwd2 = ConvertTo-SecureString -AsPlainText "Second-36-Character-Random-Password@2026!" -Force
Set-ADAccountPassword -Identity krbtgt -NewPassword $newPwd2 -Reset

# STEP 4: Force replication and verify
Repadmin /syncall /AdeP
Get-ADUser krbtgt -Properties PasswordLastSet

What Happens During Each Reset

Expected Service Disruptions

Phase 5: Recovery and Hardening (90+ minutes)

Immediate Recovery Steps

• Reset all service account passwords — Especially accounts in Domain Admins, Enterprise Admins, and accounts with SPNs (kerberoastable)
• Reset all user passwords for users whose accounts showed anomalous activity during the compromise window
• Review and reset privileged group memberships — Remove any accounts that should not be in Domain Admins, Enterprise Admins, Schema Admins
• Audit ACLs on privileged objects — Check AdminSDHolder, each DC computer object, OU delegation for unauthorized ACL modifications
• Enable Kerberos logging on all DCs — auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enable
• Enable DCSync-specific alerting — Create analytics rule for Event 4662 with DS-Replication-GetChanges on non-DC accounts
• Rotate all computer account passwords — Reset-ComputerMachinePassword on domain-joined servers

Long-Term Hardening

Post-Incident Checklist

• krbtgt password reset completed (two resets with replication wait)
• All service account passwords reset
• All privileged user passwords reset
• Privileged group memberships audited and reduced
• AD ACLs audited for unauthorized changes
• Kerberos monitoring rules created in SIEM
• Incident report completed with timeline, findings, and recommendations
• Post-mortem review with AD team and security team

Related

• Credential Theft Incident Response — detection and response for T1558.001, T1003.001, T1134 techniques
• Active Directory Basics — covers the active directory basics concepts
• EDR Basics — detection and response for T1059, T1003, T1055, T1204, T1562 techniques
• Indicators: IoC, IoA, and TTP — covers the indicators: ioc, ioa, and ttp concepts
• MITRE ATT&CK for Triage — covers the mitre att&ck for triage concepts

Sources

• Microsoft — Kerberos Golden Ticket Detection and Recovery
• MITRE ATT&CK T1558 — Steal or Forge Kerberos Tickets
• Microsoft — DCSync Detection
• CISA — Active Directory Compromise Response
• Microsoft — krbtgt Account Password Reset