EDRChoker: The EDR Bypass Playbook Adds QoS Throttling

Published: June 10, 2026
Tags: Defense Evasion, EDR Bypass, Red Team, T1562.001, Windows Internals

Introduction

For years, the conversation around EDR bypass has centered on one of two approaches: kill the agent process outright, or cut its network access. Tools in both categories have matured significantly, and defenders have responded with increasingly robust detections. Firewall-based blocks leave packet-drop artifacts. BYOVD attacks require dropping a kernel driver to disk. Neither approach is quiet anymore.

On June 7, 2026, a researcher publishing under the handle @TwoSevenOneT released a tool called EDRChoker that takes a different path entirely. Rather than killing or blocking an EDR agent, EDRChoker starves it. By applying extreme bandwidth throttling at a layer of the Windows network stack that most EDR solutions have never monitored, it causes agents to time out silently and continuously, severing their connection to the server without generating the artifacts defenders are trained to look for. It is one of the more architecturally novel EDR evasion techniques to emerge in recent memory, and understanding it has direct implications for how security teams tune their detection stacks.

The Problem with Existing EDR Bypass Techniques

Before examining how EDRChoker works, it helps to understand what it was designed to improve upon.

Windows Firewall and WFP-based blocking is the most commonly understood approach. A local administrator can create outbound firewall rules targeting specific EDR process binaries, cutting off their telemetry and command-and-control communication. Tools like EDRSilencer implement this programmatically using the FwpmFilterAdd0 API to register WFP filters that prevent EDR processes from sending traffic. The problem is that this leaves traces. When packets are dropped at the WFP layer, event logs capture packet-block and packet-drop entries. Security vendors including Elastic have published detection rules specifically for these WFP-based evasion events.

BYOVD (Bring Your Own Vulnerable Driver) tools like EDRKillShifter, Terminator, and AuKill take the most aggressive approach, loading a known-vulnerable kernel driver to gain elevated privileges and terminate EDR processes entirely. These tools are highly effective but require dropping a driver binary to disk, loading it through a service or other mechanism, and operating at kernel level, all of which create significant detection surface. Microsoft has also expanded its Vulnerable Driver Blocklist, making driver-based attacks an increasingly unreliable choice for operators who need consistency across environments.

Process suspension tools like EDR-Freeze take a driverless approach, using techniques such as WerFaultSecure.exe PPL bypass to place EDR processes into a suspended state without terminating them. These avoid the driver footprint but still manipulate process state in ways that behavioral analytics can surface.

EDRChoker's contribution to this landscape is moving the interference point to a layer where none of these detections apply.

How EDRChoker Works

The Core Idea: Timeout Instead of Block

The insight driving EDRChoker is that you do not need to drop packets to break an EDR agent's connection. You only need to make the connection slow enough that it consistently times out.

Modern applications are built with strict timeout windows to prevent hanging processes. If a TLS handshake cannot complete within roughly 2 to 5 seconds, the application assumes the connection dropped and returns a Connection Timed Out error. A standard TLS handshake, which every EDR agent must complete before it can exchange any data with its management server, requires between 3 KB and 6 KB of data to traverse the wire. Certificate chains alone can push this past 10 KB.

If the bandwidth available to that process is limited to 8 bits per second, that handshake will never complete in time. The agent will fail to connect, retry, fail again, and continue doing so indefinitely while generating no meaningful log artifacts from a network security standpoint. The agent is not dead. It is not suspended. It is just perpetually waiting.

Policy-Based QoS and pacer.sys

The mechanism EDRChoker uses to impose this limit is Policy-Based Quality of Service, a native Windows feature that allows administrators to set outbound bandwidth caps on specific applications, ports, or protocols. QoS policies can be created via Group Policy or PowerShell with a command as simple as:

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

The architectural advantage of this approach comes from where in the Windows network stack QoS enforcement sits. Traffic flowing out of a Windows system moves through the following layers, in order:

1. Application Layer
2. Transport Layer (tcpip.sys)
3. Windows Filtering Platform (WFP)
4. NDIS Boundary
5. pacer.sys (NDIS Lightweight Filter Driver)
6. Network Interface Card (NIC)

The WFP layer, where tools like EDRSilencer operate and where most EDR telemetry monitoring hooks live, sits at position 3. The QoS Packet Scheduler driver pacer.sys sits at position 5, directly above the physical NIC. This means pacer.sys intercepts raw Ethernet frames after WFP has already made its filtering decisions. EDR tools that monitor at the WFP layer never see the throttling happen. There are no blocked packets, no dropped packets, and no WFP filter events to alert on.

The Implementation

EDRChoker is written in C# and uses WMI to create QoS policies via the MSFT_NetQosPolicySettingData class in ROOT\StandardCimv2. For each EDR process name supplied in an input file, it creates a policy with the following key parameters:

• AppPathNameMatchCondition: set to the target EDR process executable
• ThrottleRateAction: set to 8 bits per second (effectively zero throughput)
• IPProtocolMatchCondition: set to 3 (both TCP and UDP)
• NetworkProfile: set to 0 (all network profiles)
• InstanceID: generated as {random-GUID}\{random-name}\ActiveStore

That last point matters for detection evasion. The GUID and policy name are randomized on every run, which means no two deployments produce the same rule signatures. Defenders cannot simply alert on a known policy name. The ActiveStore designation means policies take effect immediately, without requiring a reboot, and they persist across reboots once written.

The tool runs in two modes. Install mode accepts an input file of EDR process names and applies the throttle policies to each. Remove mode, executed with no arguments, queries all MSFT_NetQosPolicySettingData instances and deletes them, cleaning up the deployment cleanly.

The researcher demonstrated the technique against Elastic Defend in a lab environment, confirming that the Elastic agent lost contact with its management server following policy application, and that the server could no longer collect or push commands to the agent.

EDRChoker in Context: The Broader EDR Bypass Landscape

EDRChoker does not exist in isolation. It is the latest entry in a growing family of EDR evasion tools, each attacking a different layer of the defensive stack. Understanding where it fits helps defenders prioritize coverage.

EDRSilencer is EDRChoker's most direct conceptual predecessor, using WFP filters to block outbound EDR traffic entirely. It is effective but well-signatured at this point. Vendors have released detections targeting the specific WFP event artifacts it produces, and the open-source nature of the tool means its process targeting patterns are well-documented.

EDRKillShifter represents the dominant in-the-wild threat today. Originally developed by the RansomHub ransomware group, it uses BYOVD to gain kernel-level privileges and terminate EDR processes entirely. It has been adopted by at least eight distinct ransomware groups including BlackSuit, Medusa, Qilin, DragonForce, Crytox, Lynx, and INC Ransom, making it the most widely deployed EDR killer in active ransomware campaigns.

Terminator and AuKill are older BYOVD tools that abuse specific vulnerable drivers, Zemana for Terminator and the Process Explorer driver for AuKill. Both are well-understood by the security community and heavily signatured, though threat actors continue using them because vulnerable driver loading remains difficult to prevent universally without risking legitimate software breakage.

EDR-Freeze and ColdWer take a driverless approach, suspending EDR processes into a non-functional state using WER (Windows Error Reporting) abuse and PPL bypass techniques. These avoid the kernel driver footprint entirely and represent the same "no kernel required" philosophy that makes EDRChoker attractive.

EDR-Redir also from @TwoSevenOneT's research, abuses BindLink and Cloud Filter APIs to redirect EDR binary paths at the file system layer, breaking the agent without touching either the kernel or the network stack.

The trend across this toolset is clear. Kernel-based techniques (BYOVD) are becoming noisier and more defended. The newest tools are moving to driverless, lower-layer, or novel-mechanism approaches that fall outside the categories defenders have historically monitored. EDRChoker occupies the most architecturally novel position of this group by operating below WFP, without touching process state, and without requiring any driver loading.

MITRE ATT&CK Mapping

Detection Guidance

The author of EDRChoker identified the primary defensive countermeasures in the original release post, and they are worth expanding on.

PowerShell logging. If EDRChoker's underlying technique is replicated via PowerShell rather than the compiled binary (which is trivial given the New-NetQosPolicy cmdlet), Script Block Logging and Module Logging will capture the command including the process name and throttle rate. Alerting on New-NetQosPolicy calls with ThrottleRateActionBitsPerSecond values below a reasonable threshold (say, under 100 KB/s) targeting known security tool process names is a high-fidelity detection opportunity.

WMI activity monitoring. The binary itself interacts directly with MSFT_NetQosPolicySettingData via WMI. Monitoring for WMI queries against ROOT\StandardCimv2 and specifically for creation of MSFT_NetQosPolicySettingData instances with extreme ThrottleRateAction values should be logged and alerted. Sysmon Event ID 19/20/21 (WMI event activity) combined with process context provides a viable detection path.

Periodic QoS policy auditing. Defenders should implement scheduled audits of active QoS policies on endpoints, baselining expected policies and alerting on new entries targeting security tool process names. The command Get-NetQosPolicy provides a straightforward enumeration that can be incorporated into existing endpoint compliance checks.

Pre-escalation detection. EDRChoker requires local administrator rights to execute. The most reliable long-term defense is catching the attacker before they achieve the privilege level needed to run the tool. Monitoring for privilege escalation activity, lateral movement, and credential access patterns upstream of this technique provides earlier warning than trying to detect the QoS manipulation itself.

EDR agent health telemetry. Cloud-connected EDR platforms should be configured to alert when agents go offline or stop reporting. An agent that goes silent is not the same as an agent that is running cleanly. Building dashboards around agent connectivity health and alerting on unexpected disconnection patterns provides a secondary detection layer that is immune to the specific evasion mechanism.

Conclusion

EDRChoker is a well-constructed demonstration of what becomes possible when researchers look at familiar problems from a different layer of the stack. By choosing to timeout rather than block, and by operating through pacer.sys below the WFP layer that virtually all existing detection tools focus on, it sidesteps the artifact patterns that defenders have built their EDR-evasion detections around.

It is currently a red team research tool with no confirmed in-the-wild threat actor adoption. Given the pattern seen with EDRSilencer and EDR-Freeze, that window is likely measured in weeks to months rather than years. The technique requires local admin rights and a built-in Windows feature, it leaves no driver footprint, and it generates no packet-drop events. From an adoption friction standpoint, it is one of the lowest-barrier EDR bypass techniques to emerge in recent memory.

Defenders should treat this as an opportunity to get ahead of adoption. QoS policy creation via WMI and PowerShell are both detectable today, agent health monitoring is a control that can be configured today, and pre-escalation detections that catch threat actors before they reach local admin are always the most valuable investment. The telemetry exists. The question is whether detection engineering teams have it in scope.

References

• TwoSevenOneT. "EDRChoker: Choking The Telemetry Stream to Bypass Defenses." Zero Salarium, June 7, 2026. https://www.zerosalarium.com/2026/06/edrchoker-choking-telemetry-stream-block-edr.html
• TwoSevenOneT. EDRChoker Source Code (Program.cs). GitHub, 2026. https://github.com/TwoSevenOneT/EDRChoker/blob/master/Program.cs
• GBHackers. "EDRChoker Tool Abuses Windows QoS Policies to Disrupt Endpoint Security Tools." June 2026. https://gbhackers.com/edrchoker-tool-abuses-windows-qos-policies/
• CyberSecurityNews. "New EDRChoker Tool Uses Policy-Based Quality of Service to Block EDR Processes." June 2026. https://cybersecuritynews.com/edrchoker-tool/
• Arete Incident Response. "Multiple Threat Groups Using New EDRKillShifter Builds." https://areteir.com/resources/threat-groups-use-updated-edrkillshifter-tool
• MINE2. "EDR Killers 2026: Why Deception Survives When Endpoint Security Dies." March 18, 2026. https://mine2.io/blog/2026-03-18-edr-killers-deception-survives/
• GBHackers. "EDR Killers Broaden Ransomware Tactics, ESET Warns." April 13, 2026. https://gbhackers.com/edr-killers/
• NJCCIC. "Threat Actors Abuse EDRSilencer to Evade Detection." October 2024. https://www.cyber.nj.gov/Home/Components/News/News/1482/214
• Axelarator. "Hunting for EDR-Freeze." October 2025. https://blog.axelarator.net/hunting-for-edr-freeze/
• Vectra AI. "EDR vs XDR: Key Differences and How to Choose (2026)." https://www.vectra.ai/topics/edr-vs-xdr
• Microsoft. "QoS Policy Overview." Windows Server Documentation. https://learn.microsoft.com/en-us/windows-server/networking/technologies/qos/qos-policy-top
• Microsoft. "New-NetQosPolicy." PowerShell Documentation. https://learn.microsoft.com/en-us/powershell/module/netqos/new-netqospolicy?view=windowsserver2025-ps