When I first started writing books, my "recipe" for how to present the information followed the same structure I saw in other books at the time. While I was writing books to provide content along the lines of what I wanted to see, essentially filling in the gaps I saw in books on DFIR for Windows systems, I was following the same formula other books had used to that point. At the time, it made sense to do this, in order to spur adoption.
Later, when I sat down to write Investigating Windows Systems, I made a concerted effort to take a different approach. What I did this time was present a walk-through of various investigations using images available for download on the Internet (over time, some of them were no longer available). I started with the goals (where all investigations must start), and shared the process, including analysis decisions and pivot points, throughout the entire process.
Okay, what does this have to do with teaching? Well, a friend recently reached out and asked me to review a course that had been put together, and what I immediately noticed was that the course structure followed the same formula we've seen in the industry for years...a one-dimensional presentation of single artifacts, one after another, without tying them all together. In fact, it seems that many materials simply leave it to the analyst to figure out how to extrapolate a process out of the "building blocks" they're provided. IMHO, this is why we see a great many analysts manually constructing timelines in Excel, after an investigation is "complete", rather than building one from the very beginning to facilitate and expedite analysis, validation, etc.
Something else I've seen is that some courses and presentations address data sources and artifacts one-dimensionally. We see this not only in courses, but also in other presented material, because this is how many analysts learn, from the beginning. Ultimately, this approach leads to misinterpretation of data sources (ShimCache, anyone??) and misuse of artifact categories. Joe Slowik (Twitter, LinkedIn) hit the nail squarely on the head when he referred to IoCs as "composite objects" (the PDF should be required reading).
How something is taught also helps address misconceptions; for example, I've been saying for sometime now that we're doing ourselves and the community a disservice when we refer to Windows Event Log records solely by their event ID; I'm not the only one to say this, Joachim Metz has said it, as well. The point is that event IDs, even within a single Windows Event Log, are NOT unique. However, it's this reductionist approach that also leads to misinterpretation of data sources; we don't feel that we can remember all of the nuances of different data sources, and rather than looking to additional data sources on which to build artifact constellations and verification, we reduce the data source to the point where it's easiest to understand.
So, we need a new approach to teaching this topic. Okay, great...so what would this approach look like? First, it would start off with core concepts of validation (through artifact constellations), and case notes. These would be consistent throughout, and the grade for the final project would be heavily based on the existence of case notes.
This approach is similar to the Dynamics mechanical engineering course I took during my undergraduate studies. I was in the EE program, and we all had to "cross-pollinate" with both mechanical and civil engineering. The professor for the Dynamics course would give points for following the correct process, even if one variable was left out. What I learned from this was that trying to memorize discrete facts didn't work as well as following a process; it was more correct to follow the process, even if one angular momentum variable was left out of the equation.
The progression of this "new" course would include addressing, for example, artifact categories; you might start with "process execution" because it's a popular one. You might build on something that persists via a Run key value...the reason for this will become apparent shortly. Start with Prefetch files, and be sure to include outlier topics like those discussed by Dr Ali Hadi. Be sure to populate and maintain case notes, and create a timeline from the file system and Prefetch file metadata (embedded time stamps)...do this from the very beginning.
Next, go to Windows Event Logs. If the system has Sysmon installed, or if Process Tracking is enabled (along with the Registry mod that enables full command lines) in the Security Event Log, add those records to the timeline. As the executable is being launched from a Run key (remember, we chose such an entry for a reason, from above), be sure to add pertinent records from the Microsoft-Windows-Shell-Core%4Operational.evtx Event Log. Also look for WER or "Application Popup" (or other errors) that may be available from the Application Event Log. Also look for indications of malware detections in logs associated with AV and other monitoring tools (i.e., SentinelOne, Windows Defender, Sophos, WebRoot, etc.). Add these to the timeline.
Moving on to the Registry, we clearly have some significant opportunities here, as well. For example, looking at the ShimCache and AmCache.hve entries for the EXE If available), we have an opportunity clearly demonstrate the true nature and value of these artifacts, correcting the misinterpretations we so often see when artifacts are treated in isolation. We also need to bring in additional resources and Registry keys, such as the StartupApproved subkeys, etc.
We can then include additional artifacts like the user's ActivitiesCache.db, SRUM.db, etc., artifacts, but the overall concept here is to change the way we're teaching, and ultimately doing DF work. Start with a foundation that requires case notes and artifact constellations, along with an understanding of how this approach leads and applies to validation. Change the approach by emphasizing first principles from the very beginning, and keeping them part of the education process throughout, so that it becomes part of the DFIR culture.
No comments:
Post a Comment