On #DFIR Analysis, pt III - Benefits of a Structured Model

 In my previous post, I presented some of the basic design elements for a structured approach to describing artifact constellations, and leveraging them to further DFIR analysis. As much of this is new, I'm sure that this all sounds like a lot of work, and if you've read the other posts on this topic, you're probably wondering about the benefits to all this work. In this post, I'll take shot at netting out some of the more obvious benefits.

Maintaining Corporate Knowledge

Regardless of whether you're talking about an internal corporate position or a consulting role, analysts are going to see and learn new things based on their analysis. You're going to see new applications or techniques used, and perhaps even see the same threat actor making small changes to their TTPs due to some "stimulus". You may find new artifacts based on the configuration of the system, or what applications are installed. A number of years ago, a co-worker was investigating a system that happened to have LANDesk installed, along with the software monitoring module. They'd found that the LANDesk module maintains a listing of executables run, including the first run time, the last run time, and the user account responsible for the last execution, all of which mapped very well in to a timeline of system activity, making the resulting timeline much richer in context.

When something like this is found, how is that corporate knowledge currently maintained? In this case, the analyst wrote a RegRipper plugin, that still exists and is in use today. But how are organizations (both internal and consulting teams) maintaining a record of artifacts and constellations that analysts discover?

Maybe a better question is, are organizations doing this at all?  

For many organizations with a SOC capability, detections are written, often based on open reporting, and then tested and put into production. From there, those detections may be tuned; for internal teams, the tuning would be based on one infrastructure, but for MSS or consulting orgs, the tuning would be based on multiple (and likely an increasing number of) infrastructures. Those detections and their tuning are based on the data source (i.e., SIEM, EDR, or a combination), and serve to preserve corporate knowledge. The same approach can/should be taken with DFIR work, as well.

Consistency

One of the challenges inherent to large corporate teams, and perhaps more so to consulting teams, is that analysts all have their own way of doing things. I've mentioned previously that analysis is nothing more that an individual applying the breadth of their knowledge and experience to a data source. Very often, analysts will receive data for a case, and approach that data initially based on their own knowledge and experience. Given that each analyst has their own individual approach, the initial parsing of collected data can be a highly inefficient endeavor when viewed across the entire team. And because the approach is often based solely on the analyst's own individual experience, items of importance can be missed. 

What if each analyst were instead able to approach the data sources based not just on their own knowledge and experience, but the collective experience of the team, regardless of the "state" (i.e., on vacation/PTO, left the organization, working their own case, etc.) of the other analysts? What if we were to use a parsing process that was not based on the knowledge, experience and skill of one analyst but instead on that of all analysts, as well as perhaps some developers? That process would normalize all available data sources, regardless of the knowledge and experience of an individual analyst, and the enrichment and decoration phase would also be independent of the knowledge and skill of a single analyst.

Now, something like this does not obviate the need for analysts to be able to conduct their own analysis, in their own way, but it does significantly increase efficiency, as analysts are no longer manually parsing individual data sources, particularly those selected based upon their own experience. Instead, the data sources are being parsed, and then enriched and decorated through an automated means, one that is continually improved upon. This would also reduce costs associated with commercial licenses, as teams would not have to purchase each analyst licenses for several products (i.e., "...I prefer this product to this work, and this other product for these other things...").

By approaching the initial phases of analysis in such a manner, efficiency is significantly increased, cost goes way down, and consistency goes through the roof. This can be especially true for organizations that encounter similar issues often. For example, internal organizations protecting corporate assets may regularly see certain issues across the infrastructure, such as malicious downloads or phishing with weaponized attachments. Similarly, consulting organizations may regularly see certain types of issues (i.e., ransomware, BEC, etc.) based on their business and customer base. Having an automated means for collecting, parsing, and enriching known data sources, and presenting them to the analyst saves time and money, gets the analyst to conducting analysis sooner, and provides for much more consistent and timely investigations.

Artifacts in Isolation

Deep within DFIR, behind the curtains and under the dust ruffle, when we see what really goes on, we often see analysts relying far too much on single sources of data or single artifacts for their analysis, in isolation from each other. This is very often the result of allowing analysts to "do their own thing", which while sounding like an authoritative way to conduct business, is highly inefficient and fraught with mistakes.

Not long ago, I heard a speaker at a presentation state that they'd based their determination of the "window of compromise" on a single data point, and one that had been misinterpreted. They'd stated that the ShimCache/AppCompatCache timestamp for a binary was the "time of execution", and extended the "window of compromise" in their report from a few weeks to four years, without taking time stomping into account. After the presentation was over, I had a chat with the speaker and walked through my reasoning. Unfortunately, the case they'd presented on had been completed (and adjudicated) two years prior to the presentation. For this case, the victim had been levied a fine based on the "window of compromise".

Very often, we'll see analysts referring to a single artifact (ShimCache entry, perhaps an entry in the AmCache.hve file, etc.) as definitive proof of execution. This is perhaps an understanding based on over-simplification of the nature of the artifact, and without corresponding artifacts from the constellation, will lead to inaccurate findings. It is often not until we peel back the layers of the analysis "onion" that it becomes evident that the finding, as well as the accumulated findings of the incident, were incorrectly based on individual artifacts, from data sources viewed in isolation from other pertinent data sources. Further, the nature of those artifacts being misinterpreted; rather than demonstrating program execution, they simply illustrate the existence of a file on the system.

Summary

Over the years that I've been doing DFIR work, little in the way of "analysis" has changed. We started out with getting a few hard drives that we imaged and analyzed, to going on-site to do collections of images, then to doing triage collections to scope the systems that needed to be analyzed. We then extended our reach further through the use of EDR telemetry, but analysis still came down to individual analysts applying just their own knowledge and experience to collected data sources. It's time we change this model, and leverage the capabilities we have on hand in order to provide more consistent, efficient, accurate, and timely analysis.

On #DFIR Analysis, pt II - Describing Artifact Constellations

 I've been putting some serious thought into the topic of a new #DFIR model, and in an effort to extend and expand upon my previous post a bit, I wanted to take the opportunity to document and share some of my latest thoughts.

I've discussed toolmarks and artifact constellations previously in this blog, and how they apply to attribution. In discussing a new #DFIR model, the question that arises is, how do we describe an artifact or toolmark constellation in a structured manner, so that it can be communicated and shared?  

Of course, the next step after that, once we have a structured format for describing these constellations, is automating the sharing and "machine ingestion" of these constellation descriptions. But before we get ahead of ourselves, let's discuss a possible structure a bit more. 

The New #DFIR Model

First off, to orient ourselves, figure 1 illustrates the proposed "new" #DFIR model from my previous blog post. We still have the collect, parse, and enrich/decorate phases prior to the output and data going to the analyst, but in this case, I've highlighted the "enrich/decorate" phase with a red outline, as that is where the artifact constellations would be identified.

Fig 1: New DFIR Model 

We can assume that we would start off by applying some known constellation descriptions to the parsed data during the "enrich/decorate" phase, so the process of identifying a toolmark constellation should also include some means of pulling information from the constellation, as well as "marking" or "tagging" the constellation in some manner, or facilitating some other means of notifying the analyst. From there, the expectation would be that new constellations would be defined and described through analysis, as well as through open sources, and applied to the process.

We're going to start "small" in this case, so that we can build on the structure later. What I mean by that is that we're going to start with just DFIR data; that is, data collected as either a full disk acquisition, or as part of triage response to an identified incident. We're going to start here because the data is fairly consistent across Windows systems at this point, and we can add EDR telemetry and input from a SIEM framework at a later date. So, just for the sake of  this discussion, we're going to start with DFIR data.

Describing Artifact Constellations

Let's start by looking a common artifact constellation, one for disabling Windows Defender. We know that there are a number of different ways to go about disabling Windows Defender, and that regardless of the size and composition of the artifact constellation they all result in the same MITRE ATT&CK sub-technique. One way to go about disabling Windows Defender is through the use of Defender Control, a GUI-based tool. As this is a GUI-based tool, the threat actor would need to have shell-based access to the system, such through a local or remote (Terminal Services/RDP) login. Beyond that point, the artifact constellation would look like:

• UserAssist entry in the NTUSER.DAT indicating Defender Control was launched
• Prefetch file created for Defender Control (file system/MFT; not for Windows server systems)
• Registry values added/modified in the Software hive
• "Microsoft-Windows-Windows Defender%4Operational.evtx" event records generated

Again, this constellation is based solely on DFIR or triage data collected from an endpoint. Notice that I point out that one artifact in the constellation (i.e., the Prefetch file) would not be available on Windows server systems. This tells us that when working with artifact constellations, we need to keep in mind that not all of the artifacts may be available, for a variety of reasons (i.e., version of Windows, system configuration, installed applications, passage of time, etc.). Other artifacts that may be available but are also heavily dependent upon the configuration of the endpoint itself include (but are not limited to) a Security-Auditing/4688 event in the Security Event Log pertaining to Defender Control, indicating the launch of the application, or possibly a Sysmon/1 event pertaining to Defender Control, again indicating the launch of the application. Again, the availability of these artifacts depends upon the specific nature and configuration of the endpoint system.

Another means to achieve the same end, albeit without requiring shell-based access, is with a batch file that modifies the specific Registry values (Defender Control modifies two Registry values) via the native LOLBIN, reg.exe. In this case, the artifact constellation would not need to (although it may be) be preceded by a Security-Auditing/4624 (login) event of either type 2 (console) or type 10 (remote). Further, there would be no expectation of a UserAssist entry (no GUI tool needs to be launched), and the Prefetch file creation/modification would be for reg.exe, rather than Defender Control.  However, the remaining two artifacts in the constellation would likely remain the same.

Fig 2: WinDefend Exclusions

Of course, yet another means for "disabling Windows Defender" could be as simple as adding an exclusion to the tool, in any one or more of the five subkeys illustrated in figure 2. For example, we've seen threat actors create exceptions for any file ending in ".exe", found in specific paths, or any process such as Powershell.

The point is that while there are different ways to achieve the same end, each method has its own unique toolmark constellation, and the constellations could then be used to apply attribution.  For example, the first method for disabling Windows Defender described above was observed being used by the Snatch ransomware threat actors during several attacks in May/June 2020. Something like this would not be exclusive, of course, as a toolmark constellation could be applied to more than one threat actor or group. After all, most of what we refer to as "threat actor groups" are simply how we cluster IOCs and TTPs, and a toolmark constellation is a cluster of artifacts associated with the conduct of particular activity. However, these constellations can be applied to attribution.

A Notional Description Structure

At this point, a couple of thoughts or ideas jump out at me.  First, the individual artifacts within the constellation can be listed in a fashion similar to what's seen in Yara rules, with similar "strings" based upon the source. Remember, by the time we're to the "enrich/decorate" phase, we've already normalized the disparate data sources into a common structure, perhaps something similar to the five-field TLN format used in (my) timelines. The time field of the structure would allow us to identify artifacts within a specified temporal proximity, and each description field would need to be treated or handled (that is, itself parsed) differently based upon the source field. The source field from the normalized structure could be used in a similar manner as the various 'string' identifiers in Yara (i.e., 'ascii', 'nocase', 'wide', etc.) in that they would identify the specific means by which the description field should be addressed. 

Some elements of the artifact constellation may not be required, and this could easily be addressed through something similar to Yara 'conditions', in that the various artifacts could be grouped with parens, as well as 'and' and 'or', identifying those artifacts that may not be required for the constellation to be effective, although not complete. From the above examples, the Registry values being modified would be "required", as without them, Windows Defender would not be disabled. However, a Prefetch file would not be "required", particularly when the platform being analyzed is a Windows server. This could be addressed through the "condition" statement used in Yara rules, and a desirable side effect of having a "scoring value" would be that an identified constellation would then have something akin to a "confidence rating", similar to what is seen on sites such as VirusTotal (i.e., "this sample was identified as malicious by 32/69 AV engines"). For example, from the above bulleted artifacts that make up the illustrated constellation, the following values might be applied:

• Required - +1
• Not required - +1, if present
• +1 for each of the values, depending upon the value data
• +1 for each event record

If all elements of the constellation are found within a defined temporal proximity, then the "confidence rating" would be 6/6. All of this could be handled automatically by the scanning engine itself.

A notional example constellation description based on something similar to Yara might then look something like the following:

strings:

    $str1 = UserAssist entry for Defender Control
    $str2 = Prefetch file for Defender Control
    $str3 = Windows Defender DisableAntiSpyware value = 1
    $str4 = Windows Defender event ID 5010 generated
    $str5 = Windows Defender DisableRealtimeMonitoring value = 1
    $str6 = Windows Defender event ID 5001 generated

condition:

    $str1 or $str2 and ($str3 and $str4 and $str5 and $str6);

Again, temporal proximity/dispersion would need to be addressed (most likely within the scanning engine itself), either with an automatic 'value' set, or by providing a user-defined value within the rule metadata. Additionally, the order of the individual artifacts would be important, as well. You wouldn't want to run this rule and in the output find that $str1 was found 8 days after the conditions for $str3 and $str5 being met. Given that the five-field TLN format includes a time stamp as its first field, it would be pretty trivial to compute a temporal "Hamming distance", of sorts, a well as ensure proper sequencing of the artifacts or toolmarks themselves.  That is to say that $str1 should appear prior to $str3, rather than after it, but not so far so as to be unreasonable and create a false positive detection.

Finally, similar to Yara rules, the rule name would be identified in the output, along with a "confidence rating" of 6/6 for a Windows 10 system (assuming all artifacts in the cluster were available), or 5/6 for Windows Server 2019.

Counter-Forensics

Something else that we need to account for when addressing artifact constellations is counter-forensics, even that which is unintentional, such as the passage of time. Specifically, how do we deal with identifying artifact constellations when artifacts have been removed, such as application prefetching being disabled on Windows 10 (which itself may be part of a different artifact constellation), or files being deleted, or something like CCleaner being run?

Maybe a better question is, do we even need to address this circumstance? After all, the intention here is not to address every possible eventuality or possible circumstance, and we can create artifact constellations for various Windows functionality being disabled (or enabled).

LNK Files, Again

 I ran across SharpWebServer via Twitter recently...the first line of the readme.md file states, "A Red Team oriented simple HTTP & WebDAV server written in C# with functionality to capture Net-NTLM hashes." I thought this was fascinating because it ties directly to a technique MITRE refers to as "Forced Authentication".  What this means is that a threat actor can (and has...we'll get to that shortly) modify Windows shortcut/LNK files such that the iconfilename field points to an external resource. What happens is that when LNK file is launched, Explorer will reach out to the external resource and attempt to authenticate, sending NTLM hashes across the wire.  As such, SharpWebServer is built to capture those hashes.

What this means is that a threat actor can gain access to an infrastructure, and as has been observed, use various means to maintain persistence...drop backdoors or RATs, create accounts on Internet-facing systems, etc.  However, many (albeit not all) of these means of persistence can be overcome via the judicious use of AV, EDR monitoring, and a universal password change.

Modifying the iconfilename field of an LNK file is a means of persisting beyond password changes, because even after passwords are change, the updated hashes will be sent across the wire.

Now, I did say earlier that this has been used before, and it has.  CISA Alert TA18-074A includes a section named "Persistence through LNK file manipulation". 

Note that from the alert, when looking at the "Contents of enu.cmd", "Persistence through LNK file manipulation", and "Registry Modification" sections, we can see a pretty comprehensive set of toolmarks associated with this threat actor.  This is excellent intrusion intelligence, and should be incorporated into any and all #DFIR parsing, enrichment and decoration, as well as threat hunting.

However, things are even better! This tweet from bohops illustrates how to apply this technique to MSWord docs.

On #DFIR Analysis

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.

Fig 1: Process Schematic

A New DFIR 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. 

Extracting Toolmarks from Open Source Reporting, pt II

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.

Extracting Toolmarks from Open Source Intel

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. 

Speaking at Conferences, 2020 edition

As you can imagine, 2020 has been a very "different" year, for a lot of reasons, and impacts of the events of the year have extended far and wide.  One of the impacts is conference attendance, and to address this, several conferences have opted to go fully virtual. 

The Open Source Digital Forensics Conference (OSDFCon) is one such conference.  You can watch this year's conference via YouTube, or view the agenda with presentation PDFs.  Brian and his team (and his hair!) at BasisTech did a fantastic job of pulling together speakers and setting up the infrastructure to hold this conference completely online this year.

Speakers submitted pre-recorded presentations, and then during the time of their presentation, accessed the Discord channel set up for their talk in order to answer questions and generally interact with those viewing the presentation.

I've attended (in person) and spoken at this conference in the past, and I've thoroughly enjoyed the mix of presentations and attendees. This time around, presenting was very different, particularly given that I wasn't doing so in a room filled with people.  I tend to prefer speaking and engaging in person, as well as observing micro-expressions and using those to draw people out, as more often than not, what they're afraid to say or ask is, in reality, extremely impactful and insightful.  

In many ways, an online virtual conference is no different from an in-person event.  In both cases, you're going to have your vocal folks who overwhelm others.  A good example of this was the Discord channel for my talk; even before I logged in for the presentation, someone had already posted a comment about textbooks for DFIR courses.  I have to wonder, much like an "IRL" conference, how many folks were in the channel but were afraid to make a statement or ask a question.

Overall, I do think that the pandemic will have impacts that extend far beyond the wide-spread distribution of a vaccine.  One thought is that this is an interesting opportunity for those doing event planning to re-invent what they do, if not their industry.  Even after we move back to in-person meetings and conferences, there will still be significant value in holding virtual or hybrid events, and planning for such an event to be seamless and easy to access for the target audience will likely become an industry unto itself.

Addendum, 24 Nov: Here is the link to the video for my presentation.

Other videos:
Video for Brian's RDPiece presentation 
Asif's Investigating WSL presentation
Linux Forensics for IoT

Addendum, 27 Nov: This morning, I uploaded my slides for the OSDFCon and Group-IB CyberCrimeCon 2020 presentations.

Happy Birthday, Marine Corps!

 

I thought today of all days would be a good time to break from tradition and share a post that has nothing to do with DFIR or Windows, one that isn't technical, nor related to computers. 

Some of you may be aware that once, in a galaxy far, far away, I was a Marine officer.  I was commissioned out of college, and served for a total of eight years.  During that time, I attended some interesting birthday ball events.  

There was the year that I was the commander of the cake detail, in charge three other Marines as we escorted the "cake" to the proper location in the ballroom. The guest of honor, and the oldest Marine in the room, was PX Kelley.  The youngest Marine was a 2ndLt on the cake detail.  That's the year that I learned a little secret, that the 'cake' isn't really cake. The vast majority of what looks like a cake is actually plywood decorated with icing.  For the 'cake' we were escorting, the second tier of the 'cake' was ringed with small USMC flags, with a small US flag marking the left and right borders of what was actually cake.

There was the year when, for some reason, the birthday ball venue included a stage, and a ramp was constructed for the cake detail to escort the cake up to the stage for the ceremony.  I'm sure that the detail practiced moving a gurney but apparently they did so without an actual cake, because when the detail got to the top of the ramp during the ceremony, the two lead Marines realized that they needed to actually lift the cake, as there was a lip at the top of the ramp.  When they did so, the gurney beneath the cake was freed, and rolled back down the ramp.  Much hilarity ensued as the two trailing Marines, being downhill, realized that they weren't going to be holding the cake for long.  Fortunately, several Marines in the audience jumped into action and rescued the detail.

There was the year when the commanding general droned on and on, as general officers are want to do. In fact, the general went on for so long that several Marines in the ceremony (who apparently had 'celebrated' prior the ceremony) began passing out.  One of the senior Marines, who was later my boss, passed out...twice.  He was caught the first time, before he completely pitched over, and took a seat for a few minutes at a table.  Then he got up, got back into the formation, went to the position of attention, and apparently locked his knees again, because within seconds he began pitching back and forth.  After the first instance, those of us seating at tables near the ceremony set up "fields of fire" and began watching those in the ceremony closely, looking for eyes rolling back, knees buckling, etc.

However, the most memorable birthday ball occurred in Nov, 1990, as units that had participated in Operation Valiant Blitz returned to Okinawa from Pohang, South Korea.  I was temporarily assigned to the USS Duluth as the billeting officer, and was responsible for the billeting of 217 Marines, as well as several officers and staff NCOs.  On 10 Nov 1990, at 23:45, the ship's platoon assembled in the mess for mid-rats and the birthday celebration. The Navy cooks had made a big sheet cake, that apparently had been subject to the rolling of the ocean; one end of the cake had about an inch of cake, and an inch of icing, while the other end had two inches of cake and just the slightest layer of icing.  For most of the young Marines on board, I don't think it mattered...and I hope that the those 18- and 19-year-olds who were there realized that they were part of a tradition reaching back more than 200 years.

So, to all past, present, and future Marines...Happy Birthday!

Name Resolution

How often to DFIR analysts think about name resolution, particularly on Windows systems?  I know that looking back across engagements I've done in the past, I've asked for DNS server logs but very often, these were not available. I'm sure others have seen the same thing. When we moved to enterprise response and had access to EDR tools, we could look up DNS queries or create reports based on EDR telemetry, if such a thing was recorded by the agent.  In some cases, we could have the DNS queries automatically checked against a blacklist, and queries for known-bad domains highlighted or marked.

According to MS KB article 172218, Windows systems look to their local hosts file prior to making a DNS query (on the network) when looking up a host name. This hosts file is located, by default, in the %SystemRoot%\System32\drivers\etc folder.  I say "by default", because this path can be changed via the following Registry value:

Key: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters
Value: DataBasePath

Okay...so what?  Well, it's widely known that threat actors will (we know because we've seen it) make modifications to Windows systems to meet their needs, modifying the environment to suit their goals.  We've discussed some of those settings before, and we've seen where threat actors have changed the location of a user's StartUp folder in order to hide their persistence mechanism.  If I wanted to keep DNS queries from appearing on the network, it would be relatively easy to either just modify the hosts file, or change the default location and plant a malicious hosts file.

Addendum, 22 Oct - since publishing this post yesterday, others have tried this and found that changing the location of the hosts file does not appear to work.  At this point, I have only found the value to exist on a few of the Windows 10 1809 and up systems/images to which I have access, and through searches, I've found indications online that this does not work for Windows 7 systems.  At this point, in the absence of explicit documentation, a bit more testing would be valuable.

However, analysts should still keep in the name resolution order in mind, and be aware that modifying the hosts file itself is still something a threat actor can do.  Other issues to keep in mind include the use of persistent routes (I've actually seen this done for legitimate business purposes), as well as the use of a port proxy. Both are fairly trivial to check during DFIR pre-processing or threat hunting.

Addendum, 28 Oct - Okay, so there's been no new info on this topic beyond the testing that's been done.  On that note, it's actually a bit sad that you can't point Windows systems to a centralized hosts file; Trend Micro recently posted regarding some new malware, which included listings of C2 services.  Being able to quickly add this info to a centralized hosts file (redirect host names to localhost) which all systems use would be very beneficial in defanging this malware.  

An alternative to this is to maintain a centralized hosts file, but have a GPO or some other process that regularly updates the hosts files, even if only on critical systems.  

So, at this point, it appears that the DataBasePath value on Win10 systems is pointless/has no discernible impact.  However, that does not mean that we don't look to other Registry locations that contain network-based information.  For example, I previously mentioned persistent routes and port proxy info, and I'd add checking the DNS server names/IP addresses for interfaces.

Settings That Impact The Windows OS

There are a number of settings within Windows systems that can and do significantly impact the functionality of Windows, and as a result, can also impact what is available to a #DFIR analyst.  These settings very often manifest as modifications to Registry keys or values. These settings also make excellent targets for threat hunting, as well.

Application Prefetching
Most DFIR analysts are aware of application prefetching and what it means.  In short, when application prefetching is enabled, files with *.pf extensions are created in the C:\Windows\Prefetch folder.  These files are intended to provide quicker loading of frequently-used applications, by placing needed information in a specific, known location.  

Most analysts are also aware that application prefetching is not enabled by default on server versions of Windows.  As such, Prefetch files are expected on Windows 7 and 10 systems, but not on Windows Server 2016 and 2019 systems.

As Dr. Ali Hadi pointed out, not all application prefetch files appear directly beneath the Prefetch folder.

Plaintext Passwords
We've seen the UseLogonCredential value being used during credential access for some time now, as creating this value and setting it to "1" tells the operating system to maintain credentials in memory in plain text.  As a result, threat actors have been observed creating this value (via reg.exe), setting it to "1", and then returning to the system 6 - 14 days later (depending upon the time frame, campaign, threat actor group, etc.) and using freely available tools such as mimikatz to dump credentials.  In a number of cases, lateral movement has followed very shortly thereafter, as the credentials are available.

If you perform a Google search for the value name, you'll find more than a few articles that mention setting the value to "0" in order to disable the functionality; however, this will have little effect if the threat actor is able to access systems with the appropriate level of privileges to set the value to "1".  However, this does provide an excellent resource for proactive, reactive, and DFIR threat hunting.  This is easy to set up and automate, and you'll only need to react when the value is found, and when it's set to "1".  That is, however, if the value doesn't exist within your infrastructure at all; if it does, and you find it set to "0", you then have good reason to investigate further.

Disabling Security Event Logging
About a year ago, this Sec-Labs blog post described a Registry key that, when added to a system, disabled Security Event Logging.  More recently, this tweet reiterated the same thing, referring to the blog post; I tested this on a Windows Server 2016 VM and found that it worked exactly as described in the Sec-Labs blog post; the EventViewer wasn't functioning properly and after extracting Windows Event Logs from the VM image file, I found the Security Event Log was not being populated.  After adding the value to the Registry, I had rebooted the system several times, which should have caused logon events to be written to the log file; however, upon examination of the Security.evtx file, this was not the case.

This is markedly different from clearing the Security Event Log.  If a Windows Event Log is cleared, some, if not all, of the records may be recovered (I say "may" because it depends upon how soon you're able to respond).  However, adding the "MiniNt" key to the Registry causes events to not be written to the Security Event Log, and as a result, there's nothing to "recover".  Nothing is written, neither to the log nor to unallocated space.

I know...I was thinking the same thing when I read the original blog post on the topic, and thought it again when I saw that it worked.

Conclusion
There are other Registry keys and values that can significantly impact the performance and operation of the Windows operating system; the three listed here are by far not the only ones.  Rather, they are just examples, and serve to demonstrate what I meant by "significantly impact". These keys and values can also be added to a proactive, reactive, or DFIR threat hunting process.

#OSDFCON

 The agenda for the 11th annual Open Source Digital Forensics Conference has been posted.  I've attended OSDFCON before (several times), it's one of the conferences where I've enjoyed presenting over the years. Maybe someone reading this remembers the "mall-wear" incident from a number of years ago.

So, on 18 Nov, I'll be speaking on Effectively Using RRv3. This past spring, I shared some information about about this new version of RegRipper (here, and here), as well as highlighting specific plugins. What I'd like to do is, in the same vein as the conference agenda, crowd-source some of the content for my 30 min presentation.

What would you like to see, hear, or learn about during my 30-ish minute presentation regarding RegRipper 3.0?

Toolmarks

 I recently ran across an interesting article from Sophos, indicating that the Maze ransomware threat group had taken a page from the Ragnar ransomware threat group.  The article stated that the Maze group was seen delivering the ransomware in a virtualize environment as a means of defense evasion.

In describing the attack, the article includes the following:

...before they launched it, they executed a script that disabled Windows Defender’s Real-Time Monitoring feature.

Immediately following this, the article includes the contents of the batch file that perform this function, and we can see that the command is:

cmd.exe /c powershell.exe -exec Bypass /c Set-MpPreference -DisableRealtimeMonitoring 1

We know the impact of this command; Windows Defender real-time monitoring is disabled, and the Registry value is set to "1".  Also, the key LastWrite time will be updated to when this command was executed.  This is important because these toolmarks are different from other methods used to disable Windows Defender. For example, some threat actors have been observed using 'net stop' commands to stop the service, or using external tools, such as ProcessHacker or Defender Control.  Other actors have been observed enabling the DisableAntiSpyware value, or adding exclusions to the Registry. Some actors use Powershell or WMI, others use reg.exe. Whichever means that is used leaves different toolmarks.

Some folks (i.e., my wife) like analogies, so here's one...you usually access your home by putting a key in the lock, a key you own that is designed to open the door.  However, there are other ways to accomplish the same activity (i.e., opening the door).  You can use lock picks, a crowbar, or a 12 lb sledge. If the door has glass panels, maybe you can break one, reach inside and unlock the door.  However, the point is that all of these methods, while accomplishing the same goal, leave different toolmarks. These toolsmarks can be used to illustrate "humanness" in an attack, can be used to clarify and extend attribution, and can be used in proactive protection measures, such as EDR monitoring, and EDR threat hunting.  They can also be used in DFIR threat hunting, to facilitate the analysis process.

All of this is extremely valuable and can should be exploited to maximize its effect.

As far as the virtual machines go, the toolmarks differed between the Maze and Ragnar threat groups, as well.  The article sums those differences up by stating:

The Maze attackers took a slightly different approach, using a virtual Windows 7 machine instead of XP. This significantly increased the size of the virtual disk, but also adds some new functionality that wasn’t available in the Ragnar Locker version. 

Finally, as I read through the article, it occurred to me that, based on how the article was written, it seemed that the threat group knew something about the infrastructure.  Either the story of the attack was heavily edited, or the threat group had prior knowledge of the infrastructure.  Well, as it turned out:

The virtual machine was, apparently, configured in advance by someone who knew something about the victim’s network...

All of the information in the Sophos articles is extremely valuable, because it not only reinforces Microsoft's perspective on "human-operated ransomware attacks", but also reinforces that they're preventable.

The Death of AV??

I had a conversation recently, which started out being about endpoint technologies.  At one point in the conversation, the topic of AV came up.  The question was, is there still value in AV?

I believe there is; I believe that AV, when managed properly, can be a valuable tool.  However, what I've very often seen, through targeted threat response and DFIR analysis, is that AV isn't maintained or updated, and when it does detect something, that detection is ignored.

MS systems have had the Malicious Software Removal Tool (MSRT) installed for some time.  This is a micro-scanner, designed to target specific instances of malware.  Throughout many of the investigations I've done, I've seen where systems were infected with malware variants that should have been prevented by MSRT; however, in those instances, I've found that MSRT hasn't been kept up to date, and was last updated well prior to the infection.

Not long ago, I was assisting with some analysis work, and found that the customer was using WebRoot as their AV product. I found entries for AV detections in the Registry, and based on the timing, it was clear that while the product had detected and quarantined an instance of Dridex, the customer was still infected with ransomware.  That was due to no one being aware of the detection, and as such, no one took action. The threat actor was able to find something else they could install that wasn't detected by the installed AV product, and proceed with their attack.

Over the years, I've had more than a few opportunities to observe threat actor behavior, through a combination of EDR telemetry and DFIR analysis.  As such, I've seen more than a few methods for circumventing AV, and in particular, Windows Defender.  Windows Defender is actually a pretty decent AV product; I've had my research interrupted, as when I would download a web shell or "malicious" LNK file for testing, and Windows Defender would wake up and quarantine the file.  Very recently, I was conducting some analysis as part of an interview questionnaire, and wrote a Perl script to deobfuscate some code.  I ran the script and redirected the output to a file, and Windows Defender pounced on the resulting file.  Apparently, I did things correctly.

Again, I've seen threat actors disable Windows Defender through a variety of means, from stopping the service, to uninstalling the product.  I've also seen more subtle "tweaks", such as adding path exclusions to the product, or just disabling the AV component via a Registry value. However, the attacks have proceeded, because the infrastructure lacked the necessary visibility to detect these system modifications.  Further, there was no proactive threat hunting activity, not even an automated 'sweep' of the infrastructure, checking against various settings.

So, no...AV isn't dead.  It's simply not being maintained, and no one is listening for alerts.  AV can be very valuable.  Not only can checking AV status be an effective threat hunting tool (in both proactive scanning and DFIR threat hunting), but I've also been using "check AV logs" as part of my malware detection process. This is because AV has always been a great place to look for indications of attacks.

Toolmarks: The "How"

 I recently published a post where I discussed DFIR toolmarks, and not long after sharing it on Twitter, someone asked me for a list of resources that describe the "how"; that is, how to go about finding or determining toolmarks for various activities.  The specific use case asked about was malware; how to determine malware toolmarks after running the sample in a sandbox.  The best response I could come up with was Windows Forensic Analysis, 4/e, and I included the caveat that they'd have to learn the material and then apply it.  As they'd already found out, there isn't a great deal of information available related to identifying DFIR toolmarks.

One way to think of toolmarks is as artifact constellations, as these are the "scratches" or "indentations" left behind either as a direct result of the activity, or as a result of the activity occurring within the "eco-system" (i.e., operating system, audit configuration, applications, etc.).

The way I have gone about identifying toolmarks is through the use of timelines, at multiple levels.  What I mean by that is that I will start with a system timeline, using data sources such as the MFT, USN change journal, selected Windows Event Logs, Registry hives, SRUM database, etc.  From there, if I find that a specific user account was used in a manner that likely populated a number of artifacts (i.e., type 10 login as opposed to a type 3 login), I might need to create mini- or micro-timelines, based on user activity (browser history, Registry hives, timeline activity database, etc.).  This would allow me to drill down on specific activity without loosing it amongst the 'noise' of the system timeline.  Throughout the timeline analysis process, there's also considerable enrichment or "decoration" of the data that goes on; for example, the timeline might show that a Registry key had been modified, and decorating the data with the specific value that was created or modified will add context, and likely provide a pivot point for further analysis.  Data can also be decorated using online resources (knowledgebase articles, blog posts, etc.), providing additional insight and context, and even leading to additional pivot points.

The theDFIRReport write-up on Snatch ransomware attacks states that the threat actors "turned off Windows Defender"; however, there's no mention as to how this is accomplished. Now, like many will tell you, there are a number of ways to do this, and that's absolutely true...but it doesn't mean that we walk away from it.

Disabling Windows Defender falls under MITRE ATT&CK subtechnique T1562.001, and even so, doesn't go quite deep enough and address how defenses were impaired.  The data from the analyzed cases [c|sh]ould be used to develop the necessary toolmarks.  For example, was sc.exe or some other tool (GMER?) used to disable the Windows service?  Or was reg.exe or Powershell used to add or modify Registry values, such as disabling some aspect of Defender, or adding exclusions?  Given that the threat actors were found to access systems via RDP, was a graphical means used to disable Defender, such as Defender Control?  Each of these approaches has very different toolmarks, and each of these approaches is trivial to check for and identify, as most collection processes (be they triage or full image acquisition) already collect the necessary data.

So, for me, identifying toolmarks starts with timeline creation and analysis.  However, I do understand that this approach doesn't scale, and isn't something that everyone even wants to do, even if there is considerable value in doing so. As such, the way to scale something like this is to start with timeline analysis, and then incorporate findings from this analysis back into the process, 'baking' it back in to the way you do analysis.  One approach to automating this is to incorporate data decoration into a timeline creation process, so that something learned from one engagement is then used to enrich future engagements. A very simple example of how to do this can be found in eventmap.txt, which "tags" specific Windows Event Log records (based on source/ID pairs) as the Windows Event Logs are processed from the native state and being incorporated into a timeline.

If your data collection process results in data in a standard structure (i.e., acquired image, triage data in a zipped archive, etc.) then you can easily automate the parsing process, even at the lab intake point rather than having the analyst spend time doing it. If your analysts are able to articulate their findings and incorporate those back into the parsing and decoration process via some means, they are then able to share their knowledge with other analysts such that those other analysts don't have to have the same experiences.

Another example of toolmarks can be found in this u0041 post that discusses artifacts associated with the use of smbexec.py, one of the Impacket tools used for lateral movement, similar to PSExec. We can then create a timeline events file (from an acquired image, or from triage data), and add Windows Event Log records to the events file using wevtx.bat, employing data decoration via eventmap.txt.  An additional means of identifying pivot points in analysis would include running Yara rules over the timeline events file, looking for specific lines with the event source and IDs, as well as the specific service name that, per the u0041 blog post, is hard-coded into smbexec.py.  All of this can be incorporated into an automated process that is run via the lab intake team, prior to the data being handed off to the analyst to complete the case.  This would mean that the parsing process was consistent across the entire team of analysts, regardless of who was performing analysis, or what case they received.  It would also mean that anything learned by one analyst, any set of toolmarks determined via an investigation, would then be immediately available to other analysts, particularly those who had not been involved in, nor experienced, that case.  The same can be said for research items such as the u0041 blog post...one analyst might read about it, create the necessary data decoration and enrichment, and boom, they're done.  

Conclusion

Identifying toolmarks is just the first step.  Again, the means I've used is timeline analysis....not creating one big timeline, but creating mini-timelines or "overlays" (think cellophane sheets teachers used to use with overhead projectors) that allow me to see the important items without having to wade through the "noise" of regular system activity (i.e., operating system and application updates, etc.).

Once toolmarks have been identified, the next step is to document and 'bake' them back into the analysis process, so that they are immediately available for future use.

Toolmarks and Intrusion Intelligence

Very often, DFIR and intel analysts alike don't appear to consider such things as toolmarks associated with TTPs, nor intrusion intelligence. However, considering such things can lead to greater edge sharpness with respect to attribution, as well as to the intrusion itself.  

What I'm suggesting in this post is fully exploiting the data that most DFIR analysts already collect and therefore have available.  I'm not suggesting that additional tools be purchased; rather, what I'm illustrating is the value of going just below the surface of much of what's shared, and adding a bit of context regarding the how and when of various actions taken by threat actors.

Disable Security Tools
What used to be referred to as simply "disable security tools" in the MITRE ATT&CK framework is now identified as "impair defenses", with six subtechniques.  The one we're interested in at the moment is "disable or modify tools", which I think makes better sense, as we'll discuss in this section.

In TheDFIRReport regarding the Snatch ransomware actors, the following statement is made regarding the threat actor's activities:

"...turned off Windows Defender..."

Beyond that, there's no detail in the report regarding how Windows Defender was "turned off", and the question likely asked would be, "..does it really matter?"  I know a lot of folks have said, "...there are a lot of ways to turn off or disable Windows Defender...", and they're absolutely correct.  However, something like this should not be dismissed, as the toolmarks associated with a particular method or mechanism for disabling or modifying a tool such as Windows Defender will vary, and have been seen to vary between different threat actors. However, it is because they vary that make them so valuable.

Toolmarks associated with the means used by a particular threat actor or group to disable Defender, or any other tool, can be used as intrusion intelligence associated with that actor, and can be used to attribute the observed activity to that actor in the future.

Again, there are a number of ways to render Windows Defender ineffective.  For example, you can incapacitate the tool, or use native functionality to make any number of Registry modifications that significantly impact Defender.  For threat actors that gain access to systems via RDP, using a tool such as Defender Control is very effective, as it's simply a button click away; it also has it's own set of toolmarks, given how it functions. In particular, it "disables" Defender by setting the data for two specific Registry values, something few other observed methods do. 

Other techniques can include setting exclusions for Windows Defender; rather than turning it off completely, adding an exclusion "blinds" the tool by telling it to ignore certain paths, extensions, IP addresses, or processes.  Again, different TTPs, and as such, different toolmarks will be present.  The statement "turned off Windows Defender" still applies, but the mechanism for doing so leaves an artifact constellation (toolmarks) that varies depending upon the mechanism.

The "When"
Not only is the method used to disable a tool a valuable piece of intelligence, but so is the timing. That is to say, when during the attack cycle is the tool disabled?  Some ransomware executables may include a number of processes or Windows services (in some cases, over 150) that they will attempt to disable when they're launched (and prior to file encryption) but if a threat actor manually disables a security tool, knowing when and how they did so during their attack cycle can be value intrusion intel that provides insight into their capabilities. 

Deleting Volume Shadow Copies
Deleting Volume Shadow Copies is an action most often associated with ransomware attacks, employed as a means of preventing recovery and forcing the impacted organization to pay the ransom to get its files back.  However, it's also an effective counter-forensics technique, particular when it comes to long-persistent threat actors.

I once worked an engagement where a threat actor pushed out their RAT to several systems by creating remote Scheduled Tasks to launch the installer.  A week later, they pushed out a copy of the same RAT, but with a different config, to another system.  Just one.  However, in this case, they pushed it to the StartUp folder for a communal admin account.  As such, the EXE file sat there for 8 months; it was finally launched when the admins used the communal admin account in their recovery efforts for the engagement I was working.  I was able to get a full copy of the EXE file from one of the VSCs, demonstrating the value of data culled from VSCs.  I've had similar success on other engagements, particularly one involving the Poison Ivy RAT and the threat actor co-opting an internal employee to install it, and subsequently, partially remove it from the system.  The point is that VSCs can be an extremely valuable source of data.

Many analysts on the "intel side" consider deleting VSCs commonplace, and not worth a great deal of attention.  After all, this is most often accomplished using tools native to the operating system, such as vssadmin.exe.  But what if that's not the tool used?  What if the threat actor uses WMI instead, using a command such as:

Get-WmiObject Win32_Shadowcopy | ForEach-Object{$_.Delete();}

Or, what if the threat actor base64-encoded the above command and ran it via Powershell?  The same result is accomplished, but each action results in a different set of toolmarks.

Clearing Windows Event Logs
Another commonly observed counter-forensics technique is clearing the Windows Event Logs.  In some cases, it's as simple as three lines in a batch file, clearing just the System, Security, and Application Event Logs.  In other cases, it's a single line of code that is much more comprehensive:

FOR /F “delims=” %%I IN (‘WEVTUTIL EL’) DO (WEVTUTIL CL “%%I”)

As with the other actions we've discussed in this post, there are other ways to go about clearing Windows Event Logs, as well; WMI, Powershell (encoded, or not), external third party tools, etc.  However, each has its on set of toolmarks that can be associated with the method used, and are separate from the end result.

Addressing Counter-Forensics
Much of what we've discussed in this post constitute counter-forensics activities. Fortunately, there are ways to address instances of counter-forensics from a DFIR perspective, such as when Windows Event Logs have been cleared, as there are other data sources that can provide information in the absence of that data. For example, if you want to know when a user was logged into the system, you don't need the logs for that.  Instead, create a mini-timeline from data sources in the user profile, and you'll be able to see when that user was logged into the system.  However, if your question is, "what were the contents of the log records?", then you'll have to carve unallocated space to retrieve those records.

In some cases, an analyst may collect an image or selected triage files from a system, and find that some of the Windows Event Logs aren't populated.  I've been seeing this recently with respect to the Microsoft-Windows-TaskScheduler/Operational Event Log; on the two Win10 systems in my office, neither file is populated (the same is true with a number of the images downloaded from CTF sites).  This isn't because the logs were cleared, but rather because they had been disabled.  It seems that at some point, the settings for that Windows Event Log were modified such that they were disabled, and as such, the log isn't populated.  This doesn't mean that scheduled tasks aren't being executed, or that information about scheduled tasks isn't available...it just means that the historical record normally seen via that Windows Event Log isn't available.

On Artifact Constellations And "Toolmarks"

Something I've been pretty focused on in my analysis for some time is the concept of "artifact constellations".  I originally referred to this concept as "artifact clusters", but I heard someone from the FBI's Cyber BAU team use the term "constellations", and co-opted the term, in part to facilitate our conversation, but also because it sounded much more appropriate.

Artifact constellations are found as a result of events (not an event, but events) that occur on a system within close temporal proximity (another borrowed term, this one from Mr. Walters), as a result of some action, taken either by the user or threat actor.  When someone interacts with the operating system and applications, there are direct artifacts as a result of that interaction.  There are also very often indirect artifacts, created as a result of the events occurring within the "eco-system";  that is, events generated by the operating system but are not a result of direct interaction by the user.

Artifacts should never be viewed in isolation, as this can lead to incorrect findings when an artifact constellation is completed with assumption.  This can be an issue, among other instances, when examining artifacts of program execution.  For example, if an analyst were to find a prefetch file or a UserAssist entry for CCleaner, does this mean that the user executed the capabilities of CCleaner, or simply that they launched the GUI?  When viewing only artifacts such as a prefetch file or a UserAssist entry in isolation, there is qualitatively no difference between launching CCleaner and taking advantage of its full capabilities, and simply launching the CCleaner UI, waiting a few minutes, and closing the application.

Artifact constellations will vary in the number of artifacts they contain, based on a number of factors, such as the version  and configuration of the operating system, the version and configuration of installed applications, the audit configuration of the system, etc.  All of these factors play an important role in the make up of the artifact constellation, which can also be viewed as a set of "toolmarks" related to the use of the application.

The overall idea here is that rather than pursuing and basing findings on individual artifacts in isolation, we instead pursue artifact constellations, as this allows us to develop a better sense of context, as well as overcome attempts at counter-forensics, however intentional (or otherwise).

If we are used to viewing artifacts in isolation and those artifacts are not available on the system, where does that leave us?  Let's say, for example, that an analyst is familiar/comfortable with pursuing Application Prefetch files as artifacts of program execution; what happens if those artifacts don't exist on the system?  Say, the version of Windows being examined is a server variant, or the threat actor launched programs from within alternate data streams, or the threat actor took counter-forensics measures and deleted the prefetch files (and possibly disabled application prefetching).  What happens then?  How does the examiner pursue the goals of their analysis if the artifacts with which they are most comfortable no longer exist?

Attempts at counter-forensics, no matter how unintentional, should also be considered.  For example, something many analysts have seen before is an AppCompatCache entry for a possibly malicious file with a last modification time more closely aligned with the installation time of the operating system.  This can be the result of the threat actor copying the file to the system and quickly time stomping it with the $STANDARD_INFORMATION attribute time stamps from files that are part of the legitimate Windows installation.  If the analyst views this one artifact as evidence of program execution in isolation from other artifacts in the constellation, they may also make an incorrect determination as to the threat actor's dwell time.

A recent article on TheDFIRReport site regarding the Snatch ransomware describes the actions of the threat actor, which includes "turned off Windows Defender".  However, the article does not mention how the threat actor did so.  Determining the how and the when (in relation to other events) with respect to the threat actor disabling Windows Defender can be very beneficial to developing threat intelligence about that actor, and identifying toolmarks associated with their activities.

Now, there are a number of ways to disable Windows Defender, and each will have it's own artifacts or "toolmarks". We know from the article that the threat actor accesses systems via RDP, so that provides some indication as to what artifacts would be available for analysis.

One way to disable Windows Defender via the command line is to use reg.exe:

reg.exe add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender" /v
"DisableAntiSpyware" /t REG_DWORD /d "1" /f > Nul

Disabling Windows Defender can also be achieved via Powershell.  In addition to  a Registry value (or values) being modified, there will also be entries in the Powershell Event Logs indicating the usage of Powershell.  Depending upon how the commands are launched, there may also be entries in a user's Powershell console history file.

Another way to disable Defender is via a freeware tool such as Defender Control, which is a simple GUI tool with two buttons, one to disable Defender, and one to enable it.  If a threat actor uses a tool such as this, the artifact constellation will likely appear as follows:

• File downloaded to/created on the system
• AppCompatCache entry, and perhaps an AmCache.hve entry
• Launch via user account (compromised account used to RDP into the system) results in UserAssist and RecentApps entries
• There likely won't be a Prefetch file, as workstations do not run Terminal Services by default
• Registry values related to disabling Windows Defender modified
• Windows Defender Event Log records for event IDs 5001 and 5010

Again, the constellation will vary depending upon the means used to disable Defender.  However, understanding the artifact constellation, and the toolmarks associated with various methods for disabling Defender, are not only beneficial for identifying threat actors, but can also be valuable when the threat actor has taken steps to perform counter-forensics (such as clearing Windows Event Logs).

So, why is the when important? Some ransomware variants have been observed to include a series of commands to turn Windows services off, via the 'net stop' command.  In fact, one variant was found to include more than 150 such commands, specifying several EDR, AV, and backup services. However, that variant did not include a command to disable the Windows Defender service; in that case, the threat actor had to do so manually, prior to moving their malware to the system.  In some instances, the threat actor will copy a batch file over to the system and execute it, so that they don't have to retype commands (and possibly make an error); sometimes, they leave the batch files in place when they're done.

In another instance, disabling of Windows Defender was actually determined to be a result of normal system administrator actions.  In fact, not only was Windows Defender manually disabled by administrators upon installation, but it was also regularly disabled via GPO.  It's easy to see that Defender was disabled, but determining the when can make a pretty significant difference in the incident, particularly if the analyst assumes that the threat actor disabled the application.

Conclusion
While it's very useful that there are cheat sheets available that provide us with a list of DFIR artifacts to examine, as analysts we are called upon to go beyond looking at artifacts in isolation, and instead base findings on artifact constellations.  Doing so also allows us to develop toolmarks associated with specific sets of activities, providing context and allowing us to better understand that threat actors.  It's easy to say that some event (Windows Defender was disabled) occurred, but developing the how and the when of that event provides the context to better visualize a threat actor's activities.