EDRChoker Uses Quality of Service Policies to Disrupt EDR Security Processes

A newly released red team EDRChoker tool introduces a novel technique for severing the connection between Endpoint Detection and Response (EDR) agents and their cloud servers, not by blocking packets outright, but by throttling bandwidth so aggressively that agents continuously time out and lose contact with their command infrastructure.

The tool was developed and published by security researcher @TwoSevenOneT, and it targets a fundamental weakness shared by all client-server EDR architectures: without a live server connection, an EDR agent loses most of its telemetry, detection, and response capabilities.

Modern EDRs rely on persistent, low-latency communication with cloud-based servers to stream telemetry, receive updated detection rules, and execute response actions.

EDRChoker Tool Uses Quality of Service Policies

Once that connection breaks, defenders lose visibility, and attackers gain a significant operational window.

Existing EDR connection-blocking techniques have centered on two main approaches: creating outbound rules via Windows Defender Firewall and programming filters through the Windows Filtering Platform (WFP) API, notably used by tools like EDRSilencer.

Both methods, however, have a critical drawback: they generate detectable artifacts. Security platforms like Elastic already ship detection rules that flag WFP events such as packet-block and packet-drop, making these techniques increasingly noisy in monitored environments.

EDRChoker bypasses both methods entirely by leveraging Policy-Based Quality of Service (QoS), a native Windows feature that allows administrators to set outbound bandwidth limits per application or port via Group Policy or PowerShell, TwoSevenOneT said.

The key command used is:

New-NetQosPolicy -Name "EDRProcess" -AppPathNameMatchCondition "edragent.exe" -ThrottleRateActionBitsPerSecond 8 -PolicyStore ActiveStore

Setting a process to just 8 bits per second makes any meaningful network communication impossible.

A standard TLS handshake required before an EDR agent can exchange any data with its server consumes between 3 KB and 6 KB, with certificate chains alone reaching 8,000+ bytes.

Researcher @TwoSevenOneT said that at 8 bps, the handshake never completes within application timeout windows of 2–5 seconds, triggering repeated Connection Timed Out errors.

The technical advantage of this approach lies in the pacer.sys the QoS Packet Scheduler, sits in the Windows network stack. While WFP operates at the kernel transport layer (above NDIS), pacer.sys functions as an NDIS Lightweight Filter Driver, intercepting raw Ethernet frames directly above the network card miniport driver.

This places it below WFP, granting it stronger control over outbound packets and making it largely invisible to tools that only monitor the WFP layer.

EDRChoker accepts an input file containing target EDR process names and creates individual QoS policies for each, appending a random GUID to every policy name to ensure uniqueness across engagements.

The policies persist across reboots. The tool operates in two modes, available on GitHub:

• In testing against Elastic Defend, the agent lost server connectivity immediately after policy creation, preventing the server from sending control commands or collecting logs.
• Removing all policies requires re-running EDRChoker with no parameters.

Mitigation:

Security teams should implement the following mitigations:

• Regularly audit Policy-Based QoS configurations on all endpoints
• Enable PowerShell Script Block Logging and monitor Windows Event Logs for New-NetQosPolicy executions
• Alert on unexpected bandwidth throttling policies targeting security software paths
• Prioritize detections for pre-escalation activity, since EDRChoker requires local administrator privileges to deploy

Follow us on Google News , LinkedIn and X to Get More Instant Updates. Set Cyberpress as a Preferred Source in Google.

The post EDRChoker Uses Quality of Service Policies to Disrupt EDR Security Processes appeared first on Cyber Security News.