01 How Wazuh turns a Windows event into an alert
Wazuh does not detect a Windows event by its ID directly. The Windows agent ships each event from a channel (Security, System, Application, PowerShell, Sysmon), Wazuh decodes it, and then a chain of rules matches on the win.system.eventID field. Every rule has an ID and an alert level from 0 to 15. This page maps the Windows Security event IDs you meet most often to the built-in Wazuh rule that fires, so you can tell at a glance what will alert and how loudly.
This is a companion to the Wazuh SOC home lab, where you generate these events with Kali and watch them appear. Rule IDs and levels below are from the Wazuh 4.x default ruleset.
0 logged but never alerted (grouping or noise rules). 3–4 low, informational. 5–8 medium, worth a look. 9–12 high. 12–15 critical. By default Wazuh writes alerts at level 3 and above, and escalates integrations (email, Slack) at level 12 and above. You raise or lower any of these with a local rule.
Whether or not a dedicated rule exists, every collected event is searchable. In Threat Hunting → Events (or Discover) filter on data.win.system.eventID: "4625". See the Wazuh log analysis walkthrough for the query syntax.
02 Authentication and logon events
The events you generate first in any SOC lab. A hydra brute force against the Windows host produces a wall of 4625, which Wazuh rolls up into a single high-level alert.
| Event ID | What it means in Windows | Wazuh rule | Level | Notes |
|---|---|---|---|---|
| 4624 | An account was successfully logged on | 60106 | 3 | Logon type matters. Type 3 network, type 10 RDP, type 5 service. Rules 60200/60232 handle IIS and noise. |
| 4625 | An account failed to log on | 60105, 60122 | 5 | Bad password or unknown user. Repeated 4625 rolls up into rule 60204 (multiple logon failures) at level 10. |
| 4634 | An account was logged off | 60137 | 3 | Pairs with 4624 to measure session length. |
| 4648 | Logon using explicit credentials (runas) | — | — | No dedicated rule. A strong lateral-movement signal. Search it directly and write a local rule if you care. |
| 4672 | Special privileges assigned to new logon | — | — | Marks an admin logon. Covered by WEF baseline rule 67028 if you deploy that ruleset. |
| 4673 | A privileged service was called | 60107 | 4 | Repeated failures roll up into 60203 at level 10. |
| 4768 | A Kerberos TGT was requested | — | — | On a domain controller. Baseline for Kerberoasting and AS-REP hunting; no default alert. |
| 4769 | A Kerberos service ticket was requested | 60106, 60131 | 3–5 | Rule 60131 flags DC logon failure. Bursts of 4769 for many SPNs suggest Kerberoasting. |
| 4771 | Kerberos pre-authentication failed | — | — | The domain equivalent of 4625. No default rule; add one for password-spray detection. |
| 4776 | NTLM credential validation | — | — | On the authenticating server. Useful for pass-the-hash hunting. |
| 4778 / 4779 | Session reconnected / disconnected | 60108 | 3 | RDP and Fast User Switching sessions. |
03 Account and group management
Persistence and privilege escalation live here. Creating a user, then adding it to Administrators, is two events and two rules.
| Event ID | What it means in Windows | Wazuh rule | Level | Notes |
|---|---|---|---|---|
| 4720 | A user account was created | 60109 | 8 | High level because new accounts are a common persistence move. |
| 4722 | A user account was enabled | 60109 | 8 | Same rule as account creation. |
| 4725 | A user account was disabled | 60111 | 8 | |
| 4726 | A user account was deleted | 60111 | 8 | |
| 4738 | A user account was changed | 60110 | 8 | Covers attribute changes such as password-never-expires. |
| 4740 | A user account was locked out | 60115 | 9 | Often the visible result of a brute force or spray. |
| 4767 | A user account was unlocked | 60133 | 5 | |
| 4728 | Member added to a global security group | 60113, 60141 | 5 | Watch Domain Admins and Enterprise Admins here. |
| 4732 | Member added to a local security group | 60113, 60144 | 5 | Local Administrators additions are a classic privilege grab. |
| 4756 | Member added to a universal security group | 60113, 60151 | 5 | |
| 4735 | A local security group was changed | 60113, 60147 | 5 | |
| 4719 | System audit policy was changed | 60112 | 8 | Attackers disable auditing to go dark. Treat any change as suspicious. |
04 Process, service and log-clearing events
Execution and anti-forensics. The scheduled-task and service events are what the lab's Kali attacks trigger.
| Event ID | What it means in Windows | Wazuh rule | Level | Notes |
|---|---|---|---|---|
| 4688 | A new process was created | — | — | No dedicated base rule. Enable "Audit Process Creation" plus command-line logging, then hunt on it, or use Sysmon Event 1 for richer data. WEF baseline rule 67027 labels it. |
| 4689 | A process exited | — | — | Pairs with 4688 to measure process lifetime. |
| 7045 | A new service was installed | 61138 | 5 | Rule 92650 escalates to level 12 when the service binary runs from the Windows root, a PsExec / admin-share signature. |
| 7040 | Service start type was changed | 61104 | 3 | e.g. a defence service flipped to Disabled. |
| 7034 / 7036 | Service crashed / changed state | — | — | Handled as generic System events. Repeated crashes roll up via 61110. |
| 1102 | The Security audit log was cleared | 60117 | 9 | A near-certain anti-forensics move. Alert on this every time. |
| 104 | An event log was cleared (System) | — | — | The System-channel sibling of 1102. Add a local rule to match its parity. |
| 5140 | A network share was accessed | 67017 | 3 | From the WEF baseline ruleset. 5145 gives per-file detail. |
| 5142 / 5144 | A network share was created / deleted | 67025, 67026 | 3 | Also from the WEF baseline ruleset. |
4698 (a scheduled task was created) fires Wazuh rule 60228 at level 4, a common persistence technique. 4699 logs deletion. On newer builds the Task Scheduler Operational channel (events 106, 140, 141) carries the same information and is picked up by WEF baseline rules 67014–67016.
05 PowerShell and Sysmon events
The base Windows channels tell you what happened. PowerShell script-block logging and Sysmon tell you how. Enabling both turns a quiet lab into a realistic one, and Wazuh ships hundreds of rules for them out of the box.
| Event ID | Source channel | Wazuh rule(s) | Level | What Wazuh flags |
|---|---|---|---|---|
| 4104 | PowerShell/Operational (script block logging) | 91803–91846 | 3–14 | Base64 decoding 91809 L10, screen capture 91803 L14, remote Invoke-Command 91823 L14, plus dozens of discovery and collection patterns. |
| 4103 | PowerShell/Operational (module logging) | via 91802 | 0+ | Pipeline execution detail. Feeds the same script-block rule group. |
| 1 | Sysmon (process creation) | 92000–92081 | 4– | The richest execution telemetry: parent/child, hashes, command line. Script interpreters spawning processes flagged at 92000. |
| 3 | Sysmon (network connection) | 92101–92110 | 0– | PowerShell making TCP connections 92101, a beaconing signal. |
| 11 | Sysmon (file created) | 92200–92227 | 6– | Scripts and executables dropped into Temp or user folders 92200. |
06 Wazuh event ID FAQ
What is the win.system.eventID field in Wazuh?
It is the decoded Windows event ID inside a Wazuh alert. In the dashboard you query it as data.win.system.eventID, for example data.win.system.eventID: "4625" for failed logons. Wazuh rules match on win.system.eventID in the ruleset XML.
Which Windows event IDs should I monitor first?
Start with the high-signal ones: 4625 failed logon, 4740 account lockout, 4720 account created, 4732 added to a local admin group, 4698 scheduled task created, 7045 new service, 1102 log cleared, and 4104 PowerShell script block. They map to the loudest built-in Wazuh rules.
Why does Wazuh not alert on event 4688 by default?
Process creation auditing is off in Windows by default and produces very high volume, so the base ruleset does not ship a dedicated 4688 alert. Enable "Audit Process Creation", turn on command-line logging, and either hunt on the event or deploy Sysmon Event 1 for richer process telemetry.
What do Wazuh rule levels mean?
A number from 0 to 15. 0 is logged but never alerted, 3 to 4 is low, 5 to 8 is medium, 9 to 12 is high, and 12 to 15 is critical. Wazuh records alerts from level 3 up and triggers integrations from level 12 up by default.
How do I change the alert level for an event?
Write a local rule in local_rules.xml that uses <if_sid> to inherit the built-in rule and sets a new level. For example, raise scheduled-task creation from 4 to 10 in your lab so it stands out. Restart the manager and the change is live.
Do these event IDs need Sysmon installed?
No. Every Security-channel event here (4624, 4625, 4720, 7045, 1102 and the rest) comes from the built-in Windows Security log that the Wazuh agent reads automatically. Sysmon and PowerShell script-block logging are optional add-ons that give deeper execution detail.