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.
