 Freeware
Forensics Tools
Kristy Westphal
Many IT departments are pressured to merely keep things running
in a highly available state and never look back -- that is,
never understand why a service suddenly stopped working, or why
a server crashed to a grinding halt. But no matter how short-staffed
or time-crunched IT departments get, best practice dictates the
need for root cause analysis. Processes and procedures cannot improve
if the true causes of problems are not fully understood. With technology
growing at such a rapid rate, computer forensics is a key piece
of root cause analysis.
Computer forensics can also help determine whether a problem was
of malicious or unintentional intent (e.g., the careless employee
or the focused hacker). Internally and externally, forensic processes
can help define the facts, and sound forensics practices, backed
up with good tools, can help solidify any security architecture.
The UNIX tools that I will examine in this article are three popular
freeware tools:
- The Coroner's Toolkit (TCT>
- The @stake Sleuth Kit (TASK)
- Autopsy Forensic Browser
All three tools mentioned in this article were utilized in a Linux
7.3 environment. Note that a handy way to have all the tools available
without interfering or corrupting evidence is to copy them to a
CD and run them from the CD-ROM directory.
The Coroner's Toolkit (TCT)
TCT, developed by Dan Farmer and Wietse Venema, can be found at:
http://www.porcupine.org/forensics/tct.html or http://www.fish.com/tct/
TCT is a collection of forensics tools that includes grave-robber,
lazarus, and unrm. It has been ported to work on Solaris, FreeBSD,
OpenBSD, Red Hat, and HP-UX. These tools are somewhat dated as most
were originally created in 2000, however, most of the principles
still apply to today's version of the file systems. Note that
if you are using these tools on newer and not officially tested
operating systems, you might run into trouble. This freeware tool
explicitly states in the INSTALL file that it is only semi-supported,
so keep that in mind while using it.
To understand these tools, it helps to first understand the definition
of inode, which is a data structure that contains information about
files in UNIX file systems. This information is not often seen unless
something like an ls -li or stat command is issued.
Grave-robber is a data capturing tool that can be used to gather
inode information for use by mactime, which is another tool in the
toolkit. Mactime time orders files according to their mac (modification,
access, or change) inode time stamps. Lazarus and unrm are both
tools that work to recover deleted data.
The latest version of TCT available is 1.11. Download and un-tar
the file into its own directory and simply type "make"
to install the tools. You need Perl 5.0004 or later as well as a
C compiler to install the package. Make sure that you have plenty
of free space available wherever you run the tools from. Forensic
evidence tends to consume a lot of space because you are essentially
making a copy of the data that you are examining. This also implies
that it will take some time to run these tools (depending, too,
on which options you specify).
This latest version of the tool includes other programs besides
those listed above: file, icat, ils (lists filesystem inode information),
lastcomm, major_minor, md5 (the actual MD5 hash program), pcat (logs
which address space in memory that a process is running in), strip_tct_home,
and timeout. For a more complete definition of these tools, please
refer to the documentation.
Once compiled, you can cd into the bin directory to access the
tools. Variables for all of the programs can be set in the .cf files
in the conf directory. Global TCT variables are set in the coroner.cf
file, where individual program variables are set in their own .cf
files.
Using grave-robber
Grave-robber has many options, all of which are listed in the
man page. There are three main modes to grave-robber: macro, micro,
and general data collection, which can be specified by the options
used. Some of the more useful command combinations are described
below.
For general collection, use:
grave-robber -v
The -v option stands for verbose. Running with only that option
gathers information about the entire disk while spewing a lot of information
to the screen to let you know what is going on. Note that if you want
to mount a "dead" drive (or a corpse as the toolkit refers
to), you can use the -c option to point it to the mount of
the dead drive with the -o option to specify an OS type. Otherwise,
the tool guesses the OS.
For macro collection:
grave-robber -E or -f
The -E option stands for everything. The difference between
-E and the default options are that the -I (capture
the executable files of the running processes), and the -p
(copy process memory to a file using the pcat command).
For micro collection:
grave-robber -i -M -O -P -t -V
The options to specify a smaller window of collection include:
-i -- Collects the inode data from unallocated portions
of the file systems.
-M -- Makes an MD5 checksum for all of the files on
which it collects information.
-O -- Saves the files that are open, yet deleted from
the disk.
-P -- Runs process commands, such as ps, lsof
(if installed on the system or in your TCT install tree), to gather
information on processes that are currently running.
-t -- Records the trust information from the host and
user files.
-V -- Looks in the dev directory and details information
from there.
After Running grave-robber
In my case, I ran grave-robber -v on my Linux system. Be
warned that generates a lot of data to review. It helps to have
some idea of what to look for, such as key phrases and file types
that relate to the particular case you are investigating. If you
have such a list, your review of the information gathered will be
significantly shortened.
When you gather general evidence, you will end up with a large
file called "body", in which information on key files
is kept, including an MD5 checksum of the file, the file permissions,
the owner and group, access times, modification times, and time
of last change. On the 6-GB hard drive I use, the file was 21 MB.
Other information that you will get includes several directories
with the output of key commands, such as last, dmesg,
finger, who, and netstat (command_out). You
will get configuration information of key directories copied into
this safe location (conf_vault), information from the icat
command (icat), process information (proc), processes that have
been removed but are running (removed_but_running), the trust relationships
(trust), and information about the users on the system and what
they have been executing (user_vault).
Lazarus and unrm
To begin, you will probably want to use the unrm tool to create
the copy of the data you will be analyzing (remember, these two
tools are useful in data recovery). You could use a tool such as
dd, but the key difference between unrm and dd is that unrm also
recovers files from the free space on the disk. Thus, you will get
stuff that was possibly previously deleted and not overwritten.
When using unrm, make sure that you either have sufficient disk
space available on the disk that you are examining or that you have
another disk available on which to dump data, because you will be
recovering the same size file system that you are examining.
Usage:
unrm /dev/hda1 | dd count=46000 bs=1024 > /tmp/unrm.out
This translates into copying the raw filesystem from /dev/hda1 (where
you can replace the name of the disk device that you are using), and
piping it to dd to copy the 46-MB filesystem in block sizes of 1024
to /tmp/unrm.out. You can then use lazarus to parse this /tmp/unrm.out
file into two streams -- the blocks directory and a map that corresponds
to the blocks restored to the blocks directory.
Usage:
lazarus -h /tmp/unrm.out
The difference between the information in the map file and the blocks
directory is that the map will help you to examine overall what you
have just recovered. The blocks will give you all the data in a format
that can be searched with commands like grep. The -h
option will put the information into html format instead of just ASCII
text.
Note that the data that you can recover may be from a filesystem,
as well as from memory, swap, or other device file. It's best
to understand the full capabilities of these tools before you download
them and test them on the unknown device file. It is never a good
thing to try these tools in a crunch situation, only to find out
that the trial system crashes when you try to dump swap!
If you have any questions while you are using these tools, there
are several ways to obtain help. Man pages and docs are available
in the distribution. There is also a tutorial that the authors were
kind enough to put together (see the FAQ), as well as class notes
(http://www.fish.com/security/class.html).
You can join the user email list at: tct-users@porcupine.org.
The authors also suggest trying the comp.security.unix newsgroup.
If all else fails, you can email the authors at: tct@fish.com,
just keep in mind that they may not be able to get back to you right
away.
The @stake Sleuth Kit
Brian Carrier developed the TASK tool, which was originally started
as tctutils. TASK is located at:
http://www.atstake.com/research/tools/forensic/
This tool will run on Solaris, OpenBSD, FreeBSD, and Linux (as well
as Microsoft platforms). The version of TASK used in this article
is 1.60. TASK has kept more current on code development than its predecessor
TCT, and mainly focuses on gathering filesystem data.
Once you have downloaded and gunzipped the tar file, you can untar
it into its own directory. The only prerequisite for installation
is a C compiler. The installation process for TASK is simple; just
make and off you go.
Many of the TASK programs are also available with TCT (e.g., mactime,
file, icat, ils, md5), but some are new:
dcalc, dcat, dls, dstat -- Deal
with displaying details on the content layer of the filesystems.
ffind -- Identifies "the name of a file that has
allocated a given meta data structure".
fsstat -- Displays file system details in ASCII format.
hfind -- Helps search for files in a hash database
(such as the National Software Reference Library (NSRL).
ifind, istat -- These tools help analyze data
at the meta or inode level.
sha1 -- Another hash algorithm.
sorter -- Helps sort the files within the filesystem
that you are examining into categories set in the configuration
files.
The documentation for TASK recommends that these tools be used
through the Autopsy browser (described later), but that it isn't
a requirement. For both TASK and Autopsy, there is a user list to
which you can subscribe through the @stake Web site. Man pages and
docs directories are included with the standard distribution.
Autopsy Forensic Browser
As a GUI companion to TASK, Brian Carrier has also created the
Autopsy Forensic Browser (which is located at the same URL as TASK
and runs on the same platforms). The version used in this article
is 1.70. No special GUI programs are needed, because Autopsy is
HTML based and works in your favorite browser. As with TASK, simply
download the tar file, gunzip, and untar it. Cd into the directory
and type make. In the case of Autopsy, however, you will
have to determine the following: where TASK is installed, whether
you have access to the NSRL and, if so, the path, and where to locate
the Evidence Locker (i.e., where you will store the files that it
creates).
The Autopsy executable is now created and requires a few options
to be started up. Specifically, use -d to identify where
the Evidence Locker is located, the port on which to listen, and
the IP address where the investigation is being done (indicating
that it can be local or remote).
In my case, I used the following to start up Autopsy from its
install directory:
./autopsy 5555 192.168.0.2
I utilized the .2 address to access the browser remotely from my Windows
laptop. SSH forwarding can be established to encrypt traffic and further
secure connections over the network. See Figure 1 for a look at the
initial Autopsy screen.
Once you bring up the Autopsy interface, you can open an existing
case or a new one. When opening up a new case, Autopsy makes documentation
much easier by asking for some information:
- Case Name
- Description
- Investigator Logins
Then Autopsy takes the liberty of opening up a new case for you.
To proceed, you will need to add a host with a description. Once
this information is entered, you can prepare the file system image
that will be examined. It will need to be copied to a specific directory
on your TASK/Autopsy host:
/root/evidence//Test/localhost/images
In this example, /root/evidence is the location of my Evidence Locker,
Test is my case name, and localhost is my host name. Note that the
image will need to still be copied via command line. In the case of
TASK, you can use the dls command (unrm renamed for TASK).
Once the image has been copied and Autopsy recognizes it (done by
refreshing your browser), you can initiate a file timeline and integrity
check (see Figure 2). These tasks can both be done via the Autopsy
browser. Note that the browser requires some command-line knowledge
to set up, but not to run; therefore, any member of your investigation
team can run it.
To make your investigation easier, Autopsy also has an area where
you can have it automatically consult Alert, Ignore, or NSRL databases.
The Alert database can be set up to hold known "bad" files
and send a quick alert in case any are found (e.g., rootkits, virus
files). The Ignore database can be configured for known "good"
files.
Another key feature of Autopsy is the Timeline generation. To
begin, go to the "File Activity Time Lines" button in
the GUI. Then, create a Data File from the image that you are examining.
Once the Data File is created, you can select a date range for which
you would specifically like to check activity. This can be especially
helpful in cases where a large amount of data must be examined.
The Importance of Incident Response
Before you utilize these tools in your organization, you must
take care to fully comply with the security policies in place at
your company. If Incident Response is part of those policies, then
forensics will be, too. Always remember the end goal of your incidence
response policy. It's one thing if the intent is to preserve
the evidence for your own internal proceedings, but it's quite
another if the intent is to take legal action against someone who
has violated your policies. In that case, chain of command custody
rules will apply and great care must be taken in preserving the
evidence.
It's important to have a process determining exactly what
steps you will use to examine your evidence. The slides done by
Dan Farmer and Wietse Venema for the TCT class mentioned previously
clearly show what they did to arrive at the conclusions they reached.
They not only used good tools, but also an applied process to approach
the investigation in a sensible way.
Make sure that your legal counsel has reviewed and understands
your Incident Response policy and the implications of the forensics
process. It is better and easier to gain consensus on the process
up front rather than in the heat of containing an incident. It is
also important to implement an Acceptable Use policy explicitly
stating that any and all activity on company-owned systems is subject
to monitoring. This will not only cover the company during any investigation,
but also cover you.
Preserving Evidence
All incidents should be approached in the same manner in regard
to the Rules of Evidence, regardless of whether a case is going
to go to trial. The reason behind this is to keep consistency in
your incident response process and minimize confusion. Often, during
the course of an investigation, there is enough confusion already.
Throughout your investigative process, you must preserve the Chain
of Evidence. This involves keeping good notes, including 1) who
obtained the evidence, 2) where and when the evidence was obtained,
3) who secured the evidence, and 4) who had control or possession
of the evidence at all times (see the Information and Security
Management Handbook mentioned in the resources for additional
information).
Conclusions
Although the actual gathering of forensic data can be made easier
through the use of the tools mentioned in this article, there are
other factors to consider before you invest the time needed to learn
and use the tools. For starters, you should have basic security
banners, well-documented and communicated security policies, and
a well-trained emergency response team in place. Also, a good incident
handling policy for all types of IT incidents must be thoroughly
documented and tested.
Resources and Tools
"Information Security Management Handbook, 4th Edition".
Harold F. Tipton and Micki Krause, et al. Auerbach, 2000.
Tools used by CSIRTs to Collect Incident Data/Evidence Investigate
and Track Incidents: http://www.terena.nl/tech/task-forces/tf-csirt/chiht/tf-csirt-chiht-01.html
F.I.R.E. Forensics and Incident Response Environment Bootable
CD: http://biatchux.dmzs.com/?section=tools&subsection=F
Mac-daddy: a modified version of mactime that will work from a
floppy disk. Good for upfront analysis of a system: http://www.incident-response.org/mac_daddy.html
General Forensics: http://www.sans.org/rr/incident/forensics.php
http://www.tno.nl/instit/fel/intern/wkisec17.html
Security Focus Mailing lists: http://www.securityfocus.com/archive
Kristy Westphal, CISSP, is a versatile IT professional, skilled
in information security, troubleshooting, and process analysis.
Her experience in the Information Technology field has allowed her
to become knowledgeable in several flavors of UNIX and Windows,
as well as various aspects of intrusion detection and disaster recovery
planning. She is currently employed by Pegasus Solutions Companies
as Information Security Officer.
| 
