Windows eventlog: Event id: 5861 alert problem

[Trung Kiên]

Hi team, I encountered a problem with event id: 5861 when writting a custom rule for this event id; default rule: 60018 can not generate alert when this log (5861) was generated (i already overwritten level of rule 60018 to 10 so it can generate alert). My agent is a win server  2016.
Can anyone help me with this problem.

Thanks!

[victor....@wazuh.com]

Hello Trung,

The rule 60018 will triggers if the event win.system.providerName field has the Microsoft-Windows-WMI-Activity value and no other rule in the hierarchy has been triggered.

In order to help you, please provide us the following information:

• Custom rules

• An example of the event for which you want to create the rule. In this case the event 5861.

You could get the event enabling the logall option in your manager’s configuration /var/ossec/etc/ossec.conf:

<global> ... <logall>yes</logall> ...

Then, restart the manager. Finally triggers the event in the Windows agent and check the/var/ossec/logs/archives/archives.log file for the  expected5861event.

Once we get the desired event, we can use the wazuh-logtest to test our ruleset without needing to recreate the event in the environment.
For the case of windows events, it is necessary to follow this workaround:

• Make a backup of the /var/ossec/ruleset/rules/0575-win-base_rules.xml file
• Replace the 60000 rule in the /var/ossec/ruleset/rules/0575-win-base_rules.xml file as follow:

<rule id="60000" level="0"> <decoded_as>json</decoded_as> <field name="win.system.providerName">\.+</field> <options>no_full_log</options> <description>Group of windows rules.</description> </rule>

Removing the category tag and changing the decoded_as tag value for json.

After testing, restore original win-base_rules

Now we can use the wazuh-logtest tool with our event. From the archives.log file, you would have gotten something like the following:

2023 Jan 12 12:09:51 (win-8-1-pro-x64) any->EventChannel {"win":{"system":{"providerName":"Microsoft-Windows-WMI-Activity","eventID":"5861","level":"2","task":"0","keywords":"0x80000000000000","systemTime":"2023-01-12T19:09:52.000000000Z","eventRecordID":"386","channel":"","computer":"win-8-1-pro-x64","severityValue":"INFORMATION","message":"\"Testing\""},"eventdata":{"data":"Testing"}}}

This is not a real event. It has been used for testing purporses

Using the wazuh-logtest tool with the event (removing 2023 Jan 12 12:09:51 (win-8-1-pro-x64) any->EventChannel header ) we get the expected alert:

Starting wazuh-logtest v4.3.10 Type one log per line {"win":{"system":{"providerName":"Microsoft-Windows-WMI-Activity","eventID":"5861","level":"2","task":"0","keywords":"0x80000000000000","systemTime":"2023-01-12T19:09:52.000000000Z","eventRecordID":"386","channel":"","computer":"win-8-1-pro-x64","severityValue":"INFORMATION","message":"\"Testing\""},"eventdata":{"data":"Testing"}}} **Phase 1: Completed pre-decoding. **Phase 2: Completed decoding. name: 'json' win.eventdata.data: 'Testing' win.system.computer: 'win-8-1-pro-x64' win.system.eventID: '5861' win.system.eventRecordID: '386' win.system.keywords: '0x80000000000000' win.system.level: '2' win.system.message: '"Testing"' win.system.providerName: 'Microsoft-Windows-WMI-Activity' win.system.severityValue: 'INFORMATION' win.system.systemTime: '2023-01-12T19:09:52.000000000Z' win.system.task: '0' **Phase 3: Completed filtering (rules). id: '60018' level: '0' description: 'Group of Microsoft Windows Management Instrumentation (WMI) rules.' groups: '['windows']' firedtimes: '1' mail: 'False

Using this method, we could be able to determine where is the error in the ruleset.

If you have any doubts do not hesitate to ask

​