Process Windows Events, which are collected from ELK based Siem forwarded to wazuh

[MaP]

Hello everyone,

I'm currently trying to process Windows events that I receive from an elastic stack (siem) via syslog in wazuh. I collect the logs via an rsyslog server on which a client is installed. They are already in Json format (the message part of the message forwarded via syslog is json from the elk).
I also see all of these logs in the archives. Unfortunately, these are not evaluated by any rules, for example Windows messages are not available as <decoded_as>windows_eventchannel</decoded_as>.

actually the json logs are decoded by decoder json.  
I understand this to mean that the standard Windows rules do not apply.

Is there a simple way to prepare these logs (e.g. using an existing decoder as a parent or customizing it) so that they are processed with the standard rules?

Any ideas or suggestions would be appreciated
I'm happy.
If I missed the solution in a Wazuh document or in my search in the newsgroup, then sorry!

Marcel

[MaP]

Hello everybody,
I think, me and my team,  we found a good solution, thanks to the entries here in the mail group and with the help of the documentation.
Ultimately we used or wrote a kind of overlay decoder.

1) First, we made sure in the rsyslog that the JSON keys forwarded by the elastic-SIEM are adjusted so that the keys correspond to those from Wazuh. For this we used the mmjsonparse plugin from json.
The agent on the rsyslog reads the data with <logformat> json</logformat>

2) Afterwards it was necessary to adapt or slow down the json decoder built into Wazuh.
In our case, all logs start with {"win"..... We took advantage of this and, first quickly and dirty, adjusted the entries in 0006-json-decoders.xml in /var/ossec/ruleset/decoders.

The original prematch entry was adjusted so that the jsondecoder does not start immediately.
Old:
<prematch type=>^{\s*"</prematch>

New:
<prematch type="pcre2">^{\s*"[^w]</prematch>

So the JSon decoder continues to work, but not for Json files that start with {"win".

3) Now we had to build a new decoder.
This is called "windows_eventchannel" and is of type "ossec", which will be important in the rules at a later date.
 
Decoder:

<decoder name="windows_eventchannel">
<!--parent>json</parent-->
<use_own_name>true</use_own_name>
<prematch type="pcre2">^{\s*\"[w]</prematch>
<regex type="pcre2">providerName: ((?:.)*),\s*$</regex>
    <order>win.system.providerName</order>
    <type>ossec</type>
</decoder>

<decoder name="windows_eventchannel">
  <parent>windows_eventchannel</parent>
  <use_own_name>true</use_own_name>
  <plugin_decoder>JSON_Decoder</plugin_decoder>
</decoder>

Hello everybody,
I think we found a good solution, thanks to the entries here in the mail group and with the help of the documentation.
Ultimately we used or wrote a kind of overlay decoder.

1) First, we made sure in the rsyslog that the JSON keys forwarded by the elastic-SIEM are adjusted so that the keys correspond to those from Wazuh. For this we used the mmjsonparse plugin from json.
The agent on the rsyslog reads the data with <logformat> json</logformat>

2) Afterwards it was necessary to adapt or slow down the json decoder built into Wazuh.
In our case, all logs start with {"win"..... We took advantage of this and, first quickly and dirty, adjusted the entries in 0006-json-decoders.xml in /var/ossec/ruleset/decoders.

The original prematch entry was adjusted so that the jsondecoder does not start immediately.
Old:
<prematch type=>^{\s*"</prematch>

New:
<prematch type="pcre2">^{\s*"[^w]</prematch>

So the JSon decoder continues to work, but not for Json files that start with {"win".

3) Now we had to build a new decoder.
This is called "windows_eventchannel" and is of type "ossec", which will be important in the rules at a later date.
 
Decoder:

<decoder name="windows_eventchannel">
<!--parent>json</parent-->
<use_own_name>true</use_own_name>
<prematch type="pcre2">^{\s*\"[w]</prematch>
<regex type="pcre2">providerName: ((?:.)*),\s*$</regex>
    <order>win.system.providerName</order>
    <type>ossec</type>
</decoder>

<decoder name="windows_eventchannel">
  <parent>windows_eventchannel</parent>
  <use_own_name>true</use_own_name>
  <plugin_decoder>JSON_Decoder</plugin_decoder>
</decoder>

In the decoder it is still important that the win.system.providerName entry is extracted.

We think this is the only way the first standard rule 0575-win-base_rules.xml can continue to be used.

This rule checks the category for "ossec" and whether the events are decoded as windows_eventchannel. Check the code of 0575-win-base_rules.xml :

....

<group name="windows,">

  <rule id="60000" level="0">
    <category>ossec</category>
    <decoded_as>windows_eventchannel</decoded_as>
    <field name="win.system.providerName">\.+</field>

....

All of the following rules are then based on the rule in question, so that from then on you can use Wazuh's normal built-in rule set again

This email group entry helped us get on the right path:

https://groups.google.com/g/wazuh/c/yDm-tYBH6gk/m/kukbfB-uBAAJ

Thanks for that.

We tested whether Windows event channel logs read via a Windows agent continue to work, which is actually the case.

If there is another, possibly easier or better way, please let me know. 

Otherwise, I hope that the way we found and the description here will help others with their implementation

Kind regards

Marcel

[Jeremias Ignacio Posse]

Hello Marcel,

Thank you for sharing the detailed solution you and your team have developed. It’s clear that much thought and effort went into resolving the issue, and your comprehensive explanation will undoubtedly benefit others facing similar challenges. I appreciate your willingness to contribute to the community’s knowledge base. If you require further assistance or have more questions, please don’t hesitate to reach out again through this mailing list or our Slack channel. We’re here to help!

Best regards, Jeremias.