Insider threats remain one of the most difficult attack vectors to track and mitigate, especially when the culprit has physical access to a system. This post walks through a digital forensic challenge simulating such a scenario: an employee using a USB stick to exfiltrate confidential files from an unlocked corporate computer.
The following are questions posed in the USB insider threat forensic challenge:
- What is the computer name?
- What is the drive letter assigned to the USB drive?
- What is the make and serial number of the connected USB stick? answer format (make, model, serial number).
- What are the filenames of the 3 files copied to the USB? answer format (filename1.extension, filename2.extension, filename3.extension).
- What is the MFT record number of the PPTX file from its original path on the unlocked computer?
- Referring to the 3 files copied, what is the parent path of the files? (full path).
- Examining the provided evidence, how many times did the admin user click on the Start button?
- Which user was logged in when the USB drive connected? Please also specify the volume GUID of the flash drive. Answer format (username, volume GUID), example (john, {5d6f-d5f5-d5f5-d5f5}).
- What is the last removal date and time of the USB drive? Answer format (date MM-DD-YYYY, time 24 hr 00:00:00), example (05-08-1990, 23:25:15).
- What is the number of partitions and total sectors of every partition on the connected flash drive? answer format (number, number), example (3,5698458455).
- What is the USB drive's file system ID and type (e.g., FAT32, NTFS)? answer format (0x00, type), example (0x05, FAT16).
- What is the USB drive's Volume Serial Number (VSN) in hex? Answer in the format (only hex values without spaces), using an example (11CD11CD11CD11CD11CD11CD11CD).
Q1 - What is the Computer name?
SYSTEM\CurrentContolSet\Control\ComputerName\ComputerName |
| Figure 1: Computer Name |
The best location to commence a USB device audit is the SYSTEM\CurrentControlSet\Enum\USB key. This key tracks devices across a range of device classes, including USBSTOR, UASP, MTP, PTP, and HID. It gives a great overview of previously connected devices that could be of investigative value. This key is present in Windows XP and later versions. The USB key provides the following information:
A computer system used frequently may have a very long list of previously connected USB devices, in which case, examining individual subkeys under the SYSTEM\CurrentControlSet\Enum\USB key may be tedious for the investigator. The Registry Explorer tool by Eric Zimmerman has a Plugin to extract information of interest from the key and present it in tabular form, as shown in the image below. Note that the timestamp reported by this plugin is the last write time of the VID/PID registry key and may not accurately represent when the device was last used.
 |
| Figure 2: The USB registry key |
It is important to note that a complete system USB device history stored in this key may not be obtained due to a not-so-often data clean-up by the operating system following major OS updates.
Since this is a data exfiltration case (involving the transfer of confidential files via a USB device medium), it is logical to conclude that the USB device that falls within the radar of my investigation is a USB Mass Storage Class (MSC) device. The two major USB protocols used in the USB Mass Storage Class devices are
- Bulk-Only Transport (BOT): This is the most widely used protocol for USB MSC devices. It uses bulk transfer mode for sending commands and data between the host and the device. It is common in USB flash drives and older external hard drives. It is simpler but generally less efficient. BOT devices are recorded in the
SYSTEM\CurrentControlSet\Enum\USBSTORregistry key. - USB Attached SCSI Protocol (UASP): This is a newer and faster protocol introduced with USB 3.0. It uses SCSI commands over USB and supports command queuing and out-of-order processing. It improves performance, especially for solid-state drives (SSDs) and high-speed external drives. UASP devices are recorded in the
SYSTEM\CurrentControlSet\Enum\SCSIregistry key.
If you have previously audited a suspect system for USB artifacts, you would have likely focused only on the USBSTOR registry key. In modern systems, this focus can lead to missing important devices. With the introduction of UASP devices, a change in investigative approach is required to conduct a thorough audit, as UASP devices are not tracked under USBSTOR. For the most part, the investigative processes for these two different devices will mirror each other with slight deviations. From the overview of connected devices revealed by the Registry Explorer USB plugin and from manual inspection, we do not have a UASP device in this case (as seen in the Service field). Hence, my focus will be on the USBSTOR registry key.
Each immediate subkey of the USBSTOR is named with a string of the format Disk&Ven_[VendorName]&Prod_[ProductName]&Rev_PMAP\[SerialNo], known as the device identifier or hardware ID. Below each Disk&Ven_ string subkey will be one or more unique subkeys known as the iSerialNumbers. There can be more than one iSerialNumber below a device identifier because different devices of the same type have previously been connected to the computer.
 |
| Figure 3: The USBSTOR registry key |
From the above figure, it can be established that three different USB devices with the same vendor and product name were connected to the system under investigation. According to Microsoft's naming convention, the devices are Kingston DataTraveler 3.0 USB devices. One of these devices was used for data exfiltration.
Below are some of the top artifacts you might quickly want to examine first in a data exfiltration case to determine what was stolen.
- The Master File Table (MFT): Look for files copied to a central folder and zipped for exfiltration. Parse the $MFT file for .zip/.rar/.7z extensions and recent timestamp clusters.
- ComDlg32 - Attackers stage data in folders they open/save from. ComDlg32 logs that path history. The registry key
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32can show potential staging folders. - Recent Docs and LNK files - These show what was opened or created. Ideal for spotting sensitive data pre-exfiltration. Examine the path
<%SYSTEMROOT%>\User\<user>\AppData\Roaming\Microsoft\Windows\Recentfor LNKs with timestamps and original file paths. - JumpLists - These reveal recent files, zipped payloads, and tools like WinRAR, or 7zip used during staging. The path
<%SYSTEMROOT%>\User\<user>\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinatonskeeps a trail of what files have been touched.
 |
| Figure 4: JumpLists |
The drive letter is often recorded in various system artifacts such as Prefetch, RecentDocs, JumpLists, LNK files, OpenSavePidlMRU, ShellBags, and more. Matching the last mount point with these artifacts helps investigators trace file access and usage. The last mount point information can be found at the following registry locations.
SOFTWARE\Microsoft\Windows Search\VolumeInfoCache(Windows 7+ versions)SYSTEM\MountedDevices
The last mount point drive letter is not guaranteed to be available, as some factors can affect its presence or accuracy. These two registry keys only store information on the last device connected at a specific drive letter, and a given drive letter may have been shared across multiple devices connected to the system.
The VolumeInfoCache key maintains a series of subkeys, one for each drive letter in use on the system. Each of these subkeys maintains a VolumeLabel that records the volume name of the last device to be connected to that drive letter. By correlating this volume name to other artifacts previously found in your investigation, you can assign drive letters to some devices (noting that only the last device at that drive letter will be recorded). This key does not maintain a historical record of every device that has ever been connected to that drive letter. A good advantage of this artifact is that it is easier to read and extract information from than the MountedDevices registry key, which has been the more traditional source of this information. In general, this artifact is more suitable for examining SCSI drives (including MSC UASCP) and mounted objects like Microsoft VHDs.
 |
| Figure 5: The VolumeInfoCache registry key |
The DriveType data value provides information about the type of storage device connected to a drive letter. Possible values include:
- 0x0 --> (Unknown) The drive type is unknown or not properly identified.
- 0x1 --> (Reserved) A drive type reserved for future use.
- 0x2 --> (NoRootPath) The drive has no root path
- 0x3 --> (RemovableDisk) indicates a removable drive, such as a USB flash drive or a CD/DVD drive.
- 0x4 --> (RemoteDisk) indicates a network drive.
- 0x5 --> (CDROM) A CD-ROM or DVD-ROM drive.
- 0x6 --> (RAMDisk) A RAM drive (virtual storage in RAM).
- 0x7 --> (FixedDisk) A hard disk drive (HDD) or solid-state drive (SSD)
- 0x8 --> (DriveType_File) A file-based drive (e.g., virtual disk).
The SYSTEM\MountedDevices registry key is another location where you can identify the last mount point of a device. This key contains detailed information, but only for Mass Storage Class (MSC) devices. USBSTOR devices are the easiest to investigate using this registry key.
 |
| Figure 6: MountedDevices |
The MountedDevices registry key records a series of information for each drive letter it maintains. By searching for the device iSerialNumber within the value data, you can correlate the corresponding drive letter with that iSerialNumber. In the figure above, the iSerialNumber E0D55EA493BD18A179C50557, which matches that of Figure 3, is present in the value data for \DosDevices\G:, indicating that the device with that iSerialNumber was the last mounted as G:\. If the device of investigative interest is a UASP (SCSI) or a USBSTOR device that is a real disk drive (a USB-attached HDD or SSD), the profiling process with the SYSTEM\MountedDevices registry key becomes a little more complicated, as seen in this post. To be certain that the device with the above iSerialNumber is the same as that mounted at the drive letter G:, which was used to exfiltrate files, as revealed in Figure 4, we will look at the registry key below, which ties them together.
SOFTWARE\Microsoft\Windows Portable Devices |
| Figure 7: The Windows Portable Devices registry key |
Question 2: What is the drive letter assigned to the USB drive?
Answer: G:
\??\Volume{0eb1efce-1bc4-11f0-bdde-000c29989bd3}. The values within this key that start with “\??\Volume” and end in GUIDs refer to the volumes that were mounted on the system. |
| Figure 8: MountedDevices Volume GUID |
The Global Unique Identifier (GUID) between the curly braces is the Windows-assigned Volume GUID for that device. As we shall see later, this number will be needed to attribute the USB device to a specific user.
Question 3: What is the make and serial number of the connected USB stick?
Answer: From the USBSTOR registry key seen in Figure 3, the make of the USB drive is Kingston DataTraveler 3.0, and the serial number is E0D55EA493BD18A179C50557. This can be corroborated by looking up the Vendor ID (VID) and Product ID (PID) values obtained from the examination of the Enum\USB registry key, here.
 |
| Figure 9: Make of the USB device |
Question 4: What are the filenames of the 3 files copied to the USB?
From the analysis of the Windows JumpList as seen in Figure 4, the three files copied to the USB are:
- the list of new contacts.docx
- 2024 financial audit.pptx
- 2026 financial plan.xlsx
Question 5: What is the MFT record number of the PPTX file from its original path on the unlocked computer?
Answer: This can be determined by parsing the $MFT file as seen below.
 |
| Figure 10: Parsing the $MFT file |
Looking up the associated records from the resultant CSV file, we obtain the following:
 |
| Figure 11: MFT records of the exfiltrated files |
Answer: The MFT record number of the PPTX file, located in its parent path on the unlocked computer, is 118469.
Question 6: Referring to the 3 files copied, what is the parent path of the files? (full path)
Answer: From figure 11 above, the parent path of the files is C:\Users\Admin\AppData\Local\Temp\vmware-Admin\VMwareDnD\be0c984b.
Question 7: How many times did the Admin user click on the Start button?
This can be determined by examining FeatureUsage artifacts. These track events associated with the Task Bar, for example, when a user runs an application pinned to it. FeatureUsage artifacts are located in the NTUSER.dat registry file under the following key:
NTUSER.dat\Software\Microsoft\Windows\CurrentVersion\Explorer\FeatureUsageThe TrayButtonClicked subkey tracks left clicks on the following Taskbar items: Clock button, Start button, Notification Center button, and Search box.
 |
| Figure 12: Count of Start button clicks |
Answer: The Admin user clicked the Start button 11 times.
If the device being investigated is a USBSTOR device, an attempt can be made to attribute the device's usage to a user account in the system. To do this, we have to look at the NTUSER.dat registry hive. Each user in a system has an NTUSER.dat registry hive, maintaining user configuration data for the system, which is loaded into primary memory when the user logs in to the system. The MountPoints2 key within this registry hive stores information related to mounted drives, network shares, and other types of removable media the user has had access to via the Windows explorer. The full path to the key in question is NTUSER.dat\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoint2. Beneath this key are many long strings of numbers and letters that start and end with curly brackets; these are globally unique identifiers (GUIDs). These are, in fact, the same GUIDs that are found in the MountedDevices key within the System hive. As an NTUSER.dat registry hive is maintained for each user in the system, all suspected NTUSER.dat hives should be loaded into the Registry Explorer tool and searched simultaneously If you find a Volume GUID match in the MountPoints2 key for the same GUID previously identified in the SYSTEM\MountedDevices, then we know one of two things must be true about the associated user profile:
- The user was actively logged in when the device was present.
- The user was the last user to be logged in when the device was connected.
 |
| Figure 13: The MountPoint2 registry key |
Question 8: Which user was logged in when the USB drive connected? Please also specify the volume GUID of the flash drive.
Answer: The logged-in user was Admin. The above Volume GUID in the MountPoints2 registry key, which corresponds to that found in the SYSTEM\MountedDevices registry key, was found in the NTUSER.dat file of the user, Admin.
When examining modern Windows systems for evidence of USB connections, three timestamps are germane to our investigation they include:
- First connection timestamp
- Last connection timestamp
- Last removal timestamp
Under the iSerialNumber subkey for each device is a subkey named Properties. Under the Properties subkey is a specific globally unique identifier (GUID) key, {83da6326-97a6-4088-9453-a1923f573b29}, holding subkeys with the relevant timestamp information listed above. They are available for all of the different USB device classes connected - HID, MTP, USBSTOR, UASP, etc. Each key contains a 64-bit timestamp in the Windows FILETIME format. When examining these locations via Eric Zimmerman's Registry Explorer, these values are automatically converted to human-readable timestamps as seen in the figure below.
 |
| Figure 14: USB connection timestamps showing the last removal timestamp |
Question 9: What is the last removal date and time of the USB drive?
Answer: From figure 14 above, the last removal date is 04-17-2025 19:44:12.
The Windows custom log Microsoft-Windows-Partition%4Diagnostic.evtx will be needed to answer the last questions, but the events for our target USB drive appear to be corrupt, as indicated by the image shown below.
Post a Comment