Digital Forensics — Windows USB Artifacts [Insider Threat Case]
Hey Digital Defenders! I notice this case on LinkedIn post and wanted to write about USB forensic ar 2025-11-13 13:27:47 Author: infosecwriteups.com(查看原文) 阅读量:10 收藏

whoami

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 Challengehttps://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

Windows-generated iSerialNumbers

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-generated iSerialNumbers

Hardware iSerialNumbers — E0D55EA493BD18A179C50557 is identified as Kingston DataTraveler 3.0 USB Device from FriendlyName.

Press enter or click to view image in full size

Kingston DataTraveler 3.0 USB Device

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

Driver Letter G:

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

Volume Label

Press enter or click to view image in full size

Friendly Name

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

Shortlnk files

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

MountPonit2 subkey

Volume Serial Number

Using Partition-4DiagnosticParser, I have no clue why VSN number is not available. Then, I manually checked Vbr0 data fromMicrosoft-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

ParentId — No record

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

Offset 0x48 NFTS shows VSN — C6CDA7E611A8E6B8

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

GitHub — theAtropos4n6/Partition-4DiagnosticParser: Windows Event Log “Microsoft-Windows-Partition%4Diagnostic.evtx” parser and devices’ VSNs extractor.

USB Forensics — Recover more Volume Serial Numbers (VSNs) with the Windows 10 Partition/Diagnostic Event Log · DFIR Review


文章来源: https://infosecwriteups.com/digital-forensics-windows-usb-artifacts-insider-threat-case-938c35a13b7e?source=rss----7b722bfd1b8d---4
如有侵权请联系:admin#unsafe.sh