Tracking USB Activity Through Event Logs: Every Plug Tells a Story
- 2 days ago
- 5 min read
So, I had previously created a quick summary about USB activity, but I got a lot of requests asking for a more detailed version. That’s exactly why I’m here with this updated article! I’ve tried to keep things simple while adding a bit more depth so it’s easier to understand and actually useful. If you’re curious to learn even more, don’t forget to check out the full USB forensics series as well — it covers everything in much greater detail..
USB activity summary
Windows Event Logs for USB Activity
USB Forensic Series
------------------------------------------------------------------------------------------------------
There's a moment in almost every data theft investigation where the question becomes:
did they use a USB drive?
Not whether they could have — whether they actually did, when, and what they put on it.
Windows Event Logs answer that question in remarkable detail.
Not from one log, and not from one event ID — but from a layered set of logging mechanisms that, used together, can reconstruct every removable device interaction down to the individual file that was copied.
The challenge is knowing which logs to pull, which event IDs matter, and how to connect the dots between them.
------------------------------------------------------------------------------------------------------
Let's walk through the whole picture.
The Logging Ecosystem
Before diving into specific events, it's worth understanding that USB forensics in Windows isn't a single artifact — it's a collaboration between three different log sources, each with different strengths and coverage
------------------------------------------------------------------------------------------------------------
The System Log: First Impressions Only
The simplest entry point into USB forensics is the System log. When any new Plug and Play device connects and Windows tries to install a driver for it,
Event IDs 20001 and 20003 fire — and they carry the device's identifying information including its serial number.
The critical caveat:
These events only fire for the first connection of a specific device.
Once the driver is installed, subsequent connections don't trigger new Plug and Play install events. So the System log tells you the device was ever connected, and gives you the exact timestamp of that first introduction — but goes silent for every repeat visit.
One important gap:
The user account logged in at the time of device insertion isn't included in the Plug and Play events themselves. To connect a device to a user, you need to correlate the event timestamp with logon events in the Security log — or with USB registry artifacts that do tie connections to user sessions.
Modern Windows (recent Win10 and Win11 builds) has shifted toward logging only EID 20003 by default, skipping 20001 entirely.
***Check both when analyzing a system, and don't assume absence of 20001 means no device was connected.****
------------------------------------------------------------------------------------------------------------
The Security Log: Where Files Get Named
If the System log tells you that a device was connected, the Security log — when properly configured — tells you what happened on it. This is the capability that transforms USB forensics from "a device was plugged in" to "this user copied this specific file to this device at this exact time."
Two audit settings unlock this capability:
Audit Removable Storage (EID 4663) — records every interaction with a removable device: files read, files written, files deleted, even attribute changes.
Each event names the user account, the process responsible, and the operation type.
The limitation is significant:
The device is identified by a volume path like
\Device\HardDiskVolume9\ rather than by serial number. You have to cross-reference with other artifacts to know which device that volume path corresponds to.
Audit PNP Activity (EID 6416, Win10+) — records every device connection with full hardware identifiers: Vendor ID, Product ID, and iSerialNumber. Unlike the System log, this fires on every connection, not just the first. And because it lives in the Security log, it's far more likely to have been captured by enterprise SIEM infrastructure than System log events.
Neither is on by default. Finding them populated on a system you're investigating means someone proactively configured auditing — which itself tells you something about the environment's security posture.
------------------------------------------------------------------------------------------------------------
Connecting the Dots: A Real Scenario
Here's how these events work together in practice. Two events, same device, four minutes apart — and between them, a complete picture of what happened.
The Volume Path Problem
Here's the gap in the middle of this whole system that you need to know about:
EID 4663 doesn't include a device serial number. It identifies the device by its assigned volume path — something like \Device\HardDiskVolume9\ — which is a runtime assignment that changes every time the device is plugged in.
This means if you only have EID 4663 events and no 6416 events, you can see file operations on a removable device but you can't definitively identify which physical device it was without external help.
The solution is correlation:
Match the EID 4663 timestamp with a contemporaneous EID 6416 event showing the same volume path — that gives you the serial number
Cross-reference with USB registry artifacts like USBSTOR and MountedDevices to confirm the device identity
Once the volume path is tied to a physical device, every other EID 4663 event using that same path and Logon ID during that session can be attributed to the same device connection
Once that link is established for a session, the Logon ID in EID 4663 events lets you track every single file operation that user performed on that device for the duration of their session
------------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------------
The Access Type Dictionary
When EID 4663 fires, the Accesses field tells you what operation the user performed on the device. This field uses Windows access right terminology that can seem cryptic at first:
AppendData — a new file was written to the device. This is the exfiltration indicator. Data was copied to the drive.
ReadData — a file on the device was read. Data was accessed from the drive.
Delete — a file on the device was deleted.
WriteData — an existing file was modified.
SYNCHRONIZE — a standard access right that accompanies most operations; not meaningful on its own.
The Process Name field is equally useful.
explorer.exe means a human dragged and dropped or copy-pasted through the GUI.
cmd.exe means command-line operation.
robocopy.exe or xcopy.exe means a scripted or bulk copy.
The process name tells you how the transfer happened — and sometimes, whether it looks deliberate and scripted or like normal user behavior.
------------------------------------------------------------------------------------------------------------
The Big Picture
USB forensics from event logs is a layered discipline. No single event ID gives you everything.
But stack them correctly — 6416 to identify the device, 4663 to track the files, correlation with logon events to tie it to a user — and you can build a minute-by-minute record of every removable device interaction on a machine.
That's not circumstantial. That's a chain of evidence built entirely from logs the operating system generated for its own purposes, long before anyone suspected they'd need to be reviewed.#
------------------------------------------------------------Dean--------------------
Comments