Toolmarks and Intrusion Intelligence

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 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.