Blackcat detection development, file exclusion of *.exe in microsoft defender endpoint
April 11, 2022

The BlackCat Ransomware group currently has the highest number of victims in the shortest time. In this article I walk through the process of creating a detection, validating the detection and reviewing the different logs that are generated from one of BlackCat’s ransomware techniques.

While reading threat intelligence reports I found a new ransomware as a service (RaaS) group named BlackCat that uses the rust programming language. I also found a technique that the group uses which might help detect this groups ransomware activities to defend ParaFlare’s customers.

PsExec, a common administrator tool which is part of Windows Sysinternals used for performing administrative functions, was used to run multiple PowerShell commands to add a file exclusion to Microsoft Windows Defender for Endpoint (MDE).

A PowerShell command was executed and added *.exe to an exclusion list for MDE. This command was executed across an entire organisation as reported by Symantec.

First I wanted to get an understanding of MDE AV exclusions so I headed to the Microsoft documentation on information about exclusions (here) and (here) to better understand what type of exclusions can be made. Summary of exclusion types are as follows:

  • File extension
  • File
  • Folder
  • Process

I quickly stumbled across the following command “mdatp exclusion extension add –name .txt”. This is likely similar to what the attacker used, with psexec executing as the parent process and Powershell executing the command. I also found other ways exclusions can be added using PowerShell, WMI and group policy.

I wanted to know if there were any existing alerts that might trigger from out of the box (OOB) Microsoft detections, so I spun up ParaFlare’s Windows10 Detection Virtual Machine and went to the defender console (windows Security AV) and added the exclusion from the Defender GUI to see what type of logs or alerts would be generated. Alarmingly, no alerts were generated.

Figure 1: Adding file exclusion via the GUI
Figure 1: Adding file exclusion via the GUI

Searching in the windows event timeline did not reveal any activity related to the exclusion I just added outside of the elevated privileges used.

Next, I went off to check the windows event logs in the following location Applications and Services Logs\Microsoft\Windows\Windows Defender\Operational and great success! Event ID 5007 was observed, where a registry value was changed from Null (no value) to HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Extensions\exe = 0x0

Figure 2: Event ID 5007
Figure 2: Event ID 5007
Figure 3: MDE event information
Figure 3: MDE event information

I confirmed the exclusion entry and its value by viewing the relevant location in the registry.

Figure 4: Registry value
Figure 4: Registry value

Now that I had that knowledge, I thought I might try and see if I can find that event in the MDE advanced hunting logs and looking in the Device Registry Events table revealed what I was looking for.

| where Timestamp > ago(1h)
| where RegistryKey == @”HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Exclusions\Extensions”
| where RegistryValueData == @”0″
| where RegistryValueName contains “*.exe”

Figure 5: KQL Query

Figure 6: KQL Detection
Figure 6: KQL Detection

Success! We now have a valid way to detect a BlackCat ransomware technique. I ran the query against a couple of customers logs to see if the query returned any large results that might flag as false positives. The query ran and returned with no results. This should be a high confidence alert with low noise which is great for analysts. Anyone who has worked as an analyst triaging alerts will know too well about alert fatigue.

I then documented the detection following the alerting detection strategy framework (ADS) as defined by Palintir on their github page. Once I had completed the ADS, this was stored in ParaFlare’s custom detections repository along with the query itself.

Once I had completed the ADS, it was time to deploy the detection into M365. This was a manual process until our new solution is ready to deploy to all our customers at scale. The solution will reduce human error and make it easier to maintain. I didn’t deploy the detection to Microsoft Sentinel as the logs required are not shipped into Sentinel for a few reasons. Apart from a longer retention in Sentinel the logs would be duplicated and would add a cost for storing the logs in Sentinel. Costs are something that ParaFlare want to keep low for our customers while providing a high level of service.

There are other ways to detect the file exclusion techniques, for example looking for certain strings in the process command line that contain Add-MpPreference or Set-MpPreference. You could also use the raw event log of EventID 5007 from the Windows Defender operational log if you have those available to you. Other BlackCat techniques are another avenue that you might want to pursue to detect this groups activity in your environment.

What else could we look for? We could potentially look at the other exclusion options and write detections for those. Although if threat actors are not using these techniques, it may be better to look at existing Threat Intelligence to drive detection development. It’s a cat and mouse game and if an attacker is blocked or detected by our defenses, they will change their tactics and techniques to successfully compromise their target.

How would you go about detecting the file exclusions? Did I miss anything? Are there any blind spots or gaps that an attacker could use to bypass this detection?

You Should also read

Practical security tips for young businesses

Rise in attackers manipulating seo to deliver gootkit

External article

Optus Hack is the new norm

Patching, and why it still matters