Motivations behind the Forensic Scanner

At the recent OSDFC, I presented on and announced the release of the Forensic Scanner.

Since then, I've been asked to talk about things like the motivations behind the development of the Scanner, and what need I was trying to fill by creating it.  At the conference, shortly after my presentation, it was suggested to me that I should talk about what's different about the Scanner, how it's different from the other available frameworks, such as Autopsy and DFF.

One of the reasons I wrote the Scanner (and this applies to RegRipper, as well) is that over the years of performing analysis, I've found that as I've maintained a checklist of things to "look for" during an exam, that checklist has grown, become a spreadsheet, and continued to grow...but no matter how well-organized the spreadsheet is, it's still a spreadsheet and doesn't help me perform those checks faster.  If I have preconditions (something else that needs to be checked first) listed in the spreadsheet for a specific check, I have to go back into the image, do the initial check, and then see if the conditions have been met to perform the check I have listed in that row in the spreadsheet.

One good example of this is the ACMru Registry key in Windows XP.  This key can exist within the user's NTUSER.DAT hive, and illustrates what the user searched for on the system.  With Windows Vista, indications of the user's searches were moved out of the Registry, and with Windows 7, they were added back into the Registry, into the WordWheelQuery key.  So, if you wanted to see what a user had searched for, you had to first check the version of the Windows operating system (the "precondition"), and then refer to the checklist and follow the appropriate path to the Registry key for that particular platform.

All of this can be hard to remember over time, and this is true not only for someone who performs a good deal of research into the Windows Registry.  Imagine what this would be like for someone who doesn't spend a great deal of time analyzing Windows systems in general.  The fact is that even with an extensive checklist or spreadsheet, this still requires a good deal of time and effort to maintain, as well as to engage.  After all, you can't just lay a spreadsheet over your acquired image and have all the answers pop up...yet, anyway.  An analyst has to actually sit down with the checklist and the acquired image and do something.

The plugins used by the Forensic Scanner, like those used by RegRipper, can be as simple as you want them to be.  For example, with RegRipper, you may not want to look for specific values in the the Run key, because malware names and paths can change.  As such, you may want to dump all of the values in order to present them to the analyst.  You can also perform a modicum of analysis by grepping for terms such as "temp", to find any executables being launched from a temp directory (i.e., "Local Settings\Temp", or "Temporary Internet Files", etc.).  The plugins used by the Forensic Scanner can do something very similar.  For example, remember the ntshrui.dll issue?  You can write a plugin that specifically checks for a file with that name in the Windows directory, or you can write a plugin that dumps a list of all of the DLLs in the Windows directory, and either apply a whitelist ("these are the known good files"), or a blacklist.

Note: The above paragraph is intended as an example, and does not indicate that current RegRipper plugins will work with the Forensic Scanner.  They won't.  A small amount of work is necessary to get the current RegRipper plugins to work with the Forensic Scanner.

Here's another good example...ever seen these blog posts?  Do they make sense?  How would you check for this?  Well, I'd start with a plugin that parses the shell item ID lists of all of the LNK files on the user Desktop, and compares those elements to the ASCII in the LinkInfo block, if there is one.  You could then extend this to the Recents folder, and because it's all automated, it will be done the same way, every time, no matter how many user profiles are on the system.

A final example...Corey Harrell reached to me a bit ago, asking me to create a plugin for a couple of Registry keys (discussed here, in an MS KB article).  I did some looking around and found this valuable blog post on the topic of those keys.  The Order values beneath the subkeys in question contain shell item ID lists, much like the values found in the ShellBags, as well as ComDlg32 entries.  The linked blog post explains that the Order values often contain references to items the user explicitly selected, even after the application or resource has been deleted.  As such, why not include this in every scan you run...who knows when something of critical value to your examination is going to pop-up?  Most of us are aware that the one time we don't check these Registry keys will be the time that critical information is found to reside within the keys.  So...write the plugin once, and run it with every scan, automatically; if you don't need it, ignore it.  However, if you do need the information, it's right there.

One of the motivations for this sort of automation is to bridge a critical gap and get more organizations to perform root cause analysis, so that they can develop the necessary intelligence they need to properly defend themselves.  Right now, many organizations will react to an apparent compromise or infection by wiping the system in question, and trying to address all of the vulnerabilities that are out there..that is, if they do anything at all.  However, if they performed a root cause analysis, and determined the initial vector of compromise or infection, they could provide an intelligence-driven defense, reducing and optimizing their resources. One of the reasons for this sort of reaction may be performing a root cause analysis takes too long...the Forensic Scanner does not obviate analysis; rather, it is intended to get you there faster.

I understand that the idea of the Forensic Scanner is outside what most would consider "normal" thinking within the community.  This is also true for RegRipper, as well as Timeline Analysis.  The idea is not to obviate the need for analysis...rather, it's to get analysts to the actual analysis faster.  After all, tools like RegRipper and now the Forensic Scanner will extract in seconds what currently takes an analyst hours or even days to do.

NOTE: In order to run the Scanner, you'll want to either disable UAC on your Windows 7 analysis system, or right-click on the program icon and choose "Run as administrator". 

Finally, it appears that the Forensic Scanner is already making it's rounds at least one conference.  Also, the Forensic Scanner was designed to work with F-Response, and Matt Shannon has a blog post indicating that F-Response + Forensic Scanner = Awesome!