Devices

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 tracke

[…]
Content was cut in order to protect the source.Please visit the source for the rest of the article.

This article has been indexed from Windows Incident Response

Read the original article: