Pimp my...forensics analysis
How often do you find yourself in the position where, when performing forensic analysis, you end up either not having the tools you need (ie, the tools you do have don't show you what you need, or don't provide you with useful output)? Many of the tools we use provide basic functionality, but there are very few tools that go beyond that, and are capable of providing what we need over a large number of cases (or in some instances, even examination to examination). This leads to one of the major challenges (IMHO) of the forensic community...having the right tool for the job. Oddly enough, there just isn't a great market for tools that do very specific things like parse binary files, extract data from the Registry, etc. The lack of such tools is very likely due to the volume of work (i.e., case load) that needs to be done, and to a lack of training...commercial GUI tools with buttons to push seem to be preferred over open-source command line tools, but only if the need is actually recognized. Do we always tell someone when we need something specific, or do we just put our heads down, push through on the investigation using the tools and skill sets that we have at hand, and never address the issue because of our work load?
With your forensic-analysis-tool-of-choice (FTK, EnCase, ProDiscover, etc.), many times you may still be left with the thought, "...that data isn't in a format I can easily understand or use...". Know what I mean? Ever been there? I'm sure you have...extract that Event Log file from an image and load it up into Event Viewer on your analysis system, only to be confronted with an error message telling you that the Event Log is "corrupted". What do you do? Boot the image with LiveView (version 0.6 is available, by the way) and log into it to view the Event Log? Got the password?
The answer to this dilemma is to take a page from Xzibit's book and "pimp my forensics analysis". That's right, we're going to customize or "trick it out" our systems with the tools and stuff you need to do the job.
One way to get started on this is to take a look at my book [WARNING: Shameless self-promotion approaching...], Windows Forensic Analysis; specifically at some of the tools that ship on the accompanying DVD. All of the tools were written in Perl, but all but a few have been "compiled" into standalone EXEs so that you don't have to have Perl installed to run them, or know anything about Perl -- in fact, based on the emails I have received since the book was released in May 2007, the real limiting factor appears to be nothing more than a lack of familiarity with running command line (CLI) tools (re: over-dependence on pushing buttons). The tools were developed out of my own needs, and my hope is that as folks read the book, they too will recognize the value in parsing the Event Log files, Registry, etc., as well as the value of the tools provided.
Another resource is the upcoming Perl Scripting for Forensic Investigation and Security, to be published in the near future by Syngress/Elsevier.
What do these two resources provide? In a nutshell, customized and customizable tools. While a number of tools exist that will let you view the Registry in the familiar (via RegEdit) tree-style format, how many of those tools will translate arbitrary binary data stored in the Registry values? How many will do correlation, not only between multiple keys within a hive, but across hives, as well?
How many of the tools will allow you to parse the contents of a Windows 2000, XP, or 2003 Event Log file into an Excel spreadsheet, in a format that is easily sorted and searched? Or report on various event record statistics?
How many of these tools provide the basis for growth and customization, in order to meet the needs of a future investigation? Some tools do...they provide base functionality, and allow the user to extend that functionality through scripting languages. Some are easier to learn than others, and some are more functional that others. But even these can be limiting sometimes.
The data is there, folks...what slows us down sometimes is either (a) not knowing that the data is there (and that a resource is a source of valuable data or evidence), and (b) not knowing how to get at that data and present it in a usable and understandable manner. Overcoming this is as simple as identifying what you need, and then reaching out to the Xzibits and Les Stroud's of the forensic community to get the job done. Rest assured, you're not the only one looking for that functionality...
With your forensic-analysis-tool-of-choice (FTK, EnCase, ProDiscover, etc.), many times you may still be left with the thought, "...that data isn't in a format I can easily understand or use...". Know what I mean? Ever been there? I'm sure you have...extract that Event Log file from an image and load it up into Event Viewer on your analysis system, only to be confronted with an error message telling you that the Event Log is "corrupted". What do you do? Boot the image with LiveView (version 0.6 is available, by the way) and log into it to view the Event Log? Got the password?
The answer to this dilemma is to take a page from Xzibit's book and "pimp my forensics analysis". That's right, we're going to customize or "trick it out" our systems with the tools and stuff you need to do the job.
One way to get started on this is to take a look at my book [WARNING: Shameless self-promotion approaching...], Windows Forensic Analysis; specifically at some of the tools that ship on the accompanying DVD. All of the tools were written in Perl, but all but a few have been "compiled" into standalone EXEs so that you don't have to have Perl installed to run them, or know anything about Perl -- in fact, based on the emails I have received since the book was released in May 2007, the real limiting factor appears to be nothing more than a lack of familiarity with running command line (CLI) tools (re: over-dependence on pushing buttons). The tools were developed out of my own needs, and my hope is that as folks read the book, they too will recognize the value in parsing the Event Log files, Registry, etc., as well as the value of the tools provided.
Another resource is the upcoming Perl Scripting for Forensic Investigation and Security, to be published in the near future by Syngress/Elsevier.
What do these two resources provide? In a nutshell, customized and customizable tools. While a number of tools exist that will let you view the Registry in the familiar (via RegEdit) tree-style format, how many of those tools will translate arbitrary binary data stored in the Registry values? How many will do correlation, not only between multiple keys within a hive, but across hives, as well?
How many of the tools will allow you to parse the contents of a Windows 2000, XP, or 2003 Event Log file into an Excel spreadsheet, in a format that is easily sorted and searched? Or report on various event record statistics?
How many of these tools provide the basis for growth and customization, in order to meet the needs of a future investigation? Some tools do...they provide base functionality, and allow the user to extend that functionality through scripting languages. Some are easier to learn than others, and some are more functional that others. But even these can be limiting sometimes.
The data is there, folks...what slows us down sometimes is either (a) not knowing that the data is there (and that a resource is a source of valuable data or evidence), and (b) not knowing how to get at that data and present it in a usable and understandable manner. Overcoming this is as simple as identifying what you need, and then reaching out to the Xzibits and Les Stroud's of the forensic community to get the job done. Rest assured, you're not the only one looking for that functionality...