WFA 3/e

I've mentioned a couple of times, in this blog as well as in a couple of lists, that I'm working on completing Windows Forensic Analysis 3/e, and I thought it would be a good time to give a little bit of information regarding the book. 

First off, while the title includes "third edition", this edition is not one where if you purchased the second edition, you're out of luck.  Rather, the third edition is a companion book to the second edition, so you'll want to have both of them on your shelf (or Kindle).  Where a great deal of 2/e was focused on Windows XP, in 3/e I'm focusing primarily on Windows 7.

The third edition has 8 chapters, as follows:

1. Analysis Concepts - Seeing comments from those who've read DFwOST thus far, and seeing the mileage that Chris Pogue is getting from his Sniper Forensics presentations, it appears that there are a lot of analysts out there who like to hear about the concepts that drive analysis.  It's one thing to say to do timeline analysis and talk about how, but I think that it's something else entirely to discuss why we do timeline analysis, as that's the difference between an analyst who creates a timeline, and one who has a reason, justification and analysis goal for creating a timeline.

2.  Live Response - With this chapter, I wanted to take something of a different approach; rather than writing yet another chapter that gives consultants hints on doing IR, I wanted to provide some thoughts as to how organizations can better prepare for those inevitable DFIR activities.  If 2011 thus far hasn't been enough of an example, maybe it's worth saying again...it's not a matter of if your organization will face a compromise, but when.  I would take that a step further and suggest that if you don't have visibility into your systems and infrastructure, you may have already been compromised.  As a consultant, the biggest issue I've seen during IR is the level of preparedness...there's a huge difference between companies that accept that incidents will occur and take steps to prepare, and those who have "not me" culture/attitude; the latter usually ends up paying out much more, in terms of fees, fines, and court costs.  This is something consultants talk about with their customers, but it's a whole new world when you actually see it in action.

3.  Volume Shadow Copies - This chapter is somewhat self-explanatory.  I was doing some research that involved accessing VSCs, and found pretty much the only way to do what I wanted to do required significant resources (ie, $$).  What I did with this chapter is show how VSCs can be accessed within an acquired image without using expensive solutions, as well as provide some insight into how accessing the VSCs can really provide some very valuable information to an analyst.

4.  File Analysis - This chapter is very similar to the corresponding chapter in WFA 2/e, but focuses on some of the files you're likely to see on Windows 7 systems.  I also reference some of the files that you'll find on Windows XP systems, but are different on Windows 7 systems (ie, format, content).  I cover Jump Lists in this chapter, and not just the LNK-like streams, but also the DestList streams (which appear to be some sort of MRU listing for shortcuts).

5.  Registry Analysis - I know, a lot's been said about Registry analysis, particularly in WRF, but this time, instead of doing a break down of what can be found in the Registry, on a hive-by-hive basis, I'm taking more of a solutions-based approach. For example, I see a LOT of folks in the forums and lists who don't understand the role that the USBStor subkeys play in USB device analysis, so what I've done is take the more common analysis processes (that I see, based on questions asked in lists...) and I'm trying to provide solutions across all hives.

One of the things I face with writing chapters such as this one is that folks will say things like, "I want to know about blah...", and very often, there's already information out there on the subject.  One great example is the Registry ShellBags...Chad Tilbury recently posted on this topic to the SANS Forensic Blog, so given that, I have wonder, "what do you want to know?" and "how much are you willing to support the effort to present/share that topic?"  Now, by "support", I mean through such efforts as providing example hives, or just taking a few minutes to elaborate on your thoughts or questions.

6. Malware Detection - I have had a good number of "here's a hard drive that we think is infected with malware..." exams, and given that there are a number of folks out there who likely get similar cases (LE gets CP cases that evolve into the "Trojan Defense", etc.) I wanted to put together a good resource to help address this issue.  This is not a malware analysis chapter...MHL et al did a fantastic job with this topic in the Malware Analyst's Cookbook, and I'm not about to try to parrot what they've done.  Instead, this chapter addresses the topic of detecting malware within in acquired image, and I even provide a checklist of steps you can use.

Note: Many of the tools mentioned in the book are available online, and those items that are not specifically available now (the malware detection checklist, etc.) will be provided online, as well.  I really don't like the idea of providing a DVD with the book, because there are simply too many issues with getting the materials to people who purchase only the ebook, or leave their DVD at home when they go to work...

7.  Timeline Analysis - In this chapter, I not only present how to create a timeline, but I also discuss the concepts behind why we'd want to create a timeline, as well as some of the uses of timelines folks may not be too familiar with.  I presented these concepts and use case scenarios during a course I taught recently, and they seemed to have been very well received.

8.  Application Analysis - Another class of question I see a lot of in the lists has to do with application artifacts; when you think about it, there isn't too terribly much difference between some classes of dynamic malware analysis, and what you'd do to analyze an application for artifacts.

Now, there are some things that I don't cover in the book, in part because they're covered or addressed through other media or resources.  One example is memory analysis...there are a number of resources already available that cover how to capture physical memory, as well as perform analysis of a Windows memory dump, using the freely available tools. 

I wanted to provide something of a preview, because I do get a lot of those, "...does it cover...??" questions, most often from people at conferences, who are holding a copy of the book while they're asking the question.  The simple fact is that no book can cover everything, and it's especially difficult when analysts don't communicate their needs or desires beforehand.  I've done the best I can to collect up those sorts of things from lists, forums, as well as people I've talked to at conferences...but I know that the question is still going to come up, even after the book is printed.

One thing I would like to add is that, as with my other books, the focus is almost exclusively on free and open source tools to get the job done.  Like I said earlier, many of the tools are already available online, and those other items I've developed and mentioned in the book will be posted to the web when the book goes final.

From the lists and forums, I see a lot of questions regarding Windows 7, specifically, "What has changed from Windows XP?"  Truthfully, this is the WRONG question to ask, albeit a popular one.  But if you really want to know, from an analyst perspective, WFA 3/e goes final (manuscript submitted) in October, so it should be available around the beginning of 2012.

HTH

Updates

WRF Review
Andrew Hay posted a glowing review of Windows Registry Forensics on Amazon recently.  I greatly appreciate those who have purchased the book and taken the time to read it, and I especially appreciate those who have taken the time to write a review.

DFwOST
Speaking of books, it looks as if DFwOST has been picked up as a text book!  Pretty cool, eh?  I certainly hope Cory's proud of this...this is a great testament to the efforts that he put into the book, as he was the lead on this...I was just along for the ride.

One of the interesting things about this is that I've heard that other courses may be picking this book up as a resource, in part due to the focus on open source...many of the digital forensics courses out there are held at community colleges that simply cannot afford to purchase any of the commercial forensic analysis applications.  Also, I do appreciate the "tool monkey" comment from the blog post linked above...let's start folks out with an understanding of what's going on under the hood, and progress from there.  The age of Nintendo forensics is over, folks!

If that's the case for you, either as an instructor or individual practitioner, consider my other books, as well...I focus on free and open source tools almost exclusively, because...well...I simply don't have access to the commercial tools.

NoVA Forensics Meetup
Just a reminder...our next meetup is Wed, 3 Aug, starting at 7pm.  One of our members who attended our last meetup has offered to facilitate a discussion regarding some recent cyber activity and how it affects what we do.  I'm really looking forward to this, as I think that it's a great way for everyone to engage.

For location information, be sure to check out the NoVA Forensics Meetup page on the right-hand side of this blog.

PFIC
The agenda for PFIC 2011 has been posted, and I'll be presenting on Tuesday afternoon.  My presentation will be (hopefully) taking the "Extending RegRipper" presentation a bit further.  It works as it is now, but one of the things I want to do is provide a means for the analyst to designate (via both the UI and CLI) to select which user profiles to include in scans.

Bank Fraud
Yet another bank is being sued by a small business following online banking fraud.  Brian Krebs had done considerable work in blogging about other victims (most recently, the town of Eliot, ME).  What should concern folks about this is that once the victim is breached and the money transfers complete, a battle ensues between the victim and the bank.  What isn't happening is this equation is that even with all the press surrounding this, there continue to be victims, and instead of focusing on better security up front, efforts are expended toward suing the bank for "inadequate security measures". Should the bank have had some sort of anomaly detection in place that said, "hey, this connection isn't from an IP address we recognize..."?  Sure.  Should there be some other sort of authentication mechanism that isn't as easily subverted?  Sure.  There are a lot of things that should have been in place...just ask anyone who does PCI forensic assessments, or even just IR work.

One of the things Brian has recommended in his blog is to do all online transactions via a bootable live CD.  I think that this is a great idea...say your Windows system gets infected with something...if you boot the system to a live Linux distribution, this won't even "see" the malware.  Conduct your transactions and shut the system down, and you're done.

Another measure to consider is something like Carbon Black.  Seriously.  Give the guys at Kyrus a call and ask them about their price point.

Cell Phones As Evidence
Christa Miller recently had a Cops2.0 article published regarding how LEOs should approach cell phones/smart phones.  Reading the article, I think that all of it is excellent advice...but you're probably wondering, "what does this have to do with Windows IR or DF work?"  Well, something for analysts to consider is this...if you're analyzing a Windows computer (ie, laptop) confiscated as part of a search warrant, be sure to look to see if a phone has been sync'd to the system.  Did the user install iTunes, download music, and then load the music on their iPhone?  If so, the phone was likely synced/backed up, as well.  Is the Blackberry Desktop Manager installed?  Did the user back their phone up?  If so, the backup files may proved to be significant and valuable resources during an investigation.

Did you map all of the USB removable storage devices that had been connected to the system?  You don't need to have the management software installed to copy images and videos (hint, hint) off of a phone...just connect it via a USB cable and copy the images (which will likely have some very useful EXIF data available).

analyzemft 2.0 Released!
Matt Sabourin updated David Kovar's analyzemft.py to make it completely OO!  David has done some great work putting the tool together, and Matt's extended it a bit by making it OO, so that it can be called from other Python scripts.

The project is now hosted on Google Code.

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).

Carbon Black

I attended a Carbon Black (Cb) demo recently, at the invitation of the great folks of Kyrus.  The demo was intended to show some of the improvements to Cb, in particular the GUI available to quickly and easily mine through the available logs.

For those of you who haven’t heard of Cb…where’ve ya been???  Cb is a sensor that monitors the execution process on Windows systems, and reports on processes and file writes.  A coming update to Cb will also report on writes to the Registry, as well as network connections (source/dest IPs and ports, with a time stamp).

In the demo, Mike Viscuso demonstrated how the GUI can be used to quickly track down a FakeRean installation, and even track it back to an a Java “issue” (more analysis would be needed to determine if it were an exploit) delivered via Firefox.  Mike when through this slowly, and had he gone through this full speed, it would have only taken a couple of seconds.  In the demo, Mike identified three stages of the infection, and identified the executable files associated with each.  The first stage executable was identified by 14 of 42 AV engines on VirusTotal (for each stage, Mike submitted the hash of the file, not the file itself).  The second stage executable was not identified by any of the AV engines, and in fact was reported to not have been previously submitted.  Finally, the third stage executable was identified by 5 of 42 AV engines.

Now, compare that to the “normal” IR approach, and how long it would take to dump memory from that system…and this is assuming that you’ve got your IR toolkit prepped and ready to go, and you have personnel trained in the proper collection and analysis techniques.  How about obtaining a copy of the executable?  Cb does this for you; the traditional approach to doing this could take several hours, under the best conditions.

Finally, Mike could have issued a query to determine if the particular files in question had been “seen” on any other systems in the enterprise, an answer to which would be available within seconds.

Deployment, or “How this beats the current IR model”

The current model used for IR is that someone gets hacked or hit with malware of some kind and calls for help, or someone gets notified by an external third party that their data has been compromised (see annual reports from Verizon, TrustWave, or Mandiant) and calls for help.  Sometime after that, personnel and/or equipment are sent on-site, and all the while, data may continue to be exfiltrated from the infrastructure.  At some point after the call for help, network and host data, and possibly the contents of memory from hosts may be collected and analyzed…all of which takes considerable time.

Now, what if you deploy Cb before an incident?  If you were to do this, starting with a testbed of systems, and possibly some non-production systems, you could monitor that subset of your infrastructure, and once you become familiar and comfortable with the tool (check with Kyrus for licensing to get the log collection server within your infrastructure), progressively roll the sensor out to more systems.  Once you get Cb rolled out and the server installed, it’s simply a matter of reviewing the data.   Should you suspect that something has occurred, you now have considerable, albeit easily managed and viewed data available.  You can even set up a scheduled task on the server that queries for new executables having been launched, and have this task run every day (or even six hours).  You may initially get a lot of data, but over time, you’ll notice that the set that you receive back should be reduced.  You can even have the task email the list of new executables to you.

Now, even if you were to query the logs every 24 hrs (via a scheduled task or manually), the fact is that you’d know about the incident within 24 hrs (at the most), rather than hearing about it 3 months later from someone else.  Since many of these notifications come well after the actual data theft occurred, when deployed proactively, Cb is capable of providing a level of context that simply isn’t evident or available via more traditional means of IR, such as memory or even disk analysis.  Further, once something is “seen”, you can query the infrastructure for other affected systems, quickly scoping your incident.  Again, through traditional means of IR, scoping the incident can often take considerable time and be very expensive (in time, money, resources, etc.) to the already-compromised environment.

And Cb answers more than just questions related to security and IR.   One of the use cases that the Kyrus guys like to use involves addressing budgeting issues, and going out across the enterprise to determine how many employees were running all components of an office suite of tools.  With the returned information, the organization was able to drastically reduce licensing costs.  Cb can also be used to enforce acceptable use policies, among other things.

If you haven't done so, I'd recommend taking a look at Cb...it doesn't have huge overhead or a "big" footprint, and what it can save you in terms of much more than just IR and security is immense.  

More Links, Updates

Meetup
Our 6 July NoVA Forensic Meetup went very well, and I wanted to thank Tom Harper for putting in the time and effort that it takes to provide his presentation, and to also thank the ReverseSpace folks for hosting our meetings!  This time, we had about 20 or so folks show up...some new...and I wanted to thank everyone who took the time out to come by and take part in our event.

What I liked about Tom's presentation was the fact that Tom's a practitioner, and he approaches solutions from that perspective.  Tom was at OSDFC, and after the conference mentioned that some of the presentations we saw that day were from folks from the academic side of DFIR, and not so much the practitioner side.  I agree with that sentiment...and Tom's approach is practical and all about gettin' the job done.

I should also note that the ReverseSpace location doesn't say "ReverseSpace" on the outside, nor is there a sign by the road.  The address is 13505 Dulles Technology Drive, Suite 3, in Herndon, VA, and the facility says "Cortona Academy" on the outside.  Don't worry about writing this address down...simply check out the "NoVA Forensics Meetup" page associated with this blog.

Our next meetup is scheduled for 3 August (same time, 7-8:30pm) and we're looking for presentation or discussion ideas, as well as presenters.  @sampenaiii suggested via Twitter that we have a discussion on LulzSec and the impact of their activities on security and forensics; this sounds like a great idea, and I think that we'll need to have a slide or two with some background for those who may not be familiar with what happened. 

Cory-TV
Cory Altheide recently provided a link to the video of a presentation he gave in Italy on 2 May 2011.  The presentation is titled, "The death of computer forensics: digital forensics after the singularity", and is very interesting to watch.  Cory is a very smart guy, and as Chris Pogue recently tweeted, Cory is the bacon of the DFIR community, because he makes everything better!

Cory presents some very interesting thoughts regarding what were once thought to be "forensics killers", and the future of digital forensic analysis. One of the things that Cory mentioned was the existence of metadata, which is not often removed, simply because the user doesn't know about it.  There have been some pretty interesting instances where metadata has played a very important role (here, and here), and I agree with Cory that it will continue to do so, particular due to the fact that we have new formats, devices, and applications coming out all the time.

Clearly, Cory talked about much more than just metadata in his presentation, and I simply can't do justice to it through any sort of concise description.  Instead, I highly recommend that you take the hour+ to sit down and watch it.  I think that the overall point that Cory makes is that as available drive space increased (every time it did) and decreased in price, and as platforms to be analyzed have become more complex and varied, there have been those who've claimed that these things would be the "death of digital forensics"; instead, analysts have adapted. 

MBR Analysis
Speaking of Chris Pogue, he recently posted to his blog regarding MBR Analysis, referring to a discussion he and I had had not long ago.  What I like about Chris's post is that he's talking about it, and by him doing so, my hope is that the things we talked about reach more analysts.  Chris is the author of the Sniper Forensics presentations (here's the one he gave at DefCon18), and he's been getting a lot of mileage from the series, and presents to a lot of people.  As such, my hope is that more people will hear about MBR analysis, how it can be used, and start looking at this as a viable part of a malware detection process/checklist.

When you read the post, don't get caught up in the terminology...what I mean by that is, to clarify a couple of things, the TSK mmls reads the partition table within an image of a physical disk (you don't have one of these if you acquire a logical image of the C:\ volume, for example), and provides you the offsets to the partitions.  The offset to the active partition is often 63 sectors (indexed at 0), not "0x63".

Speaking of the Sniper Forensics presentations, Chris also has another post up on the SpiderLabs Anterior blog that's worth a read.

Additional Thoughts
I recently posted some thoughts regarding how the structure that data is stored in (as well as where within that structure) can provide context to the data that you're looking at, and an email exchange with James, who commented on that post, led to some thoughts regarding timelines.

James (I hope you don't mind me pointing this out...) in a comment that log2timeline doesn't provide enough context.  I was curious about this, and in the ensuing email exchange, at least part of what James was referring to was things like, if an image file was created on the system, provide a link to that file, that would then be opened in a viewer.  In this way, the analyst would have access to additional context.

I thought that this was an interesting idea...and I still do.  Having my own process for creating timelines (taking nothing away from Kristinn's efforts with log2timeline, of course) I thought about how you could implement something like this...and got stuck.  Here's why...let's say that you completely restructured timeline creation and had the timeline itself available with either the image itself mounted as a volume, or files extracted from the image...would you provide links to all files that were created on the system?  I'm thinking not.  Also, if a file is modified, what do you link to?  What value or context is there if you don't know what was modified in the file?  The same would be true for Registry keys.

However, I do think that there are some benefits to this idea, but it really depends upon how you implement it.  For example, let's say that you found some time stamped data in the pagefile or in unallocated space, and wanted to include it in your timeline.  You could do that, and then include a link to the data...but not to the offset within the image; instead, extract the data (plus 100+ bytes on either side of the data) into a separate file, and provide a link to that file.  The same might be true for other files...for example, if your timeline analysis leads you to determine that the infection vector was spear phishing via a PDF file, rather than copying the PDF file out of the image and linking to it, maybe what you could do is copy the PDF file out of image, and parse the offending portions of that file out, emasculate them (i.e., extract them to a text format, etc.), and then link to that.  You might extract images, and link to those...it all depends on how you want to present the data.  But my point is, this may not be something that you would want to completely automate; instead, use the timeline to perform your analysis, and once you've isolated the appropriate entries in your timeline, provide links to relevant data (either the file, a portion of a file, or to your analysis of the file) in order to add context and value to your timeline.

Structure Adds Context

A while ago, I was talking to Cory Altheide and he mentioned something about timeline analysis that sort of clarified an aspect of the analysis technique for me...he said that creating a timeline from multiple data sources added context to the data that you were looking at.  This made a lot of sense to me, because rather than just using file system metadata and displaying just the MACB times of the files and directories, if we added Event Log records, Prefetch file metadata, Registry data, etc., we'd suddenly see more than just that a file was created or accessed.  We'd start to see things like, user A had logged in, launched an application, and the result of those actions was the file creation or modification in which we were interested.

Lately, I've been looking at a number of data structures used by Windows systems...for example, the DestList stream within Windows 7 jump lists.  What this got me thinking about is this...as analysts, we have to understand the structure in which data is stored, and correspondingly, how it's used by the application.  We need to understand this because the structure of the data can provide context to that data.

Let's look at an example...once, in a galaxy far, far away, I was working on a PCI forensic assessment, which included scanning every acquired image for potential credit card numbers (CCNs).  When the scan had completed, I found that I had a good number of hits in two Registry hive files.  So my analysis can't stop there, can it?  After all, what does that mean, that I found CCNs in the Registry?  In and of itself, that statement is lacking context.  So, I need to ask:

Are the hits key names?  Value names?  Value data, or embedded in value data?  Or, are the hits located in unallocated space within the hive files?

The answers to any of these questions would significantly impact my analysis and the findings that I report.

Here's another example...I remember talking with someone a while back who'd "analyzed" a Windows PE file by running strings on it, and found the name of a DLL.  I don't remember the exact conclusions that they'd drawn from this, but what I do remember is thinking that had they done some further analysis, they might have had different conclusions.  After all, finding a string in a 200+ KB file is one thing...but what if that DLL had been in the import table of the PE header?  Wouldn't that have a different impact on the analysis than if the DLL was instead the name of the file where stolen data was stored before being exfil'd?

So, much like timeline analysis, understanding the structure in which data is stored, and how that data is used by an application or program, can provide context to the data that will significantly impact your analysis and findings.

Addendum, 7 July
I've been noodling this over a bit more and another thought that I had was that this concept applies not just to DF analysis, but also to the work that often goes on beyond just analysis, particularly in the LE field, and that is developing intelligence.

In many cases, and particularly for law enforcement, there's more to DF analysis than simply running keyword searches or finding an image.  In many instances, the information found in one examination is used to develop intelligence for a larger investigation, either directly or indirectly.  So, it's not just about, "hey, I found an IP address in the web logs", but what verb was used (GET, POST, etc.), what were the contents of the request, who "owns" the IP address, etc.

So how is something like this implemented?  Well, let's say you're using Simson's bulk_extractor, and you find that a particular email address that's popped up in your overall investigation was located in an acquired image.  Just the fact that this email address exists within the image may be a significant finding, but at this point, you don't have much in the way of context, beyond the fact that you found it in the image.  It could be in an executable, or part of a chat transcript, or in another file.  Regardless, where the email address is located within the image (i.e., which file it's located in) will significantly impact your analysis, your findings, and the intel you derive from these.

Now, let's say you take this a step further and determine, based on the offset within the image where the email address was located, that the file that it is located in is an email.  Now, this provides you with a bit more context, but if you really think about it, you're not done yet...how is the email-address-of-interest used in the file?  Is it in the To:, CC:, or From: fields?  Is it in the body of the message?  Again, where that data is within the structure in which it's stored can significantly impact your analysis, and your intel.

Consider how your examination might be impacted if the email address were found in unallocated space or within the pagefile, as opposed to within an email.

More Links

Meetup
Just a reminder about tonight's meetup:

Location: ReverseSpace (this is our location, unless stated otherwise)
Time: 7-8:30pm (this will be the time that we'll meet, unless stated otherwise)

Tonight, Tom Harper will be presenting...you can get a copy of his slides here.

Also, please notice that I've created a "NoVA Forensics Meetup" page, linked on the right-hand side of this blog. 

Mobius
I ran across the Mobius Forensic Framework this morning (because it had been updated), and found it very interesting.  Mobius is a Python-based framework "...that manages cases and case items, providing an abstract interface for developing extensions. Cases and item categories are defined using XML files for easy integration with other tools."  It seems that this framework has been around for some time...the main link indicates that the last update was near the end of 2009.  The framework appears to have a Hive Report capability, as well.

This appears to be very different in function from the Digital Forensics Framework, now at version 1.1.0, and is definitely worth a look.

For/Sec LinkFest
Klaus has updated his blog again, and posted an expansive set of links regarding forensic and security tools.

I'm always looking to improve the work that I do, and I very often find some interesting links in what Klaus provides.  One was a reference to the eScan AV toolkit, from TinyApps.org, in Klaus' RSS feed.  If you work cases that involve detecting suspected malware ("Trojan defense"), this may be a tool that you'll want to employ as part of your malware detection process/checklist.

Xanda
Speaking of links, I ran across this page at Xanda, and found a number of very interesting links, such as an emulator for the PDP-11.  As with many other sites that provide lists of free/open-source/(some commercial) forensics tools, there will be a considerable amount of overlap, but there are also some links on this page that I haven't seen before, and I'm not about to discount anything at this point.  I mean, while I haven't been asked to analyze an Atari system, when I was at IBM our team was asked to perform analysis of mainframe systems more than once.  The Xanda page also has an entire section on steg tools.

Reading
I ran across this interesting bit of reading on the CERIAS blog, authored by Gene Spafford.  Beyond the mention of historically famous names in the DFIR community (from before there was really a DFIR community....) were the statements in the first paragraph regarding deployment of DFIR countermeasures.

As interesting (and immensely helpful) as these countermeasures may be, having performed a number of incident response engagements and analyzed even more drives and images, I think that the reality is that we have to just file this under "ain't gonna happen".  Now, don't get me wrong...I do believe that such measures are good security and would prove to be immensely useful; however, who's going to implement and monitor them, given the state of security to begin with?  What good is any of this going to do when the bad guys have already been through your infrastructure?

Now would countermeasures such as those Gene describes be useful...sure.  If they were properly deployed.

Links

Independence Day
Before anything else, Happy 4th!  I hope that everyone takes a moment to remember those who have fought and sacrificed for our freedoms...that includes not only those who have given the ultimate sacrifice, but those who have lost loved ones in the fight for freedom.  Also remember our public servants (cops, firefighters, EMTs), as well as our service members who are fighting to give others freedom.  May God bless them all.

e-Evidence
There's been an update over at the e-Evidence web site, with the addition of some good reading...take a look.

APT
I posted recently regarding an article Jason Andress had written for ISSA, regarding APT.  Shortly thereafter, my friend Russ contacted me to let me know that he'd co-authored a similar paper, and that I might want to take a look at it.  The blog post is here, and the paper can be found here.  The paper was written as a requirement for the SANS Technology Institute MSISE program, and while it touches on some of the same themes as Jason's paper, this one takes a bit more of a tactic approach...and that's one of the things I really like about this paper.  The approach taken in the paper is not just tactical...it's "here are some of the things that are seen on the network, and here's a cheap or free way to go about detecting it."

The paper also points out some interesting aspects of tactics used by the threat actors, particularly getting into the infrastructure via some method (spear phishing), gaining a foothold with PI-RAT, and then moving laterally within the infrastructure.

Another aspect of this paper is that it provides additional insight into the threat itself; anyone unfamiliar with the threat should read this paper, Jason's article, and others in order to develop a better understanding of the threat.  Much of what I've read out there covers the general flow of these threats, and this paper provides some insight into a specific implementation, and should be considered as such.  Not every incident of this type is going to include the same persistence mechanism, use of the same RAT, or the same network traffic.  However, the paper does a very good job of pointing out some of what can be done in response to this threat, both in initial detection and then response.

So, again...some great information in the paper, and it is easy to follow; if you're trying to get a better understanding of the threat overall, be sure to include this in your reading, along with additional credible, authoritative sources.

Malware
In the past, I've talked about the four malware characteristics I'd developed to help DFIR folks understand and explain malware, and over time, those characteristics have served me pretty well.  One of those characteristics is the initial infection vector...how the malware gets on the system.  Well, I ran across this InformationWeek article this morning talks about Facebook being the "new" malware vector.  Okay, the meaning of "new" aside, I think that this is interesting, in part because it makes complete sense.  Look at the statistics in the article regarding users and the clients they use to access Facebook...pretty telling, if you ask me.

As an analyst, I'd like to hear from other analysts...have you seen incidents where Facebook was the delivery mechanism for malware?  If so, what are the artifacts on a PC or laptop, as opposed to a smartphone?

Also, Cory started a drinking game at OSDFC, because apparently, I pronounce malware "mall-ware"...so for every time I wrote "malware", you need to drink!



WFA 2/e Review
Mike Ahrendt posted a review of WFA 2/e recently; it's great to see that this book is still active and making its rounds, and that people who are reading it are finding something useful.  I tend to reference it myself now and again for my own needs, and sometimes will make notes of new, additional information that I've found with respect to a particular topic.  I think it's great that folks are still picking it up for the first time and finding it useful.

Bootkits
There was a post over on the SANS ISC site recently regarding the resurgence of bootkits, in which MS's Win32/Popureb.E (which is still short of any information useful to analysts) was specifically mentioned.  The post goes on to take a look at AV products that detect and/or clean MBR infectors, and indicates which are more successful than others.  I still think that one of the biggest issues surrounding this sort of thing is that most analysts I've spoken with appear to not look for this sort of thing when it comes to determining if there is malware (drink!) in an image acquired from an infected system.  I'm not sure if this is an awareness issue, or a training/understanding issue; I have a checklist that I use (and try to keep up to date) for engagements such as this, so when I receive an image and the statement that, "we think it was infected with malware", I run through this process, which includes checking for indications of MBR infectors.

My thoughts on this subject aren't so much that I think that MBR infectors are more pervasive than most analysts think; not at all.  I think that it's more of a knowledge or "engaging with your peers" issue than anything else.  I don't think that available courses (whether for training, or ultimately ending in a certification) are necessarily going to cover the topic of malware detection within an acquired image, but I do think that the issue is one that needs to be understood (i.e., the "Trojan defense").  As such, where do analysts go to get this sort of information or education?

What are your thoughts?

Meetup, Tools and other stuff

Meetup
Just a reminder about our next NoVA Forensic Meetup, scheduled for 6 July.  Tom Harper will be presenting, and he's posted  his slides on his site.  Take a look at his slides, and download them if you want to bring them along.  Also, taking a look at them ahead of time will make the presentation itself go a bit more smooth, and leave more time for questions and interaction.

Location: ReverseSpace, 13505 Dulles Technology Drive, Herndon, VA.

Time: 7:00 - 8:30pm

Review
Corey Harrell posted his review of DFwOST.  Thanks for the review, Corey, and for taking the time to put your thoughts out there for others to see.

MBR

I've mentioned previously that I include a check for MBR infectors in my malware detection process, and I even have it on my checklist.  I discussed this recently with Chris Pogue ("@cpbeefcake" on Twitter), and he pointed me to the mbrparser.pl Perl script that Gary Kessler makes available via his site (the script can be found in the Boot Record Parsers archive).  Gary's mbrparser.pl script does more than just display the MBR; it also parses the partition table in a very readable manner, providing a bit more information than mmls from the TSK tools.

My own Perl script is used for something other than just displaying the MBR, and it doesn't parse the partition table...instead, it looks for sectors that are not all zeros, and will either list those sectors (in summary mode) or display them.  The thought process behind this approach is that many of the identified MBR infectors will modify the MBR with a jmp instruction, and copy the original MBR to another sector.  Some may even include executable code within sectors.  This is particularly useful when you have an image acquired from a physical disk and the first active partition is located at sector 63; usually, I will see sector 0 and 63 as non-zero, and maybe one or two other sectors.  Running the script in summary mode gives me an idea of how many of the sectors I will need to look at, and then running it in full mode allows me to have something that I can redirect to a file and even include in my report, should the need arise.  Even if nothing is found, that's useful, too...because now my malware detection process includes an additional step beyond simply, "I ran an AV scanner against the mounted image...".

Here are some links to disassembling the MBR:
Links
MBR disassembly
More MBR disassembly

Also be sure to check out Gary's page for other utilities, particularly if you're into SCUBA.

Speaking of MBR infectors, a recent MS Technet blog post mentioned a new MBR infector/bootkit called "Trojan:Win32/Popureb.E", which is apparently an update to previous versions of the identified malware, in that it infects the MBR.  Unfortunately, MS's recommendation is to fix your MBR using your recovery disk - I say "unfortunately" because without a root cause analysis, what is the likelihood that you "fix" the system, and the bad guy is then able to un-fix your fix?  Pretty high.  I've seen other MBR infectors get delivered via Java exploits...so if you don't figure out how the MBR got infected, how are you going to protect your infrastructure?  I'd suggest that the steps should be more along the lines of acquiring memory and an image of the physical disk, and then if you must re-provision the system, clean the MBR as suggested, but tag the system as such, and put a high priority on determining an overall fix.

Tools
Nick Harbour of Mandiant maintains a page with a couple of interesting tools, including nstrings and pestat.  Nick's also posted some FileInsight plugins, as well as interesting presentations, on that same page.

The Malicious Streams site includes a Python-based LNK file parser (as well as some interesting MacOSX-specific tools).

David Kovar has moved his analyzeMFT tool to a new location; take note, and keep an eye out for new tools/libraries...

What is "APT"?
Jason Andress published an article for ISSA about APT, what it is, and what the threat really means.  While I do think that the article gets a little too mired down in the origins and meaning of the term "APT", it does make a very valid point...regardless of what side of the fence you're on, APT is a very real threat.  Jason does point out some very important points with respect to defending against this threat, but he does mention tools without specifically identifying any particular tools to use.  I think that in doing this, he makes a point...that is, there is no security silver bullet, and one tool (or combination of tools) may work very well for one organization, but not at all for another.

I think that the most important point that Jason makes regarding defense is the idea of "defense-in-depth".  Now, I've seen where some have suggested that this doesn't work...but the fact of the matter is that you can't deem something a failure if it was never employed.

Jason mentions "security awareness"...this is important, but it has to begin at the top.  If you spend the time and effort to train your employees and raise security awareness, but your C-level executives aren't in attendance, how effective do you think that training will be?  If it's really that important, wouldn't the boss be there?  I attended two days of manager-and-above training for an employer, which was kicked off with a message from the CEO.  And guess what...every time I looked around throughout the two days, I saw the CEO there.  More than anything else, that told me that this stuff was important.  Security has to be top-down.

Something to point out that wasn't mentioned in Jason's article is that many of the things he mentions are either directly or indirectly covered in most of the legal and regulatory compliance standards.  Testing...training...having the right tools in place...many of these map directly to the PCI DSS.  Even defense-in-depth, when you include the computer security incident response team (CSIRT), maps to chapter 12.9 of the DSS.

Jump List DestList Structure
Jump lists are one of those new things in Windows 7 that many analysts are trying to wrap their heads around.  Jump lists provide similar functionality to the user as shortcuts in the Recents folder, as well as the RecentDocs Registry key, albeit in a different manner.  First, jump lists come in two flavors; Automatic and Custom destinations.  I'm not going to be really prolific about jump lists, but from a binary point of view, custom destinations are apparently SHLLNK structures run to together consecutively, one after another, where as Automatic destinations are streams within an OLE container (that is, each *.automaticdestination-ms file is an OLE container).  Each of the streams within the contain is numbered (with the exception of one called "DestList"), and follows the SHLLNK structure. You can open the automatic destinations jump list using the MiTeC Structured Storage Viewer, extract each numbered stream, and view the contents of the stream in your favorite LNK viewer.

There is very little (i.e., "none") information available regarding the structure of the "DestList" stream, but looking at it in a hex editor seems to indicate that it may serve as a most recently used (MRU) or most frequently used (MFU) list.  We know that the SHLLNK structure in the numbered streams contains time stamps, but from the structure definition we know that those are the MAC times of the target file.  So how does Windows 7 know how to go about ordering the entries in the jump list?

Well, I spent some time with some jump lists, a hex editor and a number of colored pens and highlighters, and  I think I may have figured out a portion of the DestList structure.  First, each DestList structure starts with a 32 byte header, which contains (at offsets 0x03 and 0x18) an 8 byte number that corresponds to the number of numbered streams within the jump list.

Following the header, each element of the structure is 114 bytes, plus a variable length Unicode string.  The table below presents those items within each element that I've been able to extract on a consistent basis, albeit via limited testing.

Offset	Size	Description
0x48	16 bytes	NetBIOS name of the system; padded with zeros to 16 bytes
0x58	8 bytes	Stream number; corresponds to the numbered stream within the jump list
0x64	8 bytes	FILETIME object
0x70	2 bytes	Number of Unicode characters in the string that follows

While the information represented in the above table clearly isn't all that's available, I do think that it's a good start.  Once further testing is able to determine what the FILETIME object represents, this is enough information to allow for inclusion of jump lists into timelines.

Links and Updates

CyberSpeak
Ovie's got a new podcast up, be sure to check it out. In this podcast, Ovie interviews John Goldfoot, lawyer and author of the new paper, The Physical Computer and the 4th Amendment, published in the Berkeley Journal of Criminal Law.  The overall idea is of the paper is to no longer view the computer as a system of containers, but simply as a container, in itself.

Ovie's podcasts are great listening and very educational.  If you're one of those people who has to have a bit of coffee before becoming coherent in the morning, the CyberSpeak podcast is a great accompaniment for your Starbucks.

I especially like John's reference to the dog that did not bark, which is a Sherlock Holmes reference to the fact that the absence of evidence that would be present to something that happened, thus suggesting that it did not happen.  This is very similar to something I've said and published in my books for a long time...the absence of an artifact where you would expect to find one is, itself, an artifact.

Take away from the podcast...don't use the S-word!

Anti-Malware Tools of Note
Klaus is back, with a great post pointing out anti-malware tools of note!  I've always found Klaus's posts to be chock full of great information about the various tools that he finds, and in many cases, has tried and posted his sort-of-Consumer-Reports version of the tool.  I find posts like this to be very useful, particularly as I tend to get a lot of "...we think this computer has/had malware on it; find it..." cases, and as such, I have what I believe to be a comprehensive process, in a checklist, that includes (but is not limited to) running AV scans.  In that process, I specifically steps that require me to check the timeline of the system to determine which AV scanner(s), if any, have already been run on the system.  Many times, the system will have a fairly up-to-date scanner (Symantec or McAfee) running (find Application Event Logs records, AV logs, etc.), and in a good number of cases, I've found that an Administrator had also installed and run Spybot Search & Destroy, and maybe even the MalwareBytes Anti-Malware scanner.  If none of the tools that have already been used on the system found any threats, then it's incumbent upon the analyst to NOT use any of those tools; after all, if scanner A didn't find anything, how much value are you really providing to the customer to run your edition of scanner A on the mounted image and not finding any threats?

Compromises
I recently ran across this little gem, which states some pretty interesting "statistics".  In this case, I use quotes around that last term, as I'm not entirely sure that something wasn't edited out of the article prior to publication.  For example, the biggest issue I see with the article is that I don't understand is how you can survey 583 businesses, and then extrapolate their responses to "90% of US businesses"; this suggests that the 583 respondents, without any indication of their makeup, are a representative sampling of all US businesses.  The article does point to this Ponemon Institute report.

Based on the survey results, there seem to be some interesting, albeit not surprising  findings...

"...59% of respondents claimed that the worst consequences of the attacks were theft of information, followed by business disruption in second place."

This is interesting, as more and more organizations seem to be coming to this conclusion, that data theft is an issue.  It wasn't so long ago that data theft was something of an afterthought for many of the organizations I encountered

Another interesting quote from the article:

"Employee mobile devices and laptops are believed to be the most likely entry point through which serious attacks are unleashed."

I found this particularly interesting, because as a responder, in most of the cases I've worked, there is very often little done to attempt to determine the "most likely entry point".  I'm guessing that terms such as "believed" and "most likely" are intended to convey speculation, rather than assertions supported by fact.

One particular quote stood out from the article; Dr. Larry Ponemon reportedly stated, “conventional network security methods need to improve in order to curtail internal and external threats.”

Now, I realize that this is likely taken out of context, but "conventional network security methods" are likely not those things that security professionals have been harping on for years; these security methods are most likely what the respondents have in place, not what they should have in place.  The fact is that many organizations may not have the ability to detect and effectively respond to incidents, which not only makes the threats appear to be extremely sophisticated, but also ends up costing much more in the long run.

The Value of Data
My last blog post, in which I asked, who defines the value of data, generated some interesting comments and discussion.  Based on the discussion and further thought, I'm of the opinion that, right or wrong, and due to several factors, the value of data is entirely subjective and most often up to the analyst.

Think about it...how do most analysis engagements start?  Ultimately, regardless of where or how the overall engagement originates, an analyst is presented with data (an acquired image, logs, etc.) and a set of requirements or goals.  Where did these goals come from?  Many times, the "customer" (business organization, investigator, etc.) has stated their goals, from their perspective, with little to no translation or understanding of/expertise in the subject (beyond what they've read in the industry trade journal du jour, that is...).  These are then passed to the analyst via a management layer that often similarly lacks expertise, and the analyst is left to discern the goals of the analysis without any interaction or exchange with the "customer" or "end user". 

Now, consider the issue of context...who determines the contextual value of the data?  Again...the analyst.  Isn't it the analyst who needs to know about the data in the first place?  And then isn't it the analyst who presents the data to someone else, be it a "customer" or "end user"?  If the analyst's training has made them an expert at calculating MFT data runs, but that training didn't address the Windows Registry, then who determines the contextual value of all of the available data if not all of the data is analyzed and/or presented?

No, I'm not busting on analysts, not at all...in fact, I'm not making derogatory remarks about anyone.  What I am suggesting is that we take a look at the overall DFIR process and consider the effect that it has on studies and surveys such as was mentioned earlier in this post.  Incidents of all kinds are clearly causing some pretty significant, detrimental effects on organizations, but IMHO and based on my experience over the years, as well as talking with others in the industry, it's pretty clear to me that incidents and compromises are becoming more targeted and focused, and the battle ensues between the attacker and the target's management.

Early this year, I read and wrote a review for CyberCrime and Espionage, by John Pirc and Will Gragido.  Two statements I made in that review are:

What is deemed "adequate and reasonable" security is often decided by those with budgeting concerns/constraints, but with little understanding of the risk or the threat.

Compliance comes down to the auditor versus the attacker, with the target infrastructure as the stage.  The attacker is not constrained a specific compliance "standard"; in fact, the attacker may actually use that "standard" and compliance to it against the infrastructure itself.

I believe that these statements still apply, and do so, in fact, quite well.  However, I'd like to combine them into, A data breach comes down to the management versus the attacker.  Attackers are neither concerned with nor constrained by budgets.  Attackers pry the cover off of technologies such as Windows XP, Windows 7, Windows Media Player, Adobe Reader, etc., and dig deep into internal workings, knowing that their targets don't do the same.  Management determines the overall security culture of their organization, as well as the use of resources to implement security.  Management also determines whether their organization will focus on protecting their data, or simply meeting the letter of the law with respect to compliance.

Don Weber, a former US Marine, recently tweeted, "In their minds #LULZSEC ~== WWII French Resistance".  That's very appropriate...when the Germans invaded France, they didn't know the lay of the land the way the resistance fighters did; sure, they could navigate from point to point with a compass, and move in force with tanks and troops, but the resistance fighters knew the land, and knew how to move from point to point in a stealthy manner, remaining out of site by using the terrain to their advantage.

Tool Update
John the Ripper, a password cracker for Unix, Windows, DOS, BeOS, and OpenVMS has seen an update, intended to make it a bit faster with respect to cracking passwords.  There's a great deal of information available in the OpenWall wiki for the tool.

Selective Imaging
I ran across a reference to this thesis paper from Johannes Stüttgen via Twitter this morning.  The paper is well-worth reading, and very informative, but at the same time, I can say from experience that there are a LOT of responders and analysts out there (myself included) who have already gone through the same sort of thought process and come up with our own methods for addressing the same issues raised by the author.  Now, that is not to say that the paper doesn't have value...not at all.  I think that after having read through the paper, it's going to provide something to everyone; for example, it's going to present a thought and exploration process to the new analyst who doesn't have confidence in his or her own abilities and experience.  We often work in isolation, on our teams, and may not have someone more experienced to "bounce" things off, and if you don't feel that you can reach out to someone else in the community, this paper is a great resource.  I also think that the paper may open the eyes of some more experienced analysts, providing insights to things that may not have been considered during the development of their own processes.

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?

Awards

Not long ago, at the SANS Forensic Summit, I received two awards during the Forensic 4Cast Awards ceremony.  I was not able to attend this summit, but got to catch part of it on LiveStream.  Cory was kind enough to drop the pictured awards off the following week when he came to NoVA for OSDFC.

The top award is for Outstanding Contribution to Digital Forensics - Individual, and the lower one is for Best Digital Forensics Book, which I'm told applies to Windows Registry Forensics.

I'd like to thank everyone involved for these honors; the folks who nominated me, those who voted for me, as well as Lee Whitfield for setting up the awards, and Rob Lee and SANS staff for arranging and conducting the summit.

I'm not entirely sure what I did to receive these awards, but I'm very grateful and appreciative to the community and to everyone involved in the Forensic 4Cast awards process.

Links and Updates

Reviews
Eric Huber posted an excellent review of the DFwOST book that Cory wrote, and I assisted on the writing (full disclosure; I'm a minor co-author of the book).  Eric has even added DFwOST to his "Learn Digital Forensics" list on Amazon, along with WFA 2/e, WRF, and others.  Eric's list is intended to help others figure out which books to get if they're...well...interested in learning digital forensics.

Here's another review from Little Mac (aka, Frank) who apparently went about the review process the old fashioned way...by purchasing the book first.

Jesse Kornblum, the man behind tools such as md5deep and ssdeep (and truly a man with the gift of beard), has kindly posted his review of DFwOST, as well. It's short and sweet, although no less appreciated.  As I was reading the review, however, I got to the third paragraph, which started, "There was something I felt was missing from the book."  I read this with great interest, as I've written a number of books myself, and I'm working on one know...so anything I could take away from what Jesse said to improve my book, I'm anxious to read.  Jesse went on to mention getting free support or work from someone you've never met...that is, the person or people maintaining the open source (and very often free) tool that you're using.

Procedures
Speaking of Jesse, one of the great things he's produced (perhaps beyond his papers and tools) is his "Four Rules for Investigators" blog post.  If you've never seen it, check it out.  Then think about this list in relation to what you do.  Yes, I know that there's many of us out there who say, "I do all of them...every time!"  I've heard folks say this...and then a month later the same folks have said, "I was working on an exam and 'lost' the image"...apparently, having forgotten #4.

#3 is a big one, because most of us simply don't do it.  Examiners will often say, "I don't know what standard to write to..." as a reason for NOT taking notes.  But the fact is...you do.  What is the purpose for taking the notes?  It's so that you can come back a year later, after having done a couple of dozen other investigations, and clearly see what you did.  But...it's also so that if you get hit by a bus leaving work one day, another examiner can pick up your notes and see exactly what you did.  In short, if you didn't document it, it didn't happen.

Thoughts on Conferences
I recently attended (and spoke at) OSDFC, and while I was there, I had a chance to meet and speak with a lot of great folks from the community.  While doing so...and while talking to folks after the conference...there seemed to be a common theme with regards to the talks and presentations at conferences, in general.  OSDFC is interesting because there are talks by developers and academics, as well as by practitioners; in some cases, the developer who is speaking is him- or herself a practitioner, as well.  The common theme seemed to be that there's a desire for more meaty presentations; that is, provide someone with a 30 minute time frame where they discuss the problem or obstacle that they encountered, and their thought process/reasoning for selecting the solution at which they ultimately arrived. 

Don't get me wrong...I thoroughly enjoyed OSDFC, and I greatly appreciate the effort that the organizers and presenters put into making the conference a success.  Brian asked at the end of the conference what the attendees thought could be improved for next year, and ended up saying that he'd just flip a coin.  I'm going to go out on a limb and say that there needs to be two tracks...one predominantly focused toward developers and academics, and the other toward practitioners.  This doesn't mean that someone can't present in either track, or attend either track...but I met a number of LE examiners whose eyes glassed over when an academic talked about running a tool on 4, 16, then 64 cores; sure, that's cool and all, but how does that help me put bad guys in jail?

So, again...I'm not saying that there need to be conferences that focus on one side of the equation the exclusion of others.  In fact, it's quite the opposite...I think that all aspects of the community are important.  However, listening to folks after the presentations, there was usually one reference, with respect to a how, that most wished the presenter had discussed in a bit more detail.

This is an approach that I'd like to take with the NoVA Forensics Meetup.  At our next meeting on 6 July, Tom Harper will be giving a presentation, and I'm sure that it will be a great success.  Going forward, I'd like to have shorter talks, perhaps two each meeting, running about 20-30 min each.  To do this, I'd like to ask the folks attending (and even some of those not attending) to offer up ideas for what they'd like to hear about...and for some folks to step up and give presentations.

Tools
Along the lines of the above thoughts on presentations, one of the things about free and open source tools that are available is that they're out there...and that's the problem, they're out there.  Now, I'm NOT saying that we need to be inundating each other links to sites for tools...what I am saying is that we should take advantage of the sites that we do have available for linking to the tools, as well as providing use cases and success (or failure) stories regarding these tools.

For example, with the ForensicsWiki site already available, we also have ForensicArtifacts.com site.  One of the benefits of conferences such as OSDFC is that, if you can attend, you can find out about tools that perhaps you didn't know about, and see how someone has used them to achieve a goal or overcome an obstacle in their investigation.

So...there are some great tools out there and available, but we need more folks within the community to pass along their impressions and encounters with the tools.  It's great that we have folks within the community who blog, but very often, what's posted is missed because most of us either don't know about their blog, or simply don't have time to keep up with our RSS feeds.  There needs to be a way to make this information available without having to wait for, or attend a conference.

CyberSpeak
Ovie's back with a new CyberSpeak podcast, which includes an interview with the Kyrus Tech guys regarding their Carbon Black product.  If you've never heard of Carbon Black, you should really take a listen to the interview and hear how the tool is described.  I've looked at Cb, but any description I could provide wouldn't do justice to the interview.  Great job to Ovie for yet another great podcast, and the Kyrus Tech guys for the interview and the information about Cb.