SANS Digital Forensics and Incident Response Blog: Category - Evidence Analysis

Making Reviewing Files From Data Carving Easier: Images


I usually do a lot of data carving. With 500 gig drives becoming the norm in machines, the recovered files I see from data carving is huge. Nothing like having to review 10000+ jpegs and having to review each one. I had a lot of issues trying to find something to review that many images. After trying many programs and some hacks to break up the images into smaller subsets. I decided to write my own set of tools for processing the files recovered from data carving.

Data Carver Processors

The Data Carver Processors are a combination of Perl scripts and other programs that are designed to break up the recovered files into manageable chunks. As the script runs over the files, it will create a series of web pages with thumbnails and a second web page for each file that contains plug-in output like metadata, hashes, and etc. The scripts, for the most part, will not process damaged files. If a file is damaged, there will be no image for it on

... Continue reading Making Reviewing Files From Data Carving Easier: Images

FAT File Sizes

If you're just checking this blog for the first time, you should know that this post is one in a series of posts dealing with a FAT file system that has been tweaked in various ways to make recovery of the data more difficult, if only for the casual observer. Forensics folks like yourselves would have no issue recovering the data, but the point of this series is to learn about the FAT file system and how it works.

In last week's FAT Tuesday post we looked at a file in our usb key image (get it here) called "Scheduled Visits.exe". We looked at the metadata for the file using

Artifact Timeline Creation and Analysis - part 2

In the last post I talked about the tool log2timeline, and mentioned a hypothetical case that we are working on. Let's explore in further detail how we can use the tool to assist us in our analysis.

How do we go about collecting all the data that we need for the case? In this case we know that the we were called to investigate the case only hours after the alleged policy violation, so timeline can be a very valuable source. Therefore we decide to construct a timeline, using artifacts found in the system to start our investigation, so that we can examine the evidence with respect to time. By doing that we both get a better picture of the events that occured as well as to possibly lead us to other artifacts that we need to examine closer using other tools and techniques.

To begin with you start by imaging the drive. You take an image of the C drive (first partition) and start working


Artifact Timeline Creation and Analysis - Tool Release: log2timeline

Using timeline analysis during investigations can be extremely useful yet it sometimes misses important events that are stored inside files on the suspect system (log files, OS artifacts). By solely depending on traditional filesystem timeline you may miss some context that is necessary to get a complete picture of what really happened. So to get "the big picture", or a complete and accurate description we need to dig deeper and incorporate information found inside artifacts or log files into our timeline analysis. These artifacts or log files could reside on the suspect system itself or in another device, such as a firewall or a proxy (or any other device that logs down information that might be relevant to the investigation).

Unfortunately there are few tools out there that can parse and produce body files from the various artifacts found on different operating systems to include with the traditional filesystem analysis. A version of mactime first appeared in The

... Continue reading Artifact Timeline Creation and Analysis - Tool Release: log2timeline

Sizing up the FAT

Another Tuesday, another FAT post. If you're just joining us, you can find the whole series of posts here.

Over the last month or two, we've been working with a FAT image that has been modified by the suspect in a case we're working. We have slowly been undoing the changes made by the suspect, one file at a time. We have one file left to make right so let's see what's going on with our third and final file. Recall the output from fls from previous posts:
fls ouput from usbkey.img
We've already recovered the first two files and adjusted the cluster chains in