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.