Modern Endpoint Detection and Response (EDR) agents rely heavily on constant, low-latency communication with cloud management consoles to stream telemetry and receive threat intelligence updates. However, a newly released open-source offensive tool is exposing a critical blind spot in how these agents maintain their network connections. Developed by security researcher @TwoSevenOneT, the EDRChoker network throttling tool introduces a highly sophisticated evasion technique that blinds cloud-connected security agents. Instead of terminating processes or risking detection through memory injection, the tool exploits Windows’ native Policy-Based Quality of Service (QoS) engine to quietly choke an EDR agent’s network bandwidth to zero.

Key Details

The architectural foundation of enterprise endpoint security relies on a continuous link between local agents and cloud backend servers. When this connection is severed, the local agent is effectively isolated—unable to transmit telemetry logs, alert security operation centers (SOCs) of live malicious activity, or receive remote containment commands from administrators.

Historically, red teams and threat actors achieved this isolation by creating local Windows Defender Firewall rules or leveraging the Windows Filtering Platform (WFP) API via tools like EDRSilencer. The foundational flaw with these legacy approaches is visibility. Modern defense-in-depth platforms actively monitor WFP modifications, immediately generating high-severity telemetry alerts when unexpected applications add drop filters. EDRChoker bypasses this entire telemetry layer by manipulating native QoS traffic prioritization policies instead of blocking packets outright.

[Traditional WFP Evasion] ──► FwpmFilterAdd0 API ──► Drops Packets ──► Generates 'Packet-Drop' Logs ──► SOC Alert
                                                                                                            
[EDRChoker QoS Evasion]  ──► pacer.sys (NDIS)    ──► Throttles to 8 bps ──► TLS Handshake Timeout    ──► Stealth Connection Drop

Technical Analysis

EDRChoker functions by creating localized QoS throttling rules that restrict the target security process to an unworkable bandwidth allocation, such as 8 bits per second (bps). In a live execution scenario, a standard TLS handshake requires the exchange of digital certificate chains that generally range between 3 KB and 6 KB. By restricting the transfer speed to 8 bps, a handshake becomes mathematically impossible to complete within standard application network thresholds. The EDR agent continuously times out, generating a generic “connection dropped” or communication timeout error rather than an explicit administrative block event.

The primary defensive advantage of this technique lies within its placement inside the Windows network architecture. Traditional EFP security agents monitor traffic inside tcpip.sys at the Transport layer. In contrast, QoS policies are managed and enforced by pacer.sys, an NDIS (Network Driver Interface Specification) Lightweight Filter Driver operating directly above the physical Network Interface Card (NIC).

Because pacer.sys processes raw Ethernet frames at a lower tier of the system network stack than WFP, its bandwidth constraints govern packets before they ever reach the logical monitoring loops of standard EDR hooks.

[Application Layer]       EDR Agent / User Processes
         │
         ▼
[Transport Layer]         tcpip.sys / Windows Filtering Platform (WFP Monitoring Hooks)
         │
         ▼
[NDIS Boundary Layer]     pacer.sys (QoS Throttling Enforced Here)
         │
         ▼
[Physical Hardware]       Network Interface Card (NIC)

The utility, currently hosted publicly on GitHub, features a modular architecture operating across two core operational profiles:

• Install Mode: Accepts a target configuration file containing known EDR executable names. The tool programmatically builds a unique QoS rule mapped to a randomized GUID string (e.g., New-NetQosPolicy -Name "EDRProcess_<GUID>"), altering file signatures to prevent static string detection. These rules are committed to the active registry, ensuring the throttle persists across system reboots.
• Remove Mode: Executed with no trailing parameters, this operational state purges all installed QoS policy parameters, cleanly restoring standard system telemetry pathways during cleanup phases.

Impact and Risks

The broader deployment of QoS-based throttling tools presents an immediate risk to enterprise security infrastructure. Because the technique triggers standard hardware timeouts rather than network security events, automated detection logic within Security Information and Event Management (SIEM) systems remains blind to the disruption.

The practical implications include:

• Telemetry Blackout Windows: Attackers can deploy the tool to halt cloud data streaming immediately prior to running loud post-exploitation tools, credential dumpers, or ransomware binaries.
• Defensive Tool Neutralization: Live threat-hunting teams lose the ability to isolate an infected host remotely via their EDR console, as the inbound isolation command cannot traverse the choked network link.

Expert Recommendations

To counter deep network stack evasion tactics, security engineers and infrastructure administrators should implement several layer-neutral detection and configuration rules:

• Monitor QoS Registry Modifications: Configure EDR or auditing tools to flag unexpected registry updates within the network QoS policy branches, specifically looking for executions targeting HKEY_LOCAL_MACHINE\CurrentControlSet\Services\Profilers or the generation of New-NetQosPolicy commands.
• Enforce Endpoint Least Privilege: Restrict local administrative privileges across developer and corporate endpoints to prevent the unauthorized installation of persistent system-level network drivers or configuration modifications.
• Establish EDR Cloud Heartbeat Alerts: Configure cloud management consoles to trigger immediate administrative warnings if an active, online endpoint stops checking in or misses its automated heartbeat threshold for more than a few consecutive minutes.
• Baseline NDIS Driver Activity: Utilize application control mechanisms to audit or prevent unauthorized utilities from interacting with the underlying pacer.sys filter driver controls.

Industry Context

The release of EDRChoker reflects a wider, ongoing paradigm shift in the offensive landscape. As cybersecurity platforms achieve deeper introspection into user-mode processes and standard API calls, red teams and threat actors are descending lower into operating system kernels and hardware abstraction layers. Exploiting legitimate, native administrative frameworks like Windows Policy-Based QoS represents the next evolution of living-off-the-land (LotL) techniques, transforming standard optimization protocols into powerful evasion mechanisms.

Conclusion

The emergence of the EDRChoker methodology underscores a fundamental vulnerabilities in cloud-dependent security architectures. When endpoint agents lose their low-latency connection to centralized cloud intelligence layers, their defensive value decreases exponentially. For enterprise defenders, staying ahead of these subterranean evasion strategies requires moving detection parameters beyond user-space process logs and expanding visibility directly into low-level network stack behaviors.

FAQ SECTION

1. What makes EDRChoker different from traditional EDR silencers?

Traditional silencers typically use Windows Filtering Platform (WFP) APIs to block outbound network packets, which creates distinct “packet-drop” events that security tools can easily detect. EDRChoker instead throttles the bandwidth of target processes down to 8 bps using the native Windows QoS engine, causing connections to naturally time out without creating block logs.

2. How does operating within pacer.sys benefit an attacker?

The pacer.sys driver operates at the NDIS layer of the Windows network stack, which is physically closer to the hardware network interface than the transport layers monitored by standard WFP filtering hooks. This positioning allows it to limit data packets before traditional firewall monitoring filters ever process them.

3. Will restarting a compromised machine remove the EDRChoker rules?

No. When executed in install mode, EDRChoker writes the custom QoS throttling configurations directly into the system’s persistent policy stores, meaning the bandwidth restrictions will continue to affect the specified security processes even after a system reboot.

4. How can a security operations center (SOC) detect this attack if no firewall logs are made?

While network block logs are avoided, the attack leaves footprints elsewhere. SOC teams can detect the vector by configuring endpoint detection rules to monitor for the creation of new network QoS policies, auditing command-line parameters containing New-NetQosPolicy, and setting up cloud alerts for unexpected agent disconnects.

5. Is there an official patch available to prevent this technique?

Because EDRChoker abuses legitimate, built-in Windows Policy-Based Quality of Service features designed for network traffic optimization, there is no vulnerability patch to apply. Mitigation relies entirely on restricting local administrative privileges and hardening endpoint monitoring configurations.