Hey Digital Defenders! I notice this case on LinkedIn post and wanted to write about USB forensic artifacts, piecing together evidence and reconstruct the insider threat incident.
USB Insider Threat Challenge — https://docs.google.com/forms/d/e/1FAIpQLSev_ImZUlad0d_py_dS_2YDbcmmgpZJtcPWE4AxUQitqLf1CA/viewform
Case Scenario : An employee used a USB stick on an unlocked company computer to steal three confidential files from the finance department (.xlsx, .docx, .pptx). After copying the files to the USB, he opened them from the flash drive to check they were copied properly.
Forensics Mindset : When a USB flash drive is connected to a Windows system, the operating system records forensic traces across multiple artifacts that tells DFIR investigator “what” device was used, “when” it was connected, “which user” interacted with it and “what user” was trying to do or performed any data exfiltration activity.
USB Forensics🔍& Key Findings
USB profiling is the initial investigative steps when insider threat activity involving removable media!
Three main categories, Human Interface Devices (HID), Media Transfer Protocol (MTP) Device and Mass Storage Class.
The test image contains a Human Interface Device (HID)-class USB device where its hardware identification information is stored under the registry key HKLM\SYSTEM\CurrentControlSet\Enum\HID. Further, if we can lookup the USB database, VID 00x0E0F | PID 0x0003 is identified as VMware product.
Let that sink in: HID exploitation attacks are often successful because HID devices operate at a low, trusted level in the operating system’s input stack. Mostly endpoint security solutions do not monitor or restrict legitimate-seeming input — making it difficult to detect without specific security defenses (USB device control policies, endpoint detection rules for anomalous input rates, or hardware-based whitelisting).
Mass Storage Class :
USB registry key (HKLM\SYSTEM\CurrentControlSet\Enum\USB) This key tracks devices across a range of device classes, including USBSTOR, UASP, MTP, PTP, and HID.
As we can see from below screenshots, these are windows-generated iSerialNumber 7&1ffda586&0&0000, 7&1ffda586&0&0001, instead of hardware-generated iSerialNumber. The windows-generated iSerialNumber is useful for correlating events in SetupAPI logs, Amcache, or ShimCache, but do not represent unique hardware serials.
Press enter or click to view image in full size
The hardware serial number is alphanumeric and manufacturer-specific, which can be found under USBSTOR registry key (HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR) where stores vendor, product, and serial number details for every USB mass storage device ever connected, serving as the primary source for device identification.
Then, further correlate with USB registry key!
Press enter or click to view image in full size
Hardware iSerialNumbers — E0D55EA493BD18A179C50557 is identified as Kingston DataTraveler 3.0 USB Device from FriendlyName.
Press enter or click to view image in full size
MountedDevices registry key (HKLM\SYSTEM\MountedDevices) maps drive letters to volume GUIDs, helping correlate a USB device with a specific mount point and potential file activity.
Disk&Ven_[VendorName] &Prod_[ProductName]&Rev_PMAP\[SerialNo]- Vendor = Kingston
- Product = DataTraveler 3.0
- Revision = 0000
- Serial Number = E0D55EA493BD18A179C50557
- Volume GUID = 0eb1efce-1bc4–11f0-bdde-000c29989bd3
- Class GUID = {53f56307-b6bf-11d0–94f2–00a0c91efb8b} — Microsoft GUID — Removable Disk
Press enter or click to view image in full size
HKLM\SOFTWARE\Microsoft\Windows Search\VolumeInfoCache stores volume identifiers (such as volume GUIDs) and associated properties like the volume label or drive letter at the time of indexing, while the Portable Devices key HKLM\SOFTWARE\Microsoft\Windows Portable Devicestypically maps device instance IDs to user-friendly display names — not necessarily the volume label.
If a removable device lacks a volume label, Windows may fall back to displaying the driver letter (G: ) as the friendly name in this case.
Press enter or click to view image in full size
Press enter or click to view image in full size
User-level Interaction Artifact — such as browsing or opening files on the USB — is captured in NTUSER.DAT and USRCLASS.DAT through shellbags, LNK files, and recent file lists.
Three documents “2024 Financial Audit.pptx,” “2026 Financial Plan.xlsx,” and “List of New Contracts.docx” — were accessed or moved into the folder during the time window of the suspicious USB drive connection.
Press enter or click to view image in full size
Look into HKLU\NTUSER.dat\SOFTWARE\Microsoft\Windows CurrentVersion\Explorer\MountPoint2\ Volume GUID which is previously identified in the SYSTEM\MountedDevices.
The Volume GUID 0eb1efce-1bc4–11f0-bdde-000c29989bd3 is matched, indicating that the user “Admin” was either actively logged in when the device was connected or was the most recently logged-in user at the time of connection — 2025–04–17 at 19:43:26 UTC.
Press enter or click to view image in full size
Volume Serial Number
Using Partition-4DiagnosticParser, I have no clue why VSN number is not available. Then, I manually checked Vbr0 data from “Microsoft-Windows-StorageSpaces-Driver/Operational.evtx”, and we know this USB driver connected to a NTFS system per $Boot artifact.
Press enter or click to view image in full size
Offset : Bytes (grouped by 16 for readability)
00000000: EB 52 90 4E 54 46 53 20 20 20 20 00 02 08 00 00
00000010: 00 00 00 00 00 F8 00 00 3F 00 FF 00 40 00 00 00
00000020: 00 00 00 00 80 00 00 00 BF 7F 37 07 00 00 00 00
00000030: 00 00 0C 00 00 00 00 00 02 00 00 00 00 00 00 00
00000040: F6 00 00 00 01 00 00 00 C6 CD A7 E6 11 A8 E6 B8
Volume Serial Number starts at offset 0x48 — https://en.wikipedia.org/wiki/NTFS
Press enter or click to view image in full size
There’s a key point I haven’t looked into yet whether the USB device uses a GPT or MBR partition scheme
According to resources, 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.
Conclusions
By cross-referencing USB profiling and MountPoint2 data with relevant Windows Security Event Logs 4624 (logon) / 4634 (logoff), we can confirm that the privileged account “Admin” login to the device when a Kingston DataTraveler USB device (iSerialNumber: E0D55EA493BD18A179C50557) was connected. During the user session time, three sensitive documents were accessed and moved to the USB mounted driver G:
📌Resource
Windows USB Artifacts Forensics
13Cubed Windows Registry Cheat Sheet
Windows Forensics: USB Device Profiling | by Ross Andrews | Medium