EDR Silencer - Embracing the Silence

The blog post presents a take on EDR Silencer, a hack tool that was open sourced. It also throws light on how it works and how to detect.

EDR Silencer is a very interesting tool. It was open sourced on GitHub. The functionality was previously created in Night Hawk, a C2 framework that's sold by MDSec Labs.

🤔How does it work?

In the world of connected EDRs/XDRs, if the machine isn't connected to the Internet, much of the functionality of these solutions are essentially dead. Things like reporting threats that are identified, getting threat intelligence, providing access to telemetry on the machine, etc. are non-usable. Interesting enough, this also hampers response capabilities as functionality such as "RTR" (CrowdStrike) & "Live Response" (Microsoft Defender for Endpoint) won't work.

The idea behind this offensive tool is to utilize Windows Filtering platform, an inbuilt utility (set of system services) available in Windows Vista 7 and later to block EDRs from communicating to the Internet.

Windows Filtering Platform was intended to be used by security programs such as Firewalls or Antimalware software, etc. However, just with any other legitimate feature, Humans leave no stone unturned to abuse these features. 😂

The tool iterates through the list of current processes, if it matches with a list of predefined secrurity executable names, it adds the process (along with the full path) to the list for further processesing. In the end, it adds all the identified processes to Windows Filtering Platform's block list which effectively blocks it from communicating to it's mother ship 🖖

🔐How to detect?

The following are few techniques that you can use to detect the tool and/or usage of this tool in your environment.

The following modes are available in the tool:

EDRSilencer.exe blockedr //Created WFP rules for all identified EDRs
EDRSilencer.exe unblockall //Deletes all the rules
EDRSilencer.exe unblock <filter id> //Deletes a specific filter 
EDRSilencer.exe block <full path> //Creates a rule for a specific process.

The following queries can be used to detect activity which leverages hardcoded GUIDs.

Kibana Query:

process.command_line.text: "blockedr" and winlog.event_id: 4688

Kusto Query:

Event
| where EventID == 4688
| where RenderedDescription has_any("blockedr")

The above queries only leverage blockedr only because the other command line parameters are known to generate noise as they're likely to be used for other benign programs (since they're very simple terms)

By default, there's no log generated when a new program is added to Windows filtering platform. However, with a simple tweaking, it's possible to generate limited telemetry related to this activity. The logging can be created using Group policy editor > Security Settings > Advanced Audit Policy Configuration > System Audit Policy > Policy Change > Audit Filtering Platform Policy Change.

Alternatively, the following auditpol command can be used to enable auditing. AuditPol isn't natively available on Windows. You can download it from here.

auditpol /set /subcategory:"Filtering Platform Policy Change" /success:enable /failure:enable

When this is enabled, several types of events are generated. A very interesting event ID: 5441 is generated every time when the Windows Filtering Platform is reloaded (typically when restarted). These rules contain the list of executables added to the block list. However the format is a bit skewed and can't be used to write rules directly. See for yourself.

It's important to understand that the event is generated only after the reload of WFP (typically a reboot) and an attacker will have an advantage with respect to time. Events won't be generated if the system isn't restarted!

Plus, if an attacker enables the rules > perform malicious action > unblock the ports, the detection will fail.

The following queries can be used to detect activity using the above-mentioned event IDs.

Kibana Query:

message:("d78e1e87-8644-4ea5-9437-d809ecefc971" OR "c38d57d1-05a7-4c33-904f-7fbceee60e82" OR "4a72393b-319f-44bc-84c3-ba54dcb3b6b4") and winlog.event_id:"5441" and message: "Custom Outbound Filter"

Kusto Query:

Event
| where EventID == 5441
| where EventData has "s.m.p.e.n.g...e"

The above query covers Microsoft defender rule being created. Similar logic can be created for the respective EDRs. As I get access to other EDRs for testing, I'll update this.

Below is a snippet indicating a sample Event ID.

Interestingly, the author has hardcoded the GUIDs for Layer, Filter and Filter Name in the code. These are reflected in event logs (when the requisite policy is enabled) and the system has rebooted post the attack.

However, as corrected by Chris (the author of the tool), the GUIDs are default GUIDs that are given by Microsoft. Hence using the filter name to detect

The following queries can be used to detect activity which leverages hardcoded GUIDs.

Kibana Query:

message:("Custom Outbound Filter") and winlog.event_id:"5441"

Kusto Query:

Event
| where EventID == "5441"
| where EventData has_any ("Custom Outbound Filter")

This detection technique has to be used with caution as it's pretty easy to change the hardcoded values and recompile to evade this technique.

Finally, to detect the tool, we can use the following Yara rule. This tool can be used along with your own security tool (many major EDRs provide way to use Yara) or OsQuery or Yara | GitHub to scan files on the system.

import "pe"
rule edr_silencer_hacktool {
    meta:
        author = "Subhash Popuri <@pbssubhash>"
        filetype = "Executable"
        description = "Detects EDR Silencer tool, that's used to essentially supress communication between EDR agent and it's server"
        date = "01/03/2024"
        version = "1.0"
    strings:
        $a1 = "SeDebugPrivilege" fullword ascii 
        $a2 = "FwpmEngineClose0" fullword ascii
        $a3 = "FwpmEngineClose0" fullword ascii
	$edr1 = "MsMpEng.exe" fullword ascii
	$edr2 = "MsSense.exe" fullword ascii
	$edr3 = "SenseIR.exe" fullword ascii
	$edr4 = "SenseNdr.exe" fullword ascii
	$edr5 = "SenseNdr.exe" fullword ascii
	$edr6 = "SenseCncProxy.exe" fullword ascii
	$edr7 = "elastic-agent.exe" fullword ascii
	$edr8 = "elastic-endpoint.exe" fullword ascii
    condition:
        pe.is_pe and all of ($a*) and all of ($edr*)
}

It's important to understand that it's fairly easy to modify an executable to evade Yara rule. Usage of packers (or sophisticated loaders) can be used to achieve the same. However, in many cases these are robust enough to stop lazy adversaries.

This, along with other rules that I've created can be accessed here: Blue Sig | GitHub.

⏩ 5. Windows Filtering Platform blocking a connection.

Windows provides an Event log entry for every time a connection was blocked due to an existing rule. For more information, please check this: Event ID 5157. However, this event is known to be extremely noisy and is not recommended. Hence, use it at your own risk and only after prior testing as this would do more harm than good by overwriting important events.

💀 Variants in the wild

So far 2 variants of the same tool were identified in the wild, uploaded to Virus Total. The page might be updated with future instances of identification.

Hashes of identified files:

  • 3b2de5c23a09cee3661dd8f499d43ca5275159c64bd567cfcc133aceac5b2573

  • 08d7aa59bd14b270d8d0a7a757d796248dae7a8ce2f82a8dc7a3b882ff4170a9

  • c9b25e4425550d311d41de08e254c55945d4b0ec3206192d5c0454c3926e3d43

🤘Final Thoughts

EDR Silencer seems to be a very interesting hack tool. If my hunch is correct, we'll see more of this technique, many more variants of the same tool in sophisticated attacks.

If you see something wrong or if you feel there's a better implementation of the same or have general feedback, please reach out to me - LinkedIn or Twitter. I'd be more than happy to take constructive criticism or any feedback that comes my way. It'll help me learn, grow and contribute to the community.

Last updated