Tuesday, July 6, 2010

My Precious

SANS Digital Forensics has come up with another great idea which is the introduction of the SANS Institute Digital Forensics Lethal Forensicator Coin.  Rob explains the conditions under which the coin will be awarded over at the SANS Forensic Blog. For reasons I can’t completely explain or fully understand, I have an insatiable desire for one of these coins.  Gollum. Gollum.

The community has plenty of certifications and there is a continuing debate about the issues of licensing and certification. That’s another post or two for another day, but what we haven’t had has been these sort of awards where members of our community can be recognized for their achievements.  That’s one of the reasons why I’ve been supporting the efforts of Lee Whitfield in regards to the Forensic 4cast awards.  It’s nice to have an avenue where our best and brightest can be recognized by their peers and Lee has done the community an invaluable service with these awards.

$FILE_NAME Discussion

Harlan has a great contribution to the discussion we’ve been having here on the blog about the purpose of GUI tools and what examiners use them for in their examinations.  I think I’ve pretty much beaten the $FILE_NAME aspect into the ground, but Harlan’s post and A Thulin’s comment on my previous post made me take a step back and ask myself what do I use my primary GUI forensic tools for and what do I expect out of them?

Some rough definitions are probably in order at this point.  When I talk about primary GUI forensic tools, I’m talking about tools that are designed and marketed as a primary tool for an examination. These tools are designed to parse common file systems and in many cases are loaded up with other features such as capabilities dealing with browser forensics, email forensics, file carving and the like.  Tools in this category would be tools like EnCase, FTK, X-Ways Forensics, etc.

The tools that I think of as secondary GUI tools would be tools like Net Analysis or Cache Back which are designed to present information in a GUI format and allow an examiner to navigate around a particular bit of data. These sort of tools are designed for a limited purpose such as parsing a particular artifact like web browser logs.  Unlike the primary GUI tools, they aren’t designed to be a general forensic tool.

The tools that I think of as secondary tools would be non-GUI programs like Harlan’s Reg Ripper which aren’t designed to allow an examiner to navigate around a particular artifact (like what, for example, Registry Viewer does), but are intended to do things like parse a particular bit of data with the goal of providing the examiner a report of it’s findings.

What do I use my primary GUI forensic tools for? Not nearly as much as I used to use them for when I first started.   The tool that I tend to use the most is still EnCase and as I thought about Harlan’s post I asked myself why I still use it the most even though FTK 3 is arguably a better product.

I think I prefer EnCase still because it feels like a sort of glorified read-only hex “editor” (I put editor in quotes since it’s obviously not designed to edit anything) that is easy for me to use when I need to work at the hex level on a disk. It’s what I’ve “grown up” using so it’s something that I’m very comfortable with for what I do with primary GUI tools.    The rub is that I find myself using FTK 3 more and more these days since it scales much better when it comes to larger data sets and handles a lot non-file system artifacts like compressed files much better than EnCase.  If someone was just starting out and could only buy one, I’d tell them to get FTK 3.  I’d hate to have just one, but I suppose I’d make the same decision if I were forced to make the choice.
I just don’t tend to use all of the additional features that are loaded into programs like EnCase and FTK. Browser forensics are a good example. I don’t use FTK or EnCase to parse web history artifacts like index.dat files because there are much better programs out there such as Net Analysis.  I think that’s one of the reasons why I continue to use EnCase.  For the most part, it does what I need it to do when it comes to file system parsing and I have loads of secondary forensic (GUI and otherwise) tools that I can use by just right clicking on a file in EnCase and sending to a tool like Net Analysis.  I’m also using the SIFT Workstation a lot these days because it’s packed with all sorts of tools that greatly enhance my ability to do an examination by doing things like memory forensics and Super Timeline analysis.

I do tend to use FTK 3 for email forensic work and I think that is one of the reasons why FTK 3 is a good value.  You get the general file system forensics along with some decent secondary tools like Registry Viewer and PRTK.  You also get a nice email forensic tool built into FTK 3.  I’ve just never been that enamored with EnCase as an email forensic program largely because I don’t think the GUI works as well for email forensics compared to FTK and because I hate having to reload the email each time I reopen a case in EnCase.  EnCase just scales poorly when it comes to email, but I know Guidance is working hard to catch up based on what I learned from them at CEIC.

So the bottom line is that as I have gained more experience, I’ve relied less on my primary GUI tools and more on a whole host of other specialized tools along with the manual parsing of artifacts.  Since EnCase does a good job parsing file system data and can easily be used as a springboard for the use of other tools, I keep using it especially since it just feels very natural for me when it comes to hex level forensic work.


  1. While preparing for and giving a recent seminar on forensic analysis to locate bots, it occurred to me that I use a number of small tools, all of them each with their own specific purpose. While it is possible to pull a lot of them into a framework similar to log2timeline, I would still want to have them separate, as their functionality is simply too valuable. For example, evtrpt.pl allows me to see a report of the frequency of event sources and IDs, and provides me with a date range of all of the events in the .evt file. Evtparse.pl allows me to parse the .evt file on a binary level, bypassing the API (don't have to deal with "corrupt" messages), as well as output a list of event record numbers and their associated times (to detect modification of the system time). There have been a number of times where creating a micro- or nano-timeline has been a very valuable analysis technique, and allowed me to directly answer customer questions.

  2. I must say that I still Use EnCase (6+) as my Primary Tool or Platform to start my Investigation. From there I will direct Email, Registry Files,Inet History or other misc data to an appropriate Viewer (aka Netanlysis, AD Registry viewer, VLC media player etc.). I am still not pleased with the Stability and Overhead that FTK 3+ uses/requires.
    When needed (email investigation) for example, I will break out FTK 1.81 and work it with that... Simple and Stable.

    Will FTK do everything I need..Probably.. but old habit's die hard.. (And EnCase Scripting still Rocks!)

  3. We had been using FTK heavily, but relegated it to using it for email only. However, the fact that FTK version 1 & 2 cannot export emails in native format is a severely limiting factor. We recently picked up a copy of Intella at CEIC and are trying to get used to it. Certainly, it has a lot more features and capabilities than FTK. The graphical display is a nice touch, but takes some getting used to. The most limiting feature of Intella, however, its case manager which makes it very cumbersome to move cases around once you process them and create the index on one examination PC. If they fix some of it's quirks, Intella could become a stellar program for email examinations.