Module 10 · AD Detection — What Good Looks Like

Last updated: April 29, 2026

Every attack in this track leaves footprints in AD logs, Sysmon events, EDR telemetry, and domain controller security logs. Most go undetected because organizations either don’t collect the right logs, don’t write detection rules for AD-specific TTPs, or don’t have the process to respond to alerts in time. This closing module covers what AD detection looks like when done right.

Why AD detection is hard

• Volume. DCs generate thousands of events per second in busy environments. Signal to noise is brutal without tuning.
• Normal admin = suspicious attacker. DCSync is used legitimately by replication (normal) and by attackers (suspicious). Distinguishing requires context (source, time, frequency).
• Default log coverage insufficient. Windows default Security logs capture much but miss things like PowerShell script content, ACL changes without auditing explicitly enabled.
• Cross-source correlation required. “Unusual Kerberos ticket” is partial; combined with “unusual process on endpoint” it’s high-confidence.

Critical log sources for AD detection

# Domain Controllers — Security log events to ingest:
# 4624  Successful logon
# 4625  Failed logon
# 4768  TGT request (Kerberos authentication)
# 4769  TGS request (Kerberos service ticket) ← Kerberoasting signal
# 4662  Operation performed on AD object ← DCSync signal
# 4672  Special privileges assigned to new logon ← admin logon
# 4698  Scheduled task created (persistence)
# 4720  User account created
# 4732  Member added to security-enabled local group
# 4756  Member added to security-enabled universal group (Enterprise Admins)
# 5136  Directory service object modified ← ACL changes

# Endpoints — Sysmon + Windows event logs:
# Sysmon 1  Process creation
# Sysmon 3  Network connection
# Sysmon 7  Image loaded
# Sysmon 10 Process access (Mimikatz to LSASS)
# Sysmon 11 File created
# 4688      Process creation (native Windows)

# Enable: Advanced Audit Policies for these event IDs
# Audit Kerberos Authentication Service, Audit Kerberos Service Ticket Operations
# Audit Directory Service Changes, Audit Directory Service Access

Core detection rules

Kerberoasting

# Multiple TGS requests from one account for different SPNs in short window
# Sigma rule example
title: Kerberoasting activity
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4769
    TicketEncryptionType: '0x17'  # RC4 (attacker preference)
    TicketOptions: '0x40810000'
  filter:
    ServiceName|endswith: '$'      # computer accounts, ignore
  condition: selection and not filter
# Followed by: aggregate by AccountName, count distinct ServiceName > 10 in 10 min

DCSync detection

# Event 4662 with replication GUIDs
# From a source that isn't another DC

title: DCSync Attack
detection:
  selection:
    EventID: 4662
    Properties|contains:
      - '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'  # DS-Replication-Get-Changes
      - '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'  # DS-Replication-Get-Changes-All
  filter:
    AccountName|endswith: '$'  # Ignore legitimate DC replication
  condition: selection and not filter

Golden/Silver Ticket

Hard to detect directly. Indirect indicators:

• TGT with unusual lifetime (default 10 hours; forged tickets often 10 years)
• Kerberos pre-auth missing for TGT use
• Mismatched domain controllers in event chain
• Service ticket without corresponding TGT request (Silver Ticket)

ACL changes to sensitive objects

# Event 5136 on AdminSDHolder or privileged groups
title: ACL change on sensitive AD object
detection:
  selection:
    EventID: 5136
    ObjectDN|contains:
      - 'AdminSDHolder'
      - 'CN=Domain Admins'
      - 'CN=Enterprise Admins'
      - 'CN=Schema Admins'
  condition: selection

Unconstrained delegation + coercion

• Event 4624 type 3 (network logon) from DC to workstation (unusual)
• SMB access patterns from DCs to endpoints
• Spooler service activity on DCs (shouldn’t be running)

BloodHound / SharpHound activity

• LDAP queries with unusual patterns (many filter types, sequential)
• SharpHound PE signature in process creation events
• Registry access to HKLM\SAM (local account enumeration)
• SMB session enumeration patterns

Commercial detection products

• Microsoft Defender for Identity (MDI): reads AD event logs + passive traffic. Detects Kerberoasting, DCSync, Golden Ticket attempts, SharpHound, and many more. Built into M365 E5.
• CrowdStrike Falcon Identity Protection: similar capabilities, integrated with Falcon EDR.
• Semperis Directory Services Protector: AD-focused; attack path monitoring + rollback.
• Tenable Identity Exposure: AD hygiene + attack detection.
• PingCastle + Purple Knight: free posture scanning (not real-time detection).

Defender for Identity specifics

MDI has built-in detections for:

• Reconnaissance: LDAP enumeration, SMB session enumeration, account enumeration
• Lateral movement: PtH, PtT, Overpass-the-Hash
• Privilege escalation: Kerberoasting, DCSync, Skeleton Key, AdminSDHolder tampering
• Persistence: Golden Ticket use, DSRM manipulation, suspicious group changes

Pair with Microsoft Defender XDR for cross-domain correlation (endpoint + identity + email + cloud).

Threat hunting queries (KQL for Sentinel/Defender XDR)

# Accounts with high number of Kerberos service tickets
SecurityEvent
| where EventID == 4769
| summarize count() by TargetUserName, bin(TimeGenerated, 10m)
| where count_ > 10
| order by count_ desc

# Unusual source for DCSync
SecurityEvent
| where EventID == 4662
| where Properties contains "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2"
| where not (SubjectUserName endswith "$")
| project TimeGenerated, Computer, SubjectUserName, IpAddress

# Logon from unusual geo for admin account
SigninLogs
| where UserPrincipalName in (get_admin_list())  # custom function
| where Location != "India"
| where ResultType == "0"
| project TimeGenerated, UserPrincipalName, IPAddress, Location

Detection maturity model for AD

1. L0: Default Windows logging only. Nobody reviews.
2. L1: Security logs forwarded to SIEM. Generic SIEM rules enabled.
3. L2: AD-specific detection rules deployed and tuned. MDI or equivalent integrated.
4. L3: Threat hunting on AD data quarterly. Purple team exercises validate detection coverage.
5. L4: Continuous posture measurement + automated response (SOAR playbooks for Kerberoast detected, auto-lockdown attacker-added accounts, etc.)

Most enterprises are L1-L2 in 2026. Getting to L3 is high-value.

Response playbooks for common AD attacks

Once detected, response:

• Kerberoasting detected: force password reset on targeted service account + investigate attacker foothold
• DCSync detected: treat as emergency — rotate krbtgt twice, reset all admin passwords, investigate compromise path
• Golden Ticket detected/suspected: rotate krbtgt twice (days apart), re-image affected systems, full IR
• ACL tampering on AdminSDHolder: restore from backup AD, investigate, document
• PetitPotam/PrinterBug/DFSCoerce attempts: verify DC patches, verify disabled spooler, investigate source

Mindset takeaway

Every AD attack in this track is detectable with the right logs and rules. The reason attacks succeed isn’t undetectable technique — it’s absent detection. Invest in the log sources, the detection rules, and the response processes. In that order.

This closes the AD Mindset track. Across 10 modules: fragile-by-design, enumeration, BloodHound, ACL abuse, GPP, ADCS, trusts, delegation, hybrid, detection. The through-line: AD trusts by default; defender’s job is to remove unnecessary trust and detect abuse of the trust that remains.