红队工具箱里又多了件让人脊背发凉的"暗器"。安全研究员 @TwoSevenOneT 最近扔出的开源项目 EDRChoker，没有走传统绕过路线——不碰进程、不插代码，而是直接调用 Windows 原生自带的基于策略的服务质量（QoS）引擎，把端点检测与响应（EDR）代理的网络带宽掐到接近零。云端大脑收不到遥测，终端触角发不出告警，整套 EDR 体系就像被蒙住眼睛的哨兵，站在原地却形同虚设。
EDR 的命门，其实就系在一根网线上
现代 EDR 平台本质上是个"终端采集 + 云端分析"的分布式架构。代理端持续向云端管理服务器输送进程行为、文件哈希、网络连接等遥测数据；云端完成威胁关联、行为分析后，再反向下发检测策略、隔离指令或远程控制命令。这条连接必须保持低延迟、高可用，稍有中断，终端上的代理就会瞬间沦为"孤岛"——检测到了威胁也报不上去，管理员想远程响应也下不来指令。
老办法越来越容易被抓现行
以往红队要掐断 EDR 通信，主流思路不外乎两条路：改 Windows Defender 防火墙规则，或者调用 Windows 筛选平台（WFP）API。像 EDRsilencer 这类工具就是典型的 WFP 派，通过FwpmFilterAdd0注册出站过滤器，直接把 EDR 代理的数据包丢弃在半路。
这种手法的硬伤在于取证痕迹太重。数据包被拦截会产生明显的packet-block或packet-drop事件，Elastic Defend 等安全平台早就针对"通过 Windows 过滤平台进行潜在规避"这一行为建立了专用检测规则，一旦触发几乎秒级告警。换句话说，传统阻断方式是在告诉 EDR："我在攻击你"，而 EDRChoker 选择的方式是让它"慢慢窒息"。
8 bps 的温柔陷阱：让 TLS 握手永远完不成
EDRChoker 的核心命令看起来并不复杂：
New-NetQosPolicy -Name "EDRProcess_<GUID>" -AppPathNameMatchCondition "agent.exe" -ThrottleRateActionBitsPerSecond 8 -PolicyStore ActiveStore
真正致命的是这个8——8 bps。一次标准的 TLS 握手需要交换 3 KB 到 6 KB 的证书链数据，在每秒 8 比特的速率下，这点数据足够传到地老天荒。EDR 代理还没完成证书交换就会持续超时，连接在静默中断裂。系统日志里留下的只是普通的连接错误，而不是可被规则匹配的防火墙拦截事件，现有检测体系很难把"网速慢"和"恶意规避"划上等号。
协议栈深处的"降维打击"：pacer.sys 比 WFP 藏得更深
EDRChoker 的可怕之处不在于限速本身，而在于它站的位置。QoS 限速由pacer.sys强制执行，这是一个 NDIS 轻量级过滤器驱动，直接运行在物理网卡之上，在整个 Windows 网络协议栈里比 WFP 还要靠下。
两者的层级差异决定了视野边界：WFP 嵌在tcpip.sys传输层内部，处理的是已经解包后的会话数据；而pacer.sys在 NDIS 边界拦截的是原始以太网帧，更贴近硬件。由于它处于更低的特权层级，WFP 级别的 EDR 监控工具根本看不到、也管不到这里的数据包。攻击者不是在绕过监控，而是直接钻到了监控探头的"视线死角"。
随机 GUID + 持久化：既隐蔽又难清理
@TwoSevenOneT 在工具设计上也花了不少心思。EDRChoker 接受一份 EDR 进程名称列表作为输入，每次运行都会自动生成"进程名 + 随机 GUID"的复合策略名，确保不同环境、不同批次部署都不会留下重复的规则签名，增加了批量检测和特征狩猎的难度。
工具提供两种运行模式。直接执行不带任何参数时，它会进入移除模式，自动扫清系统中所有已安装的 QoS 策略，方便红队快速擦除痕迹；带输入文件执行时则进入安装模式，为指定进程创建限速规则，且这些策略写入ActiveStore，系统重启后依旧生效，不需要常驻内存或反复部署。
给防御方的冷思考：云原生 EDR 的单点故障
EDRChoker 的走红不只是红队的狂欢，它更像一面镜子，照出了当前云原生安全架构的一个隐性软肋——过度依赖云端连接。当所有检测逻辑、威胁情报、响应指令都集中在云端，终端代理一旦"断网"就变成无头苍蝇，这种设计天然存在单点故障风险。
攻击者已经证明，他们会持续向 Windows 网络栈的更深处挖掘以逃避检测。如果防御方仍然只盯着应用层和传输层的可见性，而不去关注 NDIS 层、驱动层甚至网卡层的异常行为，那在关键时刻，安全团队很可能手握控制台，却对终端现场发生的一切一无所知。真正的纵深防御，不该在协议栈的半山腰就停止架设监控探头。
