EDRChoker: Choking The Telemetry Stream to Bypass Defenses

 

I. INTRO

In an era where cloud-based Endpoint Detection and Response (EDR) is increasingly common, bypassing/evasion now includes ways to interfere with primarily block the connection between an EDR agent and its server. Once an EDR agent loses contact with its server, much of its power is gone.

In this article I present a technique for interfering with the client–server connection of an EDR. It’s different from EDR connection-blocking methods that use the Windows Firewall or the Windows Filtering Platform (WFP).

I’ll also demo a new tool that implements this technique called EDRChoker.

Find me on X to get the latest pentest and red team tricks that I've been researching: Two Seven One Three (@TwoSevenOneT) / X

II. MAIN

1. Known techniques for blocking EDR connections

When it comes to blocking EDR connections, most readers will likely think of two options right away:

1. Creating Windows Defender Firewall with Advanced Security rules 
2. Creating Windows Filtering Platform (WFP) rules 

The built-in Windows Defender Firewall leverages the Windows Filtering Platform to enforce its rules.

Security tools are bound by the same system mechanics they protect. Because Windows Firewall imposes no restrictions on which processes can be targeted, a local administrator can create custom rules to isolate any application. Red teams can weaponize this capability to add EDR binaries to an outbound blocklist, silently cutting off the agent's telemetry and command-and-control communication.

Microsoft Windows includes built-in protections for its primary security process, MsMpEng.exe (Windows Defender). Attempts to create restrictive firewall rules against this specific binary are typically blocked by the operating system to prevent self-interference or tampering.

Programmatic interaction with the Windows Filtering Platform (WFP) is highly efficient due to its documented API architecture. To programmatically register a network restriction, developers utilize the FwpmFilterAdd0 API function. This specific function handles the creation and enforcement of network filters, a mechanism famously utilized by tools like EDRSilencer to selectively restrict outbound agent communications.

We’ll say a bit more about WFP: using a tool like EDRSilencer will leave traces in the EDR’s logs such as “packet-block, packet-drop, etc". Some security products (for example, Elastic) even include rules for these events. Potential Evasion via Windows Filtering Platform.

2. Policy-based QoS (Quality of Service) throttling rate

Policy-based QoS (Quality of Service) allows you to set an absolute outbound bandwidth limit (throttling rate) for specific applications, ports, or protocols in Windows.

You can throttle specific programs (like a browser or file-transfer tool) or a specific network port via Group Policy or PowerShell with a command like:

New-NetQosPolicy -Name "FTP" -AppPathNameMatchCondition "ftp.exe" -ThrottleRateActionBitsPerSecond 1MB -PolicyStore ActiveStore

The smallest ThrottleRateActionBitsPerSecond I've tested in practice is 8 bits per second.

Setting a modern application to 1 KBps will effectively break its internet connection. A single modern web page request or a secure TLS handshake often requires tens to hundreds of kilobytes. Limiting an app to 1 KBps means it will constantly time out, causing connection drops rather than a smooth, slow stream.

A 1 KBps limit breaks an application because a standard TLS handshake requires tens of kilobytes can be broken down into exact cryptographic data sizes.

A typical, modern TLS handshake averages between 3 KB and 6 KB of total data. However, depending on the website’s configuration, a full handshake can easily push past 10 KB or more.

The bytes are consumed through specific components:

1. Client Hello (~150 to 500 bytes): The initial message containing supported cryptographic algorithms (cipher suites), protocol versions, and a list of structural extensions.
2. Server Hello & Key Exchange (~100 to 500 bytes): The server chooses the cipher suite and passes its cryptographic key parameters back to the client. 
3. The Certificate Chain (~3,000 to 8,000+ bytes): This is where the majority of the data lies. To prove its identity, the web server sends its public certificate alongside the intermediate certificates linking it to a trusted root authority. A single modern certificate signature (using RSA-2048 or ECDSA) and its public key occupy substantial room. If a site passes down a chain of 3 or 4 certificates, this message alone scales the handshake past 6 KB.
4. Finished & Finished Verification (~100 bytes): Short, encrypted validation strings confirming both sides successfully calculated the shared encryption keys.

Most modern applications, APIs, and operating system components are programmed with strict timeouts to prevent hanging processes. If a secure handshake takes more than 2 to 5 seconds just to exchange public security certificates, the application or remote web server will assume the network packet dropped, sever the connection, and return a Connection Timed Out error.

So instead of blocking or dropping the packets an EDR agent sends to its server, if we limit their bandwidth to a very low rate (under 1 KB/s), we can cause the EDR agent to time out whenever it tries to send any packet to the server.

The QoS Packet Scheduler (pacer.sys) operates at a layer even below the Windows Filtering Platform (WFP).

Look at how data moves downward through the Windows network stack when an app transmits a packet:

1. Application Layer: Web browser or program generates data.
2. Transport Layer (tcpip.sys): Data is packaged into TCP/IP frames.
3. Windows Filtering Platform (WFP): Sits directly inside and right below tcpip.sys. It checks rules, looks at process paths, and handles firewalls.
4. NDIS Boundary: The data leaves the core operating system kernel and enters the Network Driver Interface Specification (NDIS) layer. pacer.sys (NDIS Lightweight Filter Driver): Intercepts raw Ethernet frames right above the actual hardware network card miniport driver.
5. Network Interface Card (NIC): Data physically exits your computer.

Because pacer.sys lives at the NDIS layer (Layer 5), it is closer to the hardware network card than WFP (Layer 3).

And the closer to the hardware you operate, the higher your privileges tend to be. Current EDR-blocking tools typically only reach as deep as the WFP layer.

3. Using QoS to choke EDR connections with EDRChoker

With the above in mind, I developed a tool called EDRChoker. It takes a list of common EDR process names and creates QoS policies that limit those processes to 8 bits per second. At that bandwidth an EDR agent becomes effectively isolated from its server.

You can download and test EDRChoker in your lab here:

Github: https://github.com/TwoSevenOneT/EDRChoker

EDRChoker runs in two simple modes:

1. Install mode - runs with an input file containing the EDR process names to block.
2. Remove mode - run EDRChoker with no parameters to remove the QoS policies it installed.

I will test EDRChoker in my existing lab: Elastic Defend.

In real-world environments you often don’t know which EDR you’ll encounter, so it’s best to block them all by listing every target process name in EDRChoker’s input file.

Each process gets its own QoS policy named with the process name plus a random GUID so each run on different targets creates unique rule names. These rules persist across Windows reboots.

After creating the QoS policies, the Elastic client will lose its connection to the server; the server will no longer be able to control that client.

If you want to remove all installed rules, run EDRChoker again with no parameters.

Because EDRChoker works via pacer.sys at a lower layer, if EDRs don't actively check for QoS policies they'll be governed by these rules and get blocked as I demonstrated with Elastic Defend.

Slides video: https://youtu.be/hj05mT-45bo

III. CLOSURE

Client–server EDRs have an inherent weakness: they must maintain server connectivity to be effective. When isolated from their server they lose much of their capability, and administrators can no longer collect or monitor logs from those agents.

Previous EDR-blocking techniques mainly use the Windows Firewall and WFP; those layers aren’t low enough to reliably block arbitrary processes or avoid leaving traces in WFP logs.

The QoS pacer.sys sits at a layer closest to the physical network card, so it exerts stronger control over packets.

EDRChoker uses policy-based Quality of Service (QoS) to throttle EDR agents to the lowest bandwidth; when agents attempt to connect they will consistently time out due to the extremely low bandwidth.

Some defenses against this technique are to regularly audit Policy-based Quality of Service (QoS) on endpoints, use PowerShell Audit logs and the Windows Event Log to track events when policies are created or when a process has a bandwidth limit applied, and—most importantly—monitor for events that occur before an attacker obtains Administrator rights on the client to run EDRChoker.

Author of the article: Two Seven One Three