Linux IR: Windows of Opportunity

The talk argues that incident response on Linux receives far less attention than Windows, and that the differences come down mostly to tooling, script logging and fleet management. The speaker presents a simplified investigation method built around four questions: who, what, when and where. He suggests choosing log sources with those questions in mind and using the MITRE ATT&CK Linux matrix to decide which log types to collect.

The demonstration detonates a sample from the SystemdMiner malware family on a deliberately vulnerable Jenkins host in a home lab. The lab uses Elastic Security, osquery, Suricata and Zeek. Default alerts flag proxy activity and base64 decoding right away. Process timelines and the analyzer view reveal a chain of shell scripts, a decoded payload that tries to clear the immutable bit on a temporary directory, and a cron entry used for persistence. Network logs show a scan for PostgreSQL on port 5432, downloads through Tor SOCKS proxies, and a check-in from a cryptocurrency miner.

The main takeaways are that Linux lacks an easy equivalent to PowerShell script block logging, so related child processes are hard to tie to one script, and that persistence is almost always present in an intrusion. Process-tree views help, but tooling can hit display limits on large event sets. The speaker argues against running commands such as lsof directly on a suspect host, and suggests remote tools like Velociraptor, Salt or Ansible instead. Building a lab by hand and taking snapshots are recommended for learning and testing.