Por menos de cinquenta dólares, qualquer pessoa sem conhecimento técnico pode alugar capacidade de ataque DDoS suficiente para derrubar servidores de pequenas e médias empresas. Esses serviços — chamados de booters ou IP stressers — transformaram DDoS em um produto de prateleira, eliminando a barreira técnica que antes exigia infraestrutura própria e expertise em segurança ofensiva.
DDoS Booters (também chamados de IP Stressers) são plataformas comerciais que oferecem ataques DDoS como serviço (DDoS-as-a-Service, DaaS). Apresentam-se superficialmente como ferramentas de “teste de estresse de servidores” — mas na prática são serviços de ataque por aluguel, usados para derrubar alvos de terceiros sem autorização.
Como funcionam os booters
A maioria dos booters opera como uma plataforma web convencional, com painel de controle, planos de assinatura e suporte ao cliente. O fluxo operacional de uma contratação segue estas etapas:
- O usuário acessa o site do booter — na clearnet ou na dark web — e cria uma conta.
- Escolhe um plano conforme o volume de ataque desejado e a duração.
- Informa o alvo: endereço IP ou domínio da vítima.
- Seleciona o método de ataque: UDP Flood, SYN Flood, HTTP Flood, amplificação DNS, entre outros.
- Inicia o ataque com um clique.
A infraestrutura que executa o ataque é composta por três elementos principais: uma botnet alugada de dispositivos IoT e servidores comprometidos; refletores de amplificação UDP (servidores DNS, NTP e SSDP abertos); e servidores de Comando e Controle (C&C) que coordenam os dispositivos da botnet.
Estrutura de preços típica
| Plano | Preço estimado | Capacidade | Duração |
|---|---|---|---|
| Básico | $5–15 | 1–10 Gbps | 60–300 segundos |
| Intermediário | $30–80/mês | 10–50 Gbps | Ilimitado por sessão |
| Premium | $100–500/mês | 50–500 Gbps | Ilimitado + suporte |
| Enterprise | $1.000+/mês | 500 Gbps–1 Tbps | Ilimitado + SLA |
Os preços variam conforme a plataforma, a reputação do serviço e os vetores de ataque disponíveis.
Vetores de ataque: amplificação UDP, inundações e camada 7
Amplificação volumétrica UDP e IP spoofing
Os vetores de maior impacto em plataformas DaaS são ataques de reflexão e amplificação baseados em UDP. O mecanismo explora dois comportamentos legítimos de protocolos de rede:
Reflexão: o atacante envia pacotes UDP com o endereço IP de origem falsificado (IP spoofing) para servidores de terceiros, fazendo-os enviar a resposta diretamente à vítima — que nunca fez a requisição.
Amplificação: o protocolo explorado gera respostas muito maiores do que as requisições. Um pacote de consulta de 60 bytes pode gerar uma resposta de 4.000 bytes ao endereço falsificado, multiplicando o volume de tráfego que atinge a vítima.
A tabela abaixo compara os principais protocolos explorados para amplificação volumétrica:
| Protocolo | Camada OSI | Porta padrão | Fator de amplificação | Mecanismo de exploração |
|---|---|---|---|---|
| Memcached | L7 sobre UDP | 11211 | 10.000x–51.000x | Requisição stats retorna dados de cache acumulados; amplificação máxima documentada |
| CLDAP | L7 sobre UDP | 389 | 56x–70x | Busca LDAP sem conexão; resposta com dados de diretório |
| DNS | L7 sobre UDP | 53 | 28x–70x | Query ANY ou DNSKEY com DNSSEC gera resposta com assinaturas criptográficas |
| NTP | L7 sobre UDP | 123 | 20x–556x | Comando monlist retorna até 600 endereços IP; desativado em versões modernas |
| SSDP | L7 sobre UDP | 1900 | 30x | Descoberta UPnP em dispositivos IoT retorna descrição XML do dispositivo |
| QUIC/UDP | L4 | 443 | Variável | Initial packet flood; server processa handshake antes de validar o cliente |
O ataque de Memcached de fevereiro de 2018 contra o GitHub, com pico de 1,35 Tbps, demonstra a escala possível com amplificação massiva via um único protocolo.
Vetores de camada 7: inundações e exaustão de protocolo
Além dos ataques volumétricos, plataformas DaaS oferecem vetores de camada 7 que consomem recursos de aplicação em vez de largura de banda de rede:
HTTP Flood: envia requisições GET ou POST em volume massivo contra endpoints de aplicação. Cada requisição é sintaticamente válida, dificultando a distinção de tráfego legítimo por dispositivos de rede.
Slowloris e R.U.D.Y.: mantêm conexões HTTP abertas indefinidamente com transmissão de dados em ritmo extremamente lento. Esgotam o pool de conexões do servidor sem gerar volume de rede detectável por alertas volumétricos.
HTTP/2 Rapid Reset: explora o mecanismo de cancelamento de streams do HTTP/2 (frame RST_STREAM). O atacante abre e cancela streams em sequência rápida, forçando o servidor a alocar e liberar recursos continuamente. Em agosto de 2023, esse vetor foi usado em ataques recordes de 201 milhões de requisições por segundo contra infraestrutura do Google.
Exaustão de handshake TLS/SSL: força o servidor a processar handshakes TLS em massa, explorando a assimetria computacional onde o servidor consome aproximadamente 15 vezes mais CPU do que o cliente por sessão estabelecida.
Tabela comparativa de vetores DaaS
| Vetor | Camada | Volume de rede | Recurso esgotado | Detectável por volume? |
|---|---|---|---|---|
| UDP Flood | L3 | Muito alto | Largura de banda | Sim |
| SYN Flood | L4 | Médio | Tabela de estado TCP | Sim |
| DNS/NTP/Memcached Amplification | L3–L7 | Muito alto | Largura de banda da vítima | Sim |
| HTTP Flood | L7 | Baixo-médio | CPU, threads de aplicação | Não (volume normal) |
| Slowloris / R.U.D.Y. | L7 | Muito baixo | Pool de conexões HTTP | Não |
| HTTP/2 Rapid Reset | L7 | Baixo | CPU do servidor HTTP/2 | Não |
| TLS Exhaustion | L7 | Baixo | CPU criptográfica do servidor | Não |
O que alimenta os booters: botnets IoT
A capacidade de ataque dos booters vem principalmente de botnets compostas por dispositivos IoT comprometidos — roteadores domésticos, câmeras IP, DVRs e smart TVs — que executam malwares como Mirai e suas variantes. O ciclo de comprometimento ocorre em seis etapas:
- Um dispositivo IoT com credenciais padrão (como
admin/admin) fica exposto na internet pública. - Um scanner automatizado identifica o dispositivo e testa credenciais conhecidas via Telnet ou SSH.
- O malware (Mirai ou variante) é instalado e persiste no dispositivo.
- O dispositivo é registrado na botnet e aguarda comandos do servidor C&C.
- Quando um cliente do booter contrata um ataque, o C&C envia a ordem de flood para os bots.
- O proprietário do dispositivo raramente percebe — a CPU extra e a largura de banda consumidas passam despercebidas em uso doméstico.
O malware Mirai, cujo código-fonte vazou em 2016, gerou centenas de variantes (Satori, Hajime, Mozi) que infectam coletivamente dezenas de milhões de dispositivos. Uma única campanha de varredura pode recrutar centenas de milhares de bots em questão de horas.
Implicações legais
A contratação ou execução de ataques DDoS por meio de booters configura crime em praticamente todas as jurisdições. A seguir está o enquadramento jurídico nas principais legislações:
Brasil
No ordenamento jurídico brasileiro, o ataque DDoS via booter incorre principalmente em dois tipos penais, que podem ocorrer em concurso de crimes:
Artigo 266 do Código Penal (interrupção ou perturbação de serviço telemático ou de informação de utilidade pública): é o tipo primário para a conduta de lançar um ataque que interrompa ou perturbe serviços informáticos ou telemáticos, com pena de detenção de 1 a 3 anos, e multa. A tentativa e a mera contratação de booter com finalidade ofensiva podem ser enquadradas neste tipo, pois a perturbação do serviço é o resultado direto da conduta.
Artigo 154-A do Código Penal (invasão de dispositivo informático): aplica-se especificamente à fase de formação da botnet — a contaminação prévia dos dispositivos IoT e servidores que comporão a infraestrutura de ataque. O operador que instala malware nos dispositivos para recrutar bots pratica a invasão de dispositivo informático (pena de detenção de 3 meses a 1 ano, e multa). Quando o mesmo agente recruta bots e usa a botnet para lançar o ataque, ocorre concurso material de crimes: responde pelo Art. 154-A (pela invasão) e pelo Art. 266 (pela interrupção do serviço), com penas somadas.
Estados Unidos
Nos Estados Unidos, ataques DDoS podem ser processados sob o Computer Fraud and Abuse Act (CFAA), 18 U.S.C. § 1030, especialmente nas disposições que punem a transmissão não autorizada que causa dano a computadores protegidos. Em determinadas circunstâncias, a pena máxima para uma primeira condenação pode chegar a dez anos de prisão.
União Europeia
A Diretiva 2013/40/EU sobre ataques a sistemas de informação prevê penas de 2 a 5 anos de prisão nos estados-membros, com agravantes pelo uso de ferramentas de ataque automatizadas e pela escala do dano causado.
Importante: contratar um booter e apontar para um alvo — mesmo denominando como “teste de estresse” — configura crime se realizado sem autorização expressa e documentada do proprietário do sistema. A ausência de verificação de propriedade é característica central dos booters, distinguindo-os de ferramentas legítimas de teste de carga.
Por que “IP Stresser” é um eufemismo
Booters frequentemente se apresentam como ferramentas legítimas de “teste de estresse de servidores próprios”. Essa cobertura tem limitações técnicas e jurídicas evidentes:
- Serviços de teste de carga legítimos (como k6, Gatling e loader.io) geram tráfego HTTP com comportamento de usuário simulado — não floods UDP de 100 Gbps.
- Testes de estresse reais são documentados, com consentimento por escrito do proprietário, executados em janelas de manutenção planejadas.
- Booters não verificam se o usuário possui autorização sobre o IP-alvo — condição essencial para qualquer teste legítimo.
- A maioria dos booters opera via criptomoeda e serviços de anonimização para dificultar rastreamento e atribuição de responsabilidade.
Características do tráfego gerado por booters
O tráfego originado de plataformas DaaS apresenta padrões identificáveis que permitem sua detecção e bloqueio antes que atinja os servidores de origem:
| Característica | Padrão típico de booter |
|---|---|
| Distribuição de IP fonte | Concentrada em ranges de hosting e países com regulação permissiva |
| User-Agent (L7) | Padrões repetidos ou ausência de headers típicos de navegadores reais |
| ASN de origem | Concentração em Autonomous Systems de hosting abusivo ou bullet-proof |
| Timing de pacotes | Regular, mecânico e não-humano — intervalos constantes entre envios |
| TLS fingerprint (JA3/JA4) | Hashes de ferramentas de ataque conhecidas — LOIC, HOIC, UFONet, scripts Python |
| Reputação de IP | Ranges presentes em threat intelligence feeds e listas de abuso |
| Diversidade de payload | UDP com payload aleatório ou fixo; HTTP sem recursos secundários (CSS, JS, imagens) |
Técnicas de defesa contra tráfego DaaS
TLS fingerprinting JA3 e JA4 na borda
O handshake TLS de cada cliente deixa uma “impressão digital” baseada na sequência de cipher suites, extensões TLS e parâmetros de versão. O hash JA3 (e seu sucessor JA4) de ferramentas de ataque usadas por booters — LOIC, HOIC, scripts Python com requests ou socket — difere consistentemente dos hashes produzidos por navegadores legítimos como Chrome, Firefox e Safari.
Um WAF ou sistema de proteção de borda com suporte a JA3/JA4 pode bloquear requisições com fingerprints de ferramentas de ataque antes mesmo de analisar o conteúdo HTTP, eliminando o vetor independentemente da rotação de IPs. Isso é especialmente eficaz contra booters sofisticados que usam proxies residenciais para variar endereços.
Scrubbing distribuído no edge versus scrubbing center centralizado
Arquiteturas de scrubbing centralizado redirecionam todo o tráfego para um ponto geográfico único, onde é inspecionado antes de ser encaminhado ao destino. Esse modelo tem duas limitações críticas frente a ataques DaaS modernos:
A primeira é o hairpin de latência: tráfego de usuários legítimos no Brasil pode ser desviado para um scrubbing center nos EUA, adicionando 80–150ms de latência — degradação perceptível para aplicações em tempo real.
A segunda é a limitação contra vetores L7: scrubbing centers tradicionais operam em L3/L4. Ataques como HTTP/2 Rapid Reset, Slowloris e exaustão de TLS usam conexões sintaticamente válidas que passam pela inspeção de rede sem serem bloqueadas.
O scrubbing distribuído no edge resolve ambos os problemas: a inspeção ocorre em cada data center da rede global, próximo à fonte do tráfego. O tráfego de ataque proveniente da Europa é filtrado em data centers europeus; o da APAC, em data centers asiáticos. Usuários legítimos não sofrem desvio de rota. Sobre o tráfego HTTPS, a terminação TLS no edge permite inspeção de camada 7 em tempo real — identificando padrões DaaS, comportamento não-humano e fingerprints de ferramentas de ataque — antes que qualquer pacote chegue ao servidor de origem.
Rate limiting dinâmico por ASN e comportamento
Quando tráfego de ataque converge de ASNs específicos (redes de hosting que hospedam infraestrutura de booter), o rate limiting dinâmico por ASN bloqueia o ataque de forma mais eficiente do que o bloqueio por IP individual. Booters rotacionam IPs constantemente; os ASNs que hospedam sua infraestrutura mudam com muito menos frequência.
O rate limiting baseado em comportamento complementa o bloqueio por ASN: conexões que abrem mas não completam o handshake HTTP, requisições sem recursos secundários (CSS, JavaScript, imagens), padrões de timing mecânico e ausência de cookies de sessão são sinais comportamentais de automação que permitem descarte seletivo sem impactar usuários reais.
Threat intelligence e reputação de IP
Listas de reputação atualizadas continuamente identificam ranges de IP de infraestrutura de booters, botnets IoT e serviços de hosting abusivo. Bloquear ou desacelerar requisições desses ranges reduz significativamente o impacto de ataques, mesmo quando o booter tenta variar os IPs atacantes dentro do mesmo range de ASN.
Erros comuns e soluções
Erro: Acreditar que booters só afetam grandes empresas. Solução: Booters de baixo custo ($5–20) são acessíveis a qualquer pessoa e podem derrubar servidores de PMEs, games independentes, streamers e concorrentes em mercados competitivos. Nenhuma organização é pequena demais para ser alvo — e o baixo custo do ataque reduz ainda mais o limiar de motivação do atacante.
Erro: Bloquear IPs individualmente após o início do ataque. Solução: Booters rotacionam IPs continuamente. O bloqueio reativo por IP é ineficaz e consome recursos operacionais. Use detecção comportamental e fingerprinting TLS (JA3/JA4), que funcionam independentemente do IP de origem.
Erro: Confiar apenas em scrubbing centralizado para proteção contra DaaS. Solução: Scrubbing centralizado é eficaz contra ataques volumétricos L3/L4, mas não detecta vetores L7 como HTTP/2 Rapid Reset, Slowloris e exaustão TLS. A combinação de scrubbing distribuído no edge com terminação TLS e inspeção L7 cobre todos os vetores DaaS.
Erro: Não reportar ataques às autoridades competentes. Solução: Ataques DDoS são crimes. No Brasil, reporte ao CERT.br e, dependendo do impacto, à Delegacia de Crimes Cibernéticos. Nos EUA, ao FBI IC3. Reportes contribuem para investigações que resultam em takedowns de booters e processos criminais contra operadores.
Perguntas frequentes
Booters são ilegais mesmo para “testar meu próprio servidor”? Se você está genuinamente testando sua própria infraestrutura, é legal — desde que o servidor seja seu e você tenha autorização documentada sobre toda a infraestrutura envolvida, incluindo provedores de upstream. Na prática, booters não verificam propriedade sobre o IP-alvo. Usar um booter contra qualquer alvo que não seja explicitamente de sua propriedade configura crime, sujeitando o contratante ao Art. 266 do Código Penal no Brasil, ao CFAA nos EUA e às diretivas equivalentes na UE.
Qual a diferença entre Art. 154-A e Art. 266 do Código Penal no contexto de booters? O Art. 154-A tipifica a invasão de dispositivo informático — a conduta de instalar malware em dispositivos IoT para recrutar bots. O Art. 266 tipifica a interrupção de serviço telemático — a conduta de lançar o ataque que derruba o serviço da vítima. Um operador de booter que recruta bots e usa a botnet para atacar comete ambos os crimes em concurso material, com penas somadas.
Por que é tão difícil desligar booters? Muitos operam na dark web ou em jurisdições com aplicação de lei fraca. Usam criptomoeda para pagamentos, hospedagem bullet-proof e domínios registrados anonimamente. Takedowns bem-sucedidos como a Operação Power Off requerem cooperação internacional entre agências de múltiplos países — um processo que pode levar meses de investigação coordenada. Quando booters são usados para extorsão — ameaçando ataques em troca de pagamento — configuram também o vetor de Ransom DDoS.
Dispositivos IoT ainda alimentam booters em 2026? Sim. Estima-se que mais de 15 bilhões de dispositivos IoT estejam conectados à internet, muitos com credenciais padrão e sem atualizações de segurança regulares. O malware Mirai e suas variantes (Satori, Mozi, Hajime) continuam sendo a principal fonte de bots para booters, com novas campanhas de varredura surgindo continuamente.
O HTTP/2 Rapid Reset é oferecido por booters? Sim. Desde os ataques recordes de 2023, ferramentas que exploram o HTTP/2 Rapid Reset passaram a ser oferecidas em plataformas DaaS premium. O vetor é especialmente valioso para os booters porque gera impacto massivo (medido em requisições por segundo) com volume de rede relativamente baixo, dificultando a detecção por sistemas de monitoramento volumétrico.
Como distinguir um teste de carga legítimo de um booter? Testes de carga legítimos são documentados, têm consentimento escrito do proprietário do sistema, geram tráfego HTTP com comportamento de usuário simulado (cookies, recursos secundários, timing variável) e usam plataformas como k6, Gatling ou JMeter. Booters não verificam propriedade, geram floods UDP/TCP/HTTP em volume desproporcional, e seus clientes anonimizam os pagamentos.
Como implementar na Azion
A Azion protege contra ataques originados de booters e infraestrutura DaaS com uma arquitetura de scrubbing distribuído no edge:
- Bot Manager com TLS fingerprinting JA3/JA4: Identifica e bloqueia ferramentas de ataque usadas por booters — LOIC, HOIC, scripts Python, UFONet e ferramentas UDP customizadas — por meio de assinaturas TLS (JA3/JA4) e análise comportamental de camada 7, sem depender de reputação de IP estática. O bloqueio ocorre no edge antes que qualquer requisição alcance o servidor de origem.
- Scrubbing distribuído no edge com terminação TLS: O tráfego é inspecionado em cada um dos 100+ data centers da Azion, próximo à fonte do ataque, via rede Anycast global. A terminação TLS no edge permite inspeção de camada 7 em tempo real, detectando HTTP/2 Rapid Reset, Slowloris, R.U.D.Y. e exaustão de handshake TLS — vetores invisíveis para scrubbing L3/L4 centralizado.
- DDoS Protection always-on: Absorve automaticamente floods volumétricos (UDP, SYN, ICMP, amplificação DNS/NTP/Memcached) nos data centers da Azion, sem ativação manual, redirecionamento BGP ou ajuste de rotas durante o ataque.
- Network Shield com rate limiting dinâmico: Filtra padrões L3/L4 característicos de booters, incluindo UDP Floods com payload aleatório e SYN Floods com IPs falsificados, aplicando rate limiting dinâmico por ASN e por comportamento de conexão.
Saiba mais na documentação de DDoS Protection da Azion.