I've posted regarding my thoughts on a Forensic Scanner before, and just today, I gave a short presentation at the #OSDFC conference on the subject.

Rather than describing the scanner, this time around, I released it.  The archive contains the Perl source code, a 'compiled' executable that you can run on Windows without installing Perl, a directory of plugins, and PDF document describing how to use the tool.  I've also started populating the wiki with information about the tool, and how it's used.

Some of the feedback I received on the presentation was pretty positive.  I did chat with Simson Garfinkel for a few minutes after the presentation, and he had some interesting thoughts to share.  The second was on making the Forensic Scanner thread-safe, so it can be multi-threaded and use multiple cores.  That might make it on to the "To-Do" list, but it was Simson's first thought that I wanted to address.  He suggested that at a conference were the theme seemed to revolve around analysis frameworks, I should point out the differences between the other frameworks and what I was presenting on, so I wanted to take a moment to do that.

Brian presented on Autopsy 3.0, and along with another presentation in the morning, discussed some of the features of the framework.  There was the discussion of pipelines, and having modules to perform specific functions, etc.  It's an excellent framework that has the capability of performing functions such as parsing Registry hives (utilizing RegRipper), carving files from unallocated space, etc.  For more details, please see the web site.  

I should note that there are other open source frameworks available, as well, such as DFF.

The Forensic Scanner is...different.  Neither better, nor worse...because it addresses a different problem.  For example, you wouldn't use the Forensic Scanner to run a keyword search or carve unallocated space.  The scanner is intended for quickly automating repetitive tasks of data collection, with some ability to either point the analyst in a particular direction, or perform a modicum of analysis along with the data presentation (depending upon how much effort you want to put into writing the plugins).  So, rather than providing an open framework which an analyst can use to perform various analysis functions, the Scanner allows the analyst to perform discrete, repetitive tasks.

The idea behind the scanner is this...there're things we do all the time when we first initiate our analysis.  One is to collect simple information from the system...it's a Windows system, which version of Windows is it, it's time zone settings, is it 32- or 64-bit, etc.  We collect this information because it can significantly impact our analysis.  However, keeping track of all of these things can be difficult.  For example, if you're looking at an image acquired from a Windows system and don't see Prefetch files, what's your first thought?  Do you check the version of Windows you're examining?  Do you check the Registry values that apply to and control the system's prefetching capabilities?  I've talked with examiners who's first thought is that the user must have deleted the Prefetch files...but how do you know?

Rather than maintaining extensive checklists of all of these artifacts, why not simply write a plugin to collect what data it is that you want to collect, and possibly add a modicum of analysis into that plugin?  One analyst writes the plugin, shares it, and anyone with that plugin will have access to the functionality without having to have had the same experiences as the analyst.  You share it with all of your analysts, and they all have the capability at their fingertips.  Most analysts recognize the value of the Prefetch files, but some may not work with Windows systems all of the time, and may not stay up on the "latest and greatest" in analysis techniques that can be applied to those files.  So, let's say that instead of dumping all of the module paths embedded in Prefetch files, you add some logic to search for .exe files, .dat files, and any file that includes "temp" in the path, and display that information?  Or, why not create whitelists of modules over time, and have the plugin show you all modules not in that whitelist?

Something that I and others have found useful is that, instead of forcing the analyst to use "profiles", as with the current version of RegRipper, the Forensic Scanner runs plugins automatically based on OS type, class, and then organizes the plugin results by category.  What this means is that for the system class of plugins, all of the plugins that pertain to "Program Execution" will be grouped together; this holds true for other plugin categories, as well.  This way, you don't have to go searching around for the information in which you're interested.

As I stated more than once in the presentation, the Scanner is not intended to replace analysis; rather, it's intended to get you to the point of performing analysis much sooner.  For example, I illustrated a plugin that parses a user's IE index.dat file.  Under normal circumstances when performing analysis, you'd have to determine which version of Windows you were examining, determine the path to the particular index.dat file that you're interested in, and then extract it and parse it.  The plugin is capable of doing all of that...in the test case, all of the plugins I ran against a mounted volume completed in under 2 seconds...that's scans of the system, as well as both of the selected user profiles.

So...please feel free to try the Scanner.  If you have any questions, you know where to reach me.  Just know that this is a work-in-progress, with room for growth.

Addendum
Matt Presser identified an issue that the Scanner has with identifying user profiles that contain a dot.  I fixed the issue and will be releasing an update once I make a couple of minor updates to other parts of the code.

I had the honor and privilege of speaking at OSDFC yesterday, and wanted to provide something of a follow-up or review of how the conference went.  But first, I want to thank everyone involved in setting up and arranging the conference, as well as presenting and even just attending the conference, for making this event a real success.

This is the second time that Brian has had the conference, which is held in conjunction with a conference put on by his company, Basis Technology, for their government customers.  This year, Brian said that there were about 160 attendees, and from what I saw, we had folks from different parts of the DFIR community...private industry, public, LE, etc.  There were even international speakers and attendees.

The format of the conference was to have a series of talks in the morning, and then split off into two tracks after lunch.  After three presentations in each track, we went back to everyone meeting in one room for another presentation (from Cory Altheide), finishing up with several lightning talks.  This seemed to work very well, but having been to several conferences over the years, any presentation that's longer than 20-30 minutes and doesn't directly engage the audience is going to hit a bit of a slow-down right around the 30 minute mark.  At the end of the conference, Brian did ask some questions with respect to the format for the next year's conference, and I'll return to some thoughts on that at the end of the post.

Rather than going over each presentation that I attended individually, I want to say that they were all excellent, and I want to thank everyone...presenters as well as the organizers...for the time and effort they put into this conference.  Also, one of the things that really make these conferences a success and is often overlooked is the people within the community who, while not presenting, come to attend the conference.  Being able to interact with your peers in the community, engage and exchange ideas (or even just some jokes) is one of the biggest benefits of events like this...so a huge thanks to everyone who drove or flew in to attend the conference!  

During the conference, there were a number of presentations that mentioned JSON, from Jon Stewart discussing scripting with the TSK tools, all the way through to Cory's "Making it Rain" presentation, where he talked about browser artifacts (and we all sang "Happy Birthday" to his daughter!).  So, for what it's worth, this is likely going to be part of a LOT of examinations.

As I attended various presentations, it occurred to me that the common theme of the presentations seemed to be, "I had a problem and here's how I solved it with open source tools".  Now, this isn't specifically about using an open source tool that is already available, although there were a number of presentations that did just this (Cory Altheide of Google, and Elizabeth Schweinsberg, soon to be of Google).  There were other presentations (my own, etc.) that discussed creating something open source to solve a problem.  Like Brian said, last year's conference was a "call for frameworks", and this year's conference was an answer to that call, as a number of frameworks were described.

Now, conference format.  While I have an academic background (I earned my MSEE from NPS), I'm more of a practitioner or engineer.  There seem to be two types of folks who are drawn to conferences like this...practitioners and academics.  Now, I'm not presenting this as a division within the community, because...well...I don't see it that way.  To be honest, we need both within the community.  At the conference, we had presentations from academics who were looking at solving some pretty big problems, and I was very thankful to see them taking this on.  I really think that there is a lot of benefit in doing so.  However, when it comes to how the presentation is viewed, practitioners and academics look at things differently.  Academics ask questions about testing corpus, parallelization, and will the application scale from 4 to 64 processors.  Practitioners ask, how soon can I get this application, and will it run on the system(s) that I have in my lab?

So...Brian took a vote at the end of the conference, asking the attendees what they thought about the format for next year.  I have to say that given who attends this type of conference, it would probably be best to keep the two-track format...have a developer's track, where developers and academics can discuss developer stuff.  Keep the practitioner's track, but you don't have to keep it separate...there may be very good reason to have a developer present in both tracks, including giving a more practitioner-oriented presentation to the guys and gals in the trenches.  I think that it's important that we all come together at an event like this, even if we don't all mix all the time.

So, I'm going to throw my hat into the ring for two tracks and shorter, more narrowly-focused presentations.  I think that the shorter presentations will allow for more of them, and focusing them a bit more probably wouldn't be all that hard.

Something else that I think would be hugely beneficial is something like Cory's presentation from the first conference, where he just ran through a list of open source tools and projects, and how they were useful.  There are sights out there to maintain information like this, but they don't seem to be regularly maintained to any significant degree.  For example, there's Open Source Forensics, as well as ForensicsWiki, but as a community, I think we need to come together and come up with a way to bring all of this information together.  That aside, however, while various open source projects were discussed, there are a number of others out there that would be beneficial to many examiners, if they knew about them.  Now, this doesn't have to be a presentation, as it can be a web page or entries at one of the sites above...but I think what really gets folks over the hump regarding using this stuff is recommendations from others.

Another benefit of this conference that I hadn't realized is the reach of open source tools.  Within the US, we have various institutions, ranging from large private, academic and governmental organizations, to local community colleges and law enforcement shops.  We can all benefit from open source projects, but the smaller organizations are limited in background knowledge, training, etc.  Joshua James opened my eyes to the fact that this is an international issue...that LE in Ireland is limited by funds, as are LE in Africa.  Joshua mentioned a department in Africa that has 4 staff members and a total of 2000 Euro available annually for training, hardware, etc.  This opened me up to the need not only for open source tools that meet the needs of these departments, but to the need for free, easily available training for knowledge transfer as well as how to use the tools and really get the most out of them.

Stuff
Simson's bulk-extractor
Cory's write-up and insights on OSDFC