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.
Great post. Complements Jason's research nicely. This is the kind of research that the community needs, as it provides more locations to examine during an investigation. With so many new locations and artifacts being discovered, an end user will have a more difficult time destroying evidence or covering their tracks.
ReplyDeleteMore information being logged within the OS will serve forensic investigators well. I've said it a few times now, but MRUs can be pretty powerful, as this post and many other artifacts suggest...
Dan,
ReplyDeleteThanks for the comment.
This is the kind of research that the community needs...
Agreed. Like I said, I read Jason's blog post and got curious about what else was available...
Harlan,
ReplyDeleteGreat post. It’s interesting that the value data for Item 1, Item 2, etc. in the Office 2013 File MRU subkeys includes the third bracketed portion [O00000000]. I’m not sure whether it will have any significance during analysis since I’ve not seen a different value here, but this is an additional field/portion that isn’t found in the File MRU subkeys associated with previous versions of Office that I’ve looked at.
There’s definitely still a lot of work to do here though, both within the registry and, as you mentioned, other artifacts located in the file system. Office 2013 has introduced several new features that are bringing about some really interesting findings…
As always, really nice write up Harlan. Thank you for the great work you always do as one of the strong contributors that keep the digital investigative analysis profession advancing along.--Ovie, your older, uglier, shorter, not so smarter brother. ;)
ReplyDeleteThanks, Ovie, my brother-from-another-mother (which includes Sam Brothers, as well...)
ReplyDelete