Keypoints
- EDRSilencer enumerates running processes associated with many commercial EDR products and builds filters for those executables.
- It uses the Windows Filtering Platform (WFP) APIs to create application-specific outbound network filters on both IPv4 and IPv6 layers.
- Filters are marked persistent so they remain active after the tool exits or the system reboots.
- The tool exposes a CLI with commands: blockedr (auto-block detected EDRs), block <path> (block a specific binary), unblock <filter id>, and unblockall.
- Verification can be performed with EDRNoiseMaker to list executables silenced by custom WFP outbound filters.
- Initial use of blockedr may miss non‑hardcoded EDR executables; blocking by full binary path is required to fully silence some agents.
MITRE Techniques
- [T1057] Process Discovery – Scans the system to compile a list of running processes associated with common EDR products (‘EDRSilencer scans the system to compile a list of running processes associated with common EDR products.’)
- [T1059] Command and Scripting Interpreter – Attacker runs the tool with arguments to apply filters (‘the attacker runs EDRSilencer using the blockedr argument to block traffic from all detected EDR processes.’)
- [T1543.00] Create or Modify System Process – Configures system-level filtering to alter normal process network behavior (‘EDRSilencer configures WFP filters to block outbound network communications for both IPv4 and IPv6 protocols.’)
- [T1562.001] Impair Defenses: Disable or Modify Tools – Prevents EDRs from reporting telemetry or alerts to management consoles (‘EDRSilencer disrupts the transmission of telemetry or alerts to EDR management consoles’)
- [T1569.002] Network Traffic Filtering – Uses WFP to block outbound communications from targeted EDR processes (‘creates WFP filters to block their outbound communication’)
- [T1498] Network Denial of Service – Disrupts EDR communications to hinder detection (‘EDR tools are rendered ineffective as they are unable to send telemetry, alerts, or other data to their management consoles.’)
- [T1499] Endpoint Denial of Service – Renders endpoint security components unable to report status or telemetry (‘EDR tools are rendered ineffective as they are unable to send telemetry, alerts, or other data to their management consoles.’)
Indicators of Compromise
- [SHA256] EDRSilencer sample – 721af117726af1385c08cc6f49a801f3cf3f057d9fd26fcec2749455567888e7
- [Process names] Targeted EDR executables – MsMpEng.exe, SentinelAgent.exe, and dozens of other EDR/AV-related executables (e.g., RepMgr.exe, cb.exe, sfc.exe, elastic-agent.exe)
- [URLs] Reference/tooling repositories used in analysis – https://github.com/netero1010/EDRSilencer, https://github.com/amjcyber/EDRNoiseMaker
EDRSilencer operates by enumerating running processes to identify EDR/AV binaries, then leverages the Windows Filtering Platform (WFP) APIs to programmatically create application-scoped outbound network filters on both IPv4 and IPv6 stack layers. These filters are configured as persistent providers/rules so they survive process exit and system reboot; they target application connection parameters to prevent specified executables from establishing outbound telemetry or alert connections to management consoles.
The tool exposes a small command-line interface: blockedr to auto-block all detected EDR processes, block <path> to add a WFP rule for a specific binary path, unblock <filter id> to remove a single rule, and unblockall to remove everything created by the tool. Verification during testing used EDRNoiseMaker to enumerate executables silenced by WFP filters; initial use of blockedr missed some vendor-specific executables not in the hardcoded list, so operators needed to capture full binary paths (e.g., from Task Manager) and apply block <path> to fully silence the agent. When properly applied, the endpoint ceased sending logs and appeared disconnected in the management portal while ransomware activity ran on the device.
From an operational standpoint, defenders can reproduce and validate silencing by inspecting WFP filter tables and using tools like EDRNoiseMaker to list blocked executables; remediation requires removing the persistent WFP rules (unblock/unblockall or manual WFP rule deletion). The persistent nature of the filters and the need to block by full binary path means thorough process discovery and monitoring of WFP rule changes are essential when hunting for this technique.