Atacantes usam políticas de QoS do Windows para sufocar EDRs e burlar detecção
Aprofundamento CEVIU
Aprofundamento
A técnica de abuso de QoS no Windows não é só mais um 'Living off the Land', é uma evasão de camada de rede que ataca o ponto fraco estrutural da maioria dos EDRs modernos: sua dependência de telemetria contínua para nuvem. Ao limitar a largura de banda de saída do agente a 8 bps, o EDRChoker não apenas atrasa alertas. Ele quebra o TLS 1.3 na raiz: handshakes exigem 3, 15 KB só para certificados, e com taxa tão baixa, o agente nunca completa a conexão. O resultado? O EDR continua 'verde' no console, mas está cego e mudo. Isso é pior que um EDR desligado, porque não gera alerta de falha.
Essa tática se encaixa em uma onda maior de ataques em 2026 que ignoram malware tradicional. Dados do CrowdStrike Global Threat Report 2025 já mostravam que 79% das detecções envolviam zero arquivos maliciosos. Agora, em junho de 2026, temos três vetores convergentes: BYOVD (como no caso Qilin/Warlock), VMs ocultas via QEMU (Sophos, abril) e agora QoS como 'silenciador de rede'. Todos compartilham um padrão: usar mecanismos nativos, privilegiados e mal monitorados para isolar o agente do seu centro de comando, sem tocar no kernel, sem carregar DLLs, sem deixar artefatos de disco.
O que mudou
Em abril, o CEVIU reportou o uso de drivers vulneráveis por Qilin/Warlock para desabilitar EDRs, uma técnica de nível de kernel, com alto risco de BSOD e fácil de flagrar por assinatura de driver. Em junho, o abuso de QoS representa uma mudança radical: é fileless, opera no espaço de usuário, exige apenas privilégios de administrador (não SYSTEM), e não altera o comportamento local do EDR, só sua comunicação. Não é uma evolução da mesma técnica, mas uma alternativa estratégica: menos ruidosa, mais difícil de detectar por EDR, e compatível com ambientes onde BYOVD está bloqueado por Secure Boot ou HVCI.
Por que isso importa
Se um atacante consegue isolar seu EDR do console em menos de 3 segundos com um único comando PowerShell, sua postura de resposta está comprometida antes mesmo do primeiro alerta aparecer. Isso eleva o MTTR para horas ou dias, tempo suficiente para exfiltração de dados, movimento lateral via DCOM (como visto em 20 de abril) ou implantação de ransomware. A ameaça não é só o EDRChoker: é o fato de que frameworks de evasão automatizados, como o revelado pela Sophos X-Ops em 3 de junho, já incorporam módulos para QoS, tornando essa tática acessível até para operadores de nível médio. Ignorar isso significa confiar em um agente que pode estar funcionando perfeitamente, mas dizendo nada ao SOC.
Linha do tempo
Qilin e Warlock usam BYOVD para desabilitar +300 EDRs via drivers vulneráveis
Ataques DCOM com sequestro de sessões (T1021.003) expõem dependência de autenticação interativa
Exploits transformam Windows Defender em ferramenta de ataque via condição TOCTOU
Abuso de políticas QoS para sufocar EDRs e burlar detecção em tempo real
Perguntas frequentes
Esse ataque afeta todos os EDRs igualmente?
Não. EDRs com regras locais fortes (ex: CrowdStrike Falcon Prevent) continuam protegendo contra execução maliciosa mesmo sem nuvem. Mas todos os que dependem de telemetria em tempo real para detecção comportamental, investigação ou resposta remota ficam cegos. O problema não é o EDR em si, mas a arquitetura de nuvem-dependente.
Como saber se meu ambiente foi atacado, se não há logs de EDR?
Monitore Event ID 5857 (NetQosCim) em todos os endpoints. Se seu ambiente não usa QoS, qualquer ocorrência é suspeita. Também verifique com Get-NetQoSPolicy -PolicyStore ActiveStore, políticas com ThrottleRateActionBitsPerSecond ≤ 1000000 (1 Mbps) e AppPathName apontando para processos como csagent.exe, wdboot.exe ou falconcontainer.exe são fortemente indicativas.
EDRUnChoker resolve o problema?
Ele mitiga, mas não elimina o risco. Como ferramenta WMI permanente, depende da integridade do provedor NetQosCim, que pode ser desativado ou substituído. Além disso, ele só remove políticas ativas no ActiveStore; políticas persistentes no registro (HKLM\SOFTWARE\Policies\Microsoft\Windows\QoS) exigem detecção via Event ID 4663 e análise manual.
Posso bloquear New-NetQoSPolicy via política de grupo?
Não diretamente, é um cmdlet legítimo do módulo NetQos. Mas você pode restringir seu uso com AppLocker ou WDAC, bloqueando a execução de scripts PowerShell que chamem esse cmdlet. Melhor ainda: desative o provedor NetQosCim via 'sc config netqoscim start= disabled', se QoS não for usado em sua infraestrutura.
Fontes
- ipurple.teamfonte original
- Categoria
- CEVIU Segurança da Informação
- Publicado
- 18 de junho de 2026
- Editoria
- CEVIU Segurança da Informação

