Something I've seen consistently, from the very beginning when I first brushed up against this business of "digital forensics", is the default focus on, "...this is how you analyze this artifact...", and rarely extending beyond that.
I'm guilty of this, too. My first 8 books took this approach, listing data sources and artifacts, describing what they were in a general sense, and then maybe showing how to parse them. Each of those efforts basically left it up to the reading to stitch together their investigation on their own, and I justified this with the adage that each investigation is different.
But then, I realized that what makes each investigation different isn't the incident itself, or the data sources. No, it's the investigator. Everyone of us approaches an incident investigation supported by our own knowledge and experience, and that's really the only thing that makes each investigation different. So, yes, while it's important to understand the value and nuances of the various data sources available on a Windows endpoint, something I can to realize is that this must be done in the context of an overall investigation.
I recently ran across a blog post titled, How Do You Investigate Windows Event Logs?, with the subtitle, Windows Eventlog Analysis 101. While I am very supportive of analysts developing a thorough understanding of various data sources, so that they can leverage and truly exploit those data sources in their investigations, I also very firmly believe that this must be part of an overall analysis process.
This is why I wrote Investigating Windows Systems, to show how all of this information is, or can be, tied together by an analysis process. Once you have a process down, adding or removing data sources becomes thoughtful, intentional, and justified by data, not something that's done on a whim or because we forgot.
There's a good bit of really good advice in the article, but what stood out to me most was one of the things I absolutely do NOT want to see in any discussion of investigative or analysis processes, and that's the recommendation to "search by event ID".
I've said it before, and I'll say it again...event IDs are not unique. There's no requirement for that. In fact, MS itself doesn't use unique event IDs. For example, event IDs 4624 and 4625 mean something entirely different if the source is "Microsoft-Windows-Security-Auditing", or if it is "EventSystem".
That's right...not even Microsoft uses unique event IDs. When you start digging into the Application Event Log, and even add other applications that either write their events to the Application Event Log, or to their own log, then things really start to take a turn.
The point here is that any investigation or analysis advice that relies on a single data source, or suggests opening a single Windows Event Log in a viewer and then "search for event IDs" should be viewed as insufficient. Such advice is being shared by someone who doesn't have a defined analysis process.
What we should be looking to is using several data sources (WEVTX, file system, EDR telemetry, etc.), normalizing them into a common format, enriching them with data from either our own prior investigations or from external sources (or both), and then displaying them in a timeline format, so that we can see the progression and timing of the activity.
Another example of the narrow-aperture way of conducting analysis can be seen clearly in this LinkedIn post, and there are many more just like it.
The shortfall of all of this is that this is what AI models are being trained on, and because they're capable of doing it at scale, today's up-and-coming analysts will not be able to keep up. They won't be able to see the gaps, and they won't know when the model is hallucinating a finding. They simply won't be able to discern valid findings.
Introduction to Malware Binary Triage (IMBT) Course
Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor.
Enroll Now and Save 10%: Coupon Code MWNEWS10
Note: Affiliate link – your enrollment helps support this platform at no extra cost to you.
Article Link: Windows Incident Response: Investigations and Analysis