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.

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