Sleuthkit
The first of the tools we will cover here is actually not a GUI tool at all, but rather a collection of command line tools. We cover them here because we will soon introduce a tool (Autopsy) that provides a nice GUI wrapper.
The Sleuthkit is written by Brian Carrier and maintained athttp://www.sleuthkit.org. It is partially based on The Coroner’s Toolkit (TCT) originally written by Dan Farmer and Wietse Venema. The Sleuthkit adds additional file system support (FAT and NTFS). Additionally, the Sleuthkit allows you to analyze various file system types regardless of the platform you are currently working on. The current version, as of this writing is sleuthkit-1.66. Go to the “downloads” section of the Sleuthkit website and grab a copy. For the sake of simplicity, let’s just download the file to our/root(root user’s home) directory.
Installation is easy. You can simply un-tar the file then change in to the resulting directory:
tar xzvf sleuthkit-1.66.tar.gz**cd sleuthkit-1.66**
Take a moment to read the included documentation. We will continue with a short description here, but most of what you need to know is right there.
Compiling the tools is as simple as typingmakeright in that directory. If you run into any problems, read the_INSTALL_document. When the compiling is finished, you will find the Sleuthkit tools located in the_sleuthkit-1.66/bin_directory. Themanpages for each command are located in the_sleuthkit/man_directory. Normally you would move or link the executable files to a common directory somewhere in your path. We are going to leave the tools where they are and call them explicitly.
The Sleuthkit’s tools are organized by what the author calls a “layer” approach.
File system layer –fsstat,
File name layer–fls, ffind
Content (data) layer –dcalc, dcat, dls, dstat
Meta data (inode) layer –icat, ils, ifind, istat
Notice that the commands that correspond to the analysis of a given layer begin with a common letter. For example, the file system command starts with “fs”, and the inode layer commands start with “i”.
We are going to do a quick sample analysis using just a few of the Sleuthkit command line tools. Like all of the other exercises in this document, I’d suggest you follow along if you can. Using these commands on your own is the only way to really learn the techniques.
Let’s have a look at a coupleof the file system and file name layer tools,fsstatandfls. We will run them against our_able2_partition images8. For the sake of this analysis, the information we are looking for is located on the root partition.
Remember from our previous analysis of the able2ddimages that the root (“/”) file system is located on the second partition (able2.part2.dd).
Make sure you are in/root/sleuthkit-1.66/bin/(or wherever you installed the Sleuthkit) and run the following command:
./fsstat /root/able2/able2.part2.dd
You should see the following output (partial):
FILE SYSTEM INFORMATION
File System Type: EXT2FS Volume Name:
Last Mount: Thu Feb 13 02:33:02 1997 Last Write: Sun Aug 10 14:50:03 2003
Last Check: Tue Feb 11 00:20:09 1997 Unmounted Improperly Last mounted on:
Operating System: Linux Dynamic Structure
InCompat Features: Filetype,
Read Only Compat Features: Spars__e Super,
META-DATA INFORMATION
-------------------------------------------- Inode Range: 1 - 12880
Root Directory: 2
CONTENT-DATA INFORMATION
Fragment Range: 0 - 51299
Block Size: 1024
Fragment Size: 1024
Thefsstatcommand provides file system specific information about the file system located in a device or partition image.
We can get more information using theflscommand. flslists the file names and directories contained in a file system, with a number of options. If you type “./fls” on its own, you will see the available options (view themanpage for a more complete explanation).
./fls**–f linux-ext2 –Frd /root/able**2/able2.part2.dd
r/r * 11120(realloc): var/lib/slocate/slocate.db.tmp r/r 10063: var/log/xferlog.5 r/r 10063: var/lock/makewhatis.lock r/r 6613: var/run/shutdown.pid r/r 1046: var/tmp/rpm-tmp.64655 r/r 6609(realloc): var/cat_man/cat1/rdate.1.gz r/r 6613: var/catman/cat1/rdate.1.gz r/r 6616: tmp/logrot2V6Q1J r/r 2139: dev/ttYZ0/lrkn.tgz d/r 10071(realloc): dev/ttYZ0/lrk3 r/r 6572(realloc): etc/X11/fs/config- l/r 1041(realloc): etc/rc.d/rc0.d/K83y_pbind l/r 1042(realloc): etc/rc.d/rc1.d/K83ypbind l/r 6583(realloc): etc/rc.d/rc2.d/K83ypbind l/r 6584(realloc): etc/rc.d/rc4.d/K83ypbind l/r 1044: etc/rc.d/rc5.d/K83ypbind l/r 6585(realloc): etc/rc.d/rc6.d/K83ypbind r/r 1044: etc/rc.d/rc.firewall~ r/r 6544(realloc): etc/pam.d/passwd- r/r 10055(realloc): etc/mtab.tmp r/r 10047(realloc): etc/mtab~ r/- 0: etc/.inetd.conf.swx r/r 2138(realloc): root/lolit_pics.tar.gz r/r * 2139: root/lrkn.tgz
In this case, we are running theflscommand against an Ext2 file system (-f linux-ext2), showing only file entries (-F), descending into directories (-r), and displaying deleted entries (-d). The output gives us the file name and the_inode_to which thatfile is associated.
Now let’s use a couple of Metadata (inode) layer tools included with the Sleuthkit. An inode has unique number and is assigned to a file. The number corresponds to theinode table, allocated when a partition is formatted. The inode contains all the metadata available for a file, including the modified/accessed/changed times and all the data blocks allocated to that file.
First we are going to useistatfrom the Sleuthkit. Remember thatfsstattook afile system_as an argument and reported statistics about that file system. Well,istatdoes the same thing; only it works on a specified_inode.
If you look at the output of ourflscommand, you will see a file calledlrkn.tgz_located in the/rootdirectory (the last file in the output of ourflscommand). The inode displayed byflsfor this file is_2139. Note that this same inode also points to a file in/dev(same file, different location). We are going to useistatto gather some informationabout inode2139. Remember, we are in the_sleuthkit/bin_directory, so we use “./” to indicate that the command (not in our path) is run from the current directory:
./istat -f linux-ext2 /root/able2/able2.part2.dd 2139 | less
inode: 2139 Not Allocate__d Group: 1
uid / gid: 0 / 0 mode: -rw-r--r-- size: 3639016
num of links: 0
Inode Times:
Accessed: Sun Aug 10 00:18:38 2003
File Modified: Sun Aug 10 00:08:32 2003
Inode Modified: Sun Aug 10 00:29:58 2003
Deleted: Sun Aug 10 00:29:582003
Direct Blocks:
22811 22812 22813 22814 22815 22816 22817 22818
22819 22820 22821 22822 22824 22825 22826 22827
...
32225 32226 32227 32228 32229 32230 32231 32232
32233 32234
Indirect Blocks:
22823 23080 23081 23338 23595 23852 24109 24366
30478 30735 30992 31249 31506 31763 32020
This reads the inode statistics (./istat), on an ext2 (-f linux-ext2) partition (/root/able2/able2.part2.dd) from inode2139. There is a large amount of outputhere, showing all the inode information and the direct and indirect blocks9that contain all of the file’s data. We can either pipe the output to a file for logging or evidence results, or we can send it tolessfor viewing.
We now have the name of thedeleted file (fromfls) and the inode information, including where the data is stored (fromistat).Now we are going to use theicatcommand from the Sleuthkit to grab the actual data contained in the data blocks referenced from the inode. icatalso takes the “inode” as an argument and reads the content of the data blocks that are assigned to that inode, sending it to standard output.
We are going to send the contents of the data blocks assigned to that inode to a file for closer examination.Again, we issue the following command from the_sleuthkit/bin_directory:
./icat –f linux-ext2 /root/able2/able2.part2.dd 2139 > /root/lrkn.tgz.2139
This runs theicatcommand on our ext2 (-f linux-ext2) partition (able2.part2.dd) and streams the contents of the data blocks associated with inode2139to the file/root/lrkn.tgz.2139. The filename is arbitrary; I simply took the name of the file fromflsand appended the inode number to indicate that it was recovered. Normally this output should bedirected to some results directory.
Now that we have what we hope is a recovered file, what do we do with it? Look at the resulting file with thefilecommand:
file lrkn.tgz.2139
lrkn.tgz.2139: gzip compressed data, was "lrkn.tar", from Unix
Have a look at the contents of the recovered archive (pipe the output throughless…it’s long). Remember that the “t” option lists the contents of the archive.
Don’t just haphazardly extract an archive without knowing what it will write, or especiallywhere10:
tar tzvf lrkn.tgz.2139 | less
drwxr-xr-x lp/lp 0 1998-10-01 18:48:18 lrk3/ -rwxr-xr-x lp/lp 742 1998-06-27 11:30:45 lrk3/1
-rw-r--r-- lp/lp 716 1996-11-02 16:38:43 lrk3/MCONFIG -rw-r--r-- lp/lp 6833 1998-10-03 05:02:15 lrk3/Makefile
-rw-r--r-- lp/lp 6364 1996-12-27 22:01:43 lrk3/README
Notice that there is a_README_file included in the archive. If we are curious about the contents of the archive, perhaps readingthe_README_file would be a good idea, yes? Rather that extract the entire contents of the archive, we will go for just the_README_using the followingtarcommand:
tar xzvfO lrkn.tgz.2139 lrk3/README > /root/README.2139
The difference with thistarcommand is that we specify that we want the output sent tostdout(“O”) so we can redirect it. We also specify the name of the file that we want extracted from the archive (lrk3/README). This is all redirected to a new file called/root/README.2139.
If you read that file, you will find that we have uncovered a “rootkit”, full of trojanized programs used to hide a hacker’s activity.
What we have seen here is a simple (and in many ways incomplete) example of the Sleuthkit’s command line toolsfor forensic examination. If you are left a little confused, just go through the steps one at a time. If you don’t understand the commands or options, check the usage and read themanpages and Sleuthkit documentation. Run through the exercise a coupleof times, and the purpose and outcome will make more sense. Take your time and experiment a little with the options.
We are now going to look at an easier way to “point and click” your way through a Sleuthkit exam, organizing your investigation asyou go using Autopsy.
8. The Sleuthkit works on partition images, not on whole disk images. This is one reason why it might be useful to learn how to carve partitions (or take partition dd images). ↩
9. For a detailed description of “direct” and “indirect” blocks, see http://e2fsprogs.sourceforge.net/ext2intro.html. ↩
10. Let’s face it, it would be BAD to have an archive that contains a bunch of trojans and other nasties (evil kernel source or libraries, etc.) overwrite those on your system. Be extremely careful with archives. ↩