HowTo: Correlate an Attached Device to a User
Not long after my previous post on correlating LNK files to an external device, I received a question regarding correlating a device to a particular user. Some may look at this and think, well, that's easy...the LNK files in question are located in the user profile, so correlating the user to the device is actually pretty easy.
Okay, but what happens if there are no LNK files that point to the device? After all, for a LNK file to be available, the user must either create it manually, or perform some action where the operating system will create it automatically, right? Usually, this means that the user has opened a folder on the external device and double-clicked a non-executable file of some kind, such as a .txt file or a Word or PowerPoint document. The resulting action is that the appropriate application is launched based on the file extension, and the file is opened in that application, and an LNK file is created.
So, if you're examining a system and you suspect (or can show) that a USB device had been connected to the system, then how would you go about associating the device with a particular user, in the absence of LNK files?
MountPoints2 Key
As part of your USB device discovery process, one of the places that you're going to look is in the MountedDevices key within the System hive, in order to map the devices you've found in the USBStor subkeys to the volume globablly-unique identifier (GUID). Beneath the MountedDevices key, some of the value names will be the volume GUIDs, and their binary data will contain the device information, in Unicode format. Parsing the data and mapping back to the value name will provide you with the volume GUID. You can then use this information to search the subkeys beneath the MountPoints2 key in the NTUSER.DAT hive files for the volume GUID
The path to the MountPoints2 key is:
\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2
Shellbags Artifacts
Another artifact that allows us to correlate an attached device to a user is the shellbags artifacts, which on Windows 7 systems are found in the USRCLASS.DAT hive file within the user profile. This is how we can tie a device to a particular user.
The shellbags artifacts are simply paths to resources composed of shell items, the same types of data structures that can be found in LNK file shell item ID lists, Jump Lists, as well as other locations within the Registry. On Vista and Windows 7 systems, the first time that the user opens an Explorer window to a folder on an attached USB device (external hard drive or thumb drive), one of the shell items in the path will represent the drive letter to which the device was mapped, followed by the folder paths. The drive letter can be correlated to a particular USB device by mapping to the contents of the MountedDevices key values (or, for a device previously connected to the system, you may want to dig a bit into the MountedDevices key contents available in VSCs), or to the "Windows Portable Devices\Devices" subkeys in the Software hive (again, be sure to check VSCs, as well).
However...and this is very important...the shellbags artifacts may contain information about attached devices that are not immediately obvious via other means of analysis. For example, USB external drives and thumb drives are usually represented on the system as a volume (i.e., F:\, G:\) or drive letter, whereas smartphones, digital cameras, and MP3 players, while storage devices, usually appear beneath in the shellbags artifacts as a different type (type == 0x2e) of shell item. Not all of the tools available for parsing shellbags will parse these types of shell items; in fact, those that don't seem to simply skip parsing the entire path, so shellbags with type 0x2e shell items at their root are not displayed.
Further, depending upon the version of Windows and the type of device, the shell items the comprise the path the resource might be type 0x00, or a variable type. As the name implies, the routine for parsing these types of shell items varies, and in many instances, a great deal of information can be retrieved via knowledgeable manual analysis.
Okay, but what happens if there are no LNK files that point to the device? After all, for a LNK file to be available, the user must either create it manually, or perform some action where the operating system will create it automatically, right? Usually, this means that the user has opened a folder on the external device and double-clicked a non-executable file of some kind, such as a .txt file or a Word or PowerPoint document. The resulting action is that the appropriate application is launched based on the file extension, and the file is opened in that application, and an LNK file is created.So, if you're examining a system and you suspect (or can show) that a USB device had been connected to the system, then how would you go about associating the device with a particular user, in the absence of LNK files?
MountPoints2 Key
As part of your USB device discovery process, one of the places that you're going to look is in the MountedDevices key within the System hive, in order to map the devices you've found in the USBStor subkeys to the volume globablly-unique identifier (GUID). Beneath the MountedDevices key, some of the value names will be the volume GUIDs, and their binary data will contain the device information, in Unicode format. Parsing the data and mapping back to the value name will provide you with the volume GUID. You can then use this information to search the subkeys beneath the MountPoints2 key in the NTUSER.DAT hive files for the volume GUID
The path to the MountPoints2 key is:
\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2
Volume GUID key LastWrite time
It's commonly accepted that the LastWrite time for the volume GUID subkey beneath the MountPoints2 key indicates when that device was last connected to the system.
It's commonly accepted that the LastWrite time for the volume GUID subkey beneath the MountPoints2 key indicates when that device was last connected to the system.
Shellbags Artifacts
Another artifact that allows us to correlate an attached device to a user is the shellbags artifacts, which on Windows 7 systems are found in the USRCLASS.DAT hive file within the user profile. This is how we can tie a device to a particular user.
The shellbags artifacts are simply paths to resources composed of shell items, the same types of data structures that can be found in LNK file shell item ID lists, Jump Lists, as well as other locations within the Registry. On Vista and Windows 7 systems, the first time that the user opens an Explorer window to a folder on an attached USB device (external hard drive or thumb drive), one of the shell items in the path will represent the drive letter to which the device was mapped, followed by the folder paths. The drive letter can be correlated to a particular USB device by mapping to the contents of the MountedDevices key values (or, for a device previously connected to the system, you may want to dig a bit into the MountedDevices key contents available in VSCs), or to the "Windows Portable Devices\Devices" subkeys in the Software hive (again, be sure to check VSCs, as well).
Historical Registry Information
If you're looking for historical information from within the Registry, be sure to check the contents of the C:\Windows\system32\config\RegBack folder for backed-up copies of the System and Software hives.
If you're looking for historical information from within the Registry, be sure to check the contents of the C:\Windows\system32\config\RegBack folder for backed-up copies of the System and Software hives.
However...and this is very important...the shellbags artifacts may contain information about attached devices that are not immediately obvious via other means of analysis. For example, USB external drives and thumb drives are usually represented on the system as a volume (i.e., F:\, G:\) or drive letter, whereas smartphones, digital cameras, and MP3 players, while storage devices, usually appear beneath in the shellbags artifacts as a different type (type == 0x2e) of shell item. Not all of the tools available for parsing shellbags will parse these types of shell items; in fact, those that don't seem to simply skip parsing the entire path, so shellbags with type 0x2e shell items at their root are not displayed.
Further, depending upon the version of Windows and the type of device, the shell items the comprise the path the resource might be type 0x00, or a variable type. As the name implies, the routine for parsing these types of shell items varies, and in many instances, a great deal of information can be retrieved via knowledgeable manual analysis.
Devices connected via Bluetooth
Devices can be connected to a Windows system in other ways, including via Bluetooth. What's interesting about this type of connection is that smartphones are pretty ubiquitous at this point, and once the initial connection has been made, reconnecting to the device is trivial, and the device doesn't even have to be in view. The device can be reconnected as long as it is in range, and can be on a belt, or in a backpack or purse.
In my research, I found that a lot of users will connect to their smartphone via Bluetooth and use that connection to play music via their computer. I also found out that MS provides a file called fsquirt.exe, which is loaded on a system during installation if the system is found to have a Bluetooth radio.
Use the bthport.pl RegRipper plugin to get some information about devices connected to a Windows system via Bluetooth.
Devices can be connected to a Windows system in other ways, including via Bluetooth. What's interesting about this type of connection is that smartphones are pretty ubiquitous at this point, and once the initial connection has been made, reconnecting to the device is trivial, and the device doesn't even have to be in view. The device can be reconnected as long as it is in range, and can be on a belt, or in a backpack or purse.
In my research, I found that a lot of users will connect to their smartphone via Bluetooth and use that connection to play music via their computer. I also found out that MS provides a file called fsquirt.exe, which is loaded on a system during installation if the system is found to have a Bluetooth radio.
Use the bthport.pl RegRipper plugin to get some information about devices connected to a Windows system via Bluetooth.