Detection of “EDRSilencer”
Recently, there’s been quite a buzz in the infosec community about a new tool called “EDRSilencer”. From the tool’s Github description:
“A tool uses Windows Filtering Platform (WFP) to block Endpoint Detection and Response (EDR) agents from reporting security events to the server.”
So how exactly does this tool operate behind the scenes?
The program detects known EDR processes by maintaining a list of EDR-related process names in the edrProcess array. This array contains executables for EDR solutions like Microsoft Defender, Carbon Black, and SentinelOne, among others.
The function isInEdrProcessList() checks if the current running process is an EDR process by comparing it against the entries in this list. If a match is found and the EDR process hasn’t already been flagged (inWfpFlag), the function flags it and returns TRUE.
The core functionality of the program is to block outbound traffic for any detected EDR process using Windows Filtering Platform (WFP). This is achieved through the BlockEdrProcessTraffic() function, which sets up WFP filters based on the detected processes.
- WFP Engine Setup: The function starts by opening the WFP engine using FwpmEngineOpen0(). This is the entry point for interacting with WFP.
- Process Snapshot: The program creates a snapshot of all currently running processes using CreateToolhelp32Snapshot(). It iterates through these processes and checks if any match the EDR process list using the previously defined isInEdrProcessList() function.
- Filter Application: Once an EDR process is detected, WFP filters are created for both IPv4 (FWPM_LAYER_ALE_AUTH_CONNECT_V4) and IPv6 (FWPM_LAYER_ALE_AUTH_CONNECT_V6) network layers. The filters block outbound traffic for that specific process using the FwpmFilterAdd0() API.
This operation blocks any outbound network communication attempts from the detected process by associating the process’s app ID with the blocking filter.
The code also introduces the concept of custom WFP providers to manage the filters. The providerName and providerDescription are used to add a persistent WFP provider. This is essential because filters can be tied to providers, and the custom provider ensures that legitimate WFP providers are not affected.
In order to detect this activity in the simplest form, we have to look at event ID 5157. This event ID will log whenever a WFP connection was blocked, which is exactly what EDRSilencer is doing – adding a WFP block filter.
Unfortunately, Windows Filtering Platform rules cannot be viewed directly from the Windows Firewall UI. WFP operates at a lower level than the Windows Firewall and provides a framework for creating, adding, and managing filtering policies for network traffic.
In order to check the rules that EDRSilencer added, we can open a terminal and type the command “netsh wfp show filters”. This will produce a XML file. In it, you can search the rule that was added based on the ID of the filter that was added by EDRSilencer:
Finally, if we open event viewer and look for event ID 5157, we will see the following:
Those events can easily be sent to the SIEM, and a detection rule can be created to alert when event ID 5157 shows up with the name of the EDR process that you are using.
Now, funny enough, according to Microsoft’s documentation regarding default auditing settings, “Audit Filtering Platform Connection” which logs event ID 5157 is not being recommended not as a baseline audit and not as a “stronger” audit — which is quite surprising!
So, it is up to us to manually enable auditing for this type of activity. We can do it quite easily by typing the following commands (or deploy via group policy):
auditpol /set /subcategory:”Filtering Platform Connection” /success:enable /failure:enable
gpupdate /force
For further reading, you can also refer to the article written by TrendMicro.
If you enjoyed the article, feel free to connect with me!
https://www.linkedin.com/in/daniel-koifman-61072218b/
https://x.com/KoifSec
https://detections.xyz/