Evading Investigators and Analysts

I recently had an opportunity to spend two days with some great folks in the Pacific Northwest, talking about timeline creation and analysis.  During this time, we talked about a couple of ancillary topics, such as critical thinking, questioning assumptions, looking at what might be unusual on a system, and we even touched briefly on anti-forensics.  If you've read my blog for any considerable length of time, you know that my thoughts on anti-forensics are that most tactics are meant to target the analyst, or the analyst's training.

Along the lines of anti-forensics, a good deal of reading can be found online.  For example, in 2005, the Grugq gave a presentation at BlackHat that addresses anti-forensics.  James Foster and Vincent Lui gave a presentation on a similar subject.  Also, I recently ran across a very interesting article regarding evading the forensic investigator.  One of the most important statements in the article is:

"Here it is important to note that the software makes it possible to store..."

Why is this statement important?  Well, if you consider the statement critically for a moment, you'll see that it points out that this technique for hiding data from an analyst requires additional software to be added to the system.  That's right...this isn't something that can be done using just tools native to the system...something must be added to the system for this technique to be used.  What this means is that while the analyst may not necessarily be able to immediately determine that data may have been hidden using these techniques, they would likely be able to determine the existence of this additional software.  After all, what would be the purpose of hiding data with no way for the person hiding it to access it?  If you wanted to deny the owner access to the data, why not simply wipe it to a level at which it is prohibitively expensive to retrieve?

What are some ways that an analyst might go about finding the additional software?  Well, because many times I deal solely with acquired images, I use a malware detection checklist for those times where my analysis calls for it, and one of the things I check is the MUICache keys for the users, which can provide me with an indication of software that may have been executed, but perhaps not via the shell.  This is just one item on the checklist, however...there are others, and because the checklist is a living document (I can add to it, and note when some things work better than others), there may be additional items added in the future.

Another way to address this is through incident preparation.  For example, if the audit capability for the Windows system includes Process Tracking (and the Event Logs are of sufficient size), then you may find an indication of the software being executing there (using evtrpt.pl against Windows XP and 2003 .evt files works like a champ!).  Another possible proactive approach is to use something like Carbon Black from Kyrus Technology; installing something like this before an incident occurs will provide you with (as well as your responders) with considerable, definitive data.  To see how effective a proactive approach involving Carbon Black can be, take a look at this video.

Beyond this, however, its critical that analysts have the training and knowledge to do their jobs in a quick, efficient, and accurate manner, even in the face of dedicated attempts to obfuscate or hinder that analysis.  One of the things we talked a great deal about in the class is the use of multiple data sources to add context to the data, as well as increase the relative level of confidence in that data.  Chris Pogue talks about this a bit in one of his recent blog posts.  Rather than looking at a single data point and wondering (or as is done in many cases, speculating) "...what could have caused this?", it's better to surround that data point with additional data from other sources in order to not only see the context in which the event took place, but we also have to keep in mind that some data is more mutable (easily changed) than others.

When I teach a class like this, I learn a lot, not just in putting the course materials together, but also from engaging with the attendees.  At one point, I was asked on about how many cases do I create a timeline...my response was, "all of them", and that's fairly accurate.  Now, timeline analysis may not be my primary analysis technique...sometimes, I may have something available (an Event Log record, a file name, etc.) to get me started and the goals of my analysis simply dictate that a timeline be created.  Looking back over my recent examinations, I've created a timeline in just about every instance...either to have a starting point for my analysis, or to provide context or validation to my findings, or even to look for secondary or tertiary artifacts to support my findings.  However, the important thing to keep in mind here is that I'm not letting the technique or tool drive my analysis...quite the opposite, in fact.  I'm using the technique for a specific purpose and because it makes sense.

Another analyst told me not long ago, "...I've been doing timelines for years."  I'm sure that this is the case, as the concepts behind timeline analysis have been around for some time and used in other areas of analysis, as well.  However, I'm willing to bet that most of the analysts that have created timelines have done so by manually entering events that they discover into a spreadsheet, and that the events that they've added are based on limited knowledge of the available data sources.  Also, it has been clear for some time that the value of timelines as an analysis tool isn't completely recognized or understood, in part by looking at questions asked in online forums; many of these questions could be answered by creating a timeline.  So, while many are talking about timeline analysis, I think that its imperative that more of us do it.

Another thing I have learned through engaging with other analysts over the years is that a lot of this stuff that some of us talk about (timeline or Registry analysis) is great, but in some cases, someone will go to training and then not use what they learned for 6 - 9 (or even more) months.  By then, what they learned has become a fog.  These techniques are clearly perishable skill sets that need to be exercised and developed, or they will just fade away.

An example of this that I've seen a great deal of recently in online forums has to do with tracking USB devices on Windows systems.  In the spring of 2005, Cory Altheide and I published some research that we'd conducted regarding USB device artifacts on Windows systems.  Since then, more has been written about this subject, and Rob Lee has posted (and provided worksheets) to the SANS Forensics blog, not only covering thumb drives, but also drive enclosures.  USB artifacts have been discussed in books such as Windows Forensic Analysis (1/e, 2/e), and Windows Registry Forensics, and I'm including yet another discussion in the upcoming third edition of WFA.  I think that this is important, because with all of the information available (including this page on the Forensics Wiki), there continues to be a misunderstanding of the artifacts and analysis process regarding these devices.  For example, variations on the same question have appeared in multiple forums recently, specifically asking why all (in one case, 20 or more) device keys listed beneath the USBStor subkey have the same LastWrite time, and how could the user have plugged all of the devices into the system at the same time.  The problem with this line of analysis is that the LastWrite times for the subkeys beneath the USBStor key are NOT used to determine when the devices were last connected to the system!  What I normally suggest is that analysts engage with the various resources available, and if they want to know what could be responsible for the keys all having the same LastWrite times, generate a timeline.  Seriously.  Timelines aren't just for analysis anymore...they're a great testing tool, as well.

As a side note, RegRipper has all of the necessary plugins to make  USB device analysis pretty straightforward and simple.  I've been working on a chapter on Registry Analysis for my upcoming Windows Forensic Analysis 3/e, and I haven't had to produce any new plugins.  So, even if you're using Rob's SANS checklists, you can get the data itself using RegRipper.

Resources
IronGeek: Malicious USB Devices

Matthieu recently released DumpIt, which is a fusion of the 32- and 64-bit Windows memory dumping utilities that will create a memory dump in the current working directory (which makes this a great utility to run from a thumb or wallet drive).