Talking with a colleague the other day reminded me of just how nuanced many of the forensic artifacts are that we rely upon. Nowhere is this more true than in the Windows Registry. With no specification and even Microsoft products not following any data storage methodology, it is about as haphazard and irregular as they come. As an example, let's look at the OpenSaveMRU and LastVisitedMRU Registry keys. Both have been documented for years and are frequently cited in examinations. That being said, I would bet many examiners have not investigated the keys deeply enough to understand everything they are telling us. Here is a quick rundown on what we can glean from these keys.
In simplest terms, this key tracks files that have been opened or saved within a Windows shell dialog box. This happens to be a big data set, not only including web browsers like Internet Explorer and Firefox, but also a majority of commonly used applications. What sometimes gets missed is that this key is also responsible for tracking auto-complete terms for that same dialog box. We'll see why that matters in a moment.OpenSave Dialog Autocomplete Example
The key is located at HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDIg32\OpenSaveMRU (OpenSavePidlMRU in Vista/Win7) and contains values and multiple subkeys. The values stored in the key itself are items that do not have file extensions associated with them. Since most files have extensions, what often ends up here is auto-complete information. Consider an OpenSave dialog box that allows you to choose your file type from a list (e.g. .jpg, .png, .bmp). User input into this dialog will typically be the name of the file without the extension, since the dropdown filetype menu takes care of that. Thus what is stored in the key is the auto-complete information for that transaction, and the full filename is not stored.
The possibility for a large number of subkeys exist within the OpenSaveMRU key. All but one of these correspond to various file extensions and store full path information for files of that extension that have been opened or saved. The one outlier is the * subkey. This key tracks the last ten files of any extension (including no extension) that have been input into the OpenSave dialog. Vista and Win7 appear to have extended the * subkey to track the last twenty files and are now using binary instead of string format. Each subkey keeps its own Most Recently Used (MRU) list and last write time.
This key is a little simpler, but often misunderstood. It is located at HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDIg32\LastVisitedMRU (LastVisitedPidlMRU in Vista/Win7) and tracks the specific executable used by an application to open the files documented in the OpenSaveMRU key. In addition, each value also tracks the directory location for the last file that was accessed by that application. Data is stored in binary format. Ever wonder how an application remembers where you last opened a file from? This key is used by the OpenSave dialog box to show the last directory used by that application when you are attempting to open or save a file. It keeps its own MRU list and last write time.LastVisitedMRU ValuePutting It All Together
While checking my work via online resources, I was surprised at how little usable documentation exists. Kudos to Harlan Carvey for documenting a large number of registry keys, but weeding through thesis papers, forum posts, and Google Books results just isn't efficient for very specific, nuanced artifacts like these. What would really be ideal is a collaborative environment like a wiki. As luck would have it, our community already has a Forensics Wiki. After years of encouraging students to contribute, I am proud to say that I finally signed up for an editor account, and I am looking forward to collaborating on these keys (and others) there.
Chad Tilbury, GCFA, has spent over ten years conducting computer crime investigations ranging from hacking to espionage to multi-million dollar fraud cases. He teaches FOR408 Windows Forensics and FOR508 Advanced Computer Forensic Analysis and Incident Response for the SANS Institute. Find him on Twitter @chadtilbury or at http://ForensicMethods.com.