t1499-002-service-exhaustion-flood

# T1499.002 - Service Exhaustion Flood > [!warning] Subtécnica de Alto Impacto em Serviços Web e Criptográficos > Service Exhaustion Flood é uma das formas mais eficientes de Endpoint DoS, pois explora gargalos específicos de serviços como HTTP e SSL/TLS com volume relativamente baixo de tráfego. Difícil de distinguir de tráfego legítimo em alta demanda. ## Descrição **Service Exhaustion Flood** é a subtécnica **T1499.002** do [[mitre-attack|MITRE ATT&CK]], classificada sob [[t1499-endpoint-denial-of-service|T1499 - Endpoint Denial of Service]], na tática de **Impacto** (TA0040). Esta técnica visa específicamente os **serviços de rede** hospedados em um sistema alvo - com ênfase em serviços web (HTTP/HTTPS), DNS e outros protocolos de aplicação - ao invés de esgotar recursos do sistema operacional diretamente. A distinção fundamental em relação a outras subtécnicas de Endpoint DoS é o **vetor de exploração**: enquanto [[t1499-001-os-exhaustion-flood|T1499.001 - OS Exhaustion Flood]] ataca recursos do kernel (sockets TCP, memória, processos), o Service Exhaustion Flood explora **gargalos específicos do software de serviço** - o servidor web, o daemon SSL/TLS, o servidor DNS - que possuem seus próprios limites de recursos independentes do sistema operacional subjacente. Dois vetores primários são documentados: **1. HTTP Flood simples:** O adversário envia um volume massivo de requisições HTTP legítimas para um servidor web. Cada requisição consome um worker thread, conexão de banco de dados, processo de renderização ou chamada de API. Quando o pool de workers é esgotado, novas requisições são rejeitadas ou ficam em fila indefinidamente. A eficácia deste ataque é proporcional ao custo computacional de cada requisição - páginas com consultas pesadas ao banco de dados são alvos preferênciais. **2. SSL/TLS Renegotiation Attack:** Explora uma característica do protocolo SSL/TLS onde cliente e servidor podem renegociar os parâmetros criptográficos de uma conexão estabelecida. O processo de renegociação é computacionalmente custoso - especialmente a troca de chaves assimétrica (RSA, ECDH). Um adversário que estabelece uma conexão SSL/TLS e envia repetidas solicitações de renegociação pode consumir desproporcionalmente os recursos de CPU do servidor, mesmo com largura de banda modesta, pois cada renegociação exige operações criptográficas intensas. Ataques de Service Exhaustion são particularmente insidiosos porque o tráfego gerado frequentemente **parece legítimo** - são requisições HTTP bem formadas ou handshakes SSL válidos. Isso dificulta a discriminação por firewalls simples baseados em regras de protocolo. **Técnica pai:** [[t1499-endpoint-denial-of-service|T1499 - Endpoint Denial of Service]] ## Como Funciona ### Variante 1 - HTTP Flood O princípio do HTTP Flood é simples: sobrecarregar o servidor com volume de requisições que excede sua capacidade de processamento simultâneo. **Mecanismo:** 1. O adversário controla uma botnet ou usa uma infraestrutura de ataque 2. Cada bot envia um stream contínuo de requisições HTTP GET ou POST ao servidor alvo 3. O servidor precisa processar cada requisição: rotear, executar lógica de aplicação, consultar banco de dados, gerar resposta 4. O pool de worker threads (limitado - ex: 100-1000 workers em um Apache/nginx típico) se esgota 5. Novas conexões ficam em fila de espera ou são rejeitadas com erro 503 6. Usuários legítimos recebem timeout ou erros **Variações de HTTP Flood:** - **GET Flood:** Requisições simples para páginas estáticas - requer volume muito alto - **POST Flood:** Requisições com corpo grande - consome mais CPU no parsing - **Dynamic Content Flood:** Alvejá endpoints que geram conteúdo dinâmico (PHP, consultas SQL) - maximiza custo por requisição - **Slowloris:** Mantém conexões abertas enviando headers HTTP lentamente, esgotando o limite de conexões simultâneas sem alto volume de tráfego - **R.U.D.Y (R-U-Dead-Yet):** Envia corpo de POST extremamente lento, mantendo workers ocupados ### Variante 2 - SSL/TLS Renegotiation Attack **Mecanismo:** 1. O adversário estabelece uma conexão SSL/TLS legítima com o servidor 2. Imediatamente após o handshake inicial, envia uma solicitação `ClientHello` para renegociação 3. O servidor inicia um novo processo de handshake criptográfico - operação 10-40x mais custosa que transmissão de dados 4. O adversário repete as solicitações de renegociação continuamente na mesma conexão 5. O servidor consome ciclos de CPU em operações criptográficas em vez de servir usuários legítimos 6. Com um número modesto de conexões fazendo renegotiação contínua, um servidor pode ser derrubado **Por que é eficiente:** Um único cliente realizando renegociações contínuas pode consumir 10-15% da CPU de um servidor moderno. Com 20-30 clientes simultâneos, o servidor pode atingir 100% de utilização sem qualquer volume expressivo de rede. ### Variante 3 - DNS Query Flood Servidores DNS recursivos são alvos adicionais: o adversário envia consultas DNS por domínios inexistentes ou aleatórios, forçando o servidor a realizar lookups negativos que consomem cache e capacidade de processamento. ## Attack Flow ```mermaid graph TB A["🎯 Identificação do Serviço Alvo Servidor web, reverse proxy, CDN origin, servidor DNS autoritativo"] B["🔍 Fingerprinting do Stack Identifica software: nginx, Apache, IIS OpenSSL versão, limites de conexão"] C["⚙️ Seleção do Vetor HTTP Flood volumétrico vs. SSL Renegotiation (CPU-based) vs. DNS Query Flood"] D1["🌊 HTTP Flood Bottnet envia requisições GET/POST em volume massivo"] D2["🔐 SSL Renegotiation Clientes estabelecem conexão e solicitam renegociação contínua"] D3["❓ DNS Flood Consultas por domínios aleatórios esgotam cache e capacidade"] E["💻 Esgotamento de Recursos Worker threads, conexões SSL, cache DNS - todos saturados"] F["🚫 Indisponibilidade do Serviço Timeout para usuários legítimos Erros 503/504 / SERVFAIL"] G["🔄 Evasão de Mitigação Rotaciona IPs, muda User-Agent, adjusta volume para evitar raté limits"] A --> B B --> C C --> D1 C --> D2 C --> D3 D1 --> E D2 --> E D3 --> E E --> F F --> G G --> C ``` ## Exemplos de Uso ### Caso 1 - Operação Ababil - Bancos americanos (2012) A operação Ababil, atribuída ao grupo Izz ad-Din al-Qassam Cyber Fighters (com possíveis vínculos com o Irã), foi um dos primeiros ataques DDoS em larga escala a usar explicitamente servidores web comprometidos (em vez de PCs de usuários) como bots. A campanha alvejou os servidores HTTPS de Bank of América, JPMorgan Chase, Wells Fargo, Citigroup e outros - utilizando HTTP floods volumétricos e técnicas de SSL exhaustion. O impacto foi suficiente para tornar portais bancários intermitentemente inacessíveis, causando prejuízos operacionais e de reputação. ### Caso 2 - Ataques ao GitHub (2018) Em fevereiro de 2018, o GitHub sofreu um dos maiores ataques DDoS registrados até então (1,35 Tbps), usando amplificação via memcached. Embora o vetor primário fosse de rede, a técnica incluía saturation de serviços HTTPS - os servidores web do GitHub experimentaram esgotamento de conexões SSL antes que a mitigação via Akamai fosse ativada. O incidente demonstrou como ataques híbridos combinam [[t1498-network-denial-of-service|Network DoS]] com Service Exhaustion. ### Caso 3 - Campanhas de extorsão DDoS contra fintechs brasileiras (2021-2024) O CERT.br e instituições financeiras brasileiras documentaram campanhas de ataques DDoS contra fintechs nacionais onde atacantes exigiam pagamento em criptomoedas para cessar o ataque. O padrão de ataque incluía HTTP floods direcionados a endpoints de autenticação e processamento de transações - escolhidos por serem computacionalmente intensivos (consultas ao banco de dados de clientes, válidação de tokens). Alvos no [[financial|setor financeiro]] brasileiro foram prioritários dado o impacto operacional imediato em serviços de pagamento e crédito. ### Caso 4 - Hacktivismo durante eleições brasileiras (2022) Durante o período eleitoral de 2022, o Tribunal Superior Eleitoral (TSE) e portais governamentais foram alvos de ataques de Service Exhaustion coordenados por grupos que contestavam o processo eleitoral. O TSE implementou CDN e proteção anti-DDoS após os ataques, mas o incidente evidenciou a vulnerabilidade de infraestrutura governamental crítica a vetores de HTTP Flood. ### Caso 5 - Slowloris contra servidores Apache legados Servidores Apache com configuração padrão são particularmente vulneráveis ao Slowloris - técnica que mantém conexões HTTP abertas enviando headers incompletos a baixíssima velocidade. Organizações brasileiras com sistemas legados (ERP web, portais de intranet) sem proteção de reverse proxy adequada foram afetadas por ataques que, mesmo com largura de banda mínima, derrubavam completamente o servidor por esgotamento do pool de worker processes. ## Detecção ### Indicadores de comprometimento (IoC comportamentais) - Taxa de requisições HTTP por segundo excede 3-5x o baseline diário - Alta proporção de requisições com User-Agents idênticos ou em padrões sequenciais - Distribuição de IPs de origem concentrada em ASNs de data center/VPS - Tempo de resposta crescente correlacionado com aumento de conexões simultâneas - Pico de handshakes SSL/TLS incompletos ou renegotiations - Erros 503/504 acima de 5% das respostas - Conexões HTTP mantidas abertas por muito tempo sem dados (Slowloris) - Métricas de CPU do servidor web desproporcionais ao volume de dados transferidos ### Regra de detecção (Sigma) ```yaml title: Service Exhaustion Flood - HTTP/HTTPS Anômalo status: experimental description: Detecta padrões de Service Exhaustion Flood via análise de volume de requisições HTTP e métricas de desempenho do servidor web logsource: category: webserver product: nginx detection: selection_high_raté: status: "503" http_method: - GET - POST selection_ssl_renegotiation: ssl_protocol_error: "SSL_R_RENEGOTIATE_EXT_TOO_LONG" selection_slowloris: request_time|gt: 30 bytes_sent|lt: 100 status: "408" condition: selection_high_raté or selection_ssl_renegotiation or selection_slowloris timeframe: 1m threshold: count: "> 500" level: high tags: - attack.impact - attack.t1499.002 falsepositives: - Pico legítimo de tráfego durante eventos (black friday, lançamentos) - Bugs em clientes que geram muitas reconexões SSL ``` ### Fontes de dados para detecção | Fonte | Evento a monitorar | Prioridade | |-------|-------------------|-----------| | Logs do servidor web (nginx/Apache) | Volume de 5xx, request raté, tempo de resposta | Alta | | Métricas SSL/TLS (OpenSSL, Nginx) | Handshakes por segundo, renegotiation raté | Alta | | Firewall / WAF | Padrão de IPs, raté per source, anomalia de protocolo | Alta | | APM (Datadog, New Relic) | Latência de aplicação, erros de pool de conexão | Média | | SIEM | Correlação de logs de rede com métricas de servidor | Média | | Cloudflare / CDN Analytics | Taxa de cache miss, origem requests vs. edge | Média | ## Mitigação | ID | Mitigação | Descrição | |----|-----------|-----------| | [[m1037-filter-network-traffic\|M1037]] | Filter Network Traffic | Raté limiting por IP, por ASN e por User-Agent. Bloqueio automático de IPs que excedem threshold de requisições | | WAF (Web Application Firewall) | Inspeção de camada 7 | Regras de raté limiting baseadas em comportamento (não apenas volume), detecção de Slowloris e SSL renegotiation | | CDN com proteção DDoS | Absorção de volume na borda | Cloudflare, Akamai, AWS CloudFront com Shield Advanced - absorvem e filtram ataques antes de chegarem ao origin | | Desabilitar SSL Renegotiation | Eliminação de vetor específico | Configurar OpenSSL com `SSL_OP_NO_RENEGOTIATION`. Disponível desde OpenSSL 1.1.1 e nginx 1.17.7 | | Timeout agressivo de conexão | Mitigação de Slowloris | Configurar `client_header_timeout` e `client_body_timeout` pequenos (5-10s) no nginx/Apache | | Escalabilidade horizontal | Resiliência por design | Arquitetura auto-scaling (AWS ASG, Kubernetes HPA) que expande capacidade em resposta ao aumento de carga | | Anycast routing | Dispersão geográfica | Distribuir tráfego por múltiplos data centers para diluir o impacto do ataque volumétrico | ### Configuração nginx - mitigação de Slowloris e raté limit ```nginx # Limite de requisições por IP limit_req_zone $binary_remote_addr zone=api_limit:10m raté=100r/s; limit_conn_zone $binary_remote_addr zone=conn_limit:10m; server { # Timeout para mitigar Slowloris client_header_timeout 5s; client_body_timeout 5s; keepalive_timeout 10s; # Limite de conexões simultâneas por IP limit_conn conn_limit 50; location /api/ { limit_req zone=api_limit burst=200 nodelay; } } ``` ## Contexto Brasil/LATAM **Perfil de risco para o Brasil:** O setor financeiro brasileiro é o principal alvo de Service Exhaustion Flood na América Latina por razões técnicas e operacionais convergentes: **Dependência de serviços web críticos:** Transações Pix, consultas de saldo, autenticação multifator e operações de crédito são mediadas por APIs e serviços web que se tornam vetores de ataque. A [[2021]] exige disponibilidade de 99,9% para serviços de pagamento - tornando qualquer indisponibilidade um evento regulatório. **Infraestrutura heterogênea:** A combinação de bancos tradicionais com legado on-premises e fintechs cloud-native cria superfície de ataque diversa. Instituições menores frequentemente operam sem CDN dedicada ou proteção anti-DDoS profissional, tornando-se alvos preferidos de ataques de extorsão. **Grupos de ameaça identificados:** - **Grupos de extorsão brasileiros:** Operam principalmente via Telegram e dark web, usando serviços de stresser/booter para atacar PMEs e fintechs com HTTP floods. Demandam pagamento em Bitcoin para cessar ataques. - **Hacktivistas políticos:** [[anonymous-brasil|Anonymous Brasil]] e grupos afiliados realizam campanhas sazonais durante eventos políticos, utilizando ferramentas como LOIC e HOIC distribuídas via Telegram. - **Grupos criminosos organizados:** Com foco em extorsão combinada - DoS como mecanismo de pressão durante negociações de ransomware ou vazamento de dados. **Impacto regulatório:** O [[banco-central-do-brasil|Banco Central do Brasil]] exige que instituições financeiras reportem incidentes de disponibilidade significativos. Ataques de DoS bem-sucedidos contra bancos e fintechs frequentemente resultam em obrigações de reporte ao BACEN e à [[anatel|Anatel]] (quando envolve infraestrutura de telecom). **Recomendações prioritárias para organizações brasileiras:** 1. Implementar CDN com proteção DDoS L7 em todos os serviços voltados ao público 2. Desabilitar SSL renegotiation em todos os servidores com OpenSSL >= 1.1.1 3. Configurar raté limiting por IP e por endpoint em servidores web 4. Desenvolver runbook de resposta a DDoS com contatos de ISP e provedor de CDN 5. Realizar exercícios de resiliência (chaos engineering) para válidar capacidade de mitigação ## Referências - [MITRE ATT&CK - T1499.002 Service Exhaustion Flood](https://attack.mitre.org/techniques/T1499/002) - [CERT.br - Relatório de Incidentes 2023](https://www.cert.br/stats/incidentes/) - [Cloudflare - Understanding Application Layer DDoS Attacks](https://www.cloudflare.com/learning/ddos/application-layer-ddos-attack/) - [nginx - Mitigating DDoS Attacks](https://docs.nginx.com/nginx/admin-guide/security-controls/controlling-access-proxied-tcp/) - [OpenSSL - Disabling SSL Renegotiation](https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_options.html) - [[t1499-endpoint-denial-of-service|T1499 - Endpoint Denial of Service]] - [[t1499-001-os-exhaustion-flood|T1499.001 - OS Exhaustion Flood]] - [[t1499-003-application-exhaustion-flood|T1499.003 - Application Exhaustion Flood]] - [[t1498-network-denial-of-service|T1498 - Network Denial of Service]] - [[m1037-filter-network-traffic|M1037 - Filter Network Traffic]] - [[cert-br|CERT.br]] - [[banco-central-do-brasil|Banco Central do Brasil]] - [[financial|Setor Financeiro - Perfil de Ameaças]] - [[anonymous-brasil|Anonymous Brasil]] --- *Fonte: [MITRE ATT&CK - T1499.002](https://attack.mitre.org/techniques/T1499/002)*