Revisiting "Forensic Value"

I posted some thoughts a while back on defining "forensic value"...in that post, I pondered the question of who defines the "forensic value" of an artifact or finding.  The post had received 15 comments relatively quickly, and it seems that there's something of a consensus that the forensic value of data is in the eyes of analyst.  One would suppose that this means, then, that the forensic value of a particular artifact can be determined by viewing that artifact through the lens of the analyst's knowledge and experience.  In my previous post, I used terms like relative and subjective value, and I think that these descriptive terms come not only from the goals of the examination, but also depend heavily on the knowledge and experience of the analyst.

I recently had the opportunity to review a paper written by someone who had done some pretty comprehensive testing and documented some interesting artifacts.  In that paper, the author mentioned certain artifacts that were available, but that these artifacts were not pertinent to the analysis being performed...the artifacts were provided for informational purposes, and might be of value to other analyses.  For the paper and the analysis being performed, I thought that this was a valid distinction to make, as it addressed the issue of why those artifacts were not discussed (how the got there, their format, etc.) further in the paper. In short, the author had made a clear distinction as to the relative value of certain artifacts.

The relative value of an artifact often has a lot to do with the context of that artifact.  Consider an email address found within an image, perhaps using something like bulk_extractor or a keyword search.  The email address may already have an intrinsic value to you, possibly as a piece of intelligence.  From that point, any additional value of that artifact can rely heavily on the context in which that artifact resides.  Was that artifact found in a file?  In a PST file?  If the email address was found in a PST file, in an email, what is the context?  The value of the email address vary greatly depending upon not only the goals of your examination, but also whether the address was found in the To:, From:, or CC: block of the email, or if it is located in the body of the email.  Depending upon the goals of your examination, the fact that the email address was found in the body of an email may be more important and have more relative value than if it were found in the To: block.

The absence of an artifact can also be of significant value, but again, that will depend heavily upon (a) the goals of the examination, and (b) the skills of the examiner.  For example, I was performing some Registry analysis a while back to determine which files a user account had been used to access on that system (goals).  I noticed immediately that RegRipper reported that the "RecentDocs key was not found."  This was a very significant finding, and not something I had expected...and my experience told me that it was something worth exploring, particularly given the goals of my exam.  I quickly determined that a "scrubbing" tool had been applied to the system, and determined when that tool had been installed and run, and by which user.  I was also able to recover a significant bit of deleted data from within the hive file itself.

Now for the big question...so what?  How does this apply to...well...anything?  Well, consider my recent post on Timeline Analysis...for those analysts who want to "see everything", how much of that "everything" is actually relevant and of forensic value?

In order to address that, I think that we need to look at a couple of things...and I'd start with, what are the goals of your exam?

I've heard some folks say that during analysis, it's important to understand an attacker's methods, as well as their intentions.  I'm not so sure that's something I'd hang my hat on...mostly because the attacker isn't sitting next to me so that I can ask them questions and understand their intentions.  When performing analysis, all we see is the results of their actions...maybe only some of those results...and we often look at those results and artifacts through the lens of our own experiences in order to attempt to determine the intentions of others.  Further, when it comes to understanding the methods an attacker uses, that's an understanding that's most often developed by observing various artifacts from within the system...but if we're not familiar with the system that we're analyzing, and we're using some automated tool to pull out all of the "relevant" artifacts for us, are we observing all of the artifacts, or at least the right ones to give us a view into what the attacker is trying to do?

Consider this...given an image acquired from a system...let's say, for the sake of discussion, a Windows 7 system...how do we know that when we run a particular tool (or set of tools) against that image that we're extracting all of the relevant data that we require in order to make informed opinions regarding our findings?  When an analyst says, "I want a timeline, and I want it with everything!", how does that analyst then know that they've got everything in that timeline?

The forensic value of any particular artifact is determined by the goals of the exam, and the relevance of that artifact, taken in context with other artifacts.  The terms "relevance" and "context" will often be subjective, based on the knowledge and skill level of the examiner.

Does this mean that every analyst needs to be an expert in Windows?  No, that's not entirely practical.  What it does mean is there needs to be should be multiple levels of access to knowledge, including training, mentors and trusted advisers available to your analysts, and that these should all be part of or accessible to your analysis team.

Defining "Forensic Value"

Who defines "forensic value" when it comes to data?  How does a string of 1s and 0s become "valuable", "evidence" or "intelligence"?

These are questions I've been asking myself lately.  I've recently seen purveyors of forensic analysis applications indicate that a particular capability has recently been added (or is in the process of being added) to their application/framework, without an understanding of the value of the data that is being presented, or how it would be useful to a practitioner. Sure, it's great that you've added that functionality, or that you will be doing so at some point in the very near future, but what is the value of the data that the capability provides, and how can it be used?  Do your users recognize the value of the data that you're providing?  If not, do you have a way of educating your users?

I was also thinking about these questions during my presentation at OSDFC...I was talking about extending RegRipper into more of a forensic scanner, and found myself looking out across a sea of blank stares.  In fact, at one point I asked the audience if what I was referring to made sense, and the only person to react was Cory.  ;-)  As a practitioner, I believe that there is significant value in preserving and sharing the collective knowledge and experience of a group of practitioners.  I believe that being able to quickly determine the existence (or absence) of a number of artifacts and removing that "low hanging fruit" (i.e., things we've seen before) is and will be extremely valuable.  Based on the reaction of the attendees, it appears that Cory and I may be the only ones who see the value of something like this.  Does something like this have value?

Also, at the conference, there were a number of academics and researchers in attendance (and speaking), along with a number of practitioners.  Speaking to some of the practitioners between sessions and after the conference, there was a common desire to have more practical information available, and possibly even separate tracks for practitioners and developers/academics.  There seemed to be a common feeling that while developing applications to parse data and run on multiple cores was definitely a good thing, this only solved a limited number issues and did not address issues that were on the plates of most practitioners right now.  It would be safe to say that many of the practitioners (those that I spoke with) didn't see the value in some of the presentations.

One example of this is bulk_extractor (previous version described here), which Simson L. Garfinkel discussed during the conference.  This is a tool (Windows EXE/DLLs available) that can be run against an image file, and it will extract a number of items by default, including credit card numbers and CCN track 2 data, and includes the offset to where within the image file the data was found.  Something like this may seem valuable to those performing PCI forensic exams, but one of the items required for such exams is the name of the file in which the credit card number/track data were located.  As such, where a tool like bulk_extractor might have the most value during a PCI forensic exam is if it were run against the pagefile and unallocated space extracted from the image.  Even so, using three checks (LUN formula, length, and BIN) only gives you the possibility that you've found a CCN...we found that there are a lot of MS DLLs with embedded GUIDs that appear to be Visa CCNs, including passing the three checks.  In this case, there is some value in what Simson discussed, although perhaps not at its face value.

As a side note, another thing you might want to do before running the tool is to contact Simson and determine which CCNs the tool searches for, to ensure that all of the CCNs covered by PCI are addressed.  When I was doing this work, we had an issue with a commercial tool that wasn't covering all the bases, so to speak...so we rolled our own solution.

Recently, I began looking at Windows 7 Jump Lists, and quickly found some very good information about the structure of both the automatic and custom "destinations" files.  One thing I could not find, however, was information regarding the structure of the DestList stream located in the automatic destinations file; to me, this seemed to be of particular value, as the numbered streams followed the MS-SHLLNK file format and contained MAC time stamps for the target file, but not for led to the creation of the stream in the first place.  Looking at the contents of the DestList stream in a hex editor, and noticing a number of familiar data structures (FILETIME, etc.), it occurred to me that the DestList stream might act like a most recently used (MRU) or most frequently used (MFU) list.  More research is needed, but at this point, I think I may have figured out some of the basic elements of DestList structure; so far, my parsing code is consistent across multiple DestList streams, including from multiple systems.  As a practitioner, I can see the value in parsing jump list numbered streams, and I believe that there may be more value in the contents of the DestList stream, which is why I pursued examining this structure.  But again...who determines the value of something like this?  The question is, then...is there any value to this information, or is it just an academic exercise?  Simply because I look at some data and as a practitioner believe that it is valuable, is this then a universal assignment, or is that solely my own provenance?

Who decides the forensic value of data?  Clearly, during an examination the analyst would determine the relative value of data, perhaps based on the goals of the analysis.  But when not involved in an examination, who decides the potential or relative value of data?