In Windows, a Quality of Service (QoS) policy is a rule that handles outbound network traffic. Specifically, it is used to cap the outbound bandwidth of a process, port, or protocol. Organizations can configure QoS policies through Group Policies, MDM, or PowerShell. Threat actors with elevated privileges on the asset can point a QoS policy at an EDR agent and set the rate to effectively zero, limiting the capability of the agent to generate telemetry in the cloud console. Playbook Execution of the following command will create a new QoS policy to limit the bandwidth of the FTP application via PowerShell: New-NetQosPolicy -Name "FTP" -AppPathNameMatchCondition "ftp.exe" -ThrottleRateActionBitsPerSecond 1MB -PolicyStore ActiveStore Add New QoS Policy The ThrottleRateActionBitsPerSecond parameter defines the maximum outbound bandwidth limit for traffic that matches the application or the protocol. Grimur Grimursson demonstrated in an article that it is possible to abuse the ThrottleRateActionBitsPerSecond to prevent telemetry generated in the EDR cloud console. It should be noted that the technique doesn’t impair EDR rules, since some EDRs like CrowdStrike have their rules, stack deployed locally in the endpoints. Setting the ThrottleRateActionBitsPerSecond to 1KBps limits bandwidth to 8,000 bits per second disrupting Internet connectivity for many modern applications like EDR. A normal TLS 1.3 HTTPS connection with server authentication only, requires 3-6 KB for a small certificate chain and 6-15 KB for a larger certificate chain. This will cause the EDR agent to timeout since it will not be possible to complete the full TLS handshake due to the bandwidth limitation. The technique is different compared to the EDR Silencing because packets are not dropped but limited due to the very low bandwidth. A proof of concept was released called EDRChoker that takes a list of common EDR process names and creates QoS policies that restrict the bandwidth of these processes to 8 bits per second. It should be noted that Administrator-level privileges are required to create Quality of Service policies. EDRChoker.exe list.txt EDRChoker – Proof of Concept According to the code, the proof-of-concept creates the Quality-of-Service policy using WMI. Initially, a connection is established to the CIM namespace where the QoS provider is stored and binds to the NetQoSPolicySettingData class. A new policy object is created, and the owner is set to 1. This is equivalent to the New-NetQoSPolicy -PolicyStore ActiveStore command. The policy name is also randomized using 8 characters length. static void CreateThrottleCurlPolicyPureWmi(string procName) { try { var scope = new ManagementScope(@"\\.\ROOT\StandardCimv2"); scope.Connect(); var managementPath = new ManagementPath("MSFT_NetQosPolicySettingData"); var policyClass = new ManagementClass(scope, managementPath, null); // Construct a raw, detached memory object mapping the exact schema fields ManagementObject newPolicy = policyClass.CreateInstance(); newPolicy["Owner"] = 1; string guid = Guid.NewGuid().ToString(); string policyName = Path.GetRandomFileName().Replace(".", "").Substring(0, 8); newPolicy["Name"] = policyName; The following diagram illustrates how QoS policies can be used to restrict EDR agents reporting back to the cloud console: QoS Policies – Diagram The technique abstract is displayed below: Technique Abstract The playbook of the technique can be found below: [[Playbook.QoS Policies]] id = "1.0.0" name = "1.0.0 - QoS Policies" description = "EDR agent communucation disruption via QoS Policies" tooling.name = "EDRChoker" tooling.references = [ "https://github.com/TwoSevenOneT/EDRChoker" ] executionSteps = [ "New-NetQosPolicy -Name "ipurple" -AppPathNameMatchCondition "ipurple.exe" -ThrottleRateActionBitsPerSecond 1MB -PolicyStore ActiveStore" ] executionRequirements = [ "Local Administrator" ] Detection The technique of abusing QoS policies to restrict EDR agents from communicating back to their cloud server introduces multiple challenges for cyber defense teams. Threat actors could directly abuse the New-NetQoSPolicy cmdlet or utilize WMI to create new policies on the asset. Therefore, there is no need to introduce new binaries on the host. The other challenge is that EDR agents might continue to appear as healthy. It is recommended that SOC teams should not rely on EDR queries to engineer detections, but focus on other suspicious patterns, especially if QoS policies are not used in their environments. Non-persistent Quality of Service policies are stored in ActiveStore , and SOC teams could use the Get-NetQoSPolicy cmdlet to review policies either proactively or reactively during an incident. Get-NetQoSPolicy -PolicyStore ActiveStore Retrieve QoS Policies – ActiveStore For hosts that might contain multiple policies, the following PowerShell code could be used to format the output in a table using only the Name , PolicyStore , AppPathName , and ThrottleRate . $stores ...