Insider threats are among the most persistent and elusive attack vectors in digital investigations, particularly when the adversary has physical access to the compromised system. This forensic walkthrough examines a controlled digital forensic challenge designed to replicate such an incident: a malicious insider utilizing a removable USB mass storage device to exfiltrate sensitive proprietary files from an unlocked corporate workstation.
The following interrogatives comprise the core evidentiary questions posed in the USB insider threat forensic examination:
- 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 optimal starting point for a comprehensive USB device audit is the registry key SYSTEM\CurrentControlSet\Enum\USB. This key maintains persistent tracking of USB devices across multiple device classes, including USBSTOR, UASP, MTP, PTP, and HID. It provides investigators with a broad overview of historically connected removable media and peripherals of potential evidentiary relevance. The key has been present since Windows XP and subsequent versions. Under this key, examiners can typically recover the following artifacts for each device:
On systems with frequent USB activity, the volume of subkeys under SYSTEM\CurrentControlSet\Enum\USB can become substantial, rendering manual enumeration inefficient. In such cases, specialized tools such as Registry Explorer (developed by Eric Zimmerman) offer a dedicated plugin that parses the key and presents relevant data in a structured tabular format. Analysts should note that the timestamps reported by this plugin reflect the LastWrite time of the VID/PID registry key and may not precisely correspond to the last connection or usage instance of the device.
.
 |
| Figure 2: The USB registry key |
It is further important to recognize that the complete USB device history preserved in this key may be incomplete due to periodic operating system clean-up routines, particularly following major Windows updates or upgrades.
Given that the present investigation centers on a data exfiltration incident involving the transfer of confidential files via removable media, the logical focus is on devices falling under the USB Mass Storage Class (MSC). Two primary protocols govern modern USB MSC devices:
- Bulk-Only Transport (BOT): The most prevalent protocol for USB MSC devices. It relies on bulk transfer endpoints for command and data exchange between host and device. This protocol is standard in the majority of USB flash drives and legacy external hard drives. It is relatively simple but less efficient. BOT devices are recorded in the
SYSTEM\CurrentControlSet\Enum\USBSTORregistry key. - USB Attached SCSI Protocol (UASP): A more modern, high-performance protocol introduced with USB 3.0. It enables SCSI command passthrough over USB, supporting command queuing and out-of-order execution for significantly improved throughput. UASP is commonly implemented in high-speed SSDs and advanced external storage devices. These devices are tracked under the
SYSTEM\CurrentControlSet\Enum\SCSIregistry key.
Investigators who habitually limit their analysis to the USBSTOR key alone risk overlooking UASP devices in contemporary environments. A thorough USB device audit therefore requires examination of both locations, though the core investigative methodology remains largely parallel with minor procedural variances. In the current case, review of the Registry Explorer USB plugin output and manual inspection of the relevant keys confirmed the absence of a UASP device (as indicated by the Service field). Accordingly, the analysis proceeds with focused examination of the USBSTOR registry key.
Each immediate subkey under USBSTOR follows the naming convention: Disk&Ven_[VendorName]&Prod_[ProductName]&Rev_PMAP\[SerialNo]. This string constitutes the device identifier (hardware ID). Beneath each device identifier subkey reside one or more unique subkeys representing individual iSerialNumbers. Multiple iSerialNumber entries under a single device identifier are common when identical or similar device models have been connected to the system at different times.
 |
| Figure 3: The USBSTOR registry key |
From the above figure, it is evident that three distinct USB devices sharing the same vendor and product identifiers were connected to the subject system. Per Microsoft’s hardware enumeration conventions, these correspond to Kingston DataTraveler 3.0 USB mass storage devices. Forensic analysis determined that one of these units was employed as the vector for data exfiltration.
In data exfiltration investigations, the following high-yield artifacts should be prioritized to identify staging activity and transferred content:
- The Master File Table ($MFT): Examine for files aggregated into a central staging directory prior to compression and exfiltration. Parse the $MFT for recent timestamp clusters associated with .zip, .rar, .7z, or similar archive extensions.
- ComDlg32 - Malicious actors frequently stage data in directories accessed via common file dialogs. The key HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32 preserves Open/Save MRU paths that may reveal staging folders.
- Recent Documents and LNK Files - These artifacts record opened or created files, providing direct insight into sensitive documents accessed immediately prior to exfiltration. Examine the path
<%SYSTEMROOT%>\User\<username>\AppData\Roaming\Microsoft\Windows\Recentfor LNK files containing original file paths and relevant MACB timestamps. - JumpLists (AutomaticDestinations) - These maintain records of recently accessed files, including compressed payloads and archiving utilities (e.g., WinRAR, 7-Zip). The directory <%SYSTEMROOT%>\User\<user>\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinatons offers a valuable trail of user interaction with exfiltration-related content.
 |
| Figure 4: JumpLists |
The assigned drive letter of the removable device is frequently recorded across multiple system artifacts, including Prefetch files, RecentDocs, Jump Lists, LNK files, OpenSavePidlMRU entries, and ShellBags. Correlating the last known mount point with these artifacts enables precise reconstruction of file access and data movement timelines. The last mount point information can be recovered from 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 subkeys corresponding to each drive letter historically assigned on the system. Each subkey includes a VolumeLabel value representing the volume name of the last device mounted to that letter. By cross-referencing volume labels with other recovered artifacts, examiners can associate specific devices with drive letters. Note that this key records only the most recent device per letter and does not provide historical depth for prior devices sharing the same letter. It offers superior readability compared to MountedDevices and is particularly effective for SCSI/UASP devices and virtual mounted objects (e.g., VHDs).
 |
| Figure 5: The VolumeInfoCache registry key |
The DriveType DWORD value further classifies the storage medium. 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.
- 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 provides detailed mount point mappings, primarily for Mass Storage Class devices. USBSTOR devices are especially straightforward to correlate here.
 |
| Figure 6: MountedDevices |
The MountedDevices registry key records a series of information for each drive letter it maintains. By searching the binary value data for a known device iSerialNumber, examiners can identify the corresponding drive letter. 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:\. For UASP/SCSI devices or USB-attached HDDs/SSDs, correlation can be more complex, as seen in this post. To definitively link the device identified by the above serial number to the G: drive letter used in the exfiltration (as observed in Figure 4), the following supplementary registry key, which ties them together, should be examined:
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:
 |
| Figure 8: MountedDevices Volume GUID |
The Global Unique Identifier (GUID) enclosed within the curly braces constitutes the Windows-assigned Volume GUID for the respective storage device. This identifier is of critical importance in the investigation, as it serves as a key linkage artifact for attributing the USB mass storage device to a specific user session during subsequent timeline and user activity correlation.
Question 3: What is the make and serial number of the connected USB stick?
Examination of the SYSTEM\CurrentControlSet\Enum\USBSTOR registry key (as depicted in Figure 3) identifies the USB mass storage device as a Kingston DataTraveler 3.0. The unique serial number is E0D55EA493BD18A179C50557. This identification is further corroborated through cross-reference with the Vendor ID (VID) and Product ID (PID) values recovered from the parent SYSTEM\CurrentControlSet\Enum\USB key, enabling precise device profiling and confirmation of the hardware identifier.
Answer: (Kingston, DataTraveler 3.0, E0D55EA493BD18A179C50557)
 |
| Figure 9: Make of the USB device |
Question 4: What are the filenames of the 3 files copied to the USB?
Analysis of the AutomaticDestinations Jump List artifacts (as illustrated in Figure 4) reveals that the three files transferred to the removable USB storage device are:
- the list of new contacts.docx
- 2024 financial audit.pptx
- 2026 financial plan.xlsx
These filenames represent the exfiltrated documents staged and copied during the insider threat incident.
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 metric can be determined through forensic analysis of FeatureUsage telemetry artifacts, which record user interactions with the Windows Taskbar and associated shell components, including the execution of pinned applications and direct engagement with system UI elements. These artifacts reside within the user’s NTUSER.dat registry hive under the following path:
NTUSER.dat\Software\Microsoft\Windows\CurrentVersion\Explorer\FeatureUsageSpecifically, the TrayButtonClicked subkey maintains a record of left-click events on key Taskbar elements, including the Clock, Start button, Notification Center, and Search interface.
 |
| Figure 12: Count of Start button clicks |
Answer: The Admin user clicked the Start button 11 times.
When the device under investigation is a USBSTOR mass storage device, attribution of its usage to a specific user account becomes feasible through targeted examination of user-specific registry hives. Each user profile maintains an NTUSER.dat registry hive that stores individualized configuration data. This hive is loaded into system memory upon user logon. The MountPoints2 key within this hive is of particular investigative value, as it records information regarding mounted drives, network shares, and removable media accessed through Windows Explorer. The full path to the key in question is:
NTUSER.dat\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoint2Beneath this key reside numerous subkeys identified by lengthy alphanumeric strings enclosed in curly braces—these are Volume GUIDs. These GUIDs directly correspond to the volume identifiers (GUIDs) previously recovered from the SYSTEM\MountedDevices key in the system hive. For comprehensive analysis, all potential NTUSER.dat hives present on the system should be loaded into a registry analysis tool (such as Registry Explorer) and queried concurrently. A matching Volume GUID in a user’s MountPoints2 key, corresponding to the GUID identified in SYSTEM\MountedDevices, indicates one of the following:
- The user account was actively logged in at the time the USB device was connected and mounted.
- The user account was the last profile logged in when the device was inserted.
This correlation provides strong evidentiary linkage between the removable media and a specific user session.
 |
| 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.
Forensic correlation between the SYSTEM\MountedDevices key and the MountPoints2 subkey within the NTUSER.dat registry hive confirms that the Admin user account was logged in at the time the USB mass storage device was connected and mounted. The Volume GUID associated with the flash drive, recovered from both the system hive and the Admin user’s MountPoints2 key, is {0eb1efce-1bc4-11f0-bdde-000c29989bd3}.
Answer: (Admin, {0eb1efce-1bc4-11f0-bdde-000c29989bd3}).
When conducting USB device forensics on modern Windows systems, three temporal artifacts are particularly pertinent to timeline reconstruction and event sequencing:
- First Connection timestamp
- Last Connection timestamp
- Last Removal timestamp
For each enumerated device, these timestamps reside under the respective iSerialNumber subkey within the Properties folder. A dedicated GUID key—{83da6326-97a6-4088-9453-a1923f573b29}—contains the binary values holding the relevant chronological data. This structure applies uniformly across USB device classes, including HID, MTP, USBSTOR, UASP, and others. Each value is stored as a 64-bit Windows FILETIME timestamp. When parsed using specialized tools such as Eric Zimmerman’s Registry Explorer, these values are automatically decoded and presented in human-readable UTC format, greatly facilitating accurate temporal analysis of device insertion and removal events.
 |
| Figure 14: USB connection timestamps showing the last removal timestamp |
Question 9: What is the last removal date and time of the USB drive?
Analysis of the device Properties GUID key {83da6326-97a6-4088-9453-a1923f573b29} under the corresponding iSerialNumber subkey in the USBSTOR registry path reveals the last recorded removal (dismount) timestamp of the USB mass storage device.
Answer: (04-17-2025, 19:44:12).
For the resolution of the remaining questions in this USB insider threat forensic challenge, the Windows custom operational log Microsoft-Windows-Partition%4Diagnostic.evtx is required. However, the events associated with the target USB mass storage device appear to be corrupted or unrecoverable, as evidenced in the accompanying figure.
Post a Comment