Rules: Manage "full_log" as field

serano...@gmail.com

unread,

Sep 27, 2022, 9:10:12 AM9/27/22

to Wazuh mailing list

Hi All.

IWìI Would ask if is possible to manage the field "full_log" as field in rules.

here an exalmple of rule for linux i've tried but not works:

<rule id="600279" level="6">
<decoded_as>auditd</decoded_as>
<field name="full_log" negate="no" type="pcre2">service|chkconfig|systemctl</field>
<field name="full_log" negate="no" type="pcre2">stop|off|disable|kill</field>
<field name="full_log" negate="yes" type="pcre2">start</field>
<description>Service was Stopped/Disabled </description>
<group>linux,T1562,</group>
</rule>

this instead works, but it's triggered even when the serivce start:

so, back to my question, is possible to manage the full_log field to better filters the patterns?

thanks for your works guys, have a nice day.

serano...@gmail.com

unread,

Sep 27, 2022, 9:11:09 AM9/27/22

to Wazuh mailing list

Sample of log if needed:

{"timestamp":"2022-09-27T13:04:56.526+0000","rule":{"level":6,"description":"Service was Stopped/Disabled ","id":"600280","firedtimes":1,"mail":false,"groups":["ELK","linux","linux","T1562"]},"agent":{"id":"003","name":"SOC-UB-PENTEST","ip":"192.168.55.30","labels":{"agent":{"os":"Linux"}}},"manager":{"name":"wazuh-testrules"},"id":"1664283896.12152893","cluster":{"name":"NGW-SOC-TEST","node":"NGW-SOC-TEST"},"full_log":"type=EXECVE msg=audit(1664283895.468:434292): argc=3 a0=\"systemctl\" a1=\"disable\" a2=\"syslog.service\"","decoder":{"name":"auditd"},"data":{"audit":{"type":"EXECVE","id":"434292"}},"location":"/var/log/audit/audit.log"}

Stefano Serano

unread,

Sep 27, 2022, 10:18:22 AM9/27/22

to Wazuh mailing list

Hi, i made a mistake, the rule i'm using is this one:

<if_sid>80700</if_sid>

<field name="full_log" negate="no" type="pcre2">service|chkconfig|systemctl</field>
<field name="full_log" negate="no" type="pcre2">stop|off|disable|kill</field>
<field name="full_log" negate="yes" type="pcre2">start</field>
<description>Service was Stopped/Disabled </description>
<group>linux,T1562,</group>
</rule>

--
You received this message because you are subscribed to a topic in the Google Groups "Wazuh mailing list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wazuh/yhOXhyNJOKk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wazuh+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/2134ad03-6735-42be-be36-a267cc8f7da9n%40googlegroups.com.

Jonathan Martín Valera

unread,

Sep 27, 2022, 10:28:43 AM9/27/22

to Wazuh mailing list

Hi,

The full_log field is the result of the logs generated by Wazuh, but it is not processed as such by the analysis engine, it is later. The full_log field generated by wazuh is the result of the raw event it has received and processed, so the original event that it is processing would be the following one:

EXECVE msg=audit(1664283895.468:434292): argc=3 a0="systemctl" a1="disable" a2="syslog.service"

From here, you should see if there is any existing decoder and/or rule that matches this example, for this you can use the tool /var/ossec/bin/wazuh-logtest.

# /var/ossec/bin/wazuh-logtest

Starting wazuh-logtest v4.3.8
Type one log per line

EXECVE msg=audit(1664283895.468:434292): argc=3 a0="systemctl" a1="disable" a2="syslog.service"

**Phase 1: Completed pre-decoding.
    full event: 'EXECVE msg=audit(1664283895.468:434292): argc=3 a0="systemctl" a1="disable" a2="syslog.service"'

**Phase 2: Completed decoding.
    No decoder matched.

As you can see, this log is not decoded or matched with any rule, so you will have to add some custom decoder and rule for the use case you need.

For example, I will create a decoder and rule for your intended case.

Add the following decoder to the /var/ossec/etc/decoders/local_decoder.xml file:

<decoder name="custom_audit">
  <prematch>msg=audit(\S+):</prematch>
   <regex>a0="(\S+)" a1="(\S+)" a2="(\S+)"</regex>
   <order>command, _action, service</order>
</decoder>

Note: the name _action has been used because action is a reserved name.

And add the following content to the end of your rules file /var/ossec/etc/rules/local_rules.xml:

<group name="custom_audit,">
  <rule id="100050" level="4">
    <decoded_as>custom_audit</decoded_as>
    <field name="command">^systemctl$|^chkconfig$|^service$</field>
    <field name="_action">^start$|^stop$|^disable$|^off$|^kill$</field>
    <description>Custom audit rule</description>
  </rule>
</group>

Restart the wazuh-manager to apply the changes:

systemctl restart wazuh-manager

This will generate alerts when any decoded field such as command or _action meets the indicated regex. Remember that the wazuh-manager processes all the events and logs that are being monitored, and you have to build the rules and decoders based on that raw log, in this case, the raw log is the following:

EXECVE msg=audit(1664283895.468:434292): argc=3 a0="systemctl" a1="disable" a2="syslog.service"

Remember also, that you can test using the /var/ossec/bin/wazuh-logtest tool and see if the log is decoded and matched with some rule, but introducing the monitored log and not the one generated by wazuh.

If you have some doubts about decoders and rules, I share with you some interesting links:

Creating decoders and rules from scratch: https://wazuh.com/blog/creating-decoders-and-rules-from-scratch/
Sibling decoders: flexible extraction of information: https://wazuh.com/blog/sibling-decoders-flexible-extraction-of-information/
Custom rules and decoders: https://documentation.wazuh.com/current/user-manual/ruleset/custom.html
Testing decoders and rules: https://documentation.wazuh.com/current/user-manual/ruleset/testing.html