Active Directory is where almost every enterprise breach either starts or passes through. Attackers who get a foothold on a workstation spend their next hours trying to escalate to domain admin — and most of that path runs through AD. The techniques are well documented. The detection queries exist. What most environments are missing is having those queries actually tuned and running.
This post covers the AD attack techniques that show up most consistently in real incidents, the events that expose them, and production detection queries you can run today in Sentinel, Splunk, or CrowdStrike.
Why AD Is the Highest-Value Monitoring Target
38% of attacks in 2026 begin with identity compromise according to Wavestone IR data — up from 20% in 2024. That number isn't surprising to anyone who's worked real incidents. AD sits at the center of authentication, authorization, group membership, and policy for every Windows environment. When an attacker controls AD, they control everything it controls.
The attack chain is almost always the same: initial foothold on a workstation → credential theft or enumeration → lateral movement using stolen credentials → privilege escalation to domain admin → mission completion (ransomware, data theft, or persistent access). Every step in that chain leaves traces in AD logs. The question is whether you're watching for them.
Everything in this post requires Windows Security Event Log forwarding from domain controllers to your SIEM — specifically the Security channel. If your DCs aren't forwarding logs to Sentinel or Splunk, these queries won't find anything. Verify DC log ingestion before building detections around any of this.
1. DCSync Detection
DCSync is one of the most dangerous techniques in an attacker's toolkit. It abuses the legitimate AD replication protocol to pull password hashes directly from a domain controller — without touching LSASS, without running any code on the DC itself. An attacker with the right privileges can run Mimikatz's DCSync from any machine on the network and silently extract every domain account's hash.
The detection relies on Event ID 4662 — Directory Service Access — which fires when an account requests specific AD replication permissions. Legitimate replication only happens between domain controllers. When a non-DC machine account triggers 4662 with replication-specific GUIDs, that's your signal.
SecurityEvent | where TimeGenerated > ago(1d) | where EventID == 4662 | where Properties has_any( "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2", "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2", "89e95b76-444d-4c62-991a-0facbeda640c" ) // Exclude legitimate DC machine accounts | where SubjectUserName !endswith("$") | where SubjectUserName !in("MSOL_*", "AADConnect") | project TimeGenerated, Computer, SubjectUserName, SubjectDomainName, ObjectName, Properties | order by TimeGenerated desc
The three GUIDs are the Replicating Directory Changes, Replicating Directory Changes All, and Replicating Directory Changes in Filtered Set permissions. Any non-DC account triggering these is requesting replication rights it should never have.
index=win_* sourcetype="WinEventLog:Security" EventCode=4662 earliest=-24h latest=now (Properties="*1131f6aa*" OR Properties="*1131f6ad*" OR Properties="*89e95b76*") | where NOT match(Subject_Account_Name, "\$$") | stats count values(Properties) as ReplicationRights by Subject_Account_Name host | sort - count
2. Kerberoasting Detection
Kerberoasting targets service accounts with Service Principal Names set in AD. An attacker requests a Kerberos service ticket for that SPN — which is a completely legitimate operation any domain user can do — and then takes the encrypted ticket offline to crack. If the service account has a weak password, the attacker now has plaintext credentials for a service account that often has elevated privileges.
Detection relies on Event ID 4769 — Kerberos Service Ticket Requested. The specific signal is RC4 encryption (ticket options 0x17) being requested for a service account. Modern environments use AES encryption by default. RC4 requests against service accounts with SPNs at volume is a Kerberoasting indicator.
SecurityEvent | where TimeGenerated > ago(1d) | where EventID == 4769 | where TicketEncryptionType == "0x17" | where TicketOptions == "0x40810000" // Exclude machine accounts and krbtgt | where ServiceName !endswith("$") | where ServiceName !in("krbtgt", "kadmin/changepw") | summarize RequestCount = count(), Services = make_set(ServiceName), SourceIPs = make_set(IpAddress) by AccountName, bin(TimeGenerated, 1h) | where RequestCount > 3 | order by RequestCount desc
The threshold of 3 requests per hour is a starting point. Some legitimate applications request multiple service tickets. Baseline your environment first — check what normal RC4 ticket request volume looks like per account over 30 days before setting the threshold. Anything that looks like enumeration (many different service accounts requested by one user in a short window) is your highest-priority alert regardless of threshold.
3. Pass-the-Hash and NTLM Lateral Movement
Pass-the-hash uses a stolen NTLM hash to authenticate without knowing the plaintext password. The detection relies on Event ID 4624 Type 3 logons using NTLM authentication from workstation-class source IPs to server-class destinations — particularly when those authentications happen at volume or to targets the account has never touched before.
SecurityEvent | where TimeGenerated > ago(1d) | where EventID == 4624 | where LogonType == 3 | where AuthenticationPackageName == "NTLM" | where SubjectUserName !endswith("$") | where IpAddress !in("127.0.0.1", "::1", "-") | summarize AuthCount = count(), TargetHosts = dcount(Computer), TargetHostList = make_set(Computer) by SubjectUserName, IpAddress | where TargetHosts >= 3 | order by TargetHosts desc
4. Privilege Escalation — Group Membership Changes
Any account added to Domain Admins, Enterprise Admins, or local Administrators outside of a known change window should be treated as a confirmed incident until proven otherwise. This technique is used in virtually every ransomware pre-deployment chain — attackers need domain admin to push the encryptor via GPO or remote execution.
SecurityEvent | where TimeGenerated > ago(7d) | where EventID in(4728, 4732, 4756) | where TargetUserName in~( "Domain Admins", "Enterprise Admins", "Schema Admins", "Administrators", "Account Operators", "Backup Operators", "Print Operators", "Server Operators" ) | where SubjectUserName !endswith("$") | project TimeGenerated, Computer, EventID, SubjectUserName, MemberName, TargetUserName | order by TimeGenerated desc
Any account added to Domain Admins or Enterprise Admins outside of a ticketed change window is a P1 alert. Don't wait for investigation before escalating. Isolate first, investigate second — the same rule that applies to ransomware applies here because this is often the step immediately before ransomware deployment.
5. AD Enumeration — BloodHound and LDAP Reconnaissance
Before attackers move laterally they map the environment — which accounts have what privileges, which machines are high value, what attack paths exist to domain admin. BloodHound and similar tools do this via LDAP queries that generate significant event volume in a short window. The signal is a single account making hundreds of LDAP queries in minutes against the domain controller.
// BloodHound-style LDAP recon detection #event_simpleName=DnsRequest | regex("ldap", field=DomainName, flags=i) | groupBy([UserName, ComputerName], function=count(), as=LDAPQueries) | where LDAPQueries > 200 | sort(LDAPQueries, order=desc) // Also check 4662 for LDAP object access volume
index=win_* sourcetype="WinEventLog:Security" EventCode=4662 Object_Type="organizationalUnit" earliest=-1h latest=now | stats count as QueryCount dc(Object_Name) as UniqueObjects by Subject_Account_Name host | where QueryCount > 100 | sort - QueryCount
6. Golden Ticket Detection
A Golden Ticket is a forged Kerberos TGT using the krbtgt account hash. Once an attacker has the krbtgt hash (usually via DCSync) they can generate tickets for any account, with any group membership, valid for any duration. Detection is difficult because the tickets themselves look legitimate. The signal is a TGT with an unusually long lifetime or a TGS request where the TGT duration doesn't match expected policy.
SecurityEvent | where TimeGenerated > ago(1d) | where EventID == 4768 | extend TicketLifetime = datetime_diff( 'minute', TicketExpirationTime, TimeGenerated) // Default TGT lifetime is 600 minutes (10 hours) // Golden tickets are often set to 10 years | where TicketLifetime > 1440 | where TargetUserName !endswith("$") | project TimeGenerated, Computer, TargetUserName, TargetDomainName, TicketLifetime, IpAddress | order by TicketLifetime desc
Building AD Monitoring Into Your Detection Program
These six techniques cover the most common AD attack paths. The right way to operationalize them is in layers — start with the highest-signal detections (DCSync and privileged group membership changes) since both have very low false positive rates, get those tuned and alerting properly, then layer in the higher-volume detections (Kerberoasting, NTLM lateral movement) with appropriate baselining.
- DCSync and Golden Ticket — almost zero false positives, alert on any hit, treat as P1 by default
- Privileged group changes — low false positives, easy to baseline against change management records
- Kerberoasting — moderate tuning required, baseline RC4 ticket volume per environment first
- NTLM lateral movement — higher volume, needs per-account baselining to reduce noise
- LDAP enumeration — tune threshold to your environment, some admin tools generate legitimate LDAP volume
Every issue includes a production detection rule — often targeting exactly these AD techniques — with required log sources, false positive guidance, investigation steps, MITRE mapping, and ticket wording. Built from 10 years of real SOC operations at major financial institutions.
Join — $14.99/mo See a Sample Issue