Hi Felix!
Could you please share with us the event that you have found? but instead of the entry in the archives.log, please provide us the one in the archives.json file.
I will be waiting for your reply,
Mariano Koremblum
Hi again Felix,
I was testing your log with our wazuh-logtest tool, please take a look here, and got the following:
# /var/ossec/bin/wazuh-logtest 127 ↵
Starting wazuh-logtest v4.3.4
Type one log per line
{"win":{"system":{"providerName":"User32","providerGuid":"{b0aa8734-56f7-41cc-b2f4-de228e98b946}","eventSourceName":"User32","eventID":"1074","version":"0","level":"4","task":"0","opcode":"0","keywords":"0x8080000000000000","systemTime":"2022-06-20T09:13:09.8330106Z","eventRecordID":"20347","processID":"508","threadID":"656","channel":"System","computer":"AutoEmp01.AQUAERO.local","severityValue":"INFORMATION","message":"Vom Prozess \"C:\\Windows\\System32\\RuntimeBroker.exe (AUTOEMP01)\" wurde auf Anforderung des Benutzers \"AUTOEMP01\\standard\" das Ereignis \"neu starten\" für den Computer \"AUTOEMP01\" aus folgendem Grund initiiert: \"Anderer Grund (nicht geplant)\"\\r\\n Ursachencode: \"0x0\"\\r\\n Herunterfahrtyp: \"neu starten\"\r\n Kommentar: \"\"\""},"eventdata":{"param1":"C:\\\\Windows\\\\System32\\\\RuntimeBroker.exe (AUTOEMP01)","param2":"AUTOEMP01","param3":"Anderer Grund (nicht geplant)","param4":"0x0","param5":"neu starten","param7":"AUTOEMP01\\\\standard"}}}
**Phase 1: Completed pre-decoding.
**Phase 2: Completed decoding.
name: 'json'
win.eventdata.param1: 'C:\\Windows\\System32\\RuntimeBroker.exe (AUTOEMP01)'
win.eventdata.param2: 'AUTOEMP01'
win.eventdata.param3: 'Anderer Grund (nicht geplant)'
win.eventdata.param4: '0x0'
win.eventdata.param5: 'neu starten'
win.eventdata.param7: 'AUTOEMP01\\standard'
win.system.channel: 'System'
win.system.computer: 'AutoEmp01.AQUAERO.local'
win.system.eventID: '1074'
win.system.eventRecordID: '20347'
win.system.eventSourceName: 'User32'
win.system.keywords: '0x8080000000000000'
win.system.level: '4'
win.system.message: 'Vom Prozess "C:\Windows\System32\RuntimeBroker.exe (AUTOEMP01)" wurde auf Anforderung des Benutzers "AUTOEMP01\standard" das Ereignis "neu starten" für den Computer "AUTOEMP01" aus folgendem Grund initiiert: "Anderer Grund (nicht geplant)"\r\n Ursachencode: "0x0"\r\n Herunterfahrtyp: "neu starten"
Kommentar: """'
win.system.opcode: '0'
win.system.processID: '508'
win.system.providerGuid: '{b0aa8734-56f7-41cc-b2f4-de228e98b946}'
win.system.providerName: 'User32'
win.system.severityValue: 'INFORMATION'
win.system.systemTime: '2022-06-20T09:13:09.8330106Z'
win.system.task: '0'
win.system.threadID: '656'
win.system.version: '0'
**Phase 3: Completed filtering (rules).
id: '61100'
level: '0'
description: 'Windows System informational event'
groups: '['windows', 'windows_system']'
firedtimes: '1'
mail: 'False'
As it can be seen, the event is being caught by our rule 61100 (located on the /var/ossec/ruleset/rules/0590-win-system_rules.xml file) that looks for the field win.system.severityValue to be equal to INFORMATION, which is the case of your log. It is strange that in your entry extracted from the archives it is not informed that a rule (61100) was matched. Please check in your Wazuh’s ruleset if you have such a rule. Getting back to the rule, it has a level 0 value so that it won’t trigger any alert and it won’t be displayed on your dashboard, as the alert level should be equal to or higher than the log_alert_level set in your manager’s ossec.conf file, which is 3 by default.
PS, if you do want to test eventchannel logs, I suggest you do the following:
Currently, it is not possible to directly evaluate Windows events in wazuh-logtest, as they are embedded in code, but there is a workaround for doing so.
You would need to enable the logall_json option, just as you did, and grab the “full_log” field. Be sure, if there are escaped quotes symbols to unescape them (just the ones directly related to the JSON structure).
Logtest only allows to test rules and decoders in XML, so, to test Eventchannel events, we can make use of the 60000 rule, which must be modified. All the other Windows Eventchannel-related rules depend on this rule. In order to match it, the value of the label <decode_as> must be modified to <decode_as>json</decode_as> and if the field <category>ossec</category> is present, then remove it.
Please note that this change is only for testing the rules, then it must be returned to its original state.
The rule for testing will then look like this:
<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>
Regards,
Mariano Koremblum
Felix,
It is not recommended to modify the default Wauzh ruleset, as it can produce inconsistencies and because, when upgrading the manager, the whole /var/ossec/ruleset directory is overwritten. The best way to achieve what you are looking for is to add a new rule to /var/ossec/etc/rules/local_rules.xml in charge of raising the alert level.
Every single rule that you want to raise its level will have a format similar to the following one:
<rule id="NEW_RULE_ID_HIGHER_THAN_100k" level="7">
<if_sid>ORIGINAL_RULE_ID</if_sid>
<description>ORIGINAL_DESCRIPTION</description>
</rule>
Where you should replace the “NEW_RULE_ID_HIGHER_THAN_100k”, “ORIGINAL_RULE_ID” and “ORIGINAL_DESCRIPTION” for their corresponding values.
For example, given the rule that you have mentioned, it could be like:
<rule id="161100" level="3">
<if_sid>61100</if_sid>
<description>Windows System informational event.</description>
</rule>
PS: what do you mean by globally setting the log level to 0?
Best Regards,
Mariano Koremblum