The Need for Innovation in DFIR

Malware News
1

Barely a week goes by and we see another yet post on social media that discusses knowledge sharing or "training" in cybersecurity, and in particular, DFIR and Windows forensic analysis. However, many times, these posts aren't "new", per se, but instead share information that is dated. 

Now, there's nothing wrong with what many perceive to be "old" or "dated" information because the simple fact is that core principles simply don't change over time. However, there are more tactical elements of "analysis" (really, data parsing and presentation for analysis) that may, in fact, change over time. This is particularly true for Windows systems, particularly as it applies to the various builds available for Windows 10; analysts saw the creation or availability of a particular artifact (i.e., the "BAM" Registry key) in one build, only to no longer see it populated in another build.

Something else we see is an incorrect or incomplete use of terminology, which in some cases seems to be almost willful. We see this a lot when it comes to the Windows Registry, but that's really fodder for it's own post/article. However, there are posts like this one, that purports to share "important Windows directories", and the first six items listed are files. Further, items 4 through 6 are not "logs". Over the past several months, I've seen that particular list posted multiple times in LinkedIn, and just last week, it somehow made its way into my Twitter feed, unfortunately.

Something else we see quite often references the Windows Event Logs, and claims to share important records, but only presents those records based on event IDs. The issue here is that event IDs are not unique. While most of us are familiar with event ID 4624, it means one thing when the event source is "Microsoft-Windows-Security-Auditing", and something else entirely when the event source is "Microsoft-Windows-EventSystem".

So What?
Okay, so what? Who cares? We see this all the time, it's pretty common...no, I take that back, it's really common, everyone's doing it, so what?

Well, I think we can all agree that the bad guys are innovating day-in and day-out, and the only way the "blue" side is going to keep up or even get ahead is by innovating in our own way. As such, the first step is to move beyond the "...this is the way we've always done it..." approach, to use that as a stepping stone or launching point for implementing a new model for DFIR analysis, one that bakes the lessons of the last incident back into the process so that those lessons are applied to subsequent incidents/analysis. 

We see some application of an approach like this for the SOC with the development of SOAR capabilities, and while DFIR can be thought of as an additional tier of the SOC, or as a standalone service, this isn't something that has seen much in the way of development within DFIR. Many (albeit not all) DFIR shops follow the same basic model...collect data, assign it to an analyst to parse and provide their findings. Unfortunately, what we tend to see in consulting firms and mirrored by some in-house teams, is a 1:3 or even 1:4 ratio between analysts and licensed forensic suites, with each analyst following their own process. Many times, this process is not documented, and simply run from memory; add to that the disparity in knowledge and experience between analysts working in isolation, and you can see how this model is inefficient and error-prone. 

So, let's stop following the old way of doing things. Let's stop referring to Windows Event Log records solely by event ID. Let's stop viewing individual artifacts or data sources in isolation, and instead start correlating artifacts and events, looking at the side-by-side based on time stamps. If we then use a common set of tools, or a common framework for parsing and correlating data sources, we can then build on that process and begin decorating and enriching data, much like what I've been doing with Events Ripper (it's important to note that I'm not the only who can write Events Ripper plugins; so far, I'm just the only one who does).

This way, we can use automation to build on and share our own experiences, so that others may benefit from those experiences, without having to go through the investigative process themselves. This gets analysts to the point of actually conducting analysis sooner, so that there is more of an opportunity to discover new artifacts and associations, in a much more efficient manner.

Article Link: Windows Incident Response: The Need for Innovation in DFIR