EDRChoker Tool Blocks EDR Processes Uses Policy-Based

A recently unveiled open-source red team tool, EDRChoker, introduces a novel technique for disrupting cloud-connected Endpoint Detection and Response (EDR) agents. It achieves this not through process termination or code injection, but by quietly choking their network bandwidth to near-zero using Windows’ native Policy-Based Quality of Service (QoS) engine.

Developed by security researcher @TwoSevenOneT, the tool exploits Windows Policy-Based Quality of Service (QoS) to throttle EDR processes to near-zero bandwidth, effectively isolating them from their command infrastructure.

Modern EDR platforms rely on a persistent, low-latency connection between the endpoint agent and a cloud-based management server. That server relationship is central to telemetry collection, threat correlation, and administrative control.

EDRChoker Tool

Sever that connection and the EDR agent effectively goes dark, unable to report detections, receive updated policies, or accept remote commands from administrators. This architectural dependency is precisely what EDRChoker exploits.

Red teams have historically used two primary methods to interrupt EDR communications: Windows Defender Firewall rules and Windows Filtering Platform (WFP) API calls.

Tools like EDRSilencer weaponize the FwpmFilterAdd0 API to register outbound network filters that selectively drop EDR agent packets.

The critical limitation is that forensic visibility WFP-based blocking generates packet-block and packet-drop events that security platforms like Elastic Defend actively detect through dedicated detection rules, raising immediate alerts under the Potential Evasion via Windows Filtering Platform rule category.

New-NetQosPolicy -Name "EDRProcess_<GUID>" -AppPathNameMatchCondition "agent.exe" -ThrottleRateActionBitsPerSecond 8 -PolicyStore ActiveStore

At 8 bps, a standard TLS handshake, which requires between 3 KB and 6 KB of certificate chain data alone, becomes impossible to complete. The EDR agent continuously times out before exchanging a single packet, producing connection-dropped errors rather than detectable firewall block events.

The technical advantage of EDRChoker is architectural. QoS throttling is enforced by pacer.sys, an NDIS Lightweight Filter Driver that operates directly above the physical NIC — one layer below WFP in the Windows network stack. The stack ordering matters:

• WFP sits inside tcpip.sys at the Transport layer
• pacer.sys intercepts raw Ethernet frames at the NDIS boundary, closer to hardware
• Because it operates at a lower privilege tier in the stack, pacer.sys rules govern packets that WFP-level EDR monitoring tools never reach.

Researcher @TwoSevenOneT said that EDRChoker accepts an input file of EDR process names and auto-generates uniquely named QoS policies (process name + random GUID per run) to ensure no two deployments produce identical rule signatures.

The tool, available on GitHub, operates in two modes:

• Remove mode — Executed with no parameters to cleanly purge all installed QoS policies.
• Install mode — Accepts an input file of EDR process names and creates uniquely named QoS policies (process name + random GUID) that survive system reboots.

The EDRChoker technique underscores a critical architectural reality: EDR tools that depend entirely on cloud connectivity carry an inherent single point of failure.

As attackers descend deeper into the Windows network stack to evade detection, defenders must extend monitoring equally deep or risk operating blind precisely when it matters most.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.