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.
Last updated
EDR Silencer is a very interesting tool. It was open sourced on . The functionality was previously created in Night Hawk, a C2 framework that's sold by MDSec Labs.
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
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:
The following queries can be used to detect activity which leverages hardcoded GUIDs.
Kibana Query:
Kusto Query:
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.
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:
Kusto Query:
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:
Kusto Query:
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.
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.
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
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.
Alternatively, the following auditpol command can be used to enable auditing. AuditPol isn't natively available on Windows. You can download it from .
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 or Yara to scan files on the system.
This, along with other rules that I've created can be accessed here: .
Windows provides an Event log entry for every time a connection was blocked due to an existing rule. For more information, please check this: . 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.
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 - or . 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.
