Something I learned very early on as a DF/IR consultant was that you’re likely never going to run into a perfect environment as an on-call responder. In fact, the best you can hope for is an environment with the default logging, for the OS and applications, and that the logs haven’t been cleared. Even then, those two conditions aren’t always the case. Even today, in 2026, I regularly see environments where auditing of successful logins has been disabled, so they don’t appear in the Security Event Log.
As such, it’s not only important to keep up with what’s available from the default installation of an endpoint, and what sources can be used to validate your findings, but also note what’s available depending upon the applications installed.
However, what’s most important are your analysis goals. For example, it’s easy to say, “I want to see all USB devices connected to the endpoint”, and not provide a timeframe. However, to what are these devices pursuant? IP theft? Violation of acceptable use policies? What about CSAM production? After all, smartphones and digital cameras can be connected to a computer via a USB cable, but use different protocols, and information about the devices being connected can be found in other locations than those that we traditionally look to as a result of training we may receive.
When it comes to devices connected to a Windows system, things have definitely changed over time. Cory and I published a peer-reviewed paper in 2005, covering USB artifacts on Windows XP systems. Since then, there’s been quite a few changes to Windows, and as one would expect, how devices connected to an endpoint are tracked. Nicole mentioned some time ago (2014) that different protocols used by different devices (in this case, smartphones) have an impact on investigations; unfortunately, as time has gone on, I’ve had a hard time linking back to Nicole’s published research or even her presentations, but one of her presentations can be found here.
This WindowsIR blog post describes the fact that some of the Windows Event Log files we might look to in order to investigate USB devices connected to an endpoint have been seen to be disabled, and recommended some alternative data sources. Similarly, this NirSoft page for the USBDeView application similarly recommends data sources.
Speaking of the WindowsIR blog, here’s a whole series of blog posts about just “USB devices”.
Now, as to why I’m writing this blog post, in the first place…
I recently ran across this LinkedIn post from Garrett Moreau, which I thought was interesting. He’s right, in that information about devices connected to/removed from the endpoint is stored in the Registry, and not just in the USBStor key. RegRipper, for example, includes multiple plugins within the “devices” category. What’s really eye-opening is to read through the comments to the post; one comment, for example, states the following:
Quick note for defenders, default logging settings don’t provide much depth.
This article has been indexed from Windows Incident Response