Some problems when using audit.log

[hoanga2dtk68]

I see your tool has provided a very good result, but the commands are missing as shown in the image above. For example, I use webshell and type ls -alh, the output will only show /usr/bin/ls and the same with curl, ping, which makes it difficult to investigate. Can I fix it somehow? Looking forward to hearing from you soon.

[wagga40]

I am away right now, I will be able to take a look tomorrow

[wagga40]

Hello, it is not easy to work from screenshots, please share your raw logs when you can (even if it is only one event).

Maybe I didn't understand, you have Auditd logs and you are asking why you cannot see your ls -alh command ? Since the parameter -alh is not appearing in clear text (more on that below) in your Auditd logs, the problem is Auditd related and not really Zircolite related.

So why --alh don't appear in clear text ? depending on the way you use Auditd, the arguments of a command appear hex-encoded. For example, in your screenshots the full command can be found in proctitle= :

$> echo "7368002D63002D2D006578656320323E26313B206C73202D616C68" | xxd -r -p
sh-c--exec 2>&1; ls -alh

You can decode it using the Auditd ausearch command with the -i argument to decode them : ausearch -if <your log file> -i

As far I can see from your previous issue, the command was perfectly visible in your Sysmon for Linux logs. What you were missing is a Sigma rule to detect it correctly (the closest one is this one here)

Lastly, a recommendation : never use the CSV format !!! 😁

[hoanga2dtk68]

that's not what i meant, i want to use zircolite as a tool to detect and minimize the need to reread auditd logs, i want zircolite output to show the ls -lah part and not in auditd log. not sure if this is possible

[wagga40]

Ok, I reviewed multiple times our discussion... I think I understand now.

The detection occurs on the event type=SYSCALL msg=audit(1723619808.916:3272): ........ but this event does not contains the full command line which appear in the event just before type=PROCTITLE msg=audit(1723619808.912:3271): .........

Since the detection occurs only on the first event, it is not possible for Zircolite to output in the detected events file an event which did not trigger a rule.

One way to check it, is to keep the flattened events --keepflat :

{"type":"PROCTITLE","timestamp":"2024-08-14 09:16:48","proctitle":"sh -c -- exec 2>&1; ls -alh","host":"offline","OriginalLogfile":"auditd.log-PO9EA3JN.json"}
{"type":"SYSCALL","timestamp":"2024-08-14 09:16:48","arch":"000003e","syscall":"59","success":"yes","exit":"0","a0":"562f4c5507c8","a1":"562f4ade5938","a2":"562f4ade5950","a3":"4","items":"3","ppid":"8087","pid":"8088","auid":"4294967295","uid":"33","gid":"33","euid":"33","suid":"33","fsuid":"33","egid":"33","sgid":"33","fsgid":"33","tty":"(none)","ses":"4294967295","comm":"ls","exe":"/usr/bin/ls","key":"detect_execve_www","ARCH":"x86_64","SYSCALL":"execve","AUID":"unset","UID":"www-data","EUID":"www-data","SUID":"www-data","FSUID":"www-data","EGID":"www-data","host":"offline","OriginalLogfile":"auditd.log-PO9EA3JN.json"}

But as you said, it would force you to reread some logs.

[hoanga2dtk68]

okay, thank you

[hoanga2dtk68]

I see that 17236190808.916:3272 then the 3272 part is probably the identifier of an event the events with number 3272 after: when combined together can probably write out the complete command

[wagga40]

It won't change anything since the parsing is line-based and not identifier based.