---
title: "The traffic cop EDRs hire to guard the network can be bribed to cut their phone line"
description: "Researchers show how the Windows Filtering Platform, used by security tools themselves, can be turned against them"
author: "Penny Quirke"
published: 2026-09-27T04:34:05.885Z
modified: 2026-09-27T05:04:59Z
url: https://rews.cc/a/the-traffic-cop-edrs-hire-to-guard-the-network-can-be-bribed-713890
language: en
tags: ["cybersecurity", "edr", "windows", "security", "ai", "tech"]
publisher: "Rews (https://rews.cc)"
---

# The traffic cop EDRs hire to guard the network can be bribed to cut their phone line

*Researchers show how the Windows Filtering Platform, used by security tools themselves, can be turned against them*

By Penny Quirke · September 27, 2026 · https://rews.cc/a/the-traffic-cop-edrs-hire-to-guard-the-network-can-be-bribed-713890

## In brief

- Researchers show the Windows Filtering Platform can be used to blind EDRs or bypass their isolation mode
- WFP, introduced with Windows Vista, operates below the Windows Firewall, itself just a WFP consumer
- Filter precedence is decided by weights and flags; a hard BLOCK beats every softer decision
- Cloud-reliant EDRs can lose detection ability if an admin adds a high-weight BLOCK to their C2 traffic
- Bypassing WFP rules requires administrative privileges on the machine

Endpoint Detection and Response software is sold as the sober adult at the endpoint party: it monitors, it blocks, it calls for backup. The awkward news from researchers writing on SCRT’s blog.scrt.ch is that one of the tools EDRs rely on most heavily — the Windows Filtering Platform, or WFP — can be persuaded to work for the other team. In their testing, certain EDRs showed visibly reduced detection capabilities when disconnected from their cloud infrastructure, and the same WFP machinery that powers an EDR’s “isolation” mode can be manipulated to wriggle out of that isolation. Both tricks amount to the same outcome: a blinded watchdog.

WFP arrived with Windows Vista, replacing the older, crustier packet-filtering schemes — NDIS hooking in kernel mode, Winsock SPI hooking in user mode — that were harder to maintain and less flexible. It lives in fwpuclnt.dll, hooks deeply into the network stack, and offers permit/block decisions based on finely grained conditions: IP addresses, ports, process names, application paths. Notably, it operates *below* the Windows Firewall, which is itself merely a consumer of the WFP API — a satisfying demotion for a product that spent years as the face of Windows security. Windows Defender Firewall, third-party antivirus and EDR systems, intrusion prevention tools, even parental controls all use it.

## Meet the bureaucracy of packets

The platform is organized like a well-run ministry. A *filter* is a rule: conditions to match, an action (permit, block, or hand off to a kernel driver via a “callout”), flags, and a weight. Filters live in *sublayers* — containers with their own weights — which sit at *layers*, specific checkpoints in the network stack where traffic is inspected. *Providers* group sublayers and filters by application or service. And a *terminating callout* is the final word: an irreversible permit-or-block verdict from a driver that no other filter can override. The flagship layers for security products include FWPM\_LAYER\_ALE\_AUTH\_RECV\_ACCEPT and FWPM\_LAYER\_ALE\_AUTH\_CONNECT, the Application Layer Enforcement gates for incoming and outgoing connections.

Order of operations is where the devil sets up camp. The engine walks sublayers by priority, then filters by weight, highest first, stopping as soon as a definitive PERMIT or BLOCK matches. BLOCK beats PERMIT. And a flag called FWPM\_FILTER\_FLAG\_CLEAR\_ACTION\_RIGHT hardens a decision: the researchers summarize the pecking order as a hard BLOCK outranking a hard PERMIT, which outranks a soft BLOCK, which trumps a soft PERMIT. Which means a packet can sail through two sublayers that approve it and still be stopped by a single sublayer that objects — consensus counts for nothing here.

EDRs, meanwhile, come in two intellectual breeds. Local-intelligence EDRs keep their detection logic on the endpoint: effective even when the machine is cut off from the internet, but exposed to reverse engineering and local tampering. Cloud-reliant EDRs keep their brains and threat intelligence off-box: resistant to endpoint meddling and constantly updated, but lose a great deal of their sparkle — telemetry, advanced analysis — when the cloud umbilical is severed. The researchers focused on the second breed’s dependence, and on bending the local rules of both.

The attack, in outline, is bureaucratic coup. Many EDRs install WFP PERMIT rules so their own agents can reach their cloud management and intelligence platforms. If those rules are set with a low weight, or without the CLEAR\_ACTION\_RIGHT flag, their “permission” is negotiable. An attacker with administrative privileges enumerates the EDR’s rules, identifies its C2 permits, and adds a BLOCK filter aimed at the EDR’s cloud IP addresses — either weighted higher than the EDR’s own rule, or placed in another sublayer with CLEAR\_ACTION\_RIGHT set. The EDR keeps running, features intact, but its calls home now fall into a hole it built the ladder for.

The same lever works in reverse against endpoint isolation — the panic-button feature EDRs use to quarantine a compromised machine’s network access — because that feature is implemented with the very same WFP rules. The one dignity preserved, the researchers note, is that none of this is a free lunch: overriding another program’s WFP configuration takes administrative privileges. Windows will happily let an administrator scribble all over its filtering stack. It simply assumes, perhaps optimistically, that the administrator is on the side of the good.
