11.3. Digging Deeper with the Sleuth Kit

You may reach a point where using basic system tools leads nowhere. There are several important open source forensics tools that are in common use today that provide low-level system information that can be useful to reconstruct what has occurred on a host. Many of them share common code or have changed names over time. It is important to understand the relationship between various toolkits, especially as you look for knowledge outside of this book.

11.3.1. History of the Sleuth Kit

In 1999, Wietse Venema (author of TCPWrappers and Postfix) and a small team created a set of tools called The Coroner's Toolkit (TCT) to aid in forensic analysis of a compromised Unix system. TCT was a great leap forward for open source forensics tools and put detailed, low-level analysis in the hands of the masses.

As good as TCT was, there were several weaknesses. The tools provided in TCT were very raw and low-level, necessitating the creation of supporting tools. Also, TCT was platform dependent and difficult to port. In response to this, @stake, a security service company, created the @stake Sleuth Kit (TASK). TASK unified third-party tools with TCT into one software package to provide a "one-stop shop" for UNIX forensic analysts. TASK also reworked internal code to make it more portable. TASK also broke tools apart according the layer at which they were operating on; filesystem, content, metadata, or human interface. This distinction between tools simplified use and helped analysts chose the right tool at the right time.

Finally, TASK was taken over by a group independent of industry or academic pressure. TASK became simply the Sleuth Kit (TSK) and is continually being developed to provide more utility and adapt to changes in supported operating systems. TSK source code and documentation is available from http://www.sleuthkit.org/.

11.3.2. Installing and Understanding TSK

TSK is in the ports tree and can be installed with relative ease. If you prefer, the Sleuth Kit can be compiled and installed from source after being downloaded from the sleuthkit.org web site. As mentioned previously, the tools in TSK are broken into four different layers; filesystem, content, metadata, and human interface.

The content (or data) layer is for the actual data of files and directories. Tools that operate on this layer directly interact with the data in files and directories. These tools start with the letter d.

The metadata layer contains information that describes the files and directory themselves. This includes inode information, FAT directory structures, access and modification times of files, and privilege information. These tools start with the letter i.

The human interface layer provides a more convenient way to interact with files. Rather than have to understand and track the metadata information, the human interface layer abstracts some of that information to make it easier on the analyst. Human interface tools start with the letter f.

Finally, the filesystem layer deals with (as you may have guessed) information about the filesystem such as volume name and when a volume was last mounted. These tools start with the letters fs.

11.3.3. Using TSK

When using the tools in TSK, the first thing you should do is make a copy of the disk with which you are interacting. Never interact directly with the compromised filesystem. Performing forensic analysis against the compromised filesystem may change the data in an unexpected and untraceable way. If you make changes to the original data, you will never really be sure of what an attacker has done as opposed to what you did.

Copying filesystems is relatively easy. On your forensics workstation you need to have at least twice as much free space as the filesystem you intend to copy from the compromised drive. Not only will you be making a copy of the compromised filesystem, you are also copying of all the free space on the filesystem as well.

Take the drive from the compromised host and attach it to the drive controller on your forensic workstation. Use the dd(1) utility to copy the compromised filesystem to an image file. So, assuming you wanted to examine the root filesystem of the compromised drive currently available as ad1 to your home directory, you would execute the following.

% sudo dd if=/dev/ad1s1a of=/home/user/comp-root.dd

Depending on the size of the filesystem, this may take a while. dd is designed to be precise, not quick. You will probably see transfer speeds of 10-30MB a minute, so for a multi-gigabyte filesystem, you may consider getting some food or watching something on your TiVo.

If you are lucky enough not to have a compromised filesystem to deal with, you can still practice your forensics skills with your existing host. Hopefully you have enough space on one filesystem to hold the contents of another. Take the following host for example:

% df -k Filesystem  1K-blocks    Used    Avail Capacity  Mounted on /dev/ad0s1a    495726   85304   370764    19%    / devfs               1       1        0   100%    /dev /dev/ad0s1d  15231278 3099220 10913556    22%    /usr /dev/ad0s1e   2697326   26902  2454638     1%    /var

The root filesystem is only 500MB and there is nearly 11GB of free space on the /usr filesystem. In this setup, you can copy the root filesystem via dd to someplace in /usr and perform your "analysis."

Once dd is complete, you have a bit-for-bit copy of the original filesystem that you can start doing your analysis against. You may, for the sake of safety, copy all the filesystems on the compromised disk, shut down your workstation, and remove the drive. This will ensure that you are not going to inadvertently modify the compromised disk.

Depending on the information you're looking for, you may want to use various tools in TSK. Normally, you want to build a timeline of when files were modified on the compromised host. Start this process by using the fls tool to gather data about allocated and unallocated files in the filesystem. Use fls with the -m flag to specify the mount point and -r to ensure the entire filesystem is examined. The -f flag specifies the filesystem type you are dealing with. This flag is used in nearly all TSK tools.

% fls -f freebsd -m / -r comp-root.dd > body

Next, use the ils tool to find information about unallocated inodes. With this information you can determine what files have been changed and deleted. Note that you are adding the output of the ils command to the body file, not overwriting it.

% ils -f freebsd -m comp-root.dd >> body

Finally, use the mactime command to create the timeline from the body file. mactime takes the input body file via the -b flag and requires a start date. mactime will only log changes that occurred after that date. In this example, we examine all changes on a host since January 1, 2000.

% mactime -b body 1/01/2000 > timeline

The timeline file now contains information on every file that has changed or been deleted since the start of the twenty-first century. You can examine the file using a pager like less or grep through it for strings you're interested in. In this case, we are interested in changes in inetd.conf. Using grep, we find the following entry

Thu Jul 24 2003 17:10:08 4939 m.c -/-rw-r--r-- 0 0 60159 /etc/inetd.conf

4939 is the size of the file. The m.c indicates that the file was modified and created at that time.

The timeline file can be very valuable when piecing together the events in an attack. File access, creation, and modification around the time of the attack may be pointers to indicate how an attacker broke in and what her motivations were.

11.3.4. Autopsy

Digging through the data generated by TSK by hand can be tedious and confusing. If you are performing analysis on a large number of hosts or are working as a team, the flat files and ad-hoc storage of TSK data can be cumbersome. Thankfully, there's Autopsy, a perl script that provides a web interface for interacting with data from the Sleuth Kit.

Autopsy can be installed from sysutils in the ports tree. Alternately, the code can be downloaded directly from http://www.sleuthkit.org/ and configured manually. Note that the ports installation does not actually install Autopsy anywhere. You have to manually copy the script and supporting files to a directory of your choice, usually your home directory.

Once configured, Autopsy can be started simply with /path/to/autopsy. Once started, Autopsy will direct you to a URL where you can access its functionality as shown in Example 11-4.

Example 11-4. Starting Autopsy

% sudo ./autopsy  ============================================================================                        Autopsy Forensic Browser                               ver 1.73  ============================================================================ Evidence Locker: /usr/home/gdead/evidence/ Start Time: Mon Dec 13 23:42:47 2004 Paste this as your browser URL on localhost:         http://localhost:9999/37461905692459298670/autopsy

By default, Autopsy restricts connections to localhost only. If you want to change the port Autopsy runs on or allow remote access, you can start multiple instances of the program using the syntax autopsy port remote-host.

Autopsy does more than simply allow web access to TSK data. It aims to be a complete incident analysis tool that can be used from the beginning of the analysis process all the way through potential legal proceedings. Autopsy provides the ability for multiple analysts to work on one incident, multiple hosts to be associated with one incident, and even accounts for time drifts between hosts automatically. Further, notes can be entered for any piece of data within Autopsy allowing your analysis data to be stored with the raw information. Autopsy also automates the task of creating a timeline so you don't have to remember the awkward TSK commands. Figure 11-2 shows a timeline as viewed in Autopsy. Arguably, this is much nicer than viewing a flat text file from TSK.

Figure 11-2. A sample timeline from Autopsy

TSK and Autopsy are complicated tools and we have only scratched the surface. With the test image you have, you should examine the other tools included with TSK to become familiar with their utility now . . . before you really need them.