Active Directory Forensics: Domain Controller Event Logs

Domain controllers see every Kerberos ticket, every NTLM validation against a domain account and every change to users, groups and policies. This guide shows you which logs live on a DC, which event IDs answer which question, how to spot DCSync, directory tampering, GPO abuse and NTDS.dit theft, and how to merge evidence from several DCs into one story. It assumes you know the basics of the Windows event log forensics guide.

What lives on a domain controller

A DC is a Windows server with extra roles, so all the usual host artifacts apply. On top of them:

The NTDS.dit and Group Policy artifact pages give the structure of the database and GPO folders. The event log overview covers the EVTX format itself.

Audit policy prerequisites

Before hunting, check what the DCs were configured to record. Most interesting DC events come from Advanced Audit Policy subcategories, and several need a SACL on the directory objects as well.

# Effective audit policy on a DC
auditpol /get /category:*

# Resultant policy for the Domain Controllers OU, to see where it came from
gpresult /h C:\temp\dc-gpresult.html

Subcategories that matter most:

• Account Logon: Credential Validation (4776), Kerberos Authentication Service (4768, 4771), Kerberos Service Ticket Operations (4769, 4770).
• Account Management: User Account Management (4720 to 4726, 4738, 4740, 4767), Security Group Management (4727 to 4737, 4754 to 4758), Computer Account Management (4741 to 4743).
• DS Access: Directory Service Access (4662) and Directory Service Changes (5136 to 5141). Both depend on SACLs: without an auditing entry on the object, nothing is logged.
• Logon/Logoff and Detailed Tracking (4688 with command line) for activity on the DC itself.

Also check the Security log size. On a busy DC, the default size can hold only hours of Kerberos traffic. If logs are forwarded to a SIEM, that copy may be your only one.

Kerberos events

Kerberos is the default authentication in a domain, and every ticket request is logged by the DC that served it.

• 4768, TGT requested. Account name, client address, ticket encryption type and pre-authentication type. Encryption type 0x17 (RC4) where the environment uses AES, or pre-authentication type 0 (no pre-auth) for a user, points to downgrade or AS-REP roasting.
• 4769, service ticket requested. Service name (the SPN's account), client address and encryption type. A single account requesting RC4 tickets for many service accounts in a short time is the Kerberoasting pattern.
• 4770: ticket renewed. 4771, pre-authentication failed: failure code 0x18 means bad password. Many 4771s from one address across many accounts is password spraying.
• 4776, NTLM credential validation on the DC for domain accounts. Error codes such as 0xC000006A (bad password) and 0xC0000064 (unknown user) separate spraying from typos. The workstation field is supplied by the client and can be empty or forged.

# Kerberoasting candidates: RC4 service tickets, excluding machine accounts and krbtgt
chainsaw search -t 'Event.System.EventID: =4769' --json ./DC01/Logs |
  jq -r 'select(.Event.EventData.TicketEncryptionType=="0x17")
         | [.Event.System.TimeCreated_attributes.SystemTime,
            .Event.EventData.TargetUserName,
            .Event.EventData.ServiceName,
            .Event.EventData.IpAddress] | @tsv'

Field names in Chainsaw's JSON output follow the EVTX structure and can change between versions; adjust the jq paths after checking one record.

Account and group changes

These events are the backbone of any persistence or privilege escalation finding in AD. All carry the subject (who did it) and the target (what changed).

Watch for the chain "4720 then 4728 to a privileged group within minutes" and for changes to AdminSDHolder-protected groups. A 4738 whose UserAccountControl field shows a newly set "Don't Require Preauth" flag is an attacker preparing an AS-REP roast target. Account names alone are not enough; use the target SID (see security identifier) because names can be reused.

DCSync and 4662

DCSync abuses the directory replication protocol: a non-DC account with replication rights asks a DC for password data, exactly like another DC would. On the DC, it shows up as 4662 (an operation was performed on an object) against the domain root object, with the Properties field containing the control access right GUIDs:

• 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2: DS-Replication-Get-Changes
• 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2: DS-Replication-Get-Changes-All
• 89e95b76-444d-4c62-991a-0facbeda640c: DS-Replication-Get-Changes-In-Filtered-Set

Filter out DC computer accounts (names ending in $ that belong to the Domain Controllers OU) and Azure AD Connect or other sync accounts you have documented. What remains, especially a user account or a workstation machine account, is a DCSync candidate. Pair it with a 4624 type 3 from the same account and a source IP that is not a DC.

This only works if Directory Service Access auditing is enabled and the domain object's SACL audits those rights. Many environments have neither, so an empty result is not a clean result. Network detection of DRSUAPI traffic from non-DC hosts is the complement. Granting the rights in the first place appears as a 5136 on the domain object's nTSecurityDescriptor, if Directory Service Changes auditing is on.

Directory changes: 5136 to 5141

With Directory Service Changes auditing and a SACL, DCs log attribute-level changes:

• 5136: attribute modified, with the attribute name, old and new values (as two events with operation types "value deleted" and "value added").
• 5137 created, 5138 undeleted, 5139 moved, 5141 deleted.

These give far more detail than the Account Management events: changes to nTSecurityDescriptor (ACL backdoors), servicePrincipalName (targeted Kerberoasting), msDS-AllowedToActOnBehalfOfOtherIdentity (RBCD), sIDHistory, and GPO attributes. The catch is always the SACL: default SACLs cover only part of the directory.

GPO abuse

A modified Group Policy Object pushes code to every computer it applies to, which makes it a ransomware deployment favourite.

• Directory side: 5136 on a groupPolicyContainer object, typically versionNumber and gPCMachineExtensionNames changing, and 5137 for new GPOs or links (gPLink on an OU).
• SYSVOL side: new or modified files under \\<domain>\SYSVOL\<domain>\Policies\{GUID}\, such as Machine\Preferences\ScheduledTasks\ScheduledTasks.xml, Machine\Scripts\Startup\, or Groups.xml. File timestamps in the $MFT and 5145 share access (if auditing is on) show when and from where.
• Client side: Microsoft-Windows-GroupPolicy/Operational on endpoints records processing, and the resulting scheduled tasks or services show what actually ran.

Old Groups.xml files with a cpassword attribute are also a credential exposure worth reporting, since the encryption key is public.

NTDS.dit theft traces

Stealing the database gives the attacker every hash offline. Common methods are ntdsutil IFM, a volume shadow copy with vssadmin or diskshadow, or raw disk reads.

• Process evidence: Prefetch for NTDSUTIL.EXE, VSSADMIN.EXE, DISKSHADOW.EXE, ESENTUTL.EXE, plus 4688 or Sysmon event 1 with command lines such as ac i ntds / ifm / create full.
• ESENT events in the Application log: 325 (database created), 326 (attached) and 327 (detached) for a copy of ntds.dit in an unusual path are the classic IFM trace. The path in the message is the key field.
• VSS: shadow copy creation in the System and Application logs, and new shadow copies that did not exist in the backup schedule.
• Files: ntds.dit and a SYSTEM hive copy in C:\Windows\Temp, C:\ProgramData or a share, often compressed right after. Check the USN journal if they were deleted.

See credential access forensics for the same techniques on member servers and workstations.

Golden and silver ticket indicators

Forged tickets bypass the DC's issuance step, so the evidence is mostly an absence. None of these is conclusive alone:

• Golden ticket (forged TGT): 4769 or logons for an account with no corresponding 4768 on any DC within the ticket lifetime; RC4 encryption in an AES-only domain; account names that do not exist or do not match the SID; logons that continue after a password reset. Some older tools produced field anomalies such as an unusual domain field format, but modern tooling mimics real tickets.
• Silver ticket (forged service ticket): a 4624 on a member server with no matching 4769 on any DC, because the DC is never contacted. You need the server's logs and the DC logs side by side to see it.
• Context: DCSync or NTDS.dit theft earlier in the timeline makes forgery plausible, because the attacker then holds the krbtgt or service account keys.

The robust response is operational: reset the krbtgt password twice, following Microsoft's guidance on spacing, and reset service accounts.

Correlating across multiple DCs

• Collect every writable DC and RODC, not just the PDC emulator. Authentication is load balanced by site.
• Normalise to UTC and check the DC clocks against each other; Kerberos tolerates skew, your timeline does not.
• Deduplicate replicated events: 4740 can appear on the processing DC and on the PDC.
• Use replication metadata when logs are gone. repadmin /showobjmeta or ADTimeline show when each attribute of an object last changed and on which DC it originated, even years later.

# Attribute-level change history for a suspicious account
repadmin /showobjmeta DC01 "CN=svc-backup,OU=Service Accounts,DC=corp,DC=example"

# Hayabusa timeline of all logs collected from one DC
hayabusa csv-timeline -d .\DC01\Logs -o DC01_hayabusa.csv

Tools

• Hayabusa and Chainsaw: Sigma-based triage with rules for Kerberoasting, DCSync, group changes and log clearing. Run them per DC, then merge.
• EvtxECmd: normalised CSV of all EVTX for pivoting in Timeline Explorer.
• PingCastle: posture assessment, not forensics, but it quickly shows weak points the attacker likely used (delegation, stale admins, GPP passwords, missing auditing).
• ADTimeline (ANSSI): builds a timeline of AD object changes from replication metadata, which survives log rotation.

Flags change between releases; check --help for the version you run.

Pitfalls

• Concluding "no DCSync" from zero 4662 events. Without the SACL and the audit subcategory, DCSync is invisible in the Security log.
• Collecting one DC. You will miss most Kerberos and NTLM events and misjudge the scope.
• Trusting the workstation name in 4776. It comes from the client. Use the IP where available, and 4624 on the source host.
• Flagging every RC4 ticket. Legacy applications and trusts still use RC4. Baseline first.
• Ignoring machine accounts. A workstation $ account doing replication or modifying objects is exactly what you are looking for.
• Forgetting that the DC is also a host. Look at its services, scheduled tasks, Prefetch and lateral movement traces too, using the RDP, PsExec and WinRM guide.

DC investigation workflow

1. List every DC and RODC, confirm clock sync, and collect Security, System, Application, Directory Service, DNS Server and DFS Replication logs, plus SYSVOL and host artifacts.
2. Record the effective audit policy and log retention for each DC.
3. Run Hayabusa or Chainsaw per DC and merge the output into one UTC timeline.
4. Hunt authentication abuse: 4771/4776 spraying, 4768 with no pre-auth, RC4 4769 bursts.
5. Review account and group changes (4720, 4722 to 4726, 4728/4732/4756, 4738, 4740) for privileged targets.
6. Check 4662 for replication GUIDs and 5136 to 5141 for ACL, SPN, delegation and GPO changes.
7. Look for NTDS.dit theft: ntdsutil/vssadmin execution, ESENT 325/326/327, VSS activity, stray ntds.dit copies.
8. Where logs are missing, use replication metadata (ADTimeline, repadmin /showobjmeta) to date changes.
9. Assess ticket forgery indicators and, if credentials were exposed, plan the krbtgt and service account resets.