t1499-001-os-exhaustion-flood

# T1499.001 - OS Exhaustion Flood ## Técnica Pai Esta é uma sub-técnica de [[t1499-endpoint-denial-of-service|T1499 - T1499 - Endpoint Denial of Service]]. ## Descrição **OS Exhaustion Flood** é uma subtécnica de [[t1499-endpoint-denial-of-service|T1499 - Endpoint Denial of Service]] na qual adversários lançam ataques de negação de serviço (DoS) direcionados ao próprio sistema operacional de um endpoint. Ao contrário de ataques que visam esgotar recursos físicos como CPU ou memória RAM, esta técnica explora os **limites internos impostos pelo próprio SO** - como o número máximo de conexões TCP simultâneas permitidas, tabelas de estado de sessão e filas de gerenciamento de pacotes. O objetivo é tornar o sistema incapaz de responder a novas requisições legítimas, causando interrupção total ou parcial de serviços TCP/IP. A técnica é particularmente eficaz porque qualquer sistema operacional moderno - sejá [[linux]], [[windows]] ou [[macos]] - impõe limites finitos em suas estruturas internas de estado de rede, e esses limites podem ser atingidos com volume de tráfego relativamente baixo se o protocolo for explorado corretamente. Esta técnica está classificada na tática de **Impacto** do [[mitre-attack|MITRE ATT&CK]], pois seu objetivo primário é degradar ou eliminar a disponibilidade do sistema alvo, sem necessáriamente comprometer confidencialidade ou integridade. ### Variantes Principais **SYN Flood:** O atacante envia volumes massivos de pacotes SYN (início do handshake TCP de três vias) sem nunca completar o processo. O servidor aloca recursos de memória para cada conexão TCP "half-open" aguardando o ACK final do cliente. Como o número máximo de conexões half-open é limitado pelo kernel do SO, o buffer se esgota rapidamente, impedindo novas conexões legítimas. Cada entrada na tabela de estado de half-open consome entre 280 e 320 bytes de memória do kernel, dependendo da implementação. **ACK Flood:** Explora a natureza stateful do protocolo TCP. O atacante envia torrentes de pacotes ACK com endereços IP de origem forjados (spoofed). O sistema alvo, ao receber cada pacote ACK, precisa consultar sua tabela de estado para verificar se existe uma conexão TCP estabelecida correspondente. Como não existe, o SO percorre toda a tabela antes de descartar o pacote. Com um volume alto de ACKs forjados, o custo computacional dessa busca exaustiva degrada severamente a capacidade de resposta do sistema. **RST Flood e FIN Flood:** Variantes adicionais que também exploram a lógica de gerenciamento de estado TCP, forçando o SO a processar e responder a sinalizadores de encerramento de sessão inexistentes. ## Como Funciona A técnica funciona explorando a **finitude dos recursos de estado de rede do kernel**. Todo sistema operacional mantém estruturas de dados internas para rastrear conexões de rede ativas. Estas estruturas têm capacidade máxima definida por parâmetros do kernel. ### Mecanismo de SYN Flood Detalhado ``` Cliente Legítimo Atacante (IP Spoofado) | | |--- SYN --------------> | | |--- SYN (IP falso) ---> [Servidor] |<-- SYN-ACK ----------- | (aloca entrada na tabela) | |--- SYN (IP falso) ---> [Servidor] |--- ACK --------------> | (aloca mais entradas) | (conexão completa) |--- SYN (IP falso) ---> [Servidor] | (tabela cheia - recusa) |--- SYN legítimo ----> [Servidor] (RECUSADO - tabela cheia) ``` No Linux, o parâmetro `net.ipv4.tcp_max_syn_backlog` controla o número máximo de conexões half-open. O padrão é geralmente 128–512. Um atacante com uma conexão de 100 Mbps pode esgotar esta fila em milissegundos. ### Impacto no Sistema Alvo 1. **Esgotamento da fila de backlog TCP:** Novas conexões legítimas são recusadas com `ECONNREFUSED`. 2. **Incremento de uso de CPU:** O kernel gasta ciclos processando e descartando pacotes de estado inválido. 3. **Degradação de latência:** Serviços dependentes de TCP (HTTP, HTTPS, SSH, banco de dados) ficam lentos ou inacessíveis. 4. **Cascata de falhas:** Sistemas de monitoramento e health checks falham, podendo acionar restarts desnecessários de serviços. ### Ferramentas Comuns Utilizadas por Atacantes - **hping3:** Ferramenta de linha de comando para envio de pacotes TCP/IP customizados, muito usada em testes e ataques SYN flood. - **Botnets DDoS:** Grupos como [[killnet]] e [[anonymous-sudan]] utilizaram botnets compostas de dispositivos IoT comprometidos para amplificar ataques de OS Exhaustion. - **Frameworks de DDoS como serviço (DDoS-for-hire):** Serviços clandestinos como "stresser" ou "booter" que vendem capacidade de ataque. ## Attack Flow ```mermaid graph TB A["🎯 Reconhecimento Identificar serviços TCP expostos (SSH, HTTP, banco de dados)"] --> B["🔧 Preparação Configurar botnet ou servidor de ataque com IP spoofing"] B --> C["📡 Geração de Tráfego Enviar volume massivo de SYN / ACK packets forjados"] C --> D["📊 Esgotamento da Tabela Kernel SO atinge limite de conexões half-open ou state table"] D --> E["🚫 Recusa de Conexões Novas requisições TCP são descartadas pelo kernel"] E --> F["💥 Impacto - Negação de Serviço Servidor inacessível para usuários e sistemas legítimos"] F --> G["📈 Persistência do Ataque Manter flood contínuo para impedir recuperação do serviço"] G --> H["🔍 Objetivo Alcançado Interrupção de operações, dano reputacional, extorsão"] ``` ## Exemplos de Uso ### Caso 1 - Operações Hacktivistas no Brasil (2022–2024) Durante períodos de tensão política e eventos nacionais relevantes, grupos hacktivistas como [[killnet]] e coletivos pro-Rússia direcionaram ataques SYN flood contra infraestruturas governamentais brasileiras. Portais do governo federal, sites de tribunais eleitorais e plataformas do setor bancário foram alvos frequentes. Os ataques tipicamente duravam de 30 minutos a várias horas, causando interrupções intermitentes em serviços públicos digitais. O modelo de ataque utilizava botnets distribuídas geograficamente, dificultando o bloqueio por geolocalização de IPs. O [[cert-br]] emitiu alertas recorrentes sobre estas campanhas durante o período eleitoral de 2022. ### Caso 2 - Ataques ao Setor Financeiro LATAM Instituições financeiras em [[latam|brasil]], [[colombia]] e [[mexico]] relataram ataques recorrentes de OS Exhaustion flood como parte de campanhas de extorsão ou distração. O padrão observado envolvia um ataque DDoS de alta intensidade como cortina de fumaça enquanto operações de fraude eram executadas em paralelo - uma tática documentada em campanhas de [[grupos-crime-organizado-financeiro]]. Bancos de médio porte sem proteção especializada anti-DDoS foram os alvos preferênciais, dado que seus limites de recursos de kernel eram atingidos com volumes de tráfego relativamente menores. ### Caso 3 - Infraestrutura Crítica Operadoras de telecomúnicações e provedores de energia elétrica no Brasil relataram tentativas de OS Exhaustion flood em sistemas SCADA e portais de gerenciamento, especialmente em períodos de alta demanda como apagões ou crises de energia. A [[anatel]] registrou ocorrências em sua base de incidentes de segurança para o setor de telecomúnicações. ### Caso 4 - Plataformas de E-commerce em Datas Comerciais Durante eventos como Black Friday e Natal, plataformas brasileiras de e-commerce reportaram picos de ataques SYN flood - possívelmente de origem em concorrência desleal ou grupos oportunistas buscando extorsão. A combinação de alta carga legítima de usuários com tráfego malicioso tornava a mitigação especialmente desafiadora. ## Detecção ### Indicadores de Comprometimento (IoCs Comportamentais) - Volume anormalmente alto de conexões TCP em estado `SYN_RECV` (Linux: `ss -s` ou `netstat -an | grep SYN_RECV | wc -l`) - Taxa de pacotes SYN muito superior à taxa de conclusão de handshake (ratio SYN/ACK desproporcional) - CPU do kernel em uso elevado sem correspondência com carga de aplicação - Logs de sistema registrando `TCP: request_sock_TCP: Possible SYN flooding` (Linux kernel) - Queda abrupta na taxa de novas conexões bem-sucedidas em métricas de monitoramento ### Regra Sigma - Detecção de SYN Flood via Logs de Kernel ```yaml title: "OS Exhaustion Flood - SYN Flood Detection via Kernel Logs" status: experimental description: > Detecta indícios de SYN flood via mensagens do kernel Linux reportando possível flooding na fila de backlog TCP. Indica possível ataque T1499.001. logsource: product: linux category: syslog detection: selection: message|contains: - "Possible SYN flooding" - "request_sock_TCP" - "TCP: dropping request" - "half-open connections" condition: selection falsepositives: - "Picos legítimos de tráfego em eventos de alta demanda" - "Configurações de backlog muito baixas em servidores de baixo recurso" level: high tags: - attack.impact - attack.t1499.001 ``` ### Regra Sigma - Detecção via Métricas de Rede (SIEM) ```yaml title: "OS Exhaustion Flood - Anomalia em Conexões TCP Half-Open" status: experimental description: > Detecta volume anormal de conexões TCP no estado SYN_RECV, indicativo de ataque SYN flood (T1499.001). Requer telemetria de rede ou agente endpoint. logsource: category: network_connection product: linux detection: selection: tcp_state: "SYN_RECV" timeframe: 60s condition: selection | count() > 200 falsepositives: - "Servidores de alta carga com tráfego legítimo intenso" level: high tags: - attack.impact - attack.t1499.001 ``` ### Fontes de Dados para Detecção | Fonte | Dados Relevantes | |-------|-----------------| | Logs do kernel Linux (`/var/log/kern.log`) | Mensagens de SYN flooding e descarte de pacotes | | NetFlow / IPFIX | Análise de volume e distribuição de SYN packets por origem | | Métricas de SO (`/proc/net/tcp`, `ss -s`) | Contagem de conexões por estado TCP | | Firewall / IPS logs | Descarte de pacotes e padrões de bloqueio | | SNMP / telemetria de rede | Counters de interface e erros de protocolo | | AWS VPC Flow Logs / Azure NSG Logs | Para instâncias em nuvem (IaaS) | ## Mitigação | ID | Mitigação | Descrição | |----|-----------|-----------| | [[m1037-filter-network-traffic\|M1037]] | Filtrar Tráfego de Rede | Implementar ACLs e regras de firewall para limitar taxa de SYN packets por origem (SYN raté limiting). Bloquear endereços IP de origem com padrão de flooding. | | SYN Cookies | Proteção do Kernel | Habilitar `net.ipv4.tcp_syncookies=1` no Linux. SYN cookies permitem válidar o handshake sem alocar estado, eliminando a vulnerabilidade de esgotamento de backlog. | | Upstream Scrubbing | Serviço Anti-DDoS | Contratar serviços de mitigação de DDoS como Cloudflare, Akamai, AWS Shield ou Imperva para absorção de tráfego malicioso antes que chegue à infraestrutura. | | Raté Limiting | Controle de Fluxo | Implementar controle de taxa de novas conexões por IP de origem (ex: `iptables -m limit`) e por ASN de origem para limitar impacto de botnets. | | Ajuste de Parâmetros do Kernel | Hardening de SO | Aumentar `net.ipv4.tcp_max_syn_backlog` e `net.core.somaxconn`; reduzir `net.ipv4.tcp_synack_retries` para liberar entradas mais rapidamente. | | Anycast e Distribuição Geográfica | Resiliência Arquitetural | Distribuir o serviço por múltiplos pontos de presença (PoPs) via anycast para diluir o impacto de ataques volumétricos. | ## Contexto Brasil/LATAM O Brasil é consistentemente um dos países mais afetados por ataques DDoS na América Latina, segundo relatórios da [[netscout]], [[cloudflare]] e [[akamai]]. A combinação de alta penetração de banda larga, presença de grandes data centers e infraestrutura financeira digital robusta torna o país um alvo atrativo. ### Panorama de Ameaças DDoS no Brasil - **Setor financeiro** é o alvo mais frequente: bancos digitais como Nubank, Inter e BTG, além de bancos tradicionais, enfrentam ataques DDoS como ferramenta de extorsão (ransom DDoS) e distração para fraudes. - **Serviços governamentais** são alvos recorrentes de grupos hacktivistas, especialmente em contextos de eleições e decisões judiciais controversas. - **ISPs e operadoras de telecomúnicações** são alvos de ataques que visam degradar a qualidade do serviço de seus clientes downstream. - **Plataformas de jogos e streaming** (com alta concentração no Brasil) sofrem ataques frequentes de grupos oportunistas. ### Grupos Observados Grupos como [[killnet]], [[anonymous-sudan]] e coletivos hacktivistas ligados a conflitos internacionais já direcionaram ataques contra o Brasil. Adicionalmente, grupos locais de crime cibernético utilizam DDoS como instrumento de extorsão ("ransom DDoS") contra empresas do varejo e fintech. ### Regulamentação O [[cert-br]] (Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança no Brasil), vinculado ao [[nic-br]], coordena respostas a incidentes DDoS no país e pública estatísticas anuais. Em 2024, ataques de negação de serviço representaram uma parcela significativa dos incidentes reportados ao CERT.br, com concentração no setor financeiro e em provedores de acesso à internet. A Lei Geral de Proteção de Dados ([[lgpd]]) e o Marco Civil da Internet estabelecem obrigações de notificação e respostas a incidentes, mas ainda há lacunas específicas para DDoS no arcabouço regulatório brasileiro. ## Referências - [MITRE ATT&CK - T1499.001 OS Exhaustion Flood](https://attack.mitre.org/techniques/T1499/001) - [Cloudflare DDoS Threat Report Q4 2024](https://blog.cloudflare.com/ddos-threat-report-2024-q4/) - [CERT.br - Estatísticas de Incidentes](https://www.cert.br/stats/) - [RFC 4987 - TCP SYN Flooding Attacks and Common Mitigations](https://datatracker.ietf.org/doc/html/rfc4987) - [NIST SP 800-189 - Resilient Interdomain Traffic Exchange](https://csrc.nist.gov/publications/detail/sp/800-189/final) - [Linux Kernel Documentation - TCP SYN Cookies](https://www.kernel.org/doc/html/latest/networking/ip-sysctl.html) - [NETSCOUT Threat Intelligence - DDoS in Latin América 2024](https://www.netscout.com/threatreport) --- *Fonte: [MITRE ATT&CK - T1499.001](https://attack.mitre.org/techniques/T1499/001)*