I wanted to take the opportunity to discuss DFIR analysis; when discussing #DFIR analysis, we have to ask the question, "what _is_ "analysis"?"

In most cases, what we call analysis is really just parsing some data source (or sources) and either viewing the output of the tools, or running keyword searches.  When this is the entire process, it is not analysis...it's running keyword searches. Don't get me wrong, there is nothing wrong with keyword searches, as they're a great way to orient yourself to the data and provide pivot points into further analysis.  However, these searches should not be considered the end of your analysis; rather, they are simply be beginning, or at least early stages of the analysis. The issue is that parsing data sources in isolation from each other and just running keyword searches in an attempt to conduct "analysis" is insufficient for the task, simply due to the fact that the results are missing context.

We "do analysis" when we take in data sources, perhaps apply some parsing, and then apply our knowledge and experience to those data sources.  This is pretty much how it's worked since I got started in the field over 20 yrs ago, and I'll admit, I was just following what I had seen being done before me.  Very often, this "apply our knowledge and experience" process has been abstracted through a commonly used commercial forensic analysis tool or framework (i.e., EnCase, X-Ways, FTK, Autopsy, to name a few...). 

The process of collecting data from systems has been addressed by many at this point. There are a number of both free and commercially available tools for collecting information from systems. As such, all analysts need to do at this point is keep up with changes and updates to the target operating systems and applications, and ensure the appropriate sources are included in their collections.

Over time, some have worked to make the parsing and analysis process more efficient, by automating various aspects of the process, by either setting up processes via the commercial tools, or by using some external means.  For example, looking way back in the mists of time when Chris "CPBeefcake" Pogue and I were working PCI engagements as part of the IBM ISS ERS team, we worked to automate (as much as possible) the various searches (hashes, files names, path names) required by Visa (at the time) so that they were done in as complete, accurate, and consistent manner as possible. Further, tools such as plaso, RegRipper, and others provide a great deal of (albeit incomplete) parsing capability. This is not simply restricted to freely available tools; back when I was using commercial tool suites, I extended my use of ProDiscover, while I watched others simply use other commercial tools as they were "out of the box".

A great example of extending something already available in order to meet your needs can be found in this FireEye blog post, where the authors state:

We adapted the...parsing code to make it more robust and support all features necessary for parsing QMGR databases.

Overall, a broad, common issue with both collection and parsing tools is not with the tools themselves, but how they're viewed and used.  Analysts using such tools very often do little really identify their own needs, and then to update or extend those tools, looking at their interaction with the tools as the end of their involvement in the process, rather than the beginning.

So, while this automates some tasks, the actual analysis is still left to the experience and knowledge of the individual analyst, and for the most part, does not extend much beyond that. This includes not only what data sources and artifacts to look to, but also the context and meaning of those (and other) data sources and artifacts. However, as Jim Mattis stated in his book, "Call Sign Chaos", "...your personal experiences alone are not broad enough to sustain you." While this statement was made specifically within the context of a warfighter, the same thing is true for DFIR analysts. So, the question becomes, how can we implement something like this in DFIR, how do we broaden the scope of our own personal experiences, and build up the knowledge and experience of all analysts, across the board, in a consistent manner?

The answer is that, much like McChrystal's "Team of Teams", we need a new model.

Back in the day...I love saying that, because I'm at the point in my career where I can..."DFIR" meant getting a call and going on-site to collect data, be it images, logs, triage data, etc. 

As larger, more extensive incidents were recognized and became more commonplace, there was a shift in the industry to where some DFIR consulting firms were providing EDR tools to the customer to install, the telemetry for which reported back to a SOC. Initial triage and scoping could occur either prior to an analyst arriving on-site, or the entire engagement could be run, from a technical perspective, remotely.  

Whether the engagement starts with a SOC alert, or with a customer calling for DFIR support and EDR being pushed out, at some point, data will need to be collected from a subset of systems for more extensive analysis. EDR telemetry alone does not provide all the visibility we need to respond to incidents, and as such, collecting triage data is a very valuable part of the overall process.  Data is collected, parsed, and then "analyzed". For the most part, there's been a great deal of work in this area, including here, and here. The point is that there have been more than a few variations of tools to collect triage data from live Windows systems.

Where the DFIR industry, in the general sense, falls short in this process (see fig 1) is right around the "analysis" phase. This is due to the fact that, again, "analysis" consists of each analyst applying the sum total of their own knowledge and experience to the data sources (triage data collected from systems, log data, EDR telemetry, etc.). 

Why does it "fall short"?  Well, I'll be the first to tell you, I don't know everything. I've seen a lot of ransomware and targeted ("nation state", "cybercrime") threat actors during my time, but I haven't seen all of them.  Nor have I ever done a BEC engagement. Ever. I haven't avoided them or turned them down, I've just never encountered one. This means that the analysis phase of the process is where things fall short. 

So how do we fix that?  One way is that if I take everything I learn...new findings, lessons learned, anything I find via open sources...and "bake it back into" the overall process via a feedback loop.  Now, this is something that I've done partially through several tools that I use regularly, including RegRipper, eventmap.txt, etc. This way, I don't have to rely on my fallible memory; instead, I add this new information to the automated process, so that when I parse data sources, I also "enrich" and "decorate" appropriate fields.  I'm already automating the parsing so that I don't miss something important, and now, I can increase visibility and context by automating the enrichment and decoration phase.

Now, imagine how powerful this would be if we took several steps.  First, we make this available to all analysts on the team. What one analyst learns instantly becomes available to all analysts, as the experience and knowledge of one is shared with many. Steve learns something new, and it's immediately available to David, Emily, Margo, and all of the other analysts. You do not have to wait until Steve works directly with Emily on an engagement, and you do not have to hope that the subject comes up. The great thing is that if you make this part of the DFIR culture, it works even if Steve goes on paternity leave or a family vacation, and it persists beyond any one analyst leaving the organization entirely.

Second, we further extend our enrichment and decoration capability by incorporating threat intelligence. If we do so initially using open reporting, we can greatly extend that open reporting by providing actual intrusion intelligence. We can use open reporting to take what others see on engagements that we have yet to experience, and use that to extend our own experience. Further, the threat intelligence produced (if that's something you're doing) now incorporates actual intrusion intel, which is tied directly to on-system artifacts. For example, while open reporting may state that a particular threat actor group "disables Windows Defender", intrusion intel from those incidents will tell us how they do so, and when during the attack cycle they take these actions. This can provide insight into better tooling and visibility, earlier detection of threat actors, and a much more granular picture of what occurred on the system.

Third, because this is all tied to the SOC, we can further extend our capabilities by baking new DFIR findings back into the SOC in the form of detections. This feedback loop leads to higher fidelity detections that provide greater context to the SOC alerts themselves. A great example of this feedback process can be seen here; while this blog post just passed it's 5th birthday, all that means is that the process worked then and is still equally, if not more, valid today. The use of WMI persistence led directly to the creation of new high-fidelity SOC EDR detections, which provided significantly greater efficacy and context.

While everyone else is talking about 'big data', or the 'lack of cybersecurity skills', there is a simple approach to addressing those issues, and more...all we need to do is change the business model used to drive DFIR, and change the DFIR culture. 

On the heels of my previous post on this subject, I ran across this little gem from Microsoft regarding the print spooler EOP exploitation. I like articles like this because they illustrate threat actor activities outside the "norm", or what we usually tend to see in open reporting, if such things are illustrated in detail.

Fig 4 (in step 1) in the article illustrates a new printer port being added to a Windows system as a step toward privilege escalation. This serves as one of the more-than-a-few interesting EDR-style tidbits from the article (i.e., detect the Powershell commandline), and also results in a fantastic toolmark that can be applied to DFIR "threat hunting". 

The article illustrates, via fig 4, Powershell being used to add a printer port to the system, and that command results in a value being added to the Registry. There are other ways to go about this, of course, and this is only one example of how to achieve adding a printer port to a Windows system.  For example, you can use "win32_tcpipPrinterPort" via WMI to add a TCP printer port.

Whichever means is used, the end result is a value being added to the Registry, which means if there is no EDR capability on the system at the time that the port is created, we can still determine if a port was, in fact, created. This would be reflected in a new value being added to the Registry key, and the key LastWrite time being updated accordingly. The RegRipper ports.pl plugin will extract this information, and creating a timeline that includes Registry key LastWrite times will likely show the Registry key modification within the timeline.

Other RegRipper plugins that address toolmarks from open reporting associated with printers on Windows include:

printer_settings.pl - retrieves printer attributes, looking for indications that printers were set to not delete print jobs after they were spooled and sent to the printer (per Project TajMahal open reporting), enabling local data staging. 

printprocessors.pl - this open reporting on Winnti indicates that print processors have been used for persistence.

The purpose of this blog post (as well as the previous one) has been to illustrate a means by which open reporting can be incorporated into any analyst's process. In this example, I've shared the names of RegRipper plugins I've created, so that the toolmarks, along with the appropriate MITRE ATT&CK mappings and analysis tips, are always available to me during my analysis. As I've included the online resources in the headers of the plugins, I have those resources available should I need to refer to them. Overall, this adds breadth, depth, and most importantly, consistency to my analysis process, letting me get to the actual analysis much sooner. From this point, I can then curate any new findings or lessons learned based on that analysis, and bake that back into my process, extending that capability yet again.

There are, of course, other means to go about baking new findings and lessons learned back into your analysis process.  However, it depends largely upon what you're able to ingest or incorporate.  For example, if you're doing malware analysis or any sort of log analysis, Yara rules might provide a good option for you. The Nuix Investigate product includes extensions for both RegRipper and Yara rules, extending the capabilities of the product.

Yet another means is to use something like wevtx.bat, which uses eventmap.txt to provide a small modicum of enrichment to specific Windows Event Log records as they're added to a timeline.

These are all very basic means for extending your current analysis process with new toolmarks from open reporting, as well as baking new findings and lessons learned back into the process.

I've talked about toolmarks before...what they are, why (I believe) they're important, that sort of thing.  I've also described how I've implemented them, and about toolmarks specific to different artifacts, such as LNK files. The primary source for toolmarks should be the investigations you're performing; when you do data collection pursuant to an investigation, those toolmarks that you develop should be baked back into your analysis process.  For #DFIR consulting businesses, this is a truly powerful use of the petabytes of data flowing through your organization on a monthly basis, driving toward increasingly efficient analysis and reducing the engagement/SOW lifecycle.

While your own investigations should be the primary source of toolmarks, you can also take advantage of open source reporting to extend this capability. In some cases, open source reports are full of unrealized toolmarks, which any organization can leverage to extend their detection and threat hunting (including #DFIR threat hunting) capabilities. 

I know what you're thinking...how would you go about doing that?  How do you turn open source reporting into something actionable, leveraging toolmarks to extend your organization's capabilities?  Well, let's take a look...

Recently, Microsoft published a security blog regarding the 2nd stage activation from SunBurst, and based on the information they provided in the article, I thought that this would be a good opportunity to illustrate how to extract or realize toolmarks from open source reporting. The Microsoft article is a great example, because it is chock full of intrusion intel that leads directly to toolmarks.

For example, consider fig. 3 in the article; step 3 shows an "Image File Execution Options" Debugger value being set for the dllhost.exe executable.  The toolmark here is obvious; a new subkey is created, and a new value is added to that subkey. In step 6 we see that the Debugger value is deleted; at this point, the question is, is the dllhost.exe subkey left in place?  If so, the LastWrite time of the key would correspond to when the Debugger value was deleted; if not, and the dllhost.exe subkey is also deleted, then the residual toolmark becomes the LastWrite time of the "Image File Execution Options" key.  As a result, if the time stamp toolmark in question falls within the window of other interesting activity, then you likely have an actionable toolmark associated with this activity.

Make sense?

A couple of paragraphs below the figure, we see the following statement:

Finally, the VBScript removes the previously created IFEO value to clean up any traces of execution (step #6) and also deletes the following registry keys related to HTTP proxy:

Nomenclature alert...the two subsequent paths listed are actually to Registry values, not keys. As a result, in this case, the LastWrite time of the "Internet Settings" key would correspond closely to the above toolmark (i.e., IFEO key LastWrite time).  These two time stamps are very specific set of toolmarks related to this specific activity.

Now, let's mosy on down to the section of the article that mentions "anti-forensic behavior" because, well, this is the fun stuff.  The second bullet in that section includes the statement, "...WMI persistence filters were created..."; basically what this tells us is, be sure you're parsing the OBJECTS.DATA file!  So, different data source (i.e., not the Registry in this case), but a definite toolmark.

The third bullet in the "anti-forensic" section states, "...the attackers took care of disabling event logging using AUDITPOL and re-enabling it afterward."  Oh, now THIS is cool! We see in the table following this section that the command used is:

auditpol /set /category:”Detailed Tracking” /success:disable /failure:disable

This command modifies the "Default" value beneath the Policy\PolAdEvt key in the Security hive, which in turn causes the LastWrite time of the key to be updated.  The article then states that when the threat actor completes their activity, they set "success" and "failure" to "enable"; at this point, the toolmark is the LastWrite time of the key, and the value settings themselves.

Next, when the threat actor modifies the Windows firewall by adding a rule via netsh.exe, the action results in a modification to the Windows Registry, as does the use of sc.exe and reg.exe to disable Windows services remotely and locally, respectively, and the use of net.exe to map a OneDrive share. All of these actions result in a modification to the system that is evident tithin the Windows Registry, and all you need to do is pull them out in a timeline to see how close they are, temporally.

Another example of extracting toolmarks from open source reporting can be found in this article that describes how to use the finger.exe client to transfer files between systems. The article describes the use of netsh.exe to set up a port proxy in order to get port 79 TCP traffic out of the network.  The command used is similar to the one described in this Mandiant article on RDP tunneling, which results in a modification to the HKLM\System\CurrentControlSet\services\PortProxy\v4tov4\tcp key, adding a value. When the port proxy configuration is removed, the action can be indicated by the LastWrite time of the tcp key being updated.

An important aspect to keep in mind is detection and response time with respect to the toolmarks being created.  What I mean by that is that if response occurs relatively close to the action occurring (i.e., a Registry key and/or value being added), then the modification may exist in the transaction log, and may yet to be written to the hive.  This is also true with respect to the deletion.  Also, if the key LastWrite times correspond to the window of suspicious activity, but the keys/values do not exist, be sure to parse unallocated space within the hive file to determine if the deleted nodes can still be found and extracted.

While your own investigations should continue to be the primary source of actionable toolmarks that you apply back to or bake back into your analysis process, incorporating toolmarks developed and leveraged from open source reporting can significantly extend your reach and capabilities.