Monday, February 17, 2014

More Tracking User Activity via the Registry

I have previously posted on the topic of determining a user's access to files, and thanks to Jason Hale's recent post on a similar topic (i.e., MS Word 2013 Reading Locations), I got interested in the topic again.  I was interested in seeing if there were any similar artifacts available for other MS Office apps, such as PowerPoint or Excel.  I exchanged a couple of emails with Jason, and ran a somewhat simple, atomic test  to see what artifacts might be available.  Jason took a different approach to testing than I did...he used ProcMon on a live system, whereas I ran my test, pulled the pertinent hive files off of the system and created a timeline.

Based on Jason's testing with MS Word, I wanted to see if a user were to open a PowerPoint presentation, get partway through it and close the application, would PowerPoint make some record of which slide was last in focus when the app was closed.  Jason ran a test or two of his own, and shared with me that he found some very interesting information beneath the following key:

HKCU\Software\Microsoft\Office\15.0\Common\Roaming\Identities\Anonymous\Settings\1076\{00000000-0000-0000-0000-000000000000}\PendingChanges\

I ran my own tests, using MS Office 2013 installed on Windows 8.1.  I plugged in a thumb drive (mounted as G:\) and double-clicked a PPTX file in the root of that volume (file named "shell items.pptx").  Once the presentation was open, I clicked on the third slide, and then closed the application, launched FTK Imager on the system, copied off the NTUSER.DAT and USRCLASS.DAT hives for the user account, and shut the system down.  I moved the thumb drive to my analysis system and created a timeline of the key LastWrite times from the hives...only to find that changes hadn't been written to the hives.  So, I booted the Win8.1 system again, copied off the hives again, and repeated the process, and was able to see what I was looking for.

First, I had used my Live ID account when logging into the system, so the path to the PendingChanges subkeys was a bit different from what Jason found:

HCKU/Software/Microsoft/Office/15.0/Common/Roaming/Identities/c4d2c8d78e44cf84_LiveId/Settings/1076/{00000000-0000-0000-0000-000000000000}/PendingChanges/dafbbe5e/22434

Beneath this key are several values, including one named "ItemData" that appears to contain XML-like contents, in Unicode format, in the binary value data.  Another value, "LastModified", has data that appears to be a SystemTime structure.

I had incorporated details from the UserAssist data from the hive into the timeline, and as such, I could see in the timeline where that data marked the start of the artifacts I had hoped to see.  For example, within the same second in the timeline, I could see the UserAssist data illustrating that PowerPoint had been launched, as well as an entry beneath the RecentDocs\.pptx key being created, pointing to the file "shell items.pptx".

I also found values beneath the HCKU/Software/Microsoft/Office/15.0/PowerPoint/User MRU/LiveId_blah/File MRU and Place MRU keys that were very useful.  Specifically, both keys had values named "Item 1" with data that pointed to the resource in question.  For the File MRU key, the "Item 1" value data was:

[F00000000][T01CF2BE8F8E1FA40][O00000000]*G:\shell items.pptx

The Place MRU "Item 1" value data was similar, but only pointed to "G:\".  Notice the "T" value in the brackets...that's a FileTime structure that correlates to the time of the access to the file...in this case, 17 Feb 2014 at approx. 14:03:02 UTC.

A couple of things to note at this point:

1.  This really illustrates what I've been saying for some time; that as the versions of Windows have increased over the years, more information is being recorded and maintained with respect to user activity, particularly within the Registry.  These artifacts are based solely on the Registry; the file system is likely to have additional artifacts, such as Jump Lists, that can provide even more context and visibility into user activity.

2.  This was an atomic test...I performed one action and collected data to see what changes occurred.  We all know that DFIR work never occurs this way; in fact, most often, we may not get access to the data for weeks or months after the activity in question occurred.  As such, you should not expect the artifacts to appear exactly as described in this post.

3.  The available findings are based on extremely limited testing and data; more testing and data means better results.