There are many reasons why the activity around connecting and disconnecting USB storage devices can be of interest to an Incident Response or Forensic investigation. USB storage devices provide a quick and convenient way to take files in or out of a system or network which means they can be used to get malware files in, or company information out.

Regardless of the scenario, the investigation steps will likely be the same. The big questions are ‘what was connected and when’?

We are focusing on Microsoft Windows here, and the Mass Storage Device Class (MSC). There are two main sources of information that can be used: Windows Registry and Windows Event Logs.

Each has their own set of artefacts, and their own limitations.

Windows Registry

The Windows Registry, specifically the SYSTEM and SOFTWARE hives, contain both hardware information of USB Mass Storage devices and assigned drive letters. It will require a pivot between several keys however to get a full picture.

First, obtain the Serial Number and the Device Class ID of the device of interest from location “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR\”.

When selecting a device, keep an eye on the “FriendlyName” key which could help identify what type of device this is.

Using the Serial Number of the device of interest, pivot into location
“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Portable Devices\Devices\”, either via a search or by browsing through the keys manually. This will provide the Volume Name (another “FriendlyName” key). This can be the Drive letter as well if none was assigned.

Using the Serial Number of the device of interest, pivot into location “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\”.
This will provide the 16-bit Vendor ID and Product ID if needed. These ID’s can be mapped back to useful identifiers using sites like Devicehunt.

Using the serial number, either via a search or manually, pivot into location “HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices”. Within the listed “Drive letter” keys, the values contain some device information and the serial number of the USB drive using that assigned letter. There will be some overlap; however, multiple devices can be assigned the same drive letter when swapping USB drives around.

Connection and removal times can be obtained from the registry, but are limited to first “installation”, “safe removal” time and the first and last “connection” times. Keys and their associated values can be found at location “ControlSet001\Enum\USBSTOR\<<Device>>\<<SerialNumber>>\Properties\{83da6326-97a6-4088-9453-a1923f573b29}\”. The following Subkeys will be of use here:

Subkey	Timestamp
\64	First Connected Time After Driver Installation
\65	First Connected Time After Driver Installation
\66	Last Connected Time
\67	Last Connected or Last removed (if not connected)

The following screenshot from Registry Explorer shows the structure of these keys.

Windows Registry Based USB Analysis Tools

There are some great tools, that not only increase the speed of USB analysis through the registry, but they also add a whole range of other artefacts, beyond the scope of this article, they can for instance obtain additional information from the NTUSER.dat registry hive, setupapi logs (which includes driver install and uninstall events) and even shellbags and jumplists.

USB Detective

USB Detective is a commonly used tool that takes a whole range of inputs to provide a list of devices and an overview around when they were first and last seen. A quick example of the analysis of a Kape triage image can be seen below.

USBDeview

Another great tool utilising the Registry for USB artefacts, is USBDeview, an example of a “live” host can be seen below.

Windows Event Logs

Registry based tools are great for details on the actual device that was connected, such as hardware information, but provide limited detail around when exactly devices were plugged in and unplugged over time; registry-based tools use key creation and modification timestamps, which leaves a gap in between the first and last time a device was used. The Windows Event Log provides a much more granular timeline. The challenge here, is that this information is spread out through the logs. Manually collecting this can be a very large undertaking.

Without going into the detail of every individual event ID, here are some examples of useful EventIDs.

Useful EventIDs

SYSTEM – UserPNP – EventID 20001, 20002, 20003

This event covers the installation of USB device drivers and can be used to list when a device was connected. It included some key information such as the serial number and model number of the specific device. This event only shows the first time a device was plugged in.

Microsoft-Windows-Ntfs/Operational – NTFS – EventID 142

This event provides a point-in-time overview of the capacity of the drive and how much of this was used, based on the NTFS data.

Security – Object Access – Audit Removable Storage – EventID 4663, 4656

These events produce a wealth of information (filenames, applications, etc), unfortunately they require the “Audit Removable Storage” subcategory of the “System Audit Policies” to be enabled, which is not a default Windows setting.

There are many more EventIDs depending on the Windows Version, the level of enabled auditing and other variables. Luckily, some great tools automate the collection and presentation, enabling to focus on the analysis of the data itself.

Windows Event Log Based USB Analysis Tools

USBDriveLog

USBDriveLog by NirSoft, is a free tool that allows for the collection of USB related artefacts from the Windows Event Log. It presents device “Plug” and “Unplug” times in a timeline, with a lot of added metadata around Model Numbers, File Systems and Capacity.

USB Investigator – GitHub

This project on GitHub “simply” automates the collection of USB-related events by providing a collection of PowerShell scripts, which if unmodified, export results to .xml files for analysis.

Conclusion

The many versions of Windows, the various configurations out there and the different use cases, make a great argument to use tried and tested tools. It is important, however, to also understand the underlying workings of them in case the findings are inconclusive or even wrong. It does not take more than a laptop, some USB devices, and some time to setup a lab to test the tools and methods used in case the findings ever end up in a courtroom.