Copy Link

Add to Bookmark

Report

The Sleuth Kit Informer Issue 13

eZine lover (@eZine)

Published in

Sleuth Kit Informer

· 10 months ago

http://www.sleuthkit.org/informer
http://sleuthkit.sourceforge.net/informer

Brian Carrier
carrier at sleuthkit dot org

Issue #13
March 15, 2004

Introduction
What's New?
Call For Papers
Did You Know?
UNIX Incident Verification With Autopsy

Introduction

I'm almost done! Releasing version 2.00 of Autopsy that is. I'm polishing up the final changes and documentation and it will be released later this week. March 19 is the birthday of Autopsy and The Sleuth Kit's predecessor, TCTutils, also the goal release date for version 2.00.

This issue of the Informer will focus on the new live analysis feature of (the unreleased) Autopsy. This issue also has a lot entries in the "What's New?" category because we are on a bimonthly schedule. If you missed getting the February issue of The Informer and have lessons to share with people then make sure you read the Call For Papers section so that you can learn how to submit articles of your own.

What's New?

A new version (1.68) of The Sleuth Kit was released. It contains a couple of bug fixes. There have been discussions on the sleuthkit-developers list about what new functions should be added to the next big version 2.00 release. Michael Cohen has been looking into support for disk images, split images, RAID images, and other non-raw formats. David Collett has been looking into output formats for TSK tools so that they can be imported into databases.

Version 2.00 of Autopsy will be released later this week. I'm adding the final touches and documentation and the goal is to release it on March 19, which is the 3 year anniversary of the first release of Autopsy and TCTutils. Version 2.00 has a new internal design and has live analysis features (see below article). If you can't wait for a few days and want one of the beta copies, let me know.

Guido Metzner has been translating The Sleuth Kit Informer into German. If anyone else is translating this, let me know and I'll add a link.
http://www.guframe.de/sleuthkit.html

I started to provide a GPG signature of the source code as it is released. I have meant to do this for ages. This can help to ensure that the code being downloaded has not been modified by an attacker.

Call For Papers

I posted a call for papers on the website in late January for people that are interested in writing articles for the Informer. Here is the relevant section:

The Sleuth Kit Informer is looking for articles on open source tools and techniques for digital investigations (computer / digital forensics) and incident response. Articles that discuss The Sleuth Kit and Autopsy are appreciated, but not required. Example topics include (but are not limited to):

Tutorials on open source tools
User experiences and reviews of open source tools
New investigation techniques using open source tools
Open source tool testing results

http://www.sleuthkit.org/informer/cfp.html

Writing these articles takes away from my development time of new tool features, so any help is appreciated. To keep with the incident verification theme, any articles on the basics of using 'netstat', 'lsof', etc. to look for signs of an intrusion are also welcome for the next few issues. If we get enough interest, I'll consider going back to a monthly schedule.

Did You Know?

Have you ever noticed that the number of occurrences and locations of keywords for regular expressions in Autopsy are not always accurate? This came up on one of the mailing lists this past month and I'll explain it again here.

Previous issues of The Informer have covered keyword searching, but the general idea in Autopsy is that it runs the 'strings' command on the image file and then uses 'grep' to find the keyword. The 'strings' command returns a long ASCII string that grep examines. If the keyword is found in the string, then grep fill flag the string and autopsy will search the string to find the exact location of the keyword.

This is easy if a non-regular expression is used, but much more difficult with regular expressions because 'grep' regular expressions are different from Perl regular expressions. I do not have a way to convert the grep regular expression to Perl and therefore I only return the number of big strings that have the keyword and the location of the start of the big string. There could be more than one keyword in the string, in which case the total occurrences value is too small. The location will also be off because it points to the start of the large string and not the specific keyword.

If anyone knows of, or wants to write, a grep to perl regular expression converter, let me know so that we can update this.

UNIX Incident Verification With Autopsy

Introduction

For a couple of years, I have been saying that Autopsy can be used to analyze a live system, but it has taken me a while to make it EASY to use to analyze a live system. When version 2.0 of Autopsy is released later this week, you will find that it is much easier to configure so that it runs on a CD-ROM so that you can examine a system that is suspected of being compromised. This will allow you to view files that are hidden by rootkits and will not change the access times on files that are viewed.

This article will give an overview of how to use the new features and what features are available for dead analysis are not for live analysis. I will also show the future work for Autopsy. This article uses many of the same concepts as the "UNIX Incident Verification with The Sleuth Kit" article in issue #10 of the Informer.

Motivation

Some may be asking "why would I want a live analysis feature?". The primary motivation is for a more automated Incident Verification procedure. We saw in issue #10 of the Informer, that The Sleuth Kit can be used to verify an incident because it can show files that are hidden by rootkits and will not update the access times on files when they are read. Executing a bunch of command line tools is tedious though and Autopsy can provide a more automated investigation procedure.

The basic scenario is that Autopsy and The Sleuth Kit will be burned to a CD and inserted into a suspect computer. An investigator will connect to Autopsy on the suspect UNIX computer with her HTML browser on a trusted laptop and remotely examine the hard disk contents. If the computer is found to have been compromised, then it can be taken offline and acquired using normal procedures.

Recall from issue #10 that I used two guidelines for incident verification:

Minimize the amount of trust that you place in the system so that more accurate information is collected.
Minimize the amount of data that you change on the system so that evidence is preserved.

Creating The CD

To satisfy guideline #1 from above, we want to minimize the amount of trust that we place in the system, so we use our own executables. At a minimum, we need The Sleuth Kit and Autopsy on the CD and you will probably have additional tools to examine open network ports and running processes. This has been the most difficult part of using Autopsy for live analysis because Autopsy relies on a given directory structure and locations that it can write to.

It is now very easy with v2. With v2, you compile TSK and Autopsy on a similar system to the one that will be investigated just like you do for a dead analysis. Try the 'make static' with TSK to see if you can make static executables for your platform. After both Autopsy and TSK have been compiled, you execute the 'make-live-cd' command in Autopsy. This script will make a 'live-cd' sub-directory in the autopsy directory, which contains a copy of autopsy and copies of TSK executables, grep, strings, perl etc:

# ./make-live-cd 
Making base directory (./live-cd/) 
Copying executables 
Copying autopsy files 
Creating configuration file using existing settings

The 'live-cd' directory has a 'bin' directory where additional executables can be copied to and then the whole directory can be burned to a CD.

Basic Usage

After the CD has been created and there is a system suspected of being compromised, then it is time to take advantage of the new features. There are two scenarios for live analysis. The first scenario uses a network share from a trusted system that you can write to. In this case, autopsy is run as normal and you specify the evidence locker directory as the mounted disk. The evidence locker is specified with '-d':

# ./autopsy -d /mnt/ev_lock 10.1.32.123

The above would start autopsy, use '/mnt/ev_lock/' as the evidence locker and would allow connections from 10.1.32.123 (where the investigator would connect from using an HTML browser). Remember that we do not want to write to the suspect system, so we should only use a network share and not a local directory in this scenario.

The second scenario does not use an evidence locker and does not intentionally write any data to disk. This scenario does not need the network share and each of the devices (or partitions) that will be analyzed are specified on the command line using the '-i' flags. The '-i' flag requires three arguments: the device, the file system type, and the mounting point. For example, to examine the '/dev/hda5' and '/dev/hda8' partitions on a Linux system, the following could be used:

# ./autopsy -i /dev/hda5 linux-ext3 / -i /dev/hda8 linux-ext3 /usr/ 10.1.32.123

The file system type must be one of the types that are supported by TSK. The remote IP address must also be given, otherwise you will have to use a browser on the suspect system and that will write data to the disk.

When you use the '-i' flag, then autopsy will start in the 'Host Manager' view where you can select the image that you want to analyze. You will skip the case and host configuration. The default case name will be 'live', the default host name is 'local', and the default investigator name is 'unknown'.

Differences With Dead Analysis

There are some features that are not available for live analysis because they write files to the disk. In this section, I am using the term live analysis for the scenario where there is not a mounted network share and there is not evidence locker.

No auditing is performed during a live analysis because there is no where to write the logs. In the future, if this is needed, then a method of writing logs to a floppy disk could be configured. Timelines of file activity cannot be created because they need to create files. Hash databases are also not currently used, although they could in the future. It may be difficult to maintain the latest hash database on the same CD as the latest autopsy and TSK version though. Notes and event sequencer notes cannot be created.

Keyword searches can be performed, but the strings file and unallocated only search cannot be performed because they both require a file to be created. The search results are also not cached. You can also not sort files by their type (all executables, all pictures etc.). In many cases, you would not want to do many of these operations because they are time intensive and you are generally looking for obvious and quick evidence during the incident verification. If you need theses features, then you can use the network share scenario.

Similarities With Dead Analysis

Now that we know what is different, I'll cover what is the same. All of the file mode analysis is the same, except that you cannot get the file type. The method that is used to compile 'file' in TSK does not allow autopsy to easily move it around. This behavior may change in the future. Meta data, data unit, and file system mode all work as usual.

You can still export file contents to your trusted laptop because it uses the HTTP to save the file. So, you can select the export button on a log file to save a copy. You can also generate ASCII reports and save them to your local analysis station.

Guideline Compliance

All of these features may sound great, but lets examine how well the new Autopsy satisfies the two guidelines. I think it is always important to compare a new tool or technique against generic guidelines.

The first guideline was about not trusting the local system. No software-based live analysis tool can be 100% independent from the local system because it always needs to request service from the operating system. With Autopsy, we use our own copies of the Autopsy perl code, TSK executables, grep, and strings.

There is one large problem with the current Autopsy model and it is because of Perl. Perl is a beast and contains many modules and libraries. When the 'make-live-cd' script is run, a copy of the 'perl' executable is copied to the 'live-cd' directory, but that is it. The executable will still need the modules and libraries on the local system. Solving this may require building a special version of Perl that is more static. I need to investigate this more.

Another method of getting around this limitation is to use the 'perl2exe' program that converts a Perl script to a dynamic executable. The resulting executable will still rely on dynamic libraries on the suspect system, but it seems a little cleaner. The perl2exe program is a commercial tool.

One of the benefits of the Autopsy design, is that Autopsy did not exist on the system when it was suspected of being compromised. Therefore, the attacker will not know that Autopsy will be used to investigate the system and therefore will be less likely to tamper with its dependencies. If the investigation tools are running on the system during the attack, then I would guess that the attacker will be more likely to tamper with them.

The second guideline was about modifying data on the system. I described the features that were removed in the previous section. This was easy to do because there were functions that write the logs or notes. Each of those starts with a check to see if logging is enabled. Timelines and file type sorting were also disabled because it required writing to disk.

I can never guarantee that no data will be written from a live analysis. Memory will be overwritten when the software is loaded and the access times on dynamic libraries will updated. Running the tools may require the operating system to write memory to the page file, which may overwrite data from the attacker.

This is a shameless plug, but for those that are interested in live analysis, then you may want to check out a paper that a colleague, Joe Grand (author of pdd), and I wrote about a hardware device to acquire memory from a live system. It does not overwrite memory because there is no process to load and it access the physical memory directly so it does not rely on the local operating system. It was recently published in the new Journal of Digital Investigation (reference is below and that issue of the journal is currently free to view).

Future Work

There is always more to do, and I'll cover that here.

I would like to also include other system utilities, such as 'ps' or 'netstat' on the CD and allow the Autopsy user to run the commands from within autopsy. This should be fairly easy, but the difficult part is that many of the operating systems use different flags for different tools.

I would like to start incorporating scripts into the tool (for both dead and live analysis). This will allow you to more easily detect rootkits or other signatures.

The biggest thing that needs future work is using Perl. Autopsy still relies on the version of Perl on the suspect system and that could run into problems if an attacker modifies it. Using the perl2exe tool can reduce the risk, but it is a commercial tool.

Conclusion

The live analysis mode of Autopsy allows you to more easily analyze a system that is suspected of being compromised. It can also be used to examine a honeypot. Live analysis is not ideal because you are stilly relying on the suspect operating system for data, but it is required in some situations. More work needs to be done with Autopsy so that it depends less on the local system.