I signed up to attend again SANS DFIR Europe Summit and Training 2019 - Prague Edition, as I appreciated meeting with peers and present my new tool for Linux incident response. I started working on the tool concept back in March and decided that it will be a great addition to my toolbox of scripts and commands. Share with the community is something I wanted to do for a while, since I’ve been so blessed to learn for free from everyone who shares.

Idea for TuxResponse came after incident response engagement, where I realized the need of automation of certain checks on Linux boxes. Instead of relying on saved commands, cheat sheets and unstructured scripts, I decided it’s time for a tool that will help me and others. I started first with identifying common problems of Live Incident Response:

  • Unprotected compromised server in need of quick triage.
  • Artifact collection of a known ongoing compromise.
  • Cloud deployments, where no disk or memory image out of the box is possible.
  • IT, Security Operations Center, Cloud Security Monitoring or someone else tells me to look at a Linux box, because it behaves ”wired” (whatever that means).

Being exposed to cloud environments, I face some disappointments and limitations of acquiring evidence. Not able to take memory snapshots, nor disk images out of the box is not something I am happy with. Using DD and LiME to acquire disk and memory image, however some of my commands failed to give me what I want - more testing is needed. That’s why I decided it’s time to create something that’s more reliable and can serve the community.

In Azure as well as in Digital Ocean, you’re quite limited of what you can do with the systems there. Disk image snapshots are enabled for download in Azure, but not in Digital Ocean. Memory snapshots are disabled in both environments, thus making it impossible to capture memory on systems without EDR or any kind of third-party forensics tools. When capturing Linux systems, things are more tricky and you need to script before you go on the box and take what you need. Then I came up with the idea for a script that will give community something reliable in #bash.

With above scenario however comes lots of challenges, as Linux world is not like Windows world.

As per current data (September 2019), there are 285 Linux actively developed Linux distributions.

All of them would use same kernel, but not same configuration, file system, log location and this opens another set of problems I need to overcome. Using shell scripting to create the tool is the natural way to go, since scripts will support most Linux shells (with small exceptions). If I keep up with POSIX style of shell scripting, then I eliminate the need of choosing between, Python, Ruby, Go or other language and the dependency nightmare they introduce.

Dependencies, dependencies, dependencies

TuxResponse Functionality

Considering incident scenario on a system I know nothing about and such that cannot be forensically acquired (memory image, disk image), initial purpose is to footprint all the things. In essence, I’m running commands

hostnamectl; who -b; uname -a; uptime; ifconfig; date; last reboot

one after another to give me the information I need. More about TuxResponse functions is available in well-maintained documentation on the tool’s GitHub repo:

https://github.com/la3ar0v/TuxResponse

Some of the responses I’ve got:

MITRE ATT&CK Framework for Linux - Mapping against common attacks

At first sight, some checks I do are not present in MITRE framework, thus I had to submit them (pending response) to MITRE team. But let’s focus on what’s available and TuxResponse can test against:

MITRE ATT&CK Linux ID: T1139 - Bash History - https://attack.mitre.org/techniques/T1139/

MITRE ATT&CK Linux ID: T1158 - Hidden Files And Directories - https://attack.mitre.org/techniques/T1158/

MITRE ATT&CK Linux ID: T1168 - Local Job Scheduling - https://attack.mitre.org/techniques/T1168/

My presentation at SANS DFIR Europe Summit 2019, slides available at the link below:

https://www.sans.org/event/dfir-prague-2019/summit-agenda

Further development

I’m developing a plan with all the feedback I received, so I can improve the tool further. Once I’m 100% happy with end results, I’ll let Tsurugi Linux team to implement in the Bento Toolbox.

Tell me what you think in the comments section below!