Open JcabreraC opened 1 year ago
It appears that the current issue is hindering the creation of custom decoders for auditd, and could potentially being impacting other aspects of the ruleset as well.
This problem has been reported by the community. We aim to enhance the SYSCALL auditd decoder to capture additional fields such as AUID and UID in the provided log:
type=SYSCALL msg=audit(1689686195.372:594462): arch=c000003e syscall=59 success=yes exit=0 a0=1820440 ... SYSCALL=execve AUID="testing" UID="testing" GID="test" EUID="testing"
We have proposed the following decoders:
<decoder name="auditd-syscall">
<parent>auditd</parent>
<regex offset="after_regex">AUID=\p(\S+)\p </regex>
<order>audit.auid_name</order>
</decoder>
<decoder name="auditd-syscall">
<parent>auditd</parent>
<regex offset="after_regex">UID=\p(\S+)\p </regex>
<order>audit.uid_name</order>
</decoder>
However, these decoders do not function properly when defined in the local_decoders file. They only seem to work when integrated into the native auditd Wazuh decoders, just before the following decoder:
<decoder name="auditd-config_change">
<parent>auditd</parent>
<regex offset="after_regex">res=(\S+)</regex>
<order>audit.res</order>
</decoder>
Nevertheless, this approach is not maintainable as changes to the ruleset will be lost after an upgrade. Therefore, further investigation into this issue is required.
I came here to open an issue on this specific issue. Though, I tried with other fields, too.
<decoder name="auditd-syscall">
<parent>auditd</parent>
<regex offset="after_parent" type="pcre2">AUID="(\S+)" UID="(\S+)" GID="(\S+)" EUID="(\S+)" SUID="(\S+)" FSUID="(\S+)" EGID="(\S+)" SGID="(\S+)" FSGID="(\S+)"</regex>
<order>audit.auid_resolved,audit.uid_resolved,audit.gid_resolved,audit.euid_resolved,audit.suid_resolved,audit.fsuid_resolved,audit.egid_resolved,audit.sgid_resolved,audit.fsgid_resolved</order>
</decoder>
Though, when it comes to auditd, laurel has better parsing and enrichment capabilities. I requested to make use of it too. https://github.com/wazuh/wazuh/issues/14461
I am not sure how it would be possible. But we need the uid -> username
resolution for proper alerting.
There is a bug when working with sibling decoders. Let's look at the decoders in the
0040-auditd_decoders.xml
file that we have modified to captureEXECVE
logs:If we try to decode an
EXECVE
log:we can verify that it has not been decoded correctly. However, if between these two types of decoder (SYSCALL and EXECVE) we add a dummy:
and we run the test again:
we check that this time it does decode the fields correctly.
Even with this, we can see that the
a4="dhcp4-change"
field has not been decoded either. The last field is not being decoded due to an extra space at the end of each field in the decoders.To resolve this, please update the EXECVE decoders to the following:
output: