Hackers have used red team tool EDRSilencer to make the Windows Filtering Platform (WFP) block a list of EDR products from communicating with their management consoles. this software can affect any Windows workstation or Windows server that runs an EDR.
EDR Silencer uses the WFP to block outgoing traffic from EDR processes that are currently operating. It was inspired by MDSec's NightHawk FireBlock application.
“The WFP is a powerful framework built into Windows for creating network filtering and security applications,” Trend Micro researchers said. “It provides APIs for developers to define custom rules to monitor, block, or modify network traffic based on various criteria, such as IP addresses, ports, protocols, and applications.”
In order to prevent security software from providing telemetry to their management consoles, EDRSilencer exploits WFP by dynamically recognizing active EDR processes and establishing persistent WFP filters to block their outgoing network interactions on both IPv4 and IPv6.
To prevent outbound traffic from such processes by configuring WFP filters, the attack involves scanning the system to obtain a list of active processes linked to popular EDR products. Then, EDRSilencer is invoked with the option “blockedr”.
While testing this activity in the ProCircular Lab environment we discovered this “Deleted customWFP provider.” string as a result of the .\EDRSilencer.exe unblockall” command.
Looking at the source code we see the following // Add WFP provider for the filter BEFORE the EDR filters are created.
So, what does all of this even mean?
The program creates its own WFP provider
EventID=5448 Message contains 'Change Type: Add' and Message contains 'Type: Persistent')
We will also see connections being actively blocked by the new WFP provider
(When looking at this alarm search for your EDR provider on the list below)
EventID=5157 Application_Name contains 'sentinelagent.exe'
|
EDR Product |
Process |
|
Carbon Black Cloud |
RepMgr.exe, RepUtils.exe, RepUx.exe, RepWAV.exe, RepWSC.exe |
|
Carbon Black EDR |
cb.exe |
|
Cisco Secure Endpoint (Formerly Cisco AMP) |
sfc.exe |
|
Cybereason |
AmSvc.exe, CrAmTray.exe, CrsSvc.exe, ExecutionPreventionSvc.exe, CybereasonAV.exe |
|
Cylance |
CylanceSvc.exe |
|
Elastic EDR |
winlogbeat.exe, elastic-agent.exe, elastic-endpoint.exe, filebeat.exe |
|
ESET Inspect |
EIConnector.exe, ekrn.exe |
|
FortiEDR |
fortiedr.exe |
|
Harfanglab EDR |
hurukai.exe |
|
Microsoft Defender for Endpoint and Microsoft Defender Antivirus |
MsMpEng.exe, MsSense.exe, SenseIR.exe, SenseNdr.exe, SenseCncProxy.exe, SenseSampleUploader.exe |
|
Palo Alto Networks Traps/Cortex XDR |
Traps.exe, cyserver.exe, CyveraService.exe, CyvrFsFlt.exe |
|
Qualys EDR |
QualysAgent.exe |
|
SentinelOne |
SentinelAgent.exe, SentinelAgentWorker.exe, SentinelServiceHost.exe, SentinelStaticEngine.exe, LogProcessorService.exe, SentinelStaticEngineScanner.exe, SentinelHelperService.exe, SentinelBrowserNativeHost.exe |
|
Tanium |
TaniumClient.exe, TaniumCX.exe, TaniumDetectEngine.exe |
|
Trellix EDR |
xagt.exe |
|
TrendMicro Apex One |
CETASvc.exe, WSCommunicator.exe, EndpointBasecamp.exe, TmListen.exe, Ntrtscan.exe, TmWSCSvc.exe, PccNTMon.exe, TMBMSRV.exe, CNTAoSMgr.exe, TmCCSF.exe |
First, we need to ensure we are collecting the proper EventIDs in this case we need “Audit Filtering Platform Policy Change” Success and Failure “Audit Filtering Platform Connection” Success and Failure, and “Audit Filtering Platform Packet Drop” Success and Failure. These audit policies are not enabled by default in most environments.
With these two logs, we can write a high-fidelity detection looking for the backend behavior of EDRSilencer and not rely on just a static hash detection! Below is a sigma style rule we can use to write this detection:
Resources
- https://cionews.co.in/hackers-abuse-edrsilencer-tool/
- https://www.trendmicro.com/en_us/research/24/j/edrsilencer-disrupting-endpoint-security-solutions.html