Tracing a Domain Compromise: Key Active Directory Logs and Indicators of Compromise to Check First

When you suspect Active Directory itself has been touched, not just a single workstation or mailbox, the investigation is different from normal endpoint response: you’re looking for evidence in domain controller logs, replication metadata, and a handful of very specific event IDs that experienced responders check first, before anything else.

1. Check for Golden Ticket / Kerberos anomalies first

This is the single most consequential AD compromise technique, and it leaves specific traces:

Get-EventLog -LogName Security -InstanceId 4769 -After (Get-Date).AddDays(-7) |
  Where-Object { $_.Message -match "0x17|0x1F" }

Look for Kerberos service tickets (Event ID 4769) requested with an unusually long lifetime, or TGTs issued for accounts that don’t normally authenticate from that source. A genuine Golden Ticket attack uses the krbtgt account’s hash to forge tickets that bypass normal authentication entirely. If you have any real suspicion of this, the krbtgt password needs to be reset twice, not once, since AD keeps the previous password valid briefly, so a single reset doesn’t fully invalidate forged tickets.

2. Pull DCSync-related events

DCSync abuses legitimate AD replication permissions to pull password hashes without ever touching a domain controller directly as an admin:

Get-EventLog -LogName Security -InstanceId 4662 -After (Get-Date).AddDays(-7) |
  Where-Object { $_.Message -match "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2" }

That GUID is the “Replicating Directory Changes” extended right. An event 4662 referencing it from an account/computer that isn’t a domain controller or an authorized sync tool (like an on-prem sync service) is a strong signal.

3. Check for new/modified Group Policy Objects

GPOs are a very effective persistence mechanism precisely because they push changes to every machine in scope automatically:

Get-GPO -All | Sort-Object ModificationTime -Descending | Select-Object DisplayName,ModificationTime,Owner | Select-Object -First 20

Anything modified outside a known change window is worth opening directly and reviewing for scheduled tasks, startup scripts, or new local admin group memberships being pushed, all common malicious-GPO patterns.

4. Check for AdminSDHolder / ACL tampering

A well-known persistence technique modifies permissions on the AdminSDHolder object, which then propagates to every protected group (Domain Admins, Enterprise Admins, etc.) on the next SDProp cycle:

dsacls "CN=AdminSDHolder,CN=System,DC=yourdomain,DC=com"

Compare the output against a known-good baseline if you have one. An unfamiliar account or group with write/modify permissions here is a serious finding regardless of anything else you’ve found.

5. Check for new SID history entries

Get-ADUser -Filter * -Properties SIDHistory | Where-Object { $_.SIDHistory -ne $null } | Select-Object Name,SIDHistory

SID History is legitimately used during domain migrations, so context matters here, but an entry that doesn’t correspond to a real, known migration is a documented privilege-escalation/persistence technique (SID History injection) and needs immediate follow-up.

6. Check Domain Controller-specific events

Get-EventLog -LogName Security -InstanceId 4624 -After (Get-Date).AddDays(-3) |
  Where-Object { $_.Message -match "Logon Type:\s*3" -and $_.Message -match "Account Name:.*\$" }

Interactive or network logons directly on a domain controller using accounts that aren’t your known service/admin accounts deserve scrutiny. DCs should have a very small, very well-known set of accounts that ever touch them directly.

7. Check for unauthorized scheduled tasks on domain controllers

Get-ScheduledTask | Where-Object { $_.Author -notlike "Microsoft*" }

Run this directly on each DC. Legitimate third-party scheduled tasks on a domain controller should be rare and all accounted for. Anything unexpected here is worth investigating immediately, since a DC-resident scheduled task is a very durable and high-privilege persistence mechanism.

The single most important habit: a real baseline

Every one of the checks above is far faster and far more reliable if you already have a documented baseline of what “normal” looks like: normal GPO modification dates, normal AdminSDHolder ACLs, the known list of accounts that legitimately touch domain controllers. Building that baseline before you need it is the difference between a two-hour investigation and a two-day one.

Frequently asked questions

How far back should I look in the logs?
It depends on your log retention, but for a serious suspected compromise, go back at least as far as your default Security log retention allows (often only a few days by default unless you’ve configured a SIEM or increased retention). This is exactly why forwarding Security logs to a SIEM/central log store with longer retention is worth doing before an incident, not during one.

Do I need to reset the krbtgt password even if I don’t confirm a Golden Ticket attack?
If there’s a strong enough suspicion of broader AD compromise (not just a single endpoint), most incident response guidance recommends the double krbtgt reset as a precaution regardless, since the cost of doing it is low and the cost of leaving a forged-ticket path open is very high.