ArticlesOctober 14, 202612 min read

Active Directory SIEM Use Cases: 22 Detections and Event IDs

By UTMStack Team

Almost every serious intrusion on a Windows network ends up in Active Directory. Attackers steal a password, look for a service account they can crack, add themselves to a privileged group and then copy the domain’s password database. Each of those steps leaves a trace in the Security log of a domain controller, if the right auditing is turned on and something is reading the log.

This guide lists the Active Directory use cases worth running in any SIEM, the Windows event IDs each one depends on, and what the detection actually looks for. For each one we also say whether UTMStack ships the rule out of the box or whether you add it yourself. If you are still setting up auditing, start with our Active Directory auditing guide and come back.

The short answer: the highest-value Active Directory detections are Kerberoasting (event 4769 with RC4 tickets), AS-REP roasting (4768 without pre-authentication), DCSync (4662 with replication rights from a machine that is not a domain controller), changes to privileged groups (4728, 4732, 4756), AdminSDHolder tampering (5136), theft of the NTDS.dit database, password spraying (4625 and 4771 across many accounts) and a cleared Security log (1102).

Where each detection catches an attacker

The 22 use cases along a typical Active Directory attack, with the Windows event IDs each one reads

Ships with UTMStackAdd as a custom rule

Get inGuess or reuse a password
Brute force4625, 4624Password spraying4625, 4771 customPass-the-hash4624
Steal credentialsCrack or copy secrets
Kerberoasting4769AS-REP roasting4768LSASS memory access4656DPAPI backup key4662
Gain privilegeBecome an administrator
Privileged group change4728, 4732, 4756 customNew or re-enabled account4720, 4722 customCertificate Services abuse4886, 4887
Own the domainTake every password
DCSync4662 customNTDS.dit extraction4656, 4663Golden ticket4768, 4769, 4672Silver ticket4769
Stay and hideKeep access, erase traces
AdminSDHolder change5136SID history injection4765, 4766Group Policy change5136, 5137 customDSRM password set4794 customSecurity log cleared1102Audit policy changed4719 customNTLM downgrade4657AD FS token failures342, 516

Catching an attacker in the first two stages is cheapest. By the fourth, assume every password in the domain is known.

Before you start: the audit settings these detections need

Most failed Active Directory detections fail for a dull reason: the event was never written. Windows does not log most of these events by default. Set these Advanced Audit Policy subcategories on your domain controllers through Group Policy:

Audit subcategory	Setting	Events it produces
Kerberos Authentication Service	Success and Failure	4768, 4771
Kerberos Service Ticket Operations	Success and Failure	4769
Credential Validation	Success and Failure	4776
Logon / Special Logon	Success and Failure / Success	4624, 4625, 4672
User Account Management	Success and Failure	4720, 4722, 4738, 4740, 4765, 4766, 4794
Security Group Management	Success	4728, 4732, 4756
Directory Service Access	Success and Failure	4662
Directory Service Changes	Success	5136, 5137
Audit Policy Change	Success	4719
File System, Registry, Kernel Object	Success (with SACLs on the targets)	4656, 4657, 4663
Certification Services (on CA servers)	Success and Failure	4886, 4887

Two practical notes. Events 4662 and 5136 only appear for objects that carry a system access control list (SACL), so add auditing entries on the domain root and on sensitive objects such as AdminSDHolder. And raise the Security log size on domain controllers well above the default, or forward events continuously, so nothing rolls over before your SIEM collects it.

Credential attacks

1. Password brute force

Events: 4625 (failed logon), followed by 4624 (successful logon). Look for: many failures for one account from one source in a short window, and especially a success right after the failures. The second pattern matters more: a burst of failures followed by a success often means the attacker found the password. MITRE ATT&CK: T1110. UTMStack: built in, as two rules (failures alone, and failures followed by success).

2. Password spraying

Events: 4625 and 4771 (Kerberos pre-authentication failed, failure code 0x18 for a bad password). Look for: one source failing against many different accounts with few attempts each. Sprayers stay under the lockout threshold, so per-account counting misses them; count distinct accounts per source instead. MITRE ATT&CK: T1110.003. UTMStack: add as a custom rule that counts distinct users per source address.

3. Pass-the-hash

Events: 4624 with logon type 3 over NTLM and a key length of 0, or logon type 9 with the seclogo logon process. Look for: network logons that authenticate with a stolen hash instead of a password, typically from a workstation to servers it does not normally reach. MITRE ATT&CK: T1550.002. UTMStack: built in.

4. Kerberoasting

Events: 4769 (Kerberos service ticket requested) with ticket encryption type 0x17 (RC4). Look for: service tickets requested with weak RC4 encryption for accounts other than krbtgt, especially many in a row from one user. Attackers request these tickets to crack service account passwords offline. Modern domains should use AES (types 0x11 and 0x12), so RC4 requests stand out. MITRE ATT&CK: T1558.003. UTMStack: built in.

5. AS-REP roasting

Events: 4768 (Kerberos ticket-granting ticket requested) with pre-authentication type 0 and RC4 encryption. Look for: ticket requests for accounts that have “Do not require Kerberos preauthentication” set. Any such account can be cracked offline, so also review which accounts have the flag. MITRE ATT&CK: T1558.004. UTMStack: built in.

6. Golden ticket

Events: 4768, 4769 and 4672, read together. Look for: service tickets used without a matching ticket-granting ticket request, tickets with unexpected encryption types, and special privileges such as SeTcbPrivilege appearing on logons that should not have them. A golden ticket means the krbtgt account’s key was stolen, so treat it as a full domain compromise. MITRE ATT&CK: T1558.001. UTMStack: built in.

7. Silver ticket

Events: 4769 and service logon events. Look for: access to a specific service with forged service tickets, seen as service tickets without a ticket-granting ticket request and unusual Kerberos patterns. Silver tickets often follow a successful Kerberoast of the same service account. MITRE ATT&CK: T1558.002. UTMStack: built in.

8. LSASS memory access

Events: 4656 (handle to an object requested) on lsass.exe with access rights used by dumping tools. Look for: processes other than known security software opening the LSASS process with read rights. This is how tools pull passwords and hashes from memory. MITRE ATT&CK: T1003.001. UTMStack: built in.

Domain database theft

9. DCSync

Events: 4662 with the replication rights DS-Replication-Get-Changes (1131f6aa-9c07-11d1-f79f-00c04fc2dcd2), DS-Replication-Get-Changes-All (1131f6ad-9c07-11d1-f79f-00c04fc2dcd2) or DS-Replication-Get-Changes-In-Filtered-Set (89e95b76-444d-4c62-991a-0facbeda640c). Look for: replication requests from an account or address that is not a domain controller. Only domain controllers replicate; anyone else asking for password data is pulling every hash in the domain. MITRE ATT&CK: T1003.006. UTMStack: add as a custom rule; keep a list of your domain controller accounts as the exception.

10. NTDS.dit extraction

Events: 4656 and 4663 on files under the NTDS folder, plus process creation for tools such as ntdsutil or vssadmin. Look for: anything reading the Active Directory database file or creating a volume shadow copy on a domain controller outside a backup window. MITRE ATT&CK: T1003.003. UTMStack: built in (needs a SACL on the NTDS folder).

11. DPAPI backup key theft

Events: 4662 on a SecretObject whose name contains BCKUPKEY. Look for: access to the domain’s DPAPI backup key, which lets an attacker decrypt protected secrets such as saved browser passwords for every user. MITRE ATT&CK: T1003.004. UTMStack: built in.

Privilege and persistence

12. Changes to privileged groups

Events: 4728 (added to a global security group), 4732 (local or domain local group), 4756 (universal group). Look for: any addition to Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Backup Operators or other groups you consider privileged. These groups change rarely, so every event deserves a look. MITRE ATT&CK: T1098. UTMStack: add as a custom rule with your list of privileged groups. A ready-made response flow that disables the added account is included; point it at your rule.

13. AdminSDHolder tampering

Events: 4662, 5136 and 4670 on CN=AdminSDHolder,CN=System. Look for: writes or permission changes to the AdminSDHolder object. Every hour Active Directory copies its permissions onto protected accounts, so an attacker who edits it keeps admin rights even after you remove them from a group. MITRE ATT&CK: T1098. UTMStack: built in, with a response flow that disables the account that made the change.

14. SID history injection

Events: 4765 (SID history added to an account) and 4766 (attempt failed). Look for: any SID history change outside a planned domain migration. Adding an administrator’s security identifier to an ordinary account gives it the same rights silently. MITRE ATT&CK: T1134.005. UTMStack: built in.

15. New or re-enabled accounts

Events: 4720 (user account created), 4722 (account enabled), 4738 (account changed). Look for: accounts created outside your provisioning process, by unexpected administrators, or at unusual hours, and old accounts that suddenly come back to life. MITRE ATT&CK: T1136.002. UTMStack: add as a custom rule; exclude your identity management service account.

16. Directory Services Restore Mode password change

Events: 4794. Look for: any attempt to set the DSRM administrator password. That account is a local administrator on the domain controller and is a known way to keep a back door. MITRE ATT&CK: T1098. UTMStack: add as a custom rule.

17. Group Policy changes

Events: 5136 and 5137 on groupPolicyContainer objects. Look for: edits to Group Policy objects linked to domain controllers or to the whole domain. Attackers use them to push scheduled tasks or scripts to every machine at once. MITRE ATT&CK: T1484.001. UTMStack: add as a custom rule.

18. AD Certificate Services abuse

Events: 4886 (certificate request received) and 4887 (certificate issued) on certificate authority servers. Look for: certificate requests by machine accounts or anonymous logons, and certificates issued for templates that let the requester choose the subject. Forged certificates can authenticate as any user, including domain admins. MITRE ATT&CK: T1649. UTMStack: built in.

Defense evasion

19. Security log cleared

Events: 1102. Look for: the Security log being cleared on any domain controller or server. It is almost never legitimate, and it usually means someone is covering their tracks. MITRE ATT&CK: T1070.001. UTMStack: built in.

20. Audit policy changed

Events: 4719. Look for: auditing being switched off for a category, which blinds every detection above it. MITRE ATT&CK: T1562.002. UTMStack: add as a custom rule.

21. NTLM downgrade

Events: 4657 (registry value modified) on LmCompatibilityLevel, NtlmMinClientSec or NtlmMinServerSec. Look for: settings lowered to allow LM or NTLMv1, which makes captured credentials easy to crack and relay. MITRE ATT&CK: T1562.001. UTMStack: built in.

22. AD FS token validation failures

Events: AD FS events 342 and 516. Look for: repeated token validation failures on your federation servers, which can point to forged tokens or password attacks against single sign-on. MITRE ATT&CK: T1078. UTMStack: built in.

All 22 at a glance

#	Use case	Key event IDs	UTMStack
1	Password brute force	4625, 4624	Built in
2	Password spraying	4625, 4771	Custom rule
3	Pass-the-hash	4624	Built in
4	Kerberoasting	4769	Built in
5	AS-REP roasting	4768	Built in
6	Golden ticket	4768, 4769, 4672	Built in
7	Silver ticket	4769	Built in
8	LSASS memory access	4656	Built in
9	DCSync	4662	Custom rule
10	NTDS.dit extraction	4656, 4663	Built in
11	DPAPI backup key theft	4662	Built in
12	Privileged group changes	4728, 4732, 4756	Custom rule
13	AdminSDHolder tampering	4662, 5136, 4670	Built in
14	SID history injection	4765, 4766	Built in
15	New or re-enabled accounts	4720, 4722, 4738	Custom rule
16	DSRM password change	4794	Custom rule
17	Group Policy changes	5136, 5137	Custom rule
18	Certificate Services abuse	4886, 4887	Built in
19	Security log cleared	1102	Built in
20	Audit policy changed	4719	Custom rule
21	NTLM downgrade	4657	Built in
22	AD FS token failures	342, 516	Built in

Which to turn on first

If you can only do a few this week, pick the ones with the fewest false alarms and the worst outcome if missed:

DCSync, golden ticket and NTDS.dit extraction. Any of these means the attacker already has, or is about to have, every password in the domain.
Privileged group changes and AdminSDHolder. Rare in normal operations, decisive in an attack.
Security log cleared and audit policy changed. Cheap to run and they protect every other detection.
Kerberoasting and AS-REP roasting. Easy to detect once RC4 is rare in your domain, and they catch attackers early.
Brute force and password spraying. Noisier, so tune them with exceptions for known scanners and service accounts.

How to keep the noise down

Active Directory rules fail in practice for two reasons: they fire too often, or they never fire because a log source stopped. A few habits help with both:

Build exception lists once. Domain controllers for replication, your identity management service for account creation, your vulnerability scanner for failed logons. Reference the lists from every rule instead of editing each rule.
Watch for missing logs, not just bad ones. An alert when a domain controller stops sending events catches failed agents, full disks and attackers who stop the logging service.
Correlate across sources. A Kerberoast from a workstation that also shows a new PowerShell download in its endpoint logs is a much stronger signal than either event alone.
Attach a response. For the decisive detections, have the SIEM disable the account or isolate the machine automatically, with a person reviewing afterwards.

How UTMStack handles Active Directory

UTMStack collects Windows events through its agent, normalizes them and checks each event against its detection rules as it arrives, before it is stored, so an alert fires in seconds rather than after a scheduled search. The Windows rule set includes the built-in detections in this list, each mapped to MITRE ATT&CK, and you can write the custom ones in the rule editor using the same fields. Alerts can trigger response flows that disable an account, block an address or isolate a host, and the same events feed the audit logging controls in its compliance reports.

See it on sample data in the live demo, or install the free edition and point a domain controller at it. For the broader picture of Windows logging, read our Windows event log analysis guide.

Frequently asked questions

What are the most important Windows event IDs for Active Directory security? 4624 and 4625 (logons), 4768, 4769 and 4771 (Kerberos), 4662 and 5136 (directory access and changes), 4728, 4732 and 4756 (privileged group changes), 4720 (new accounts), 4719 (audit policy changes) and 1102 (Security log cleared).

Do I need to collect logs from every domain controller? Yes. Kerberos and logon events are written by the domain controller that handled the request, so an attacker’s activity can land on any of them. Missing one controller leaves a blind spot.

Why does my SIEM never see event 4662? Directory Service Access auditing must be enabled, and the objects you care about need a SACL with auditing entries. Without the SACL, Windows does not write the event.

Can these detections run in a free SIEM? Yes. UTMStack’s free Community edition includes the Windows agent, the built-in Windows rules and the rule editor for custom rules.

How do I test that the detections work? Run the matching tests from an open source library such as Atomic Red Team in a lab domain, then confirm each one raises the expected alert. Repeat after every major change to auditing or rules.