Let’s discuss a topic that I feel like doesn’t get enough coverage or is the “unspoken” or “daunting” territory of Digital Forensics and Incident Response (DFIR). I’m going to say the words… LINUX FORENSICS. Oh yeah, this blog post is going to discuss how to collect a triage image of a nix box. This is a tool that you need to add to your toolkit and have at the ready when it comes to triaging nix systems. Before we talk about the tool, let’s talk about why a “triage image” and what this is exactly.
Modern-day DFIR is all about getting to the important stuff faster, right? (of course, depending on what your role is, capabilities and questions you’re trying to answer). In order to respond effectively to an active incident, we need to know where the data is, how to collect it, quickly parse it, and identify actionable data in order to effectively respond and combat a threat. As you can imagine, if you’re responding to an active incident, you’re likely not going to want to collect a full-disk image. This can take not only a long time to collect, its very large to store, time-consuming to upload the data to the proper team, time-consuming to download, and very time-consuming to parse into your tools and begin searching through the noise. Sure, you’ll have pivot-points and whatnot, but when it comes to intrusion analysis, do we really need to be collecting pictures, videos, and the content of every single file on the filesystem? Why don’t we just focus on the important things regarding the intrusion? This can include various logging sources, filesystem, other artifacts, etc. All the important things to identify what the actor did, when they did it, how they did it, and collect that intelligence to eradicate the threat to move towards recovery. This is where “triage-analysis” comes into play. For Windows systems, you may have heard of Eric Zimmerman’s (Kroll), fantastic tool named “KAPE” or Kroll Artifact Parser and Extractor. But what do we have for Linux? Majority of files on Linux are just that… files. So, as you can imagine, data collected will be a bit different than that of a Windows system.
During this blog post, we’ll discuss a fantastic tool called “Unix like Artifact Collector” or simply, UAC. This can be downloaded from here https://github.com/tclahr/uac and it’s a fantastic tool. I won’t explain the tool in all its glory, but in a nutshell, it’s a shell script file (with a few configuration files), that will collect the important data on a nix based system for intrusion analysis, or forensics in general. This will collect items such as browser history, /var/log contents containing many Linux logs, tmp files, Linux Body File (which is an export of the EXT filesystem), live system information such as netstat output, running processes, configuration files found in /etc, and much, much more. You can even customize your own collection profile that contains specific files you want to collect! I mean, what else can you ask for? Essentially, all you need is a nix based system with shell access. So, if you’re dealing with a compromised appliance such as a firewall that’s *nix based, ESX server, storage device such as a NAS, this tool will likely be perfect for you!
Just remember, this is a “tool”. It will not “find evil” for you, but it will collect the data for your review and provide it in a nicely wrapped package for you!
Some of the main features described on the GitHub for the tool are:
Run everywhere with no dependencies (no installation required).
Customizable and extensible collections and artifacts.
Respect the order of volatility during artifact collection.
Collect information from processes running without a binary on disk.
Hash running processes and executable files.
Extract information from files and directories to create a bodyfile (including enhanced file attributes for ext4).
Collect user and system configuration files and logs.
Collect artifacts from applications.
Acquire volatile memory from Linux systems using different methods and tools.
Okay, now that I’ve piqued your interest, let’s discuss a scenario here.
You are notified of suspicious activity on your ESX host. This host triggered an alert on your Network Security Monitoring (NSM) appliance, such as an IDS (Intrusion Detection System) for a signature matching that of a Linux-based crypto-miner. Essentially, someone is using your resources from your server to make money. The nerve! Let’s use a tool to collect a triage image of this server in order to get a better understanding of what we’re dealing with here, collect intel, and use this intel to scope the incident and ensure this is contained!
Let’s start by downloading the tool. As mentioned, this can be found here: https://github.com/tclahr/uac. Be sure to download the latest release.
Excellent! Now let’s go ahead and move this file to our system of interest. This can be done remotely using SSH, SCP, TFTP, external storage, file-share, etc. Whatever works for you in this scenario!
Perfect, let’s decompress this archive now. This can be done with the command “tar -xf uac”. You'll now see the decompressed folder named 'uac-2.8.0'.
Once fully decompressed, we can now see all the files associated with this! Including our profile configuration and more. Again, I won't go into detail about what each file does but in summary:
Artifacts - Contains a listing of what to collect. This can be customized
Bin - You can place additional binaries here that you may want to use for your collections
Tools - Various *nix scripts the collector may use as part of its normalization
Profiles - Contains the profiles of the collectors. These essentially define what "artifacts" will be collected. By default, this comes with three profiles, but you can make your own
uac - The shell script file
In this scenario, for the sake of time, we’ll go ahead and use the default profiles, which are “full” and “ir triage”. To execute this, its simple! Just navigate to the directory where the decompressed tool is and run the following command sudo /uac -p full output_directory_here
The below command indicates executing the 'uac' file, using the profile 'ir_triage' and placing the output in my current working directory.
Shown below are the artifacts collected by this profile.
Let the tool do its thing! This will begin collecting a large number of artifacts. Note that the above example used the “ir_triage” profile, which will collect less data versus “full”. The collector will now start. Depending on how much data there is to collect and the size of the system, processing power, etc. the time to collect all requested data will vary.
Boom! We have out output nicely compressed for us!
Let’s take a look at some of the data.
/var/log directory
/etc files including ‘shadow’ and ‘passwd’.
Items in the ‘tmp’ directory
And of course, live data!
Here's some of the "live_response data collected
/var/log content
As mentioned, it even collected the bodyfile of the filesystem! So you can use a tool such as "mactime" to sort this and use it to review files that have presence on the system!
Again, the interesting part of this tool is the fact that its simple! Yet amazing! It’s using various built in *nix tools to run a multitude of commands and placing this in an easy-to-understand archive. It even retains the directory structure! With this data, we can now analyze it! You can place this in your favorite forensics tool, since this retained the directory structure, it gets treated as if you uploaded an image. You can then start parsing through the logs or doing keyword searches.
If you do DFIR, whether internally or as an MSSP, this is a tool you need to have at the ready. Consider making your own profiles that fit your organization and needs.