EDRChoker Tool Exploits QoS to Disable EDR Security Processes

Key Takeaways

• A new red team tool, EDRChoker, can effectively disable cloud-connected EDR agents.
• The tool exploits Windows’ native Policy-Based Quality of Service (QoS) to throttle EDR process network bandwidth.
• By reducing bandwidth to near-zero, EDRChoker prevents agents from communicating with their cloud infrastructure.
• This technique operates at a lower level in the network stack than traditional firewall-based methods, making it harder to detect.

A novel open-source red team utility named EDRChoker has been introduced, offering an innovative method for neutralizing cloud-dependent Endpoint Detection and Response (EDR) agents. Unlike conventional approaches that involve terminating processes or injecting code, EDRChoker achieves its objective by subtly restricting network bandwidth for EDR processes using Windows’ built-in Policy-Based Quality of Service (QoS) engine.

Developed by security researcher @TwoSevenOneT, this tool leverages Windows Policy-Based Quality of Service (QoS) to severely limit the network throughput of EDR processes, effectively severing their connection to central command and control infrastructure.

Modern EDR systems rely on a continuous, low-latency connection between their endpoint agents and cloud-based management servers. This vital link is fundamental for collecting telemetry data, correlating threats, and enabling administrative control over the endpoints.

EDRChoker Tool Functionality

Disrupting this critical connection renders an EDR agent effectively inert. It becomes incapable of reporting detected threats, receiving updated security policies, or responding to remote commands from security administrators. EDRChoker is specifically designed to exploit this architectural reliance.

Historically, red teams have employed two primary tactics to interrupt EDR communications: configuring Windows Defender Firewall rules or making direct calls to the Windows Filtering Platform (WFP) API.

Tools such as EDRSilencer weaponize the FwpmFilterAdd0 API to register outbound network filters, selectively dropping packets generated by EDR agents.

However, a significant drawback of WFP-based blocking is its forensic visibility. Such actions typically generate packet-block and packet-drop events, which security platforms like Elastic Defend are specifically configured to detect. These events trigger immediate alerts under categories such as “Potential Evasion via Windows Filtering Platform.”

EDRChoker, conversely, uses a different mechanism, exemplified by the command: New-NetQosPolicy -Name "EDRProcess_<GUID>" -AppPathNameMatchCondition "agent.exe" -ThrottleRateActionBitsPerSecond 8 -PolicyStore ActiveStore

By throttling bandwidth to a mere 8 bits per second (bps), even a standard TLS handshake, which requires between 3 KB and 6 KB of certificate chain data, becomes impossible to complete. The EDR agent continuously times out before exchanging a single packet, resulting in connection-dropped errors rather than easily detectable firewall block events.

The core technical advantage of EDRChoker lies in its architectural placement. QoS throttling is enforced by pacer.sys, an NDIS Lightweight Filter Driver that operates directly above the physical Network Interface Card (NIC). This places it one layer below the Windows Filtering Platform (WFP) in the Windows network stack. This stack order is crucial for evasion:

• WFP resides within tcpip.sys at the Transport layer.
• pacer.sys intercepts raw Ethernet frames at the NDIS boundary, closer to the hardware.
• Because it functions at a lower privilege tier in the stack, pacer.sys rules govern packets before WFP-level EDR monitoring tools can observe them.

Researcher @TwoSevenOneT indicated that EDRChoker can accept an input file containing EDR process names. It then automatically generates uniquely named QoS policies (combining the process name with a random GUID for each execution) to prevent identical rule signatures across different deployments.

The tool, which is publicly available on GitHub, offers two primary operational modes:

• Remove mode: Executed without parameters, this mode efficiently purges all previously installed QoS policies.
• Install mode: This mode accepts an input file of EDR process names and creates uniquely named QoS policies (process name + random GUID) that are persistent across system reboots.

The EDRChoker technique highlights a critical architectural vulnerability: EDR solutions that are entirely reliant on cloud connectivity inherently possess a single point of failure. As attackers increasingly delve deeper into the Windows network stack to bypass detection, defenders must extend their monitoring capabilities to equally low levels, or risk operating without vital visibility during critical security incidents.

What You Should Do

• Implement robust network segmentation to limit the impact of compromised endpoints.
• Deploy EDR solutions with strong offline capabilities or local caching of telemetry to maintain visibility even when cloud connectivity is lost.
• Enhance network monitoring at lower layers of the OSI model, potentially including NDIS filter driver activity, to detect unusual QoS policy changes or throttling.
• Regularly audit existing QoS policies on endpoints, especially those applied to security tools, to identify unauthorized modifications.
• Educate security teams on advanced evasion techniques that target network stack components below traditional firewall levels.

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.