t1498-002-reflection-amplification

# T1498.002 - Reflection Amplification ## Técnica Pai Esta é uma sub-técnica de [[t1498-network-denial-of-service|T1498 - T1498 - Network Denial of Service]]. ## Descrição **Reflection Amplification** é uma subtécnica de [[t1498-network-denial-of-service|T1498 - Network Denial of Service]] na qual adversários geram ataques de negação de serviço de altíssimo volume utilizando uma combinação de duas propriedades de certos protocolos de rede: **reflexão** (a capacidade de redirecionar tráfego para um terceiro) e **amplificação** (a geração de respostas muito maiores que as requisições originais). O mecanismo fundamental é o **IP Spoofing**: o atacante envia requisições a servidores intermediários legítimos (os "refletores"), mas forjá o endereço IP de origem das requisições, fazendo parecer que elas vieram da vítima. Os servidores refletores, sem saber que foram instrumentalizados, enviam suas respostas - que são ordens de magnitude maiores que as requisições - diretamente para o IP da vítima. O resultado é um fluxo massivo de tráfego indesejado que satura a capacidade de rede e processamento do alvo. Esta técnica está classificada na tática de **Impacto** do [[mitre-attack|MITRE ATT&CK]] e é especialmente perigosa porque: 1. **O atacante não precisa de grande largura de banda própria** - a amplificação é feita pelos refletores. 2. **O tráfego de ataque parece vir de servidores legítimos**, dificultando a diferenciação de tráfego normal. 3. **Servidores refletores são sistemas legítimos**, impossibilitando bloqueio indiscriminado. 4. **Fatores de amplificação** podem chegar a dezenas de milhares vezes o volume de tráfego enviado pelo atacante. ### Protocolos Frequentemente Explorados | Protocolo | Fator de Amplificação | Porta | Observação | |-----------|----------------------|-------|------------| | DNS (open resolvers) | até 179x | UDP/53 | Resposta ANY muito maior que query | | NTP (monlist) | até 4.556x | UDP/123 | Comando obsoleto que retorna lista de clientes | | Memcached | até 51.200x | UDP/11211 | Maior amplificação documentada (2018) | | SSDP | até 30x | UDP/1900 | Universal Plug and Play - dispositivos IoT | | CLDAP | até 70x | UDP/389 | Connection-less LDAP da Microsoft | | CHARGEN | até 358x | UDP/19 | Protocolo legado raramente necessário | | SNMP | até 650x | UDP/161 | Gerenciamento de rede - refletores comuns | | RIPv1 | até 131x | UDP/520 | Protocolo de roteamento legado | A preferência por protocolos UDP se deve ao fato de que UDP não requer handshake, tornando o IP spoofing trivial - o atacante simplesmente envia pacotes sem precisar de resposta para confirmar a sessão. ## Como Funciona ### Mecanismo de Reflexão ``` [Atacante] [Refletor 1: DNS Server] | | |--- Query DNS (src: VÍTIMA) ->| | |--- Resposta grande -> [VÍTIMA] |--- Query DNS (src: VÍTIMA) ->| | |--- Resposta grande -> [VÍTIMA] | [Refletor 2: NTP Server] |--- NTP monlist (src: VÍTIMA)->| | |--- Lista enorme -> [VÍTIMA] ``` O atacante envia pacotes relativamente pequenos para milhares de refletores. Cada refletor responde com pacotes muitas vezes maiores para o IP da vítima (que nunca fez as requisições). O volume agregado de tráfego pode exceder centenas de gigabits por segundo. ### Ciclo de Ataque Detalhado **Fase 1 - Reconhecimento de Refletores:** O atacante realiza varreduras massivas na internet buscando servidores com protocolos amplificáveis expostos: DNS open resolvers (resolvedores abertos que respondem a qualquer IP), servidores NTP com comando `monlist` habilitado, instâncias Memcached com porta UDP/11211 exposta, ou dispositivos IoT com SSDP ativo. **Fase 2 - Preparação dos Payloads:** Construção de requisições específicas para maximizar a amplificação - por exemplo, queries DNS do tipo `ANY` para domínios com registros extensos, ou requisições NTP `monlist` que retornam listas completas de clientes. **Fase 3 - Spoofing e Disparo:** Envio em massa dos pacotes com o IP da vítima como endereço de origem. Em ataques de grande escala, botnets são utilizadas para aumentar o volume de requisições enviadas aos refletores. **Fase 4 - Amplificação e Saturação:** Os refletores enviam respostas volumosas para a vítima. Com fatores de amplificação elevados, um atacante com 1 Gbps de largura de banda pode gerar dezenas ou centenas de Gbps de tráfego na vítima. ### O Caso Memcached (2018) O ataque mais poderoso documentado utilizando esta técnica ocorreu em fevereiro de 2018 contra o GitHub, gerando **1,35 Tbps** de tráfego - um recorde histórico na época. O protocolo Memcached, projetado para cache de dados em memória, acidentalmente expunha uma funcionalidade UDP com fator de amplificação de até **51.200x**: uma requisição de 15 bytes poderia gerar uma resposta de 750 KB. Milhares de servidores Memcached mal configurados com porta UDP/11211 exposta à internet foram utilizados como refletores. ## Attack Flow ```mermaid graph TB A["🔍 Reconhecimento Varredura massiva na internet buscando refletores vulneráveis (DNS open resolvers, NTP monlist, Memcached UDP, SSDP)"] --> B["📊 Catalogação de Refletores Identificar servidores com alto fator de amplificação e baixa latência"] B --> C["🎭 Preparação do Spoofing Configurar capacidade de IP spoofing (raw sockets) e construir payloads otimizados para máxima amplificação"] C --> D["📡 Envio de Requisições Forjadas Disparar pacotes UDP para milhares de refletores com src IP = IP da vítima"] D --> E["🔄 Reflexão e Amplificação Refletores enviam respostas massivas para o IP da vítima (fator 10x a 51.200x)"] E --> F["🌊 Saturação de Largura de Banda Tráfego agregado excede capacidade de uplink da vítima (Gbps → Tbps)"] F --> G["💥 Impacto - Serviço Indisponível Saturação de rede impede acesso legítimo; roteadores upstream podem sofrer congestionamento"] G --> H["🎯 Objetivo Alcançado Extorsão (Ransom DDoS), dano competitivo, distração para outros ataques, hacktivismo"] ``` ## Exemplos de Uso ### Caso 1 - Ataque ao GitHub (2018) via Memcached Em 28 de fevereiro de 2018, o GitHub sofreu o maior ataque DDoS registrado até então: **1,35 Tbps** utilizando amplificação via Memcached. O ataque durou aproximadamente 10 minutos antes de ser mitigado pelo serviço Akamai Prolexic. O fator de amplificação do Memcached (51.200x) significa que apenas ~26 Mbps de tráfego do atacante foram suficientes para gerar 1,35 Tbps na vítima. O incidente levou à desativação emergêncial de UDP em milhares de servidores Memcached públicamente expostos. ### Caso 2 - Ataques DNS Amplification contra o Setor Financeiro Brasileiro O setor bancário brasileiro sofreu múltiplos ataques de amplificação DNS entre 2022 e 2024, especialmente durante períodos de instabilidade política. DNS open resolvers no Brasil e na região LATAM foram utilizados como refletores. O [[cert-br]] públicou notificações para operadores de DNS sobre a necessidade de desabilitar resolução recursiva aberta para IPs externos. Grupos como [[killnet]] e afiliados documentaram o uso de amplificação DNS e NTP em operações hacktivistas direcionadas a organizações brasileiras, coordenando ataques de múltiplos países de forma simultânea. ### Caso 3 - Amplificação SSDP via IoT no Brasil O Brasil possui uma das maiores frotas de dispositivos IoT mal configurados da América Latina - roteadores domésticos, câmeras IP e impressoras com SSDP (UPnP) exposto. Estes dispositivos foram frequentemente catalogados por atacantes como refletores para ataques SSDP amplification. O fator de amplificação de até 30x, combinado com o grande número de dispositivos vulneráveis, torna o Brasil um repositório involuntário de capacidade de ataque DDoS. ### Caso 4 - Ransom DDoS contra Provedores de Serviços em Nuvem LATAM Grupos de extorsão enviaram ameaças a provedores de hospedagem e CDN no Brasil, Argentina e Colômbia, exigindo pagamento em criptomoedas sob ameaça de ataques DDoS via reflection amplification. Empresas sem proteção upstream adequada foram as mais afetadas, com alguns incidentes resultando em interrupções de serviço de 4 a 12 horas. ### Caso 5 - NTP Amplification em Provedores de Internet Provedores de internet regionais no Brasil relataram ataques de amplificação NTP explorando servidores legacy com o comando `monlist` ainda ativo. O ataque visava saturar os links de uplink dos provedores, afetando não apenas um alvo específico mas todos os clientes downstream. Esta técnica de "carpet bombing" DDoS - atacar um range de IPs de um provedor - afeta a disponibilidade de toda a base de clientes. ## Detecção ### Indicadores de Comprometimento (IoCs Comportamentais) - Volume súbito e anormal de tráfego UDP de entrada de múltiplas fontes distintas (servidores legítimos) - Respostas DNS, NTP ou SSDP não solicitadas chegando ao IP da vítima em alto volume - Tráfego UDP de entrada com tamanho de pacote grande e sem requisições correspondentes de saída - Alertas de upstream ISP ou serviço de proteção DDoS sobre volume anormal - Latência extrema ou indisponibilidade de rede mesmo sem saturação de CPU/memória local ### Regra Sigma - Detecção de DNS Amplification ```yaml title: "Network DoS - DNS Reflection Amplification Attack" status: experimental description: > Detecta padrão de recebimento massivo de respostas DNS sem requisições correspondentes, indicativo de ataque de amplificação DNS (T1498.002). Requer telemetria de NetFlow ou análise de tráfego de rede. logsource: category: network_traffic product: zeek detection: selection: dns.type: "response" network.transport: "udp" destination.port: 53 filter_legitimate: dns.flags.response: true source.ip|cidr: - "8.8.8.0/24" # Exemplo: ajustar para IPs conhecidos timeframe: 10s condition: selection | count(source.ip) > 1000 falsepositives: - "Operações legítimas de alto volume em servidores DNS autoritativos" level: high tags: - attack.impact - attack.t1498.002 ``` ### Regra Sigma - Detecção de NTP Amplification ```yaml title: "Network DoS - NTP Reflection Amplification" status: experimental description: > Detecta volume anormal de respostas NTP de entrada (porta UDP/123) não precedidas por requisições de saída, indicando possível ataque de amplificação NTP (T1498.002 via monlist). logsource: category: network_traffic product: zeek detection: selection: network.transport: "udp" source.port: 123 destination.port: 123 network.bytes_received|gt: 400 timeframe: 30s condition: selection | count(source.ip) > 500 falsepositives: - "Sincronização NTP em ambientes com muitos clientes" level: high tags: - attack.impact - attack.t1498.002 ``` ### Fontes de Dados para Detecção | Fonte | Dados Relevantes | |-------|-----------------| | NetFlow / IPFIX | Volume e distribuição de tráfego UDP por porta e origem | | Zeek (Bro) IDS | Análise de protocolo DNS, NTP, SSDP com correlação req/resp | | AWS VPC Flow Logs | Tráfego de entrada volumétrico em instâncias IaaS | | Upstream ISP / BGP telemetria | Alertas de volume de tráfego antes de chegar à infraestrutura | | Cloud WAF / DDoS Protection | AWS Shield, Cloudflare, Akamai alertas em tempo real | | SNMP counters de interface | Saturação de interface de rede (rx_bytes, rx_errors) | ## Mitigação | ID | Mitigação | Descrição | |----|-----------|-----------| | [[m1037-filter-network-traffic\|M1037]] | Filtrar Tráfego de Rede | Bloquear tráfego UDP de entrada de portas de protocolos amplificáveis (53, 123, 11211, 1900, 161, 389) quando não esperado. Implementar uRPF (Unicast Reverse Path Forwarding) para bloquear IP spoofing na origem. | | BCP38 / BCP84 | Prevenção de IP Spoofing | Implementar filtragem de entrada (ingress filtering) nos roteadores de borda para bloquear pacotes com endereços de origem inválidos ou não roteáveis. Padrão de boa prática para ISPs. | | Desabilitar Refletores | Hardening de Serviços | Desabilitar resolução DNS recursiva aberta, desabilitar NTP `monlist` (`noquery` no ntpd), bloquear UDP/11211 em servidores Memcached, desabilitar SSDP em dispositivos IoT expostos à internet. | | Serviço Anti-DDoS Upstream | Proteção Arquitetural | Contratar serviços de mitigação como Cloudflare Magic Transit, Akamai Prolexic, AWS Shield Advanced ou Imperva. A proteção upstream absorve tráfego antes de atingir a infraestrutura. | | Anycast para DNS/NTP próprios | Resiliência | Distribuir serviços de DNS e NTP próprios em múltiplos PoPs via anycast para diluir o impacto de ataques reflexivos. | | Monitoramento de Tráfego Assimétrico | Detecção Proativa | Implementar análise de NetFlow/IPFIX para detectar assimetrias entre tráfego de saída (requisições) e entrada (respostas) em protocolos UDP, indicativo de reflexão. | ## Contexto Brasil/LATAM ### Brasil como Alvo e como Origem Involuntária O Brasil ocupa posição paradoxal no panorama de ataques DDoS via reflection amplification: é simultaneamente um dos principais **alvos** da região e uma significativa **fonte involuntária** de capacidade de reflexão, dado o grande número de servidores e dispositivos mal configurados conectados à internet brasileira. Segundo dados do [[cert-br]], o Brasil historicamente concentra uma das maiores populações de DNS open resolvers e servidores NTP com `monlist` ativo da América Latina. Isso torna a infraestrutura brasileira uma fonte preferêncial de refletores para atacantes globais que sequer têm o Brasil como alvo final. ### Impactos Setoriais Observados **Setor Financeiro:** Bancos e fintechs brasileiras figuram entre os alvos mais frequentes de ransom DDoS - grupos extorsivos enviam ameaças de ataques de amplificação massivos e exigem pagamento em criptomoedas para "proteção". A [[febraban]] (Federação Brasileira de Bancos) orienta suas associadas a não pagar extorsões e a contratarem proteção especializada. **Provedores de Internet (ISPs):** Provedores regionais sem proteção upstream adequada são vulneráveis a ataques de amplificação que saturam seus links, afetando toda a base de clientes. A [[anatel]] registra ocorrências de indisponibilidade causadas por DDoS em provedores de menor porte. **E-commerce e Varejo Digital:** Durante datas comerciais de alto volume (Black Friday, Natal), ataques de amplificação são utilizados contra plataformas de e-commerce concorrentes ou como distração para tentativas de fraude. **Infraestrutura Crítica:** Hospitais, distribuidoras de energia e operadoras de saneamento que migraram serviços para ambiente digital são alvos emergentes, especialmente em contextos de hacktivismo ligado a conflitos internacionais. ### Legislação e Resposta Institucional No Brasil, a conduta de realizar ataques DDoS pode ser enquadrada nos artigos 266 e 298 do Código Penal (sabotagem de sistema de informação e falsidade informática), com penas de 1 a 3 anos de reclusão. A Lei 14.155/2021 aumentou as penas para crimes de fraude cibernética. O [[cert-br]] opera um programa de notificação para operadores que hospedam infraestrutura reflexível ([[anty-spoofing-program-cert-br]]), enviando notificações automáticas para ASNs brasileiros quando detecta servidores sendo utilizados como refletores em ataques observados. Regionalmente, o [[lacnic]] (Latin Américan and Caribbean Internet Addresses Registry) coordena iniciativas de implementação de BCP38 entre ISPs da região para reduzir a capacidade de IP spoofing que habilita ataques de reflexão. ## Referências - [MITRE ATT&CK - T1498.002 Reflection Amplification](https://attack.mitre.org/techniques/T1498/002) - [Cloudflare - Understanding DDoS Amplification Attacks](https://www.cloudflare.com/learning/ddos/dns-amplification-ddos-attack/) - [GitHub Engineering Blog - February DDoS Incident (Memcached, 2018)](https://github.blog/2018-03-01-ddos-incident-report/) - [CERT.br - Ataques de Amplificação DNS](https://www.cert.br/docs/whitepapers/dns-amplification/) - [BCP38 - Network Ingress Filtering: Defeating Denial of Service Attacks](https://www.rfc-editor.org/rfc/rfc2827) - [US-CERT Alert TA14-017A - UDP-Based Amplification Attacks](https://www.cisa.gov/news-events/alerts/2014/01/17/udp-based-amplification-attacks) - [LACNIC - Iniciativa BCP38 para LATAM](https://www.lacnic.net/innovaportal/file/694/1/bcp38_lacnic.pdf) - [NETSCOUT Threat Intelligence - Global DDoS Threat Report 2024](https://www.netscout.com/threatreport) - [Cloudflare Radar - DDoS Attack Trends Brazil 2024](https://radar.cloudflare.com/) --- *Fonte: [MITRE ATT&CK - T1498.002](https://attack.mitre.org/techniques/T1498/002)*