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