SANS Digital Forensics and Incident Response Blog

SANS Digital Forensics and Incident Response Blog

OpenSaveMRU and LastVisitedMRU

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.

OpenSaveMRU

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


OpenSave Dialog Autocomplete

The key is located at HKCU&#092Software&#092Microsoft&#092Windows&#092CurrentVersion&#092Explorer&#092ComDIg32&#092OpenSaveMRU (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.

LastVisitedMRU

This key is a little simpler, but often misunderstood. It is located at HKCU&#092Software&#092Microsoft&#092Windows&#092CurrentVersion&#092Explorer&#092ComDIg32&#092LastVisitedMRU (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 Value


LastVisitedMRU Value

Putting It All Together


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

6 Comments

Posted April 02, 2010 at 8:56 PM | Permalink | Reply

H. Carvey

Thanks for a great post, Chad. I'm going to update the ComDlg32.pl plugin to RegRipper to support both XP and Vista subkeys, and then release it.

Posted April 07, 2010 at 11:42 AM | Permalink | Reply

fifth.sentinel

<strong>Registry Data for Forensics, Incident Response, Pentest and Pivot Part&nbsp;2...</strong>

Location HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSaveMRU Description of Keys The Windows Operating System uses a common feature to help applications track and determine what content access requests (e.g. Files) has m...

Posted June 24, 2011 at 4:32 PM | Permalink | Reply

Rune Nordvik

The OpenSavePidlMRU in W7 seams to use PIDLs (Pointer ID Lists) to save which files has been opened or saved and more. The first BYTE or WORD describe the length of the PIDL, the next DWORD describe the type of PIDL. But the content structure is variable. Some PIDL has strings in Unicode, others in ASCII, and there are some as far as I can see with unknown structures. Have you seen this? And do you know how to parse the unknown structures?

One of the PIDL with unknown structures looks like this:

14001F580D1A2CF021BE504388B07367FC96EF3C

Posted June 28, 2013 at 1:58 PM | Permalink | Reply

Michael G.

In addition to the key LastVisitedPidMRU, There was also a key called LastVisitedPidMRULegacy in the on a Win 7 machine. It contained a list of 7 applications. Anyone familiar with this key?

Posted June 28, 2013 at 2:57 PM | Permalink | Reply

Michael G.

I used RegRipper v2.8 with comdlg32 v20121008 to parse an ntuser.dat file from a Win 7 machine. The resulting report for the OpenSavePidMRU\*, \docx, \jpg and \pdf entries contained files described as "Libraries" but the other files were properly listed. When I viewed the key using registry viewer, those files labeled in the regripper output as "Libraries" were found to actually be listed as follows:

For OpenSavePidMRU\*:
C:\Users\\Pictures\imagesCAWGOQ84.jpg
C:\Users\\Pictures\imagesCAOIJB1X.jpg
C:\Users\\Pictures\imagesCA5EXBTC.jpg
C:\Users\\Documents\sales.docx
C:\Users\\Documents\Walkways 2 pg_3.jpg

For OpenSavePidMRU\docx:
IT_Resume.docx
C:\Users\\Documents\sales.docx
C:\Users\\Documents\Receipt No 1001.docx

For: OpenSavePidMRU\jpg:
C:\Users\\Documents\Walkways 2 pg_3.jpg
C:\Users\\Pictures\imagesCA5EXBTC.jpg
C:\Users\\Pictures\imagesCA0IJB1X.jpg
C:\Users\\Pictures\imagesCAWGOQ84.jpg
C:\Users\\Pictures\imagesCAQIJY3M.jpg
C:\Users\\Pictures\imagesCAMPVG6T.jpg
C:\Users\\Pictures\images.jpg
C:\Users\\Pictures\imagesCAP3GIH1.jpg
C:\Users\\Pictures\imagesCAP25MGJ.jpg

For: OpenSavePidMRU\pdf:
C:\Users\\Documents\Receipt No 1001.docx

Does anyone know why regripper is reporting the above files and file paths simply as "Libraries"?

Posted June 30, 2013 at 10:51 PM | Permalink | Reply

Chad Tilbury

I was going to recommend you submit a bug report to the RegRipper code page (https://code.google.com/p/regripper/issues/list), but it looks like you already have! This is a great example of why it is important to double-check important artifacts in cases.

Post a Comment






Captcha

* Indicates a required field.