Active Directory Monitoring: Security Event IDs That Matter

What Is Active Directory Monitoring?

Active Directory monitoring is the combination of audit policy, event collection, correlation, and baseline analysis needed to detect identity attacks against Domain Controllers and privileged accounts. Many AD environments generate Windows Security events, but far fewer generate the right events and route them into detections that an analyst can actually use.

Monitoring in AD is not just log retention. It is the discipline of choosing the subcategories that matter, proving the events are present on Domain Controllers, and building detections around attacker behavior rather than raw volume.

A useful AD monitoring program starts with the attack paths defenders actually need to see: Kerberos ticket abuse, DCSync, privileged group changes, directory-object writes, NTLM authentication, certificate issuance, and lateral movement into sensitive servers.

How Active Directory Monitoring Works

Windows Security auditing is controlled by Advanced Audit Policy and only produces useful data if the right subcategories are enabled.

A practical monitoring pipeline looks like this:

1. Advanced Audit Policy enables the events you need
2. Windows Event Log stores the Security events locally
3. WEF or an agent forwards the events to a central platform
4. SIEM correlation turns those events into detections and investigations

The most common failure is still step one: the collector and SIEM exist, but key AD subcategories were never enabled on the Domain Controllers that matter.

Microsoft Defender for Identity documentation reinforces this point by listing required Windows events for sensors and related infrastructure. The list includes core identity events such as 4662, 4728, 4732, 4756, 4769, and 4776. If your domain controllers do not generate and forward those events, downstream detection logic cannot recover the missing evidence.

The Attack Chain Without Monitoring

DCSync - No Directory Service Access Auditing

Without Audit Directory Service Access, event 4662 does not give defenders the visibility they expect for replication-rights abuse. Event 4662 is generated when an operation is performed on an Active Directory object, but object auditing and SACL configuration still matter for useful coverage.

Kerberoasting - No Kerberos Ticket Visibility

Without 4769 collection and review, unusual service-ticket requests blend into normal traffic and RC4-heavy requests are easy to miss. Microsoft documents event 4769 as a TGS request event generated on domain controllers. Newer Windows updates expose additional Kerberos fields, which can improve investigation when available.

Privileged Group Abuse - No Membership Change Alerting

Without coverage for 4728, 4732, and 4756, an attacker can add a backdoor account to a privileged group and rely on administrators noticing only after the fact. These events map to global, local, and universal security group membership changes.

Delegation or GPO Abuse - No Change Visibility

Without 5136 and related change auditing, high-impact directory modifications can happen with very little investigative context. Event 5136 is generated when a directory service object is modified, and it becomes more useful when paired with the changed attribute and object context.

Detection

Essential Audit Policy Configuration

Deploy through GPO: Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration

Critical Event IDs Reference

SIEM Detection Queries (Elastic KQL)

DCSync detection:

event.code: "4662" AND
winlog.event_data.Properties: ("*1131f6ad*" OR "*1131f6aa*") AND
NOT winlog.event_data.SubjectUserName: ("*$")

Kerberoasting detection:

event.code: "4769" AND
winlog.event_data.TicketEncryptionType: "0x17" AND
NOT winlog.event_data.ServiceName: ("krbtgt" OR "*$")

Privileged group change:

event.code: ("4728" OR "4732" OR "4756") AND
winlog.event_data.TargetUserName: ("Domain Admins" OR "Enterprise Admins" OR "Schema Admins")

Tip: Start with a small set of high-confidence detections that the team will actually investigate. DCSync, privileged group changes, and service-ticket abuse usually produce far more value than a large unmaintained rule set.

Field Mapping and Parser Validation

Before writing complex detection logic, validate field mapping for your SIEM. The same Windows event can arrive with different field names depending on the connector, agent, or normalization layer. For each critical detection, confirm:

• event ID is parsed consistently
• account fields separate user, domain, and machine accounts
• source workstation and client address fields are retained
• ticket encryption fields are present for Kerberos detections
• directory object and attribute fields are retained for 4662 and 5136
• certificate request and template fields are retained for AD CS events

A rule that works in a lab but loses the critical field in production is not coverage.

Remediation

Quick Win: Enable Directory Service Access, Directory Service Changes, and the Kerberos subcategories on all Domain Controllers before tuning anything else.

1. Deploy Advanced Audit Policy Through GPO

auditpol /get /category:*

auditpol /set /subcategory:"Directory Service Changes" /success:enable
auditpol /set /subcategory:"Directory Service Access" /success:enable
auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enable
auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable /failure:enable
auditpol /set /subcategory:"Security Group Management" /success:enable
auditpol /set /subcategory:"Certification Services" /success:enable /failure:enable

2. Increase Security Log Capacity

The default Security log size is often too small for busy Domain Controllers.

wevtutil sl Security /ms:1073741824 /rt:false /ab:true

Log capacity should be sized against real event volume. Kerberos-heavy domains and busy DCs can overwrite evidence quickly if Security logs remain at small defaults.

3. Forward Domain Controller Events Centrally

winrm quickconfig
wecutil cs subscription.xml
gpupdate /force

Forwarding should preserve event XML or normalized fields required for detection. If your collector drops Properties, ObjectDN, TicketEncryptionType, or source workstation fields, high-value rules degrade into generic alerts.

4. Establish Baselines Before Tuning Thresholds

Get-WinEvent -ComputerName DC01 -FilterHashtable @{LogName='Security'; Id=4768} |
    Group-Object {$_.TimeCreated.Hour} |
    Select-Object Name, Count |
    Sort-Object Name

Use those baselines to understand normal Kerberos and logon volume before you introduce anomaly thresholds.

5. Map Detections to Attack Paths

Do not monitor event IDs in isolation. Map each detection to the attack path it supports:

• DCSync needs replication-right events and privileged directory changes
• Kerberoasting needs service-ticket visibility, encryption context, and service-account inventory
• delegation abuse needs attribute-change visibility and unusual machine-account authentication
• NTLM relay needs NTLM validation, target logons, and service-specific follow-on actions
• AD CS abuse needs certificate request, issuance, and template context

This mapping prevents the monitoring program from becoming a disconnected event list.

How EtcSec Detects This

EtcSec checks the audit-policy coverage that defenders need to investigate the major AD attack paths surfaced elsewhere in the report.

Monitoring-related findings highlight missing audit subcategories, insufficient retention, and other gaps that would leave high-value identity abuse invisible or difficult to reconstruct.

Detections to Implement First

If the monitoring team can only deploy a few high-value rules initially, start with the attacks that are both common and operationally reviewable:

• replication-rights abuse and DCSync attempts
• privileged group membership changes
• suspicious service-ticket requests associated with Kerberoasting
• high-value directory-object changes such as GPO or delegation writes
• certificate issuance activity for ADCS-enabled environments
• NTLM validation and network logon patterns for relay or lateral movement investigations

Those detections create a useful foundation without flooding analysts with low-quality noise.

Retention and Coverage Review

Active Directory monitoring should also include a retention review. A domain controller can produce large volumes of Kerberos, logon, and account-management events, and a small local Security log can overwrite the exact evidence needed during incident response. Review the maximum Security log size, forwarding latency, SIEM ingestion failures, and hot-storage retention together. If the SIEM keeps 90 days of searchable data but the collector silently drops high-volume event IDs during busy periods, the apparent retention policy is not the real investigative coverage.

For Tier-0 evidence, define which events must remain searchable during the full response window. Privileged group changes, directory-object modifications, certificate issuance, DCSync-relevant object access, and high-value Kerberos events should not be treated as disposable debug telemetry. They are the evidence that lets defenders reconstruct what changed, who changed it, and whether the same path was reused after remediation.

Validation After Audit Policy Changes

After changing audit policy, confirm the monitoring chain works end to end:

• verify the expected events appear on the Domain Controllers in scope
• confirm the same events reach your collector or SIEM without excessive delay or silent drops
• test at least one controlled administrative action and one benign Kerberos action to validate parsing and field mapping
• review retention to ensure critical evidence is still present when investigators need it
• confirm that 4662 and 5136 include the object and attribute context needed for directory investigations
• confirm that 4769 includes encryption and service information needed for Kerberos investigations
• confirm that AD CS events are present if certificate services exist in the environment

Related Controls

This article pairs naturally with Active Directory Password Security: Misconfigurations That Matter, NTLM Relay Attacks: Hijacking Authentication in AD, GPO Misconfigurations: How Group Policy Becomes an Attack Vector, Stale Privileged Accounts: Hidden Risk in Active Directory, and Kerberos Delegation Attacks: From Unconstrained to RBCD Abuse. Good monitoring is what lets teams prove those problems were fixed and detect when they reappear.

Primary References

• Defender for Identity event collection overview
• Configure Windows event auditing for Defender for Identity
• 4662: An operation was performed on an object
• 4769: A Kerberos service ticket was requested
• 5136: A directory service object was modified
• Audit Security Group Management