Lion Cipher Lab
Reassemble Linux audit EXECVE records and hunt the decoded commands
- SOC Analyst / Blue Team
- Advanced
- ~90 min
- Free · no account required
Why it matters
On a Linux server, the audit subsystem is often the only record of exactly which commands ran, with which arguments, as which user. It is what an incident responder reaches for when a web server has been turned into a remote shell. But the raw log is not written for humans or for grep. One command becomes five lines; any argument containing a space is silently rewritten as a hexadecimal string; a long argument is cut into pieces across several lines; and the convenient 'process title' field stops after 128 bytes. An analyst who greps audit.log for 'curl' or 'base64' gets a confident, wrong…
What you'll learn
- Reading a raw audit.log: type=, msg=audit(time:serial), and the SYSCALL / EXECVE / CWD / PATH / PROCTITLE records that make one event
- Knowing the kernel's exact rule for when an argument is written as hex instead of quoted text
- Reassembling split EXECVE arguments (aN_len, aN[0], aN[1]) by joining the hex BEFORE decoding
- Explaining why PROCTITLE cannot be trusted for long command lines (the 128-byte cut)
- Using auid versus uid (and auid=4294967295, 'unset') as the who-is-really-behind-this context
- Scoring a hunt per event with true positives, false positives and misses, and naming what each tier cannot see
Steps in this lab
- What you are looking at, and why a SOC hunts it
- One event, five records, one serial number
- The encoding rule: why some arguments turn into hex
- Build the synthetic audit.log
- Read the raw records before you write any code
- Write the reassembler
- Why you decode EXECVE and do not trust PROCTITLE
- auid versus uid: who is really behind a command
- Four hunts over the same log, scored per event
- The judgment: which hunt to run, and when
- The way the pros read it: ausearch -i, keys and enriched logs
- Honest limits, and where to go next