EDRSilencer by netero1010 is a tool that utilizing Windows Filtering Platform (WFP) to block EDR agent to send out its event data to its server by adding both IPv4 and IPv6 WFP outbound block rule (Administrator access required). That is bad as most of the defenders are heavily depends on the event data from EDR to perform their operation task. In this blog, here are some of the indicators that we can go for if the EDR event data flow has been “blocked” due to any security events (e.g. red teaming or threat actor).
Event Logs
As usual, Security event logs contain event that is related to WFP and now we are focusing on the WFP block events which are EID 5152 and 5157
However, it is not enable by default as enabling it may cause event flood and thus leading to performance issue.
There is a down side on this audit as it won’t immediately log the WFP filter rule add event from EDRSilencer once the EDRSilencer added the WFP rule to block the outbound connection of the EDR process. Those WFP events only log if the user execute any files (e.g. Laucnhing mimikatz.exe) that will trigger EDR to send out event data to its server.
Screenshots above are the events EID 5157 & 5152 that the outbound connection from msmpeng.exe being blocked by the WFP rule (I don’t have EDR in my environment, so I’m just using it as example 🤣)
Thanks for the blog from Soren, there is another event log for the MDE agent which is Microsoft-Windows-SENSE/Operational that will log any failed connection from MDE to the server as EID 5. Probably different EDR will have different ways of logging this kind of event.
Netsh
We also can leverage netsh wfp show netevents command to get the WFP events in xml form.
As we can see in netevents.xml, the string in the <asString> tag is in UTF16-LE format while the <data> tag is the hex representation of string in <asString> tag.
WFPExplorer
WFPExplorer from zodiacon is a GUI tools that can look for the WFP objects. Look for the Filters and we can find the hard coded filter name from EDRSilencer, Custom Outbound Filter in there.
Note that, the ALE App ID bytes in WFPExplorer the matches with the App ID in netviews.xml (<appId> > <data> tag)
Firewall Logs
Firewall logs also contains some useful information (Src & Dest IPs, packet size etc) to support further support the events stored in security event log.
Same with WFP event logs, the windows firewall doesn’t log those packet drop events by default. We have to enable it based on the network profile the we are using.
Once enabled the Log dropped packets, any dropped packet will be logged in %systemroot%\system32\logfiles\firewall\pfirewall.log
Registry Key
The WFP filter data of the EDRSilencer can be found in the service registry key Base Filtering Engine (BFE) which is located as HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter
Some extra reading on the WFP from QuarksLab.
Host Events
EDRSilencer have to load the msmpeng.exein order to pass EDR process into the WFP filter function (Relevant code). So theoretically, the loading process will still get log by EDR.
However, this is just a clue for the investigator that a EDR process has been loaded.
Once it was succeed, we can see the the TCP Disconnect events from the msmpeng.exe and once the WFP block rule disabled, the event data flow to server gets back to normal (TCP Send & TCP Receive). However, this part will be not visible in EDR since the WFP block rule has been applied on the EDR process.
Hopefully, this quick blog post helps and remember check both IPv4 and IPv6 WFP rules, cheers !!
