Testing the auditd config & auditd parser. The sample isn't holding back, a lot to unpack here - should be a good test! An image of the process tree - 1666 process events alone.
| https://twitter.com/exeron | |
| Github | https://github.com/exeronn/ |
Chris Walker
- 9 Followers
- 96 Following
- 59 Posts
An account to share my effort to understand the Linux threat landscape better. Previously 10 years of experience with SOC, Threat Hunting & IR which was mainly windows focused with dabbles into OSX and Linux.
I do this by never recording anything with a3 set to 0. This seems to be the majority of cases for file reads. Whereas most other interesting activity has some kind of mode set in a3. I need to do more testing, add some defeats and probably look at some a2 masks for reliability.
I've got the current, but early version of my auditd log parser library published into Pypi. Currently it can parse process (execve) and network connect events. It also attempts to add edges (GUIDs) to the events.
https://github.com/exeronn/auditd-python-parser
"pip install auditd-python-parser"
GitHub - exeronn/auditd-python-parser: A python library to parse raw auditd events generated on a linux system
A python library to parse raw auditd events generated on a linux system - GitHub - exeronn/auditd-python-parser: A python library to parse raw auditd events generated on a linux system
Network events are now being parsed, mapped to the parent process GUID where possible and the parent comamndline added when the GUID is sucessful. This should make mapping connections back to processes easier and the commandline should make investigating / detection easier.
Working on parsing auditd logs to both generate similar data to SysmonForLinux & anything additional it may record. I've intially focused on process events & will mvoe to other data types shortly.
Most worthy of note is the Process Access event has some records in. It appears that unlike on Windows, you can have it enabled fairly widely - at least for a fairly vanilla install.
The file create data doesn't record the target files very well, with a lot being blank. The file deletes works more reliably, giving some insight into the Wine file system.
For the fun of it I thought I'd try out Wine & see what the telemetry looked like (plus any blind spots for windows malware to run in)
The process create data shows the Wine server being created, but fails to link the process ancestry like htop does.
It does run a few scripts to get execution started (start -> run -> go). Nohup in sysmon at least appears to be a process chain break & the parent is systemd.
Overall this one doesn't do a great deal that's interesting and is mainly just messy. One thing I noticed as a trend was the use of chmod to set a file as executable.