There Are Four Lights: USB-Accessible Storage
There's been a good deal of discussion and documentation regarding discovering USB devices that had been connected to a Windows system, as this seems to be very important to a number of examiners. In 2005, Cory Altheide and I published some initial information, and over the years since then, that information has been expanded, simply because it continues to grow. For example, Rob Lee has published valuable checklists via the SANS Forensics Blog, and Jacky Fox recently published her dissertation, which includes some interesting and valuable information regarding interpreting some of the information that is available regarding user access to USB devices via the Registry. Ms. Fox determined that when a USB device is connected to a system and mounted as a volume, that volume GUID is added to the MountPoints2 key for all logged in users, not just the user logged in at the console.
Further, Mark Woan recently updated information collected by his USBDeviceForensics tool, to include querying some additional keys/values.
Regarding the additional keys/values that Mark's tool is querying, Windows 7 and 8 systems have additional values beneath the device keys in the System hive, specifically a "Property" key with a number of GUID subkeys. This blog post provides some very good information that facilitates further searches, which leads use to information regarding a time stamp value that pertains to the InstallDate, as well as one that pertains to the FirstInstallDate.
So what? Well, let's take a look at the MS definition for the FirstInstallDate:
Windows sets the value of DEVPKEY_Device_FirstInstallDate with the time stamp that specifies when the device instance was first installed in the system.
Pretty cool, eh? This is what MS says about the InstallDate time stamp:
This time stamp value changes for each successive update of the device driver. For example, this time stamp reports the date and time when the device driver was last updated through Windows Update.
Ah, interesting. So it would appear that, based on the MS definitions for these values, we now have the information about when the device was first connected to the system available right there in the Registry. I'm not saying that we don't have to go anywhere else...rather, I'm suggesting that we have corroborating data that we can use to provide an increased relative confidence (a phrase that you usually see in my posts regarding timelines) in the data that we're analyzing.
Something that hasn't been addressed is that most of the publicly-available processes that are currently being used are not as complete as they could be. Wait...what? Well, this is where specificity of language within the DFIR community comes into play...it turns out that the processes are actually really very good, as long as all we're interested in is specifically USB thumb drives or external drives. However, there are devices that can be connected to Windows systems via USB and accessed as storage devices (digital cameras, iStuff, smartphone handsets), that do not necessarily become apparent to analysts using the commonly-accepted tools, processes and checklists. We can find these devices by looking beneath other Registry keys, as well as in other locations beyond the Registry, and by correlating information between them. This is particularly useful when counter-forensics techniques have been used (however unintentional...), as not everything may be completely gone, and we may be able to find some remnant (LNK file, shellbags, deleted Registry keys/values, Windows Event Log, etc.) that will point us to the use of such devices.
One of the pitfalls of interpretation of Registry data, as Ms. Fox pointed out in her dissertation, is that we often don't have current, up-to-date databases of all devices that could be connected to a Windows system, so we might see vendor ID (VID) and product ID (PID) values within key names beneath the Enum\USB key, but not know what they translate to...I've found Motorola devices, for instance, that required a good deal of searching in order to determine which smartphone handset was pointed to by the PID value. As such, no process is going to be 100%, push-a-button complete, but the point is that we will know that the data is there, we know to get it, and we know how to use it.
Full analysis of USB-accessible storage media can be extremely important to a number of exams, such as illicit image and IP theft cases. Many examiners used to think that sneaking a thumb drive into an infrastructure was a threat...and it still is; these devices get smaller and smaller every day, while their capacity increases. But we need to start thinking about other USB-accessible storage, such as smartphones and iDevices, not because they're easily hidden, but because they're so ubiquitous that we tend to not focus on them...we take them for granted.
A Mapping Technique
The EMDMgmt subkey (within the Software Registry hive) names include the serial number for the mounted volume (VSN), which is also included in the MS-SHLLLINK structure, which itself is found in Windows shortcut/LNK files, as well as Windows 7 and 8 Jump Lists. By correlating the VSNs from multiple sources, I was able to illustrate access to external storage devices in a manner that overcomes the shortcoming identified by Ms. Fox. What I've done is used code to parse through the LNK structures (LNK files in the Recent folder, for example, and the LNK streams within the Jump Lists) to list the VSNs, looking for the one (or two, or however many...) that point to the device identified in the EMDMgmt subkey name.
Further, Mark Woan recently updated information collected by his USBDeviceForensics tool, to include querying some additional keys/values.
Regarding the additional keys/values that Mark's tool is querying, Windows 7 and 8 systems have additional values beneath the device keys in the System hive, specifically a "Property" key with a number of GUID subkeys. This blog post provides some very good information that facilitates further searches, which leads use to information regarding a time stamp value that pertains to the InstallDate, as well as one that pertains to the FirstInstallDate.
So what? Well, let's take a look at the MS definition for the FirstInstallDate:
Windows sets the value of DEVPKEY_Device_FirstInstallDate with the time stamp that specifies when the device instance was first installed in the system.
Pretty cool, eh? This is what MS says about the InstallDate time stamp:
This time stamp value changes for each successive update of the device driver. For example, this time stamp reports the date and time when the device driver was last updated through Windows Update.
Ah, interesting. So it would appear that, based on the MS definitions for these values, we now have the information about when the device was first connected to the system available right there in the Registry. I'm not saying that we don't have to go anywhere else...rather, I'm suggesting that we have corroborating data that we can use to provide an increased relative confidence (a phrase that you usually see in my posts regarding timelines) in the data that we're analyzing.
Something that hasn't been addressed is that most of the publicly-available processes that are currently being used are not as complete as they could be. Wait...what? Well, this is where specificity of language within the DFIR community comes into play...it turns out that the processes are actually really very good, as long as all we're interested in is specifically USB thumb drives or external drives. However, there are devices that can be connected to Windows systems via USB and accessed as storage devices (digital cameras, iStuff, smartphone handsets), that do not necessarily become apparent to analysts using the commonly-accepted tools, processes and checklists. We can find these devices by looking beneath other Registry keys, as well as in other locations beyond the Registry, and by correlating information between them. This is particularly useful when counter-forensics techniques have been used (however unintentional...), as not everything may be completely gone, and we may be able to find some remnant (LNK file, shellbags, deleted Registry keys/values, Windows Event Log, etc.) that will point us to the use of such devices.
One of the pitfalls of interpretation of Registry data, as Ms. Fox pointed out in her dissertation, is that we often don't have current, up-to-date databases of all devices that could be connected to a Windows system, so we might see vendor ID (VID) and product ID (PID) values within key names beneath the Enum\USB key, but not know what they translate to...I've found Motorola devices, for instance, that required a good deal of searching in order to determine which smartphone handset was pointed to by the PID value. As such, no process is going to be 100%, push-a-button complete, but the point is that we will know that the data is there, we know to get it, and we know how to use it.
Full analysis of USB-accessible storage media can be extremely important to a number of exams, such as illicit image and IP theft cases. Many examiners used to think that sneaking a thumb drive into an infrastructure was a threat...and it still is; these devices get smaller and smaller every day, while their capacity increases. But we need to start thinking about other USB-accessible storage, such as smartphones and iDevices, not because they're easily hidden, but because they're so ubiquitous that we tend to not focus on them...we take them for granted.
A Mapping Technique
The EMDMgmt subkey (within the Software Registry hive) names include the serial number for the mounted volume (VSN), which is also included in the MS-SHLLLINK structure, which itself is found in Windows shortcut/LNK files, as well as Windows 7 and 8 Jump Lists. By correlating the VSNs from multiple sources, I was able to illustrate access to external storage devices in a manner that overcomes the shortcoming identified by Ms. Fox. What I've done is used code to parse through the LNK structures (LNK files in the Recent folder, for example, and the LNK streams within the Jump Lists) to list the VSNs, looking for the one (or two, or however many...) that point to the device identified in the EMDMgmt subkey name.