Questions about Decoders and sensitive information

[Bloom]

Hello Wazuh Team,

I hope you're doing well !

I have two questions about decoders that I couldn't find answers to anywhere. I'm wondering if you can guide me towards some sort of solution.

My first question is about decoders with a variable number of fields :

I have a command that can return a different number results :

ossec: output: 'command ':
A
B
C
D
etc ...

I want to parse this result and have different fields decoded such as :
data.result1 : A
data.result2 : B
And so on.

The problem is, the number of results is different between agents, so I'm wondering if there is a way to have some sort of dynamic decoder where I can have fields like result1, result2, result3 until the end of the command output.

What I can do is create sibling decoders and just anticipate a high number that can go beyond what the results can be. But that doesn't account for all possibilities. Do you have some ideas about how I can proceed ?

The second question I have is about hiding sensitive information. I am currently monitoring executed commands on my servers and every now and then a password pops up in the logs. Is there a way to mask this part of the alert ?

There is some functionality related to roles in opensearch that can anonymize fields but that requires specific parsing and new roles, and the full_log will still include the executed command with the visible password. What do you think about this ?

Thanks,

Bloom 

[Juan Nicolás Asselle (Nico Asselle)]

Hi Bloom,

About your first question:

Unfortunately, there’s only one way to create dynamic and on-demand fields during the event processing stage: wrapping them into a JSON object. Maybe jq could help in this scenario, leading to the next output (example)

ossec: output: 'mycommand ':{ "result1":"A", "result2":"B", "result3":"C", "result4":"D",.....}

After this, you should add a custom decoder that handles that output as a JSON object

<decoder name="ossec-mycommand-json"> <parent>ossec</parent> <type>ossec</type> <prematch offset="after_parent">^output: 'mycommand':</prematch> <plugin_decoder offset="after_prematch">JSON_Decoder</plugin_decoder> </decoder>

Testing it with wazuh-logtest

[root@wazuh-server wazuh-user]# /var/ossec/bin/wazuh-logtest Starting wazuh-logtest v4.7.0 Type one log per line ossec: output: 'mycommand':{ "result1":"A", "result2":"B", "result3":"C", "result4":"D"} **Phase 1: Completed pre-decoding. full event: 'ossec: output: 'mycommand':{ "result1":"A", "result2":"B", "result3":"C", "result4":"D"}' **Phase 2: Completed decoding. name: 'ossec' parent: 'ossec' result1: 'A' result2: 'B' result3: 'C' result4: 'D' **Phase 3: Completed filtering (rules). id: '530' level: '0' description: 'Wazuh process monitoring rules.' groups: '['ossec', 'process_monitor']' firedtimes: '1' mail: 'False'

After this, you just only need to create the rule to catch your events

About your second question

It’s difficult to make this work since we need heuristics to figure out what could or not be a password/sensitive information. On the other hand, let me check if there’s a way to limit full_log visualization by RBAC

Regards,
Nico

​