Friday, March 8, 2013

Windows 8: Tracking Opened Photos

One of the many new features of Windows 8 is a new stock photo viewing application called Photos.  With the inclusion of a new photo viewer comes the creation of new artifacts resulting from its use. Specifically, I've found that the Windows 8 Photos app stores usage history information within a user's UsrClass.dat registry hive.  Buried within this hive is a wealth of information about files that have been viewed using Photos (specifically by double-clicking an image).  By "wealth of information", I mean information about each file viewed using the Photos app.  This includes the file name, path to the image file, timestamps associated with the image file, the last time the file was viewed using Photos, the type of device from which the file was opened, and more.

Based on my research, if an image file has been opened using the Photos app via double-clicking the file in Explorer, a subkey named using a {GUID} value will be added to the "Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\microsoft.windowsphotos_8wekby3d8bbwe\PersistedStorageItemTable\ManagedByApp" subkey located in the user's UsrClass.dat hive. The screenshot below is a depiction of the values and value data from a ManagedByApp\{GUID} subkey as viewed with regedit.


Based on my research, each {GUID} subkey beneath the ManagedByApp subkey corresponds to an image that has been opened using the Photos app and includes six values.  The table below includes information about each value located within one of these {GUID} subkeys.

Value Name
Value Type
Value Data
FilePath
REG_SZ
Full path to the file
Flags
REG_DWORD
Appears to relate to the media type from which the image was opened
LastUpdatedTime
REG_BINARY
64-bit FILETIME value; appears to reference last time the file was opened
Link
REG_BINARY
Variation of Windows LNK file [MS-SHLLINK]
Metadata
REG_SZ
Holds the name of the file
PackageFamilyName
REG_SZ
microsoft.windowsphotos_8wekyb3d8bbwe

File Path Value
If you guessed that the FilePath value data includes the path to the image file, you'd be correct.  Based on my testing, the full path (including drive letter) is included in this data if the image file was opened from the C:\ drive, external hard drive, or network share.  If the image file was opened from a flash drive, the volume GUID is listed instead of the drive letter (e.g. \\?\Volume{D729662E-868D-11E2-BE69-000C29930361}\file1.jpg).  The inclusion of the volume GUID here will allow an examiner to corroborate this data with information from the MountPoints2 subkey of the user's NTUSER.DAT hive as well as the MountedDevices subkey from the SYSTEM hive.  The drive letter assigned to the media where the file was stored can also be found in the Link value data within the same {GUID} subkey.

Flags Value
The Flags value data appears to relate to the type of media from which the image file was opened.  Based on my testing, a flag value of 13 (0x0000000D) indicates that the image file was located on the internal C:\ drive at the time it was opened.  A flag value of 9 (0x00000009) is assigned when the image file is opened from some type of external media (such as a flash drive or external hard drive), including network shares. This should be easy to verify by checking the FilePath value data (or the Link value data) stored in the subkey.

LastUpdatedTime Value
The LastUpdatedTime value data is a 64-bit FILETIME value and appears to be updated each time the image file referenced by the {GUID} subkey is opened using the Photos app.  Since this value is updated each time the image file is opened, the LastWrite time of the {GUID} subkey to which this value belongs is also updated.  In my [fairly limited] testing, I have yet to come across a case where the LastUpdatedTime value data is different than the LastWrite time of the {GUID} subkey to which the value belongs.  

Link Value
With the exception of the first 16 bytes, the Link value data appears to follow the MS-SHLLINK file format (see this document provided by Joachim Metz for more info on this format).  The first 16 bytes of the Link value data appear to hold the LNK class identifier and are the same as bytes 20-35 of the value data (where one would expect to find the LNK class identifier based on the MS-SHLLINK file format).  After the first 16 bytes, we can find much of the same useful information here as would expect to find in Windows shortcut files (target file timestamps, full path to target file, etc.).  The value data alone provides a great deal of insight into the opened file.  

Forensic Implications 
Using the values from these {GUID} subkeys related to the Windows 8 Photos app, an examiner can determine not only what files were viewed using the app, but also the last time each file was viewed, the type of device from which each image was viewed, the path to each file, timestamps associated with each image, and much more.  This information can be used to track user activity surrounding image files, corroborate USB device activity found in other locations, as well as provide useful timestamps for inclusion within a timeline.  A RegRipper plugin or otherwise some other means of quickly harvesting this information will need to be written (it's on my TODO list unless someone beats me to it), but knowledge of these artifacts will be important when examining a Windows 8 machine (particularly when image files are of interest).  

As an aside, I have yet to determine if there is a maximum to the number of {GUID} subkeys created before they begin to be cycled out, but I have populated more than 200 subkeys without the oldest entry being removed.  This indicates that an examiner may encounter a large number of these subkeys during an investigation, depending on how often the user views images using the Photos app.  Additionally, this information does not appear to be removed when the user clears their app usage history (using any of the stock options that I've tried to date).  

3 comments: