Wednesday, 10 October 2012

SANS Forensic Artifact 1: Open/Save MRU

As most of you would have seen by now SANS posted a fantastic forensic poster for everybody to use which will "map a specific artifact to the analysis question that it will help to answer". Basically what that means is that SANS have 8 categories used to determine an analysis question. "Was the file opened?" for example an analyst could review the 'File Opening / Creation" category which will show artifacts that assist in determining whether files were opened.

We already know there are a number of tools available to us that can easily rip this information to us, such as RegRipper, and countless articles written about each of the artifacts listed. I find however that if you're purely reviewing the output of the tools to identify that a file was opened or that a file had executed in some way you may be missing the context in how that file was opened. Security analysts must ensure they have the technical understanding for each of the tools they run to ensure they can explain the prescence of an artifact, or lack thereof, listed within the output of their tools.

So I thought for my own benefit I'd create a series of blog posts going through each of the forensic artifacts and hopefully providing some examples with screenshots on how each artifact is created. Again there is no better way to understand these tools then running it across your own workstation where you understand exactly what you've done to complete that action. So with that being said lets take a look at the first artifact SANS lists within the File Download category: Open/Save MRU.

SANS lists the following information within the poster.

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.
XP NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSaveMRU
Win7 NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePIDlMRU
• The “*” key – This subkey tracks the most recent files of any extension input in an OpenSave dialog

• .??? (Three letter extension) – This subkey stores file info from the OpenSave dialog by specific extension

So how can we test the information we've been presented with above. The best and simplest way is create a text file called SANS_ForensicArtifact1_MRU_1.txt  and SANS_ForensicArtifact1_MRU_2.txt and open one of them within notepad through the Windows shell dialog box and open another just by double clicking and letting the associated application open the file. We should note the differences in this key from before and after snapshots.

There were a number of ways to export the user hive from my current workstation I decided to leverage of one of my previous posts by using hobocopy to rip it from my live machine. You could use tools such as the built in regedit.exe,  simply run a reg save query from the command line or even use a tool such as ftkimager to get this information.

I ran the following first so that  I could have a comparison. Please note there are two separate commands in the dialog box below.

FOR /F "tokens=*" %%G IN ('dir /b ^"C:\Documents and Settings\*^"') DO .\tools\hob\hobocopy.exe "c:\Documents and Settings\%%G" .\hives\%%G NTUSER.DATregripper command:rip.exe -r ..\..\hives\username\NTUSER.DAT -f ntuser >> username.txt

I searched the output of regripper for OpenSaveMRU and currently it only listed documents that I'd open previously.

Important to note that  from the above example the first key is for objects opened that do not have an extension. The SANS reference below indicates the following "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".

The '*' key indicates the last 10 files opened through the windows dialog box regardless of the extension it has. This can assist us with determining the opening order of each of those 10 files listed. Finally there is a key for each of the extensions opened and in this case we are only concerned with the txt so that we can use our example above. Lets open our file created above and I'll also open a secondary location with a file that has no extension in c:\blogmrulocation\test_noext

As you can see from the screenshot I've opened the file named SANS_ForensicArtifact1_MRU_1.txt. I also opened the file with no extension. For compasion I also double clicked on SANS_ForensicArtifact1_MRU_2.txt (i.e. did not open through windows dialog box) so that we have a  comparison to work with.

Lets run the script again to dump my hive and process it with regripper.

As we can see the only files listed are the ones that we opened through the windows dialog box and there is nothing currently listed for SANS_ForensicArtifact1_MRU_2.txt. As I ran the RegRipper plugin with the -f ntuser option selected it will parse my ntuser.dat file against a number of different plugins and enter the output in the same text file. I decided to search for the second file opened through double click to see where we had references for it.

Although the above keys have nothing to do with my current post (although we'll hit on them later) its important to note that our actions have modified another area within the system so now we not only understand how to review items opened within the windows dialog but we also have some clues how we can identify items not opened by the dialog.

None of this information above is rocket science by any means and as listed from the SANS reference below the information has already been provided by Chad Tilbury who has written an excellent article on these registry keys. What I do hope to provide to you from this is post is some practical examples and comparisons between what we saw before and what we saw after the files were open. The next time we run the tool rather than accepting the output for what it is we'll have a deeper understanding and hopefully revert back to our example to assist with better understanding and gathering context to an incident where we do not have the luxury of understanding how or why a file was opened and therefore need to piece our view of the world back together.



  1. Cool post. That's a great idea for a series of posts. Keep it up!

    1. Thanks Patrick I appreciate the feedback and I'm really enjoying your posts also.

  2. Excellent post. I think that in too many cases, analysts are running the tools and accepting the output without really understanding the nature of what it's telling them...

    1. Many thanks Harlan, always appreciate your feedback. The above post is a result of listening to your advice/wisdom.

  3. ditto!!! what a cool idea for blog articles. i'm gonna keep my eye on this place!