Windows Event Log Analysis: Investigating Kerberos & AD Attacks

Updated on February 18, 2026

Table of Contents

• Prerequisites
• 1. Initial Triage & Investigation Workflow
• 2. Deep Technical Breakdown – Event IDs & Attack Mapping
• 3. Practical Log Analysis Techniques & Tooling
• 4. SIEM-Based Detection & Correlation
• 5. Red Team Insight (The Adversary Perspective)
• Conclusion

You've got the call. The Domain Controller (DC) is acting strange, a high-privilege user just logged in from a subnet that doesn't exist, and the CISO is breathing down your neck. You've been handed a zip file full of .evtx files and asked to find the bleeding.

Now, I've spent years on the offensive side executing these exact attacks. I know exactly what artifacts I leave behind when I'm sloppy, and I know what I try to hide when I'm being careful. But here's the reality: on a Windows domain, everything is a transaction. Even the stealthiest Golden Ticket leaves a footprint if you know where to look.

In this guide, we're going to break down how to perform Windows Event Log Analysis for Kerberos-based attacks and Active Directory abuse. We aren't just looking for "bad" events; we are reconstructing the crime scene using the exact methodology I use to evade you.  if you need more info on how the Kerberos authentication and attacks work in detail - you can check out our article on Understanding Kerberos Authentication and its Attacks

Prerequisites

To follow along effectively, you need a forensic workstation set up to parse these logs without modifying them.

• Target Logs: Security.evtx (Authentication), System.evtx (Services/Reboots), Directory Service.evtx (AD Object Access).
• Access: You don't need Domain Admin to analyze logs, just a workstation with the right tools.
• Tools:
  • Chainsaw (Rapid artifact parsing)
  • Hayabusa (Threat hunting tool)
  • EvtxECmd & Timeline Explorer (Eric Zimmerman's suite)
  • PowerShell (Native filtering)

# Install Hayabusa (Windows via Scoop)
scoop bucket add extras
scoop install hayabusa

# Chainsaw setup
# Download binary, no install needed
chainsaw.exe --help

1. Initial Triage & Investigation Workflow

When you first open a 20GB Security.evtx file, it's easy to get overwhelmed. Don't just start grep-ing for "Error". You need a workflow that mirrors how an attacker moves.

Prioritization Strategy

1. Security.evtx: This is your primary source of truth. It holds the "Who, What, Where" of authentication.
2. System.evtx: Look here for service installations (PSEXEC leaves traces here) and specific lateral movement indicators like Service Control Manager events (Event ID 7045).
3. Directory Service.evtx: Critical for detecting DCSync, Shadow Credentials, and AdminSDHolder abuse.

Building the Timeline (The Anchor Event)

Find an Anchor Event. This is a confirmed bad event - maybe the time the ransomware note dropped or the time a specific user reported a lockout.

• Work Backward: How did they get the privileges to execute the anchor event?
• Work Forward: What did they do after they got those privileges?

The Forensic Pivot

You must pivot to track lateral movement. Here is the operational loop:

1. Identify Suspicious User: Find a compromised account (e.g., backup_admin).
2. Filter by UserID (SID): See every logon event for that user.
3. Identify Source IP: In Event 4624, look at the "Source Network Address."
4. Pivot to IP: Filter for that IP address to see who else logged in from that compromised machine. This reveals the attacker's pivot point.

Operational Check: If you see a Domain Admin logging in from a workstation that typically only houses marketing interns, you have a confirmed compromise. For more on domain controller attack patterns, see our red teamer guide on Penetration Testing Domain Controllers - this can be very helpful in figuring out how the attacker infiltrated the network.

2. Deep Technical Breakdown – Event IDs & Attack Mapping

Let's map specific Red Team attacks to their Blue Team artifacts using advanced Windows Event Log Analysis.

2.1 Credential Access: Roasting Attacks

Attacking offline material is my favorite way to get passwords without touching LSASS.

Kerberoasting

The Attack: I request a TGS (Service Ticket) for a service account (SQL, IIS). I take the ticket offline and crack the RC4-HMAC hash.

The Artifact: Event 4769 (Kerberos Service Ticket Requested).

Red Flags:

• Encryption Type: 0x17 (RC4). Modern domains use AES (0x11 or 0x12). If I force RC4, I'm likely cracking it.
• Ticket Options: 0x40810000 (Forwardable, Renewable, Canonicalize).
• Service Name: Not krbtgt or $ machine accounts.

AS-REP Roasting

The Attack: I find a user with "Do not require Kerberos preauthentication" enabled. I ask the DC for a TGT. It gives it to me, encrypted with the user's password. I crack it.

The Artifact: Event 4768 (TGT Requested).

Red Flags:

• PreAuthType: 0 (This is the smoking gun).
• Status: 0x0 (Success).

2.2 Lateral Movement & Delegation Abuse

Lateral movement is where the attacker pivots from patient zero to the crown jewels. We look for NTLM abuse and Delegation misuse.

Pass-the-Hash (PtH)

The Attack: Using an NTLM hash to authenticate (no plaintext password needed).

The Artifact: Event 4624 (Logon).

Red Flags:

• Logon Type: 3 (Network).
• Logon Process: NtLmSsp.
• Key Length: 0 (Critical Indicator). A normal NTLM logon usually has a 128-bit session key. Tools like Mimikatz often leave this as 0.
• Account: Targeted user.

Detection Logic: Look for Logon Type 3 events where Key Length is 0 and Authentication Package is NTLM.

Overpass-the-Hash (Pass-the-Key)

The Attack: Using an NTLM hash to request a Kerberos TGT. This upgrades a hash to a full Kerberos ticket.

The Artifact: Event 4768 (TGT Request).

Red Flags:

• PreAuthType: 0x17 (RC4-HMAC). When we use the NTLM hash to encrypt the timestamp in the AS-REQ, it forces RC4 encryption.
• Certificate Information: Blank (Normal smart card logins use PreAuthType 15/16).

Logic: High-privilege users requesting TGTs using RC4 encryption in an environment that enforces AES.

Pass-the-Ticket (PtT)

The Attack: I steal a TGT/TGS from memory and inject it.

The Artifact: Event 4624 (Target Server) & 4769 (DC).

Red Flags:

• Inconsistency: A user accesses a service (Event 4769) from a workstation, but there is no record of that user ever requesting a TGT (Event 4768) from that IP address in the last 10 hours. The ticket appeared out of thin air.

Unconstrained Delegation Abuse

The Attack: I compromise a server trusted for "Unconstrained Delegation." When a Domain Admin connects to it (e.g., via CIFS), their TGT is saved in memory. I steal it.

The Artifact: Event 4624 (Logon) & 4672 (Admin Logon).

Red Flags:

• Look for Domain Admin logons (4624) to servers that are not Domain Controllers.
• Event 4769: The compromised server uses the stolen TGT to request tickets for other services.

Detection: Focus on identifying which machines have Unconstrained Delegation enabled (userAccountControl attribute) and monitoring them closely.

Constrained Delegation Abuse

The Attack: I compromise a user/service allowed to delegate to specific services (e.g., SQL/db01). I use S4U2Self to impersonate any user to myself, then S4U2Proxy to access the target service as that user.

The Artifact: Event 4769.

Red Flags:

• Transited Services: Field in 4769 is non-empty.
• S4U2Self: You see a service requesting a ticket for itself on behalf of a Domain Admin.

Detection Command: Watch for Event 4769 where the Service Name and Account Name are identical (S4U2Self indicator).

Resource-Based Constrained Delegation (RBCD)

The Attack: I compromise an account with GenericWrite over a target computer object. I modify the target's msDS-AllowedToActOnBehalfOfOtherIdentity attribute to trust a machine I control.

The Artifact: Event 5136 (Directory Service Change).

Red Flags:

• Attribute: msDS-AllowedToActOnBehalfOfOtherIdentity.
• Operation: Value Added.

Detection Command (Critical):

# Requires Audit Directory Service Changes enabled
Get-WinEvent -LogName "Directory Service" | Where-Object { 
    $_.Id -eq 5136 -and $_.Properties[4].Value -like "*msDS-AllowedToActOnBehalfOfOtherIdentity*" 
}

2.3 Domain Dominance: Golden & Silver Tickets

Golden Ticket (The King's Keys)

The Attack: I have the krbtgt hash. I forge a TGT valid for 10 years giving me Domain Admin access.

The Artifact:

• Event 4624/4634: I log in and out.
• Negative Correlation: I present a TGT to the DC to get a Service Ticket (4769). The DC validates it because the signature is correct. However, the DC has no log of ever issuing that TGT (Event 4768).
• Time Skew: If you inspect the ticket properties (requires traffic analysis or memory inspection), the End Time will often be 10 years in the future, which violates Domain Policy.

Silver Ticket (Stealth Mode)

The Attack: I have the service account hash for a specific server (e.g., SQL). I forge a TGS for that server. I never talk to the DC.

The Artifact:

• The DC is Blind: There are NO logs on the Domain Controller.
• The Target Knows: The target server will show Event 4624 (Type 3 Kerberos Logon), but the DC will show absolutely nothing for that transaction. This discrepancy is the detector.

DCSync (Replication Abuse)

The Attack: I pretend to be a DC and ask for password hashes using the Directory Replication Service (DRS) Remote Protocol.

The Artifact: Event 4662 (Directory Service Access).

Red Flags:

• Object: Domain-DNS Class.
• Access Mask: 0x100 (Control Access).
• Properties: Contains {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} (DS-Replication-Get-Changes-All).
• Logic: If the "Subject User Name" is NOT a Domain Controller (DC01$), it's an attack.

2.4 Persistence: Object Modification

AdminSDHolder Abuse

The Attack: I add my user to the ACL of the AdminSDHolder object. SDProp (Security Descriptor Propagator) runs every 60 mins and pushes my permissions to all protected groups (Domain Admins, etc.).

The Artifact: Event 5136 (Directory Service Change).

Red Flags:

• Object DN: CN=AdminSDHolder,CN=System,DC=domain...
• Attribute: nTSecurityDescriptor.
• Operation: Value Added.

Detection: Any modification to AdminSDHolder that adds a user who is not a Domain Admin is an immediate critical alert.

Shadow Credentials (Whisker/PyWhisker)

The Attack: I have write access to a computer object. I inject a certificate into the msDS-KeyCredentialLink attribute. I can now authenticate as that machine using PKINIT (Certificate auth).

The Artifact: Event 5136.

Red Flags:

• Attribute: msDS-KeyCredentialLink.

Detection: Monitor 5136 events for this specific attribute. It is rarely changed in a stable environment.

Skeleton Key

The Attack: Malware patched into lsass.exe on the DC. It allows a "master password" to work for ANY account.

The Artifact: Event 4673 / 4611 (Privilege Use - rare).

Red Flags:

• Encryption Downgrade: The malware often downgrades encryption to RC4 or even DES to handle the password validation.
• Event 4624: Multiple accounts logging in from the same source IP using different usernames but generating identical encryption artifacts.

Detection: Hard to detect via logs alone. Best detected by Sysmon looking for process injection into LSASS on DCs.

Summary: Attack to Event ID Mapping

Attack	Critical Event IDs	Key Field / Artifact
Kerberoasting	4769	Ticket Encryption: 0x17 (RC4), Service != krbtgt
AS-REP Roasting	4768	PreAuthType: 0
Pass-the-Hash	4624	Logon Type: 3, Key Length: 0, Process: NtLmSsp
Overpass-the-Hash	4768	PreAuthType: 0x17 (RC4)
Silver Ticket	4624 (Target)	Kerberos Logon without preceding 4768/4769 on DC
Golden Ticket	4769	TGS Request without preceding TGT Request (4768)
DCSync	4662	Access Mask: 0x100, Properties: 1131f6aa...
RBCD	5136	Attribute: msDS-AllowedToActOnBehalfOfOtherIdentity
Shadow Creds	5136	Attribute: msDS-KeyCredentialLink
AdminSDHolder	5136	Object: AdminSDHolder, Attribute: nTSecurityDescriptor

3. Practical Log Analysis Techniques & Tooling

You can't do this manually line-by-line. Use these tools to filter the noise.

PowerShell Hunting (Live or Mounted)

Using Get-WinEvent with FilterXPath is the fastest way to query raw logs without third-party tools.

PowerShell

# Hunt for DCSync (Requires Audit Directory Service Access enabled)
$DCSyncGUID = "{1131f6aa-9c07-11d1-f79f-00c04fc2dcd2}"
Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=4662] and EventData[Data[@Name='Properties'] and (contains(., '$DCSyncGUID'))]]"

# Hunt for Kerberoasting (RC4 Encryption)
Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=4769] and EventData[Data[@Name='TicketEncryptionType']='0x17'] and EventData[Data[@Name='TicketOptions']='0x40810000']]"

Chainsaw (The Sledgehammer)

Chainsaw parses logs against Sigma rules. It's my go-to for "what did I miss?"

Bash

# Search specifically for credential dumping and kerberos attacks
./chainsaw search ./logs/Security.evtx --mapping mappings/sigma-event-logs.yml --rules rules/ --tag "kerberos" --tag "credential_access"

Timeline Explorer & CSV

1. Use EvtxECmd.exe to convert the Security.evtx to CSV.

   Bash

   EvtxECmd.exe -f Security.evtx --csv c:\temp\out.csv

2. Open in Timeline Explorer.
3. Group by Event ID.
4. Color Code:
   • 4624 (Logon) -> Green
   • 4625 (Fail) -> Red
   • 4768/4769 (Kerberos) -> Orange
   • 4662 (Object Access) -> Purple
5. Look for "Success" events (Green) immediately following a block of "Failures" (Red). That's your brute force breakthrough.

4. SIEM-Based Detection & Correlation

If you have a SIEM (Splunk, Sentinel, ELK), you need logic, not just signatures. See MITRE ATT&CK for more context on these techniques.

Detection Strategy: Volume vs. Anomaly

• Roasting = Volume. I need to request tickets to crack them. One ticket is normal; 50 in a minute is an attack.
• Forgery = Anomaly. I am creating things that shouldn't exist.

Splunk Query: Kerberoasting

Code snippet

index=wineventlog EventCode=4769 TicketEncryptionType=0x17 ServiceName!="*$"
| bucket _time span=5m
| stats dc(ServiceName) as unique_targets by src_user
| where unique_targets > 5

Logic: Alert if one user requests RC4 tickets for >5 distinct services in 5 minutes.

Splunk Query: Golden Ticket (The Gap Analysis)

Code snippet

index=wineventlog EventCode=4769
| join type=left src_user [ search index=wineventlog EventCode=4768 | eval has_tgt="yes" ]
| where isnull(has_tgt)

Logic: Find a Service Ticket Request (4769) where that user has NO TGT Request (4768) in the logs.

5. Red Team Insight (The Adversary Perspective)

This is the section where I tell you how we beat your SOC.

Why We Choose Kerberos

We abuse Kerberos because it is trusted. NTLM is loud and being deprecated. Kerberos is the native language of AD. If I speak the language fluently, I look like a local.

Evasion & Blind Spots

1. AES Downgrade Avoidance: Sophisticated attackers stop using RC4. We extract AES keys from compromised hosts. If I use AES to Kerberoast, your "Encryption Type 0x17" alert is useless. You must alert on volume regardless of encryption type.
2. The "Low and Slow" Approach: I will request one Service Ticket every 30 minutes. It takes me longer, but it keeps me under your velocity thresholds.
3. Hiding in Plain Sight: For DCSync, I won't use the Administrator account. I will compromise a legitimate backup service account that should be replicating data. If you don't baseline what "normal" replication looks like, you will miss me.

Where Defenders Fail

You fail when you only look for failures.

I am a Senior Red Teamer. I don't guess passwords. I steal hashes. I steal tickets. My logins succeed.

If you aren't hunting for anomalous successes - logins at 3 AM, logins to servers marketing shouldn't touch, logins via RDP from a workstation that usually only does SMB - then you are only catching the script kiddies, not the operators. This mindset shift is essential for effective Windows Event Log Analysis.

Conclusion

Forensics is about reconstructing a story from fragments. The logs tell the truth, but they whisper.

• Event 4769 (RC4) whispers "Kerberoasting."
• Event 4662 (GUID) whispers "DCSync."
• Event 4624 (Key Length 0) whispers "Pass-the-Hash."

Take these IDs, put them into your tool of choice, and build the timeline. If you follow the authentication trail, you will find the breach. For further reading on securing your environment, check our guide on Active Directory Pentest. Also, verify your detection logic against official Microsoft Audit Policy Recommendations.

Note: Before pentesting any system or performing live forensics, have proper authorization from concerned authorities and follow ethical guidelines.

Enjoyed this guide? Share your thoughts below and tell us how you leverage Windows Event Log Analysis in your projects!

Windows Event Log Analysis, Kerberos Attacks, Active Directory Forensics, Red Team Guide, Event ID 4769, Event ID 4624, Cyber Security