# Silencing the EDR Silencers

Local admins can add Windows Firewall or WFP rules blocking EDR agent traffic, blinding detection while telemetry never reaches the server.

- Payout: Research
- Severity: medium
- Program: Microsoft
- Write-up by: Huntress
- Disclosed: 2024-11-18
- Write-up quality: 6/10
- Original: https://www.huntress.com/blog/silencing-the-edr-silencers
- Library page: https://bugbountylibrary.com/r/blog%3Ahuntress-com-blog-silencing-the-edr-silencers
- Tags: area:os domain:desktop impact:dos kind:research platform:threat-intel sev:medium technique:source-review vuln:dos vuln:misconfiguration

**Target:** Windows Defender Firewall and Windows Filtering Platform registry keys
**Root cause:** Firewall rules and WFP filters can target any process with no restriction, so a local admin can block an EDR agent's inbound/outbound network connections, preventing telemetry upload.
**Steps:**
1. Obtain local administrator rights on the host.
2. Create a block rule against the EDR binary, e.g. via `netsh advfirewall` or the INetFwRule/INetFwRules COM interfaces (as EDRSandblast does with the Add method).
3. Alternatively create persistent WFP filters/providers for IPv4 and IPv6 via `FwpmFilterAdd0` (as EDRSilencer does).
4. Rules land in `HKLM\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules\{GUID}` as REG_SZ (e.g. `v2.32|Action=Block|Active=TRUE|Dir=In|App={application-path}|...`) or as REG_BINARY filter byte arrays.
5. EDR telemetry is collected locally but cannot reach the server for detection.
**How found:** Booth-talk observation that the most common EDR-blinding method is firewall rules; noted the attacker never touches the EDR process directly, only its outbound/inbound connectivity, then traced where rules are persisted in the registry.
**Exploitation:** With admin rights, attacker writes firewall/WFP rules blocking the EDR agent's network path; the agent still logs locally but cannot upload, so detections and investigations never occur.
**Insight:** Firewall and WFP rules persist in predictable registry locations (FirewallRules REG_SZ strings, WFP filter REG_BINARY blobs); defenders can hook RegNtPreSetValueKey to deny or RegNtPostSetValueKey to parse and remove via INetFwRules::Remove / FwpmFilterDeleteById0, or watch WFP event 5447.

## Proof of concept (copied exactly from the original report)

**Firewall rule registry value format**

```
v2.32|Action=Block|Active=TRUE|Dir=In|App={application-path}|Name={firewall-rule-name}|Desc={firewall-rule-name}|
```

**WFP filter deletion API calls**

```
For the filters and providers within the WFP, I leveraged the FwpmFilterDeleteById0 function to delete the filter and the FwpmProviderDeleteByKey0 function to delete the provider.
```