Look, I need to be straight with you — my data on this is thinner than I'd like. The tooling around QoS policy tampering is a legitimate blind spot, and that matches what I already said about the Windows ETW gap being a real platform deficiency. Here's what I can confirm from evidence, and where the detection fabric is still missing.
1. NDIS LWF / pacer.sys telemetry and QoS policy creation events
I can confirm pacer.sys is the pivot point — the tool sits at the NDIS LWF layer and uses Policy-Based QoS, not WFP, which is why it avoids the packet-block / packet-drop telemetry that tools like EDRSilencer generate. I found the ETW provider GUID for Microsoft-Windows-QoS-Pacer as {88CD9180-4491-4640-B571-E3BEE2527943} in the provider list, but I have no evidence from my searches that this provider emits discrete, queryable events when a new per-process QoS policy is registered via pacer.sys. That's the gap.
What I do know architecturally, though my tools didn't surface a specific detection rule: QoS policies are ultimately persisted through the MSFT_NetQosPolicySettingData WMI CIM class under root\standardcimv2. My prior data left an open question about whether CIM namespace mutation tracing against that class reliably surfaces EDRChoker activity across all Windows versions. I still don't have a firm answer — but that's where I'd hunt. A SOC should be instrumenting WMI activity traces for mutations on MSFT_NetQosPolicySettingData, specifically CREATEINSTANCE or MODIFYINSTANCE operations where the Name or AppPathName targets an EDR binary path.
As for dedicated Windows Event Log IDs for unauthorized QoS policy creation: our database has no mapping. QoS policy changes don't appear to write a clean, single event ID you can overlay on a SIEM dashboard. If anyone at this table has evidence otherwise, I want to see it.
2. Anomalous per-process bandwidth cap in telemetry
I have no published detection query or filter logic from my tool results. But based on the confirmed 8 bps throttle figure, here's the telemetry pattern you hunt for: connecting EDR processes exhibiting sustained TCP retransmits, TLS handshake timeouts, and zero effective throughput — not intermittent drops, but a flatline just above zero. Look at TcpConnectionEstaVersusBytesSent ratios approaching zero for processes like MsSense.exe, CylanceSvc.exe, or SentinelAgent.exe while every other process on the same host maintains normal throughput.
If your EDR or NDR platform exposes per-process network metrics, the filter logic is: identify processes where egress bytes/sec < 50 for > 60 seconds, TLS handshake failures spike, and no corresponding WFP block or firewall deny events are present. That's your cap signature. But I emphasize: I didn't find a prebuilt Sigma, KQL, or Splunk rule confirming this in the wild. You'd be writing custom telemetry.
3. EDRChoker timeout vs. legitimate disruption
This one I can give you a hard discriminator. Legitimate network disruption — upstream link saturation, DNS failure, proxy outage — is system-wide. It doesn't discriminate by executable path. EDRChoker is surgical: only the EDR agent's process gets throttled. So the signature is a timeout pattern that's sharply bounded to specific security-agent processes while browser traffic, lateral movement tools, or attacker C2 channels on the same host flow normally.
Additionally, EDRChoker induces TLS handshake timeouts, not RST packets or ICMP unreachables. A real network outage usually surfaces at multiple OSI layers. Here, the TCP three-way handshake likely completes, but the TLS exchange collapses because the cert payload can't traverse an 8 bps pipe. So you see connection-open events with zero TLS success, repeated at regular retry intervals, and only for the EDR agent's executable identity.
Bottom line: This technique works because detection hasn't caught up to the telemetry gap. The Windows QoS subsystem doesn't emit clean audit events for process-level throttling, and the NDIS LWF path is largely invisible to standard host-based network monitoring. If you're building detection, you're either building WMI CIM mutation monitors or behavioral anomaly baselining on per-process throughput — and both are custom engineering, not vendor checkbox features.