Historically, testing sample Windows events against the Wazuh ruleset has been a somewhat high friction process because Wazuh currently does not have native support for this. I have written some scripts which streamline that process and have made those available to the Wazuh community.
Conventional Testing of Wazuh Analysis of Sample Windows Events
The Wazuh logtest facility allows us to test sample log events against the most recently saved version of the Wazuh ruleset (rules, decoders, and CDB lists) even when the latest ruleset changes have not been reloaded via a restart of the wazuh-manager service. This can be done via CLI tool, Wazuh Dashboard, or Wazuh API. It is a very important feature, critical to effective tuning and custom development of the Wazuh ruleset. However, it does not natively support testing Windows log samples, making it necessary to take extra steps to work around this limitation.
https://documentation.wazuh.com/current/user-manual/ruleset/testing.html
Why this facility is not easy to use with sample Windows events.
- By default, Wazuh does not generate alerts about events that fail to trip a Wazuh rule of severity level 3 or higher.
- With alerted-on Windows events, the alerts do not include the full_log JSON representation of the Windows event that triggered them, which is what the logtest facility needs as input.
- The logtest facility does not natively recognise JSON records of sample Windows events as actually coming from an EventChannel source, misinterpreting them as plain JSON events and thus not testing them against the Windows rule family in the Wazuh ruleset.
The generally recommended process to test specifically Windows sample events against the Wazuh ruleset
First, acquire a JSON representation of the Windows event sample(s) you wish to use in ruleset testing.
- Enable <logall_json> in the Wazuh manager’s ossec.conf file to activate writing all events unabridged to archives.json.
- Restart the Wazuh manager service.
- Wait for the desired Windows events to arrive and be written to archives.json.
- Manually find the Windows event JSON record(s) of the sample(s) you want to use for testing.
- Manually extract the full_log key’s value(s) from the JSON record(s).
- Manually unescape the quotes in the extracted full_log value(s) and set these aside for feeding to the Wazuh logtest facility.
- Disable <logall_json> in the Wazuh manager’s ossec.conf file to deactivate writing all events unabridged to archives.json.
- Restart the wazuh-manager service.
Please Note: If you fail to disable <logall_json> and restart the wazuh-manager service, the archives.json file will continue to grow rapidly, risking filling the disk on the Wazuh manager.
With the collected/extracted/unescaped full_log JSON Windows event samples now in hand, test them with the logtest facility
- In Wazuh rule 60000 in /var/ossec/ruleset/rules/0575-win-base_rules.xml, change the <decoded_as> setting from windows_eventchannel to json, and comment out the <options> line.
- Use whichever form of the Wazuh logtest facility you wish (web, API, or CLI), feeding in your collected samples and assessing the results.
- Promptly return rule 60000 to its original form.
Please Note: If this rule is left as is or is broken in any way, and the wazuh-manager service is restarted, all further Windows event analysis will be completely broken.
Using the Blue Wolf Ninja Script Suite instead
To cut through the friction and streamline the Wazuh log testing process for Windows event samples, I wrote a collection of scripts. This is how to deploy and use them on your own Wazuh manager(s).
1. Download and execute the deployment script for the Blue Wolf Ninja Wazuh Windows Logtest helper suite
sudo curl -sS https://raw.githubusercontent.com/BlueWolfNinja/wazuh-resources/refs/heads/main/deploy-ninja-suite-for-windows-logtesting > ./deploy-ninja-suite-for-windows-logtesting
chmod 744 ./deploy-ninja-suite-for-windows-logtesting
./deploy-ninja-suite-for-windows-logtesting2. Enable unabridged writing of log events to archives.json.
sudo enable-wazuh-archives3. After enough new Windows events have been written to archives.json, disable further writing to archives.json before too much disk space is consumed.
sudo disable-wazuh-archives4. Extract an unescaped full_log JSON representation of Windows events from archives.json that correspond to a specific Windows EventID. (sample included)
sudo extract_windows_full_log_samples event 4624
{"win":{"system":{"providerName":"Microsoft-Windows-Security-Auditing","providerGuid":"{54849625-5478-4994-a5ba-3e3b0328c30d}","eventID":"4624","version":"2","level":"0","task":"12544","opcode":"0","keywords":"0x8020000000000000","systemTime":"2025-10-24T00:31:28.1910501Z","eventRecordID":"107767637","processID":"1204","threadID":"2356","channel":"Security","computer":"BNC-DESKTOP-2","severityValue":"AUDIT_SUCCESS","message":"\"An account was successfully logged on.\r\n\r\nSubject:\r\n\tSecurity ID:\t\tS-1-5-18\r\n\tAccount Name:\t\tBNC-DESKTOP-2$\r\n\tAccount Domain:\t\tWORKGROUP\r\n\tLogon ID:\t\t0x3E7\r\n\r\nLogon Information:\r\n\tLogon Type:\t\t5\r\n\tRestricted Admin Mode:\t-\r\n\tVirtual Account:\t\tNo\r\n\tElevated Token:\t\tYes\r\n\r\nImpersonation Level:\t\tImpersonation\r\n\r\nNew Logon:\r\n\tSecurity ID:\t\tS-1-5-18\r\n\tAccount Name:\t\tSYSTEM\r\n\tAccount Domain:\t\tNT AUTHORITY\r\n\tLogon ID:\t\t0x3E7\r\n\tLinked Logon ID:\t\t0x0\r\n\tNetwork Account Name:\t-\r\n\tNetwork Account Domain:\t-\r\n\tLogon GUID:\t\t{00000000-0000-0000-0000-000000000000}\r\n\r\nProcess Information:\r\n\tProcess ID:\t\t0x490\r\n\tProcess Name:\t\tC:\\Windows\\System32\\services.exe\r\n\r\nNetwork Information:\r\n\tWorkstation Name:\t-\r\n\tSource Network Address:\t-\r\n\tSource Port:\t\t-\r\n\r\nDetailed Authentication Information:\r\n\tLogon Process:\t\tAdvapi \r\n\tAuthentication Package:\tNegotiate\r\n\tTransited Services:\t-\r\n\tPackage Name (NTLM only):\t-\r\n\tKey Length:\t\t0\r\n\r\nThis event is generated when a logon session is created. It is generated on the computer that was accessed.\r\n\r\nThe subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.\r\n\r\nThe logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).\r\n\r\nThe New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.\r\n\r\nThe network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.\r\n\r\nThe impersonation level field indicates the extent to which a process in the logon session can impersonate.\r\n\r\nThe authentication information fields provide detailed information about this specific logon request.\r\n\t- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.\r\n\t- Transited services indicate which intermediate services have participated in this logon request.\r\n\t- Package name indicates which sub-protocol was used among the NTLM protocols.\r\n\t- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.\""},"eventdata":{"subjectUserSid":"S-1-5-18","subjectUserName":"BNC-DESKTOP-2$","subjectDomainName":"WORKGROUP","subjectLogonId":"0x3e7","targetUserSid":"S-1-5-18","targetUserName":"SYSTEM","targetDomainName":"NT AUTHORITY","targetLogonId":"0x3e7","logonType":"5","logonProcessName":"Advapi","authenticationPackageName":"Negotiate","logonGuid":"{00000000-0000-0000-0000-000000000000}","keyLength":"0","processId":"0x490","processName":"C:\\\\Windows\\\\System32\\\\services.exe","impersonationLevel":"%%1833","virtualAccount":"%%1843","targetLinkedLogonId":"0x0","elevatedToken":"%%1842"}}}
...5. Alternatively or additionally, do the sample extraction looking for a specific Wazuh rule ID. (sample included)
sudo extract_windows_full_log_samples rule 61615
{"win":{"system":{"providerName":"Microsoft-Windows-Sysmon","providerGuid":"{5770385f-c22a-43e0-bf4c-06f5698ffbd9}","eventID":"13","version":"2","level":"4","task":"13","opcode":"0","keywords":"0x8000000000000000","systemTime":"2025-10-24T00:05:12.2334772Z","eventRecordID":"11042842","processID":"4668","threadID":"6756","channel":"Microsoft-Windows-Sysmon/Operational","computer":"Peters-Desktop","severityValue":"INFORMATION","message":"\"Registry value set:\r\nRuleName: technique_id=T1543,technique_name=Service Creation\r\nEventType: SetValue\r\nUtcTime: 2025-10-24 00:05:12.222\r\nProcessGuid: {4396056d-c2b5-68fa-1135-000000005900}\r\nProcessId: 2884\r\nImage: C:\\Program Files (x86)\\ossec-agent\\wazuh-agent.exe\r\nTargetObject: HKLM\\System\\CurrentControlSet\\Services\\bam\\State\\UserSettings\\S-1-5-18\\\\Device\\HarddiskVolume5\\Windows\\SysWOW64\\cmd.exe\r\nDetails: Binary Data\r\nUser: NT AUTHORITY\\SYSTEM\""},"eventdata":{"ruleName":"technique_id=T1543,technique_name=Service Creation","eventType":"SetValue","utcTime":"2025-10-24 00:05:12.222","processGuid":"{4396056d-c2b5-68fa-1135-000000005900}","processId":"2884","image":"C:\\\\Program Files (x86)\\\\ossec-agent\\\\wazuh-agent.exe","targetObject":"HKLM\\\\System\\\\CurrentControlSet\\\\Services\\\\bam\\\\State\\\\UserSettings\\\\S-1-5-18\\\\\\\\Device\\\\HarddiskVolume5\\\\Windows\\\\SysWOW64\\\\cmd.exe","details":"Binary Data","user":"NT AUTHORITY\\\\SYSTEM"}}}
...6. Run the wazuh-logtest-eventchannel script and paste in one of your extracted Windows event samples. Repeat this until your testing goals are met.
sudo wazuh-logtest-eventchannel7. When needed, use the “verbose” parameter to include rule-trace output for hierarchical accounting of the assessment of your sample against the ruleset.
sudo wazuh-logtest-eventchannel -v8. You can even chain together the extraction and logtest wrapper script, to immediately extract and verbosely test the first matching sample in archives.json.
sudo extract_windows_full_log_samples event 61615 | head -n1 | sudo wazuh-logtest-eventchannel -vIf you wish to to completely uninstall this toolset and its deploy script, run this:
rm -f /usr/local/bin/extract_windows_full_log_samples /usr/local/bin/wazuh-logtest-eventchannel /usr/local/bin/enable-wazuh-archives /usr/local/bin/disable-wazuh-archives ./deploy-ninja-suite-for-windows-logtestingCaveats related to wazuh-logtest-legacy
The wazuh-logtest-legacy CLI tool is deprecated.
However, my wazuh-logtest-eventchannel script depends on it for a feature not present in the more modern wazuh-logtest program.
Though depreciated, it continues to be included up through Wazuh 4.13 and I have been told it will persist until Wazuh 5. I am optimistic that when Wazuh 5 is released, it will include full native support for testing Windows log samples against the Wazuh ruleset, making this script suite unnecessary.
Minor testing irregularity involving rules that use the “ignore” property
When your sample is tested against rules that use the ignore property to prevent excessive alerts being generated for the same rule, this testing method may mark more alerts with “Alert to be generated” than would truly trigger additional alerts, due to a minor low level misalignment of the wazuh-logtest-legacy tool compared to the modern Wazuh logtest facility. This is rarely impactful to normal log testing.