Wazuh Active Directory Monitoring and Attack Detection

Why Active Directory Is the Priority

Active Directory (AD) is the identity backbone of almost every Windows environment. It holds the accounts, groups, policies and trust relationships that control access to the whole estate. That is exactly why attackers target it: compromise AD and you compromise everything. The large majority of real-world intrusions involve some abuse of AD, from credential theft to privilege escalation to domain dominance.

For a SOC, this makes the domain controllers the highest-value place to watch. If you can only monitor a few systems well, monitor the DCs. Wazuh is well suited to this because it collects Windows event logs natively through its agent and processes them with a rules engine that can express the multi-event patterns AD attacks produce.

Collecting AD Logs with Wazuh

Install the Wazuh agent on every domain controller and configure it to read the Security event channel using the efficient eventchannel log format, which preserves the full structured XML of each event. The Security channel carries the authentication, account management and directory access events that AD detections depend on.

Make sure the underlying auditing is actually enabled in Group Policy. Advanced Audit Policy should log account logon, logon/logoff, account management, directory service access and directory service changes. Without those audit categories turned on, the events never appear and Wazuh has nothing to collect. Deploy Sysmon on the DCs as well, collecting the Sysmon Operational channel, to add process creation with command lines and network connection telemetry that enriches detection.

The Windows Event IDs That Matter

A handful of event IDs underpin most AD detections. Knowing what each one means is the foundation for writing or tuning rules.

• 4624 / 4625: successful and failed logons. Failures across many accounts signal password spraying.
• 4768 / 4769 / 4771: Kerberos TGT and service ticket requests and pre-auth failures. The raw material for Kerberoasting and AS-REP roasting detection.
• 4720 / 4722 / 4725: account creation, enabling and disabling.
• 4728 / 4732 / 4756: additions to global, local and universal security groups, including privileged groups like Domain Admins.
• 4662: an operation on a directory object. With the replication-related GUID it is the key signal for DCSync.
• 4670 / 5136: permission changes and directory object modifications, useful for spotting ACL abuse and persistence.

High-Value AD Attack Detections

With the events flowing, you can build detections for the techniques that matter. Kerberoasting shows up as a burst of 4769 service ticket requests, especially with weak RC4 encryption (ticket encryption type 0x17), as an attacker harvests service account tickets to crack offline. A frequency rule in Wazuh that counts 4769 events with RC4 per source is a practical detection.

Password spraying appears as many 4625 failures spread across different usernames from a single source IP over a short window, the inverse of a classic brute force. DCSync, where an attacker impersonates a domain controller to pull password hashes, surfaces as a 4662 event referencing the directory replication GUID from a host that is not a DC. Privilege escalation is caught by alerting on any addition to Domain Admins, Enterprise Admins or other high-privilege groups (4728, 4732, 4756).

Other valuable detections include disabled-account logon attempts, logons at unusual hours for privileged accounts, and new service creation on DCs. The goal is not to detect everything at once but to cover the common domain-dominance path first.

Writing and Tuning the Rules

Wazuh ships with a base Windows ruleset, but AD-specific detections usually need custom rules in local_rules.xml. Many are frequency rules: they fire only when a count threshold is crossed within a time window, which is exactly how password spraying and Kerberoasting are distinguished from normal activity. Write them with a clear match on the event ID and relevant fields, a sensible frequency and timeframe, and a rule level that reflects severity.

Tuning matters because AD is noisy. Service accounts, scheduled tasks, backup jobs and legitimate admin activity all generate events that resemble attacks. Build allowlists for known service accounts and expected automation, and validate every rule with real data before trusting it. The practical loop is: deploy the rule, watch what it fires on for a week, and tune the thresholds and exclusions until the alerts are almost all real.

Measuring Coverage with MITRE ATT&CK

Once you have a set of AD detections, map them to MITRE ATT&CK techniques so you can see your coverage objectively. Kerberoasting is T1558.003, DCSync is T1003.006, password spraying is T1110.003, and privileged group changes relate to T1098 and T1078. Tagging Wazuh rules with the technique ID lets you build a coverage view and, more importantly, see the gaps.

This turns AD monitoring from a pile of rules into a measurable programme. You can show stakeholders which domain-attack techniques you detect, prioritise the gaps, and track improvement over time. It also makes purple-team exercises far more productive, because you can validate each detection against a simulated technique and confirm it fires.