EDRChoker: Throttling EDR Agents Through Windows QoS Policies

What EDRChoker Targets and Who It Is Built For

EDRChoker addresses a specific problem: EDR agents depend on a continuous connection to a management server, and if that connection is slow enough for long enough, the agent's own timeout logic takes over. The README describes the goal directly: the tool sets hard bandwidth caps on EDR agents, causing them to always time out, which the author describes as effectively blocking them. The mechanism is Windows Policy-based Quality of Service, and the tool relies on the pacer.sys driver that Windows ships for QoS enforcement.

The intended audience is narrow. This is offensive security tooling: red teamers, penetration testers, and researchers studying endpoint defense evasion. The README lists agents the author says have been successfully tested, including Elastic Defend, Microsoft Defender for Endpoint, Tanium Threat Response Agent, Trend Micro Deep Security Agent, HarfangLab EDR, and Cortex XDR, and invites readers to report other agents they have tested. That list is the author's claim, not an independent evaluation, and it is the only evidence of effectiveness the repository offers. Nothing in the README describes a lab environment, a measurement method, or a detection-rate baseline, so the list should be read as a starting point for your own testing rather than a guarantee.

How the QoS Policy Mechanism Actually Works

The tool does not hook the EDR process, inject into it, or terminate it. It configures Windows' own traffic-shaping machinery against the process by name. Policy-based QoS on Windows associates a bandwidth limit with a set of matching criteria, and pacer.sys is the kernel driver that enforces the resulting packet scheduling. EDRChoker's contribution is automating the creation of those policies from a list of process names, and automating their removal.

The data flow is therefore indirect. The EDR agent continues to run and continues to attempt connections to its management server. What changes is the rate at which its packets leave the host. If the cap is low enough relative to the agent's heartbeat or upload volume, the agent's requests and uploads fail to complete inside its own timeouts, and the README states the result is that the agents always time out. Two properties matter operationally: the README says the rules take effect immediately, and it says they persist after the target reboots Windows. Persistence is the interesting part for an engagement, because it means the effect is not tied to a running process on the attacker's side.

One design consequence is worth naming. Because the policy matches on process name, the tool's precision is only as good as the names in the list file. An agent that renames its process, runs under a generic host process, or splits telemetry across multiple child processes will not be fully covered by a single entry.

Installing EDRChoker and Running a First Throttle

The repository does not document a build or install procedure. There are no release binaries described in the README, and the top-level layout shows a Visual Studio solution (EDRChoker.sln) and project file (EDRChoker.csproj) targeting the .NET Framework, with Program.cs, Utils.cs, App.config and a Properties folder alongside them. The practical route is to open the solution in Visual Studio and build it, or to build the project file directly with MSBuild, which is the standard path for a .NET Framework console project of this shape. The README does not state a required .NET Framework version, so check App.config and the project file before building.

The tool has exactly two invocation modes, both documented in the README. The first takes a list file, one process name per line, and creates a QoS policy for each name:

EDRChoker.exe <ListFile

The README writes the argument as `<ListFile` with a trailing angle bracket and no closing bracket; treat the intended form as a path to a text file, for example a file containing one process name per line. After running it, the README states the policies take effect immediately, so the next step is to observe the target agent's connection behavior rather than to look for a confirmation message, which the README does not describe.

The second mode removes everything the tool installed. Running the binary with no arguments is the documented uninstall:

EDRChoker.exe

The README describes this as removing all installed QoS Policy. Note the scope: it removes all policies the tool installed, not a selected subset. If you created policies in several separate runs, a single bare invocation is the documented way to clear them. There is no documented per-entry removal and no dry-run mode, so a first test on a disposable lab host is the sensible order of operations.

Where the Throttling Approach Breaks Down

The most important limitation is that this is a denial-of-connectivity technique, not a stealth technique. The EDR agent is still running, still loaded in memory, and still visible to anything that inspects running processes or loaded drivers. An agent that queues telemetry locally when it cannot reach its server may deliver that backlog the moment the QoS policy is removed, which turns a temporary gap into a burst of delayed evidence. The README does not discuss buffering behavior, so this is a question each agent's own documentation has to answer.

Process-name matching is the second weak point. Policies keyed to a name do not follow an agent that updates, renames, or relaunches itself under a different image name, and they do not cover telemetry sent by a separate updater or helper binary. The README's list of tested agents is a snapshot; it says nothing about which version of each agent was tested, and agent vendors change process architecture between releases.

Third, this is administrative tooling. Creating Policy-based QoS rules requires elevated rights on the host, so EDRChoker is not a privilege-escalation primitive and does not help an operator who lacks administrator access. It also depends on pacer.sys being present and functioning; the README states the reliance on that driver but does not describe what happens when QoS is disabled by policy or the driver is unavailable. Finally, the repository states no license. That is not a legal opinion, but it does mean the terms under which you may use, modify or redistribute the code are undefined, which matters for anyone planning to use it in commercial engagements.

How EDRChoker Differs From Host Firewall Rules and Network Isolation

The obvious alternative is a Windows Firewall rule blocking the EDR agent's outbound connections to its management server. The difference in approach is substantial. A firewall rule drops packets, so the agent sees connection failures or resets and its own error handling engages quickly. A QoS bandwidth cap keeps the connection alive but starves it, which is why the README frames the outcome as timeouts rather than blocks. Those two failure modes look different to the agent and to the server, and an agent that treats a hard connection refusal as a tamper event may treat a slow connection differently. Which behavior is preferable depends on what you are testing.

A second alternative is network-level isolation: cutting the host off from the management server at a switch, VLAN, or upstream firewall. That is more complete and harder for the endpoint to attribute to a local change, but it requires control of network infrastructure rather than local administrative rights, and it affects every process on the host rather than the named EDR processes. EDRChoker's advantage over both is granularity and locality: it acts on named processes, from the endpoint itself, with rules that the README says persist across reboots. Its disadvantage is that it is the most detectable of the three at the endpoint, because it leaves QoS policy configuration and pacer.sys activity on the host.

Maintenance, Persistence and Cost of Running It

The repository was last pushed on 2026-06-13, and the most recent release, labeled main (Version 1.0), is dated 2026-06-07. The project is not archived. With roughly three months between that push and today, there is no long track record of maintenance to point to, and the README does not describe a support policy, an issue triage process, or a compatibility matrix for Windows versions. Anyone adopting it should assume they may need to read Program.cs and Utils.cs themselves if a target agent's process naming does not match expectations.

Upgrade cost is low in code terms, because the tool is small and the mechanism is a stable Windows feature rather than a moving target. The real recurring cost is operational: every Windows or agent update can change process names or telemetry behavior, so the list file is a living artifact that needs revalidation against each agent version you care about. There is no documented way to enumerate the policies the tool created; the README only offers create-from-list and remove-all, so auditing what is currently applied means inspecting Windows QoS configuration directly.

The license is not stated in the repository. That absence has practical consequences: without a license file, the default position is that the author retains rights, and redistribution or incorporation into another product is not clearly permitted. That is a factual observation about the repository contents, not legal advice; if you need to ship this in a commercial context, ask the author for terms.

Editorial conclusion

EDRChoker is for red teamers and security researchers who already have administrative rights on a Windows host and want to test how an EDR agent behaves when its telemetry channel is starved rather than blocked outright. It is not for production endpoint management, and not for anyone who needs per-connection control or a documented uninstall path beyond running the binary with no arguments. Before adopting it in an engagement, verify three things on a lab host: that your target agent's process name matches the entry you put in the list file, that the QoS rules survive a reboot as the README claims, and that removing the rules with a bare EDRChoker.exe invocation actually clears the policies you created. The license is not stated in the repository, so confirm terms with the author before using it outside personal research.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. TwoSevenOneT/EDRChoker on GitHub