There are a plethora of keys in the Registry dedicated to telling you where you’ve been. Known as MRU (Most Recently Used) keys, they provide that little bit of history you get in the File menu of certain apps or in the drop-down box where you are specifying a name to open/save a file. Very convenient for users; extremely useful for forensics exams. The MRU keys provide a window into the actions of the users on the system, sometimes even recording illicit activities that the user didn’t realize would be recorded. Here are several types of MRU lists:



We will save shellbags for a separate post because they are a bit particular and involved in what they do and how they do it, but I want to mention them here because they are full of Binary MRUs. Windows uses these to remember the window size and position, the view (list, details, etc), and other user preferences regarding the presentation of a folder. In forensics, they become an indicator that a folder was viewed and what was in that folder. See Willi Ballenthin’s write up for more info.


String MRUs and Binary MRUs

These two types operate basically the same way, but with different data structures. It goes something like this. A user opens file1.txt and an entry gets put into an MRU list. The user opens file2.txt and another entry to the list. The user then opens file1.txt again so we move that back to the top of the list. We don’t want to rewrite the entire list every time, so instead we maintain an index that tells us the order we should display the items. We must process this index in order to get the order correct. It is easy to assume that the order they are physically listed indicates the order they were first opened, but that isn’t always the case. Most of these lists have a max number of entries. When that max is exceeded, the next new entry will overwrite the oldest entry. After a while and given enough new and resused uses, the physical layout could end up rather random.

The structure of a String list is for the key to contain a series of REG_SZ string values that are named “a”, “b”, “c”, through “z” as they get created. The data in each value will be the command or file used saved as an ASCII string. There will be a REG_SZ string value named “MRUList” whose data is a string of ASCII letters indicating the order the values should be presented, with the most recent on the left and the oldest at the end of the string to the right. Some notable MRUs that use this format are…

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Map Network Drive MRU

The structure of a Binary list is with the key containing a series of REG_BINARY binary values that are named “0”, “1”, “2”, “3”, and so on. The data for each value depends on the function of the list. They frequently contain Unicode strings. There will a REG_BINARY value named “MRUListEx” whose data is a series of Uint32 4-byte integers stored in little endian. The value names end up being the integer value in decimal (e.g. “24”) whereas the “MRUListEx” is presented to us in hex (e.g. “18 00 00 00”), so the ability to easily slip between numbering systems is key. Just like with the string MRU’s index, the very first entry is the most recent progressing back in time as deeper offsets are read. The final entry in the list will be an end of whatever marker of “0xFFFFFFFF”. Some notable MRUs that use this format are…

HKCR\Local Settings\Software\Microsoft\Windows\Shell\BagMRU*
HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\BagMRU*

You can find more information here.


Office MRUs

Starting with Office 2010, that suite of tools uses a format for their MRU lists that I have not seen used outside this suite. The key will contain a series of REG_SZ string values that are named “Item 1”, “Item 2”, “Item 3”, and so on. The structure of each value’s data is as follows: A marker of “[F00000000]”, next is a time stamp in that looks like “[T<datetime>]” where the <datetime> is a hex string representing a win32 datetime in big endian, next is a marker of “[O00000000]*”, and last is an ASCII string of a full path and file name. For example…

[F00000000][T01CDC2FCC3BD6990][O00000000]*C:\Users\jdoe\Downloads\Sample Presentation.pptx

While this format has a significant advantage for forensics in that there is a time stamp associated with each entry. There is also a REG_DWORD value named “Max Display” that contains a number indicating the number of entries the application should display, but the actual list can grow well beyond this number.

The locations of some of these Office MRUs are…

HKCU\Software\Microsoft\Office\14.0\Excel\File MRU
HKCU\Software\Microsoft\Office\14.0\Excel\Place MRU
HKCU\Software\Microsoft\Office\14.0\PowerPoint\File MRU
HKCU\Software\Microsoft\Office\14.0\PowerPoint\Place MRU
HKCU\Software\Microsoft\Office\14.0\Publisher\File MRU
HKCU\Software\Microsoft\Office\14.0\Word\File MRU
HKCU\Software\Microsoft\Office\14.0\Word\Place MRU

You can find more information here.


Other MRUs

Any application can implement an MRU list and there is no law that says they have to do it in one of the above ways. Many applications have come up with their own ways to format and control these lists. Frequently, they don’t even include the string “MRU” in the scheme, making them a little harder for us to locate.

For example, the Adobe Photoshop suite of tools save their MRU as a series of keys named with a time stamp with each key containing a “(Default)” string value that contains the file opened at that time. Two examples of paths leading to a single entry in the MRU list for an Adobe product are…


Or the Nitro PDF Reader, which saves its recently opened files as a series of values named “File 1”, “File 2”, etc in the following location…

HKCU\Software\Nitro PDF\Reader\2.0\Recent File List