Digital Forensics Stream
Findings, tips, and tools developed while trekking through the world of digital forensics

Archive for Windows 8

Posted by Jason Hale 
· February 4, 2015 
· No Comments

Leveraging the DeviceContainers Key

If you’ve ever examined registry artifacts related to a particular USB device, you’ve probably come across a value called “ContainerID”.  For example, a flash drive’s instance ID subkey of the USBSTOR key includes a ContainerID value.  Prior to Windows 8, a device’s Container ID was probably of little interest to an examiner. However, beginning with Windows 8, a device’s Container ID can be used to help profile a specific device and corroborate findings from other locations.  The CurrentControlSetControlDeviceContainers key of the SYSTEM hive on a Windows 8 machine holds a wealth of information, broken down by Container ID, about devices connected to the system.

Before dissecting the DeviceContainers subkey, it’s important to understand what a container ID represents in the first place.  Starting with Windows 7, container IDs were used to identify a physical device on the system.  This Windows Dev Center page describes a container ID as “a system-supplied device identification string that uniquely groups the functional devices associated with a single-function or multifunction device installed in the computer.”  This “system supplied identification string” is a GUID and is referenced in various locations, including the EnumUSBSTOR and EnumUSB subkeys of the SYSTEM hive, as the “ContainerID”.  One thing to keep in mind is that all physical devices should be assigned a ContainerID – not just storage devices.  This means that when digging into the DeviceContainers key, many of the devices listed may be something other than storage devices (e.g. monitors, external speakers, keyboards, etc.).

DeviceContainersContainerID subkey structure

The screenshot on the right is an example of what you might see when browsing a device’s DeviceContainers subkey.  The top node as well as the subkey to the BaseContainers key is named by the ContainerID value (the same one found in the USBSTOR key).  The Properties subkey contains eight different sets of…. well, properties.  The idea of useful information being found in a set of “Properties” subkeys is not new; Harlan blogged about the Properties subkeys within the USBSTOR key here and Yogesh Khatri wrote about it here as well.  This is a different set of properties, however, than what is found in the USBSTOR key.

While there are numerous bits of data available in the Properties subkey, I will only highlight a few of the items that may prove useful in a typical forensic examination. The table below summarizes some of the information about a device that is available from the DeviceContainers key.  As you can see, the device instance ID, “DeviceContainer_ModelName”, and “DeviceContainer_PrimaryCategory” properties are available here in addition to two 64-bit FILETIME properties.  The “DeviceContainer_ModelName”, and “DeviceContainer_PrimaryCategory” properties are defined in the devpkey.h file of the Windows 8.1 SDK.  In addition to the property subkey listed in the table below, the device instance ID is also available in the subkey named by the device’s Container ID within the BaseContainers key.

 

 

 

The device instance ID is a valuable piece of information, as it contains the VID and PID of a device as well as the serial number or unique identifier of the device.  For example, when connecting a flash drive to a Windows 8.1 system, I found “USBVID_090C&PID_10001009070810017910” to be the device instance ID associated with the flash drive.  In this case, you can see that “1009070810017910” is the serial number of the flash drive; this information can be corroborated with the USB and USBSTOR keys as well.

The DeviceContainer_ModelName helps describe the device – similar to the FriendlyName value of the USBSTOR key.  Examples of what I have seen in this property are “My Passport 0730”, “iPhone”, and “USB DISK”.  The DeviceContainer_PrimaryCategory helps describe the purpose of the device.  Some examples of what I have noted in this property are “Storage”, “Audio”, and “Display Monitor”.

There are also two 64-bit FILETIME timestamps that appear to be consistent with the first time the device was connected to the system.  Specifically, the “3464f7a4-2444-40b1-980a-e0903cb6d912\0007” property appears to contain the time the device driver installation started, while the “3464f7a4-2444-40b1-980a-e0903cb6d912\0008” property appears to contain the time the device driver installation completed.  This theory is supported by the setupapi.dev.log file, which includes the start and end time of device driver installations.  Interestingly, these two timestamps are slightly different than the Install and First Install timestamps found in other Properties subkeys in the registry. Unfortunately I have not yet found a precise definition – such as that from a Windows SDK – for what these two timestamps officially represent.

One of the nice things about the DeviceContainers key is that it appears to group all physical devices that have been connected to a system into one place.  If an examiner is focusing solely on the USBSTOR key, he or she may miss the fact that an MTP device was connected or that a hard drive was connected using something other than USB.  While the DeviceContainers key may not necessarily provide information that cannot be found elsewhere, it serves as yet another source to help examiners corroborate findings from other locations on the system and may be critical in cases where the ordinary sources of device-related information are not available.

No Comments
Categories : Registry Forensics
Tags : , ,
Posted by Jason Hale 
· September 9, 2013 
· 3 Comments

Windows 8 and 8.1: Search Charm History

The upcoming release of Windows 8.1 offers new features that will add to and/or modify the forensic artifacts available for examination.  One of these additions is the “Search Everywhere” feature that allows a user to search his or her files, settings, apps, and even the Internet at the same time.  In contrast, Windows 8 restricts a user to searching within a single category of data at a time (files, settings, apps).  The new search feature of 8.1 introduces artifacts not available in Windows 8 and provides examiners with another source of search charm data.  This post will discuss artifacts available in both Windows 8 and 8.1 as a result of the user conducting searches via the Windows search charm.

In order to utilize the “Search Everywhere” feature of Windows 8.1, the user must run a search using the Windows search charm, a feature introduced with Windows 8. This is not the same as conducting a search using Windows Explorer and leaves a different set of artifacts.

Windows 8.1 Search Charm
Windows 8 Search Charm

When a user runs a search using the search charm in Windows 8, specifically selecting “Files” as the search category, the search term is added as a value to an MRU list (maintained by an MRUListEx value) in the user’s NTUSER.DAT under SoftwareMicrosoftWindowsCurrentVersionExplorerSearchHistory Microsoft.Windows.FileSearchApp.  If the “Settings” or “Apps” category is selected, the search term does not appear to be added as a value to the MRU list (nor is a separate subkey created in the SearchHistory key).

Windows 8.1 also utilizes the SearchHistory key to maintain an MRU list of search terms, but within the SearchHistoryEXPLORER.EXE subkey instead.  Additionally, it appears that all search terms executed using the search charm are stored as a value here (as opposed to only the terms executed against the “Files” category).  An MRUListEx value is used to maintain the list here as well and the search term itself is stored in Unicode as type REG_BINARY.

In addition to the SearchHistory subkey, it appears that Windows 8.1 maintains another set of artifacts in the form of LNK files in the user’s AppDataLocalMicrosoftWindows ConnectedSearchHistory directory.  Interestingly, the LNK files associated with the search charm history that I’ve examined consist of only the LNK header and a shell item ID list containing the search term.  This means that if your tool does not parse shell item ID lists, it will not extract the search term from these files.  The LNK files I’ve examined that are associated with the search charm do not contain embedded FILETIME timestamps in the LNK header or DOSDate timestamps in the shell item ID list.  Further, if the user runs the same search term at a later date, there appears to be no change to the file content or file system timestamps of the LNK file.  This means that the file system timestamps associated with these files can only be used to identify the first time a particular search was conducted.

The search charm LNK files could be quite useful during an examination, despite the fact that the search terms are also stored in the user’s NTUSER.DAT.  For example, these files can help determine a specific time that each search term was used, provide additional artifacts to support that a particular search term was/wasn’t used, and may be useful if the user has taken steps to remove his or her search charm history.  When the search charm history is cleared (via search & apps settings), the entire SearchHistory subkey and the LNK files in the ConnectedSearchHistory directory are deleted.  The existence of these LNK files provides another possible avenue to recover previously used search terms.  One thing to note with respect to these files is that they are likely to be resident, given the fact that they contain only the LNK header and a small shell item ID list.

The testing I’ve conducted with regard to the Windows 8 and 8.1 search charm history has been with the default settings.  The Preview version of Windows 8.1 Professional was used for all testing related to 8.1.  At the time of this writing, the option to search the Internet using Bing is not a default option and thus was not tested.  It will be interesting to see if/how this option changes the artifacts available to an examiner.  At any rate, the Windows search charm, both with and without the “Search Everywhere” feature, provides additional forensic artifacts to help examiners piece together user activity in a Windows environment.

3 Comments
Categories : Registry Forensics
Tags : ,
Posted by Jason Hale 
· March 8, 2013 
· 5 Comments

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 SettingsSoftwareMicrosoftWindowsCurrentVersionAppModelSystemAppDatamicrosoft.windowsphotos_8wekby3d8bbwePersistedStorageItemTableManagedByApp” 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).

Update: 07/08/2014: As pointed out in a comment to this post, this information does not appear to be recorded in the same manner in Windows 8.1. 

5 Comments
Categories : Registry Forensics
Tags : , ,
Posted by Jason Hale 
· May 8, 2012 
· 4 Comments

Windows 8 TypedURLsTime

Amanda Thomson posted a Windows 8 Forensic Guide last month that covers a variety of topics examiners can expect to encounter with this new operating system on the horizon.  One of the new items in Windows 8 – existing at least in the Consumer Preview version – is the TypedURLsTime subkey that is located in the respective user’s NTUSER.DAT hive.  Amanda touched on this in her guide, but also mentioned that additional research should be conducted on this subkey. I was interested in when this key was updated, how it might be affected by a user performing specific actions (such as clearing the browsing history), and the added benefits to forensic analysis that an examiner may see with the existence of this subkey.  In an attempt to answer these questions, I ran a few tests on a clean install of Windows 8 Consumer Preview using Internet Explorer 10.

Note that this post doesn’t go into a great deal of detail regarding the TypedURLs subkey because it’s been covered in other locations such as the Crucial Security Forensics Blog and ForensicArtifacts.com.  I would recommend checking out one of those or the many other sources out there that discuss the TypedURLs subkey if you’re interested in more information.

Upon review of the NTUSER.DAT hive immediately after the first login (before Internet Explorer was ever opened), I observed a single value named “url1” in the TypedURLs subkey with the data being “http://go.microsoft.com/fwlink/?LinkId=69157”.  This existence of this value appears to be consistent with the behavior in older versions of Windows.  The TypedURLsTime subkey had not been created at this point.

After visiting a few websites by typing the URL into the address bar and hitting Enter, I observed that the URLs I typed had been added to the TypedURLs subkey with the most recently visited site being associated with the value “url1”.  This is consistent with the behavior an examiner would expect to see in older versions of Windows.  However, I also observed that the TypedURLsTime subkey had been created after values were added to the TypedURLs subkey.  The TypedURLsTime subkey is located at HKCUSoftwareMicrosoftInternet ExplorerTypedURLsTime. The values within this key are similar to those in the TypedURLs subkey (“url1”, “url2”, etc.), but the data for each of the values consists of a 64-bit FILETIME structure, as noted in Amanda’s guide.  This date/time combination appears to be the most recent date/time the corresponding URL was added to the TypedURLs subkey.  The connection is trivial to make between the TypedURLs subkey and the TypedURLsTime subkey. The URL listed as the data of value “url1” in the Typed URLs subkey was last added to that subkey at the date and time (UTC) contained within the data of value “url1” in the TypedURLsTime subkey.  This appears to be consistent and accurate with each “url##” value within each subkey.

An important point to note is that the date/time listed in the TypedURLsTime subkey corresponds to the most recent date/time the corresponding value was added to TypedURLs.  That is, if an entry for “www.google.com” already exists as the data of “url5” in TypedURLs and is added to the key again, the entry for “www.google.com” will become “url1” in the TypedURLs subkey and the data for “url1” in the TypedURLsTime subkey will correspond to the most recent visit to “www.google.com”.  The original data that once existed as “url5” will be replaced by the data from “url4” as each of the values are shifted down in order to add the most recent URL as “url1”.  Values existing in either subkey after “url5” (“url6”, “url7”, etc.) will remain the same.

One difference I noted with Windows 8 is that it appears the maximum number of values within the Typed URLs subkey – and thus the TypedURLsTime subkey – has been increased to 50, as opposed to the limit of 25 that exists in previous versions of Windows.  This may not be a huge difference, but more information – especially when it comes to user activity – is always nice.

When a user clears the browsing history via Internet Options –> Delete (under the Browsing History category), both the TypedURLs and TypedURLsTime subkeys are deleted.  I observed this when monitoring the deletion operating using procmon (snipped screenshot below).

The deletion of these subkeys, specifically the TypedURLs subkey, is of note to an examiner.  As Harlan mentioned in his corollary to the first law of computer forensics, “Once you understand what actions or conditions create or modify an artifact, then the absence of that artifact is itself an artifact”.  Since we know that the TypedURLs subkey should exist in a default installation of Windows 8, the absence of this subkey would be an indication that the browsing history may have been deleted (or the user may have taken other means to remove this subkey).

Further, the TypedURLs subkey does not appear to be immediately recreated after it is deleted using the method described above.  I have noted that opening Internet Explorer and navigating to websites using links within web pages will not prompt Windows to recreate this key.  I also noted that launching regedt32 directly from the System32 folder will not recreate the key, nor will restarting the machine.  However, oddly enough, opening the Run window appears to cause the shell to recreate the TypedURLs subkey (I would imagine there are other means of accomplishing this too, aside from visiting websites to populate the subkey).  When TypedURLs is created in this manner, the “url1” value with “http://go.microsoft.com/fwlink/?LinkId=69157” as its data does not exist as we observed before.  Instead, there are no values contained within the subkey.  This is yet another interesting note for an examiner. Observing the existence of an empty TypedURLs subkey may be an indication that the browsing history was deleted at some point, but the subkey was later recreated by the shell.  Note that when the TypedURLs and TypedURLsTime subkeys are deleted, their contents may still be recoverable as with any other deleted registry keys.  I successfully recovered portions of these subkeys after the browsing history was deleted by using regslack as well as X-Ways Forensics, although any registry-carving utility should work.

So what exactly are we gaining as forensic examiners with the introduction of the TypedURLsTime subkey? Once obvious benefit is that we’re provided with more information regarding the URLs listed in the TypedURLs subkey.  We can now correlate those URLs with a date and time that they were last added to the subkey.  And you can’t say date/time in the DFIR world today without thinking timeline.  A tool/script/RegRipper plugin or log2timeline module will need to be written, but correlating the contents of TypedURLs with TypedURLsTime may contribute valuable information to a timeline.  When you add in the additional entries that may exist in NTUSER.DAT hives from volume shadow copies, these subkeys become even more interesting.

Overall, it appears that the TypedURLsTime subkey is closely tied to the TypedURLs subkey, which doesn’t come as a surprise.  However, the knowledge that this key exists and how we might be able to use it will be important when we begin encountering it during examinations.  This is just a single aspect of Windows that will be a bit different with the introduction of Windows 8 (assuming this key is still around when its officially released).  There is certainly a lot of work and research that will need to be conducted so that we as forensic examiners can be ready for what’s to come with Windows 8.

4 Comments
Categories : Registry Forensics
Tags : , ,

Twitter

Subscribe via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Archives

DISCLAIMER

The contents of this blog reflect my opinion and may not represent the views of my employer or anyone else.  Any material on this blog, especially related to technology and/or forensic methodology should not be assumed to be true in all possible scenarios.  As always, test any theories, ideas, or tools from this blog in your own environment before stating them or the results therefrom as factual.