Ransom DDoS (RDDoS) é uma campanha de extorsão em que agentes de ameaça ameaçam executar — ou demonstram brevemente — ataques de negação de serviço distribuída contra uma organização, exigindo pagamento (geralmente em criptomoeda) para cessar ou não iniciar o ataque.
Em alguns casos, o RDDoS ocorre como extorsão focada exclusivamente em disponibilidade — sem comprometimento interno, sem acesso a dados e sem ransomware. Em campanhas mais complexas, ele pode ser combinado com ransomware, exfiltração de dados, ameaça de vazamento e abuso de aplicações. Nem todo RDDoS inclui comprometimento interno; nem todo ransomware envolve DDoS; nem toda extorsão com dados exfiltrados envolve ransomware.
O que é Ransom DDoS (RDDoS)?
O ciclo típico de uma campanha de extorsão por DDoS segue um padrão reconhecível em fases. Na fase de reconhecimento, o agente de ameaça identifica alvos com alta dependência de disponibilidade online — e-commerce, serviços financeiros, plataformas de jogos, exchanges de criptomoeda — e levanta informações sobre a infraestrutura técnica do alvo.
Na fase de demonstração (opcional, mas comum), é executado um ataque DDoS breve — ilustrativamente, de alguns minutos a poucas dezenas de minutos — suficiente para causar degradação perceptível mas não necessariamente para derrubar completamente o serviço. O objetivo é criar urgência e evidenciar que a ameaça tem alguma substância operacional.
Na fase de demanda, o agente envia comunicação — geralmente por e-mail — exigindo pagamento em criptomoeda com prazo definido. A mensagem frequentemente atribui a campanha a grupos APT conhecidos (como Fancy Bear ou Lazarus Group) para inflar a percepção de sofisticação — o que, isoladamente, não é evidência de capacidade real.
Na fase de decisão, a organização precisa responder de forma coordenada, sem impulsividade. A natureza e a extensão da resposta dependem do perfil do incidente, da jurisdição, dos contratos, da regulação setorial e da avaliação de risco.
Na fase de execução ou desistência, grupos com perfil predominantemente oportunista podem desistir se o alvo demonstra proteção ativa ou ignora a demanda. Grupos com maior capacidade operacional ou motivação além do financeiro podem executar o ataque independentemente do pagamento.
Como funciona uma campanha de Ransom DDoS?
HTTP Flood e abuso de APIs de camada 7
Ataques modernos de RDDoS frequentemente operam na camada de aplicação (L7) em vez de na camada de rede (L3/L4), tornando-os mais difíceis de detectar por sistemas de monitoramento exclusivamente volumétrico. Ferramentas automatizadas, headless browsers e scripts são usados para enviar requisições HTTP sintaticamente válidas que esgotam a lógica de negócios da aplicação sem gerar anomalias simples de banda.
Um HTTP Flood direcionado a endpoints críticos de API — como autenticação, processamento de pagamentos ou geração de relatórios — pode impactar um serviço com volume de tráfego consideravelmente menor do que um ataque volumétrico L3/L4, porque o custo computacional por requisição é maior. Agentes de ameaça que conhecem a estrutura interna da API do alvo podem concentrar o ataque em endpoints especialmente custosos, maximizando o impacto com volume mínimo de tráfego.
QUIC Flood — vetores sobre UDP
O surgimento do HTTP/3 sobre o protocolo QUIC criou uma superfície de ataque adicional em campanhas de RDDoS. QUIC usa UDP como encapsulamento e integra TLS 1.3. Dispositivos de segurança que não terminam QUIC podem aplicar controles L3/L4 e observar metadados de fluxo, mas normalmente não conseguem inspecionar integralmente requisições HTTP/3, cabeçalhos e lógica de aplicação sem a terminação TLS. Controles possíveis sem terminação incluem filtragem UDP, rate limiting, políticas por IP/porta, análise de fluxo e detecção comportamental.
Sobre amplificação via QUIC: a RFC 9000 define mecanismos de validação de endereço, incluindo o Retry packet. Antes da validação do endereço, servidores QUIC devem aplicar um limite anti-amplificação — como regra geral, não enviando mais de três vezes os bytes recebidos antes de validar o endereço do cliente. Esses controles reduzem a exposição a spoofing e reflexão, mas não eliminam ataques por botnets com IPs reais ou pressão sobre recursos de CPU e user-space.
Ataques low-and-slow transportados sobre QUIC podem limitar a visibilidade de camada 7 para ferramentas que não terminam QUIC/TLS. Mesmo assim, sinais de rede como duração de fluxos, taxa de pacotes, volume, comportamento de conexões e pressão sobre UDP/443 ainda podem ser monitorados.
RDDoS e extorsão múltipla: quando há ransomware e exfiltração
A terminologia “dupla”, “tripla” e “quádrupla extorsão” varia entre relatórios de inteligência de ameaças e não é padronizada de forma uniforme no setor. Os termos são usados aqui para descrever a combinação progressiva de pressões — não como uma taxonomia definitiva ou universal.
Ransomware e indisponibilidade como pressão adicional
Em algumas campanhas, o agente de ameaça infiltra a rede da organização, criptografa dados internos e exige resgate pela chave de descriptografia. O DDoS pode ser adicionado como pressão paralela: se a vítima demora a pagar ou tenta recuperar os dados de forma independente, a indisponibilidade dos serviços externos aumenta o custo operacional da resistência. Essas são duas ameaças distintas com vetores de acesso diferentes — a presença de uma não implica automaticamente a outra.
Exfiltração de dados e ameaça de vazamento
Em outras campanhas, antes de criptografar ou destruir dados, o agente os exfiltra. A demanda inclui a ameaça de publicação em fóruns criminosos ou venda a terceiros. Para organizações sujeitas à LGPD ou ao GDPR, isso eleva substancialmente o impacto regulatório potencial — mas as obrigações específicas dependem das circunstâncias do incidente, conforme detalhado na seção de governança.
Pressão sobre clientes, parceiros e terceiros
Em campanhas mais amplas, o agente pode contatar diretamente clientes, parceiros, fornecedores ou acionistas da organização, informando sobre o incidente e criando pressão reputacional e regulatória externa. Serviços de DDoS-for-hire (booters ou stressers) podem reduzir a barreira de entrada para extorsionários oportunistas — esses serviços podem abusar de botnets, dispositivos comprometidos, servidores expostos ou infraestrutura indevidamente utilizada. O uso de um serviço terceirizado não prova a autoria nem a capacidade técnica própria do grupo.
Vetores técnicos usados em campanhas RDDoS
Os vetores mais frequentes em campanhas de extorsão por DDoS incluem:
- Volumétrico L3/L4: floods de UDP, ICMP, SYN e amplificação DNS — esgotam capacidade de rede ou de processamento de pacotes.
- HTTP Flood L7: requisições válidas que esgotam CPU, banco de dados ou lógica de negócios.
- Abuso de APIs: exploração de endpoints custosos, autenticação, webhooks ou integrações.
- QUIC Flood: floods sobre UDP/443, pressão sobre CPU e estado de user-space.
- Low and Slow: ataques de baixa taxa que mantêm conexões abertas ou esgotam workers.
- SYN Flood: exaustão de filas de conexão TCP.
Campanhas sofisticadas frequentemente combinam múltiplos vetores para dificultar a mitigação seletiva.
Como avaliar a credibilidade de uma ameaça RDDoS
A avaliação da credibilidade de uma ameaça exige análise baseada em evidências — não em afirmações. A presença de um sinal isolado não prova capacidade real nem confirma blefe; ele deve ser interpretado em conjunto com os demais.
| Evidência observada | Interpretação recomendada | Ação defensiva |
|---|---|---|
| Ataque de demonstração anterior à demanda | Pode indicar alguma capacidade operacional; exige validação de volume e sofisticação | Analisar logs, verificar volume, padrões e origem do ataque |
| Mensagem genérica com nome de APT sem evidência técnica | Pode indicar oportunismo ou impersonação; sinal de baixa credibilidade, mas exige validação | Não descartar; monitorar e documentar |
| Conhecimento específico da arquitetura interna | Pode indicar reconhecimento avançado, vazamento prévio ou acesso; eleva o nível de preocupação | Disparar investigação de intrusão e exfiltração imediatamente |
| Evidência de exfiltração apresentada | Exige verificação por resposta a incidentes; não comprova autoria isoladamente | Acionar IR, jurídico e privacidade; avaliar obrigações regulatórias |
| Campanha sustentada, adaptativa e multivetorial | Pode indicar maior maturidade operacional, mas pode envolver infraestrutura terceirizada | Escalar mitigação, envolver ISP/provedor e considerar suporte especializado |
| Prazo muito curto ou pressão extrema | Tática de urgência para forçar decisão impulsiva | Não responder ao atacante; seguir processo de governança |
A atribuição de um RDDoS a um grupo específico é incerta mesmo para equipes especializadas. Um ataque de demonstração pode ser executado com serviços de DDoS-for-hire. A impersonação de APTs é uma tática comum de extorsionários oportunistas.
Arquiteturas de mitigação: scrubbing, always-on e edge
A escolha da arquitetura de proteção tem impacto direto na capacidade de resposta durante um RDDoS, especialmente dado o elemento surpresa inerente às campanhas de extorsão.
Scrubbing sob demanda
No modelo de scrubbing sob demanda, o tráfego é desviado para um centro de limpeza após a detecção do ataque. O tempo entre detecção, ativação e início da mitigação efetiva depende de automação, propagação de rotas BGP, topologia, provedores e pré-provisionamento — e pode variar de segundos a períodos mais longos. Durante esse intervalo, o ataque pode causar indisponibilidade.
Alguns scrubbing centers operam predominantemente em L3/L4. Outros incluem proxy reverso, WAF, proteção de APIs e controles L7. A cobertura deve ser validada por protocolo, fluxo, produto e arquitetura específicos.
Scrubbing always-on
No modelo always-on baseado em scrubbing, o tráfego pode já passar pela rede de mitigação ou ter rotas e túneis pré-provisionados, reduzindo o tempo de convergência. A detecção e o início da mitigação tendem a ser mais rápidos, mas o desempenho depende da configuração, da automação e da natureza do ataque.
Proteção distribuída no edge
No modelo distribuído no edge, o tráfego pode ser inspecionado e filtrado nos próprios data centers de borda, antes de alcançar o servidor de origem. Uma arquitetura always-on distribuída pode reduzir o tempo de reação e aplicar controles antes que o tráfego alcance a origem. Seu desempenho depende da cobertura geográfica, capacidade, configuração, políticas de mitigação, natureza do ataque e integração com aplicações.
Modelos híbridos
Organizações com alto nível de maturidade frequentemente combinam elementos dos modelos acima, adaptando a arquitetura ao perfil de risco e à tolerância a impacto. A organização deve testar seu processo de mitigação em exercícios controlados para compreender o comportamento real sob ataque.
Para mais detalhes sobre as diferenças entre scrubbing centralizado e suas alternativas, consulte o artigo específico sobre arquiteturas de mitigação.
Governança, pagamento e risco jurídico
Por que autoridades desaconselham o pagamento
Autoridades de segurança frequentemente desencorajam pagamentos porque:
- eles não garantem a interrupção do ataque;
- podem estimular novas extorsões, incluindo de outros grupos;
- podem gerar riscos legais, financeiros e reputacionais;
- confirmam ao agente que a organização é receptiva a ceder.
A decisão sobre comunicação, negociação ou pagamento exige avaliação formal com liderança executiva, jurídico, privacidade, resposta a incidentes, seguradora cibernética — quando aplicável — e autoridades competentes. Não se deve responder impulsivamente ao atacante nem tomar decisões sem coordenação.
Riscos legais e regulatórios
Exposição sob regimes de sanções: para organizações com exposição aos Estados Unidos, transações que envolvam pessoas, entidades ou carteiras sancionadas podem gerar riscos relevantes sob regimes administrados pela OFAC (Office of Foreign Assets Control). A avaliação desse risco exige consulta jurídica especializada considerando a jurisdição, os contratos e as características do incidente.
No Brasil: qualquer decisão sobre pagamento deve ser avaliada por assessoria jurídica especializada, considerando riscos criminais, regulatórios, de compliance, prevenção à lavagem de dinheiro, sanções internacionais e preservação de evidências.
LGPD e notificação à ANPD: um ataque DDoS isolado não implica, por si só, comprometimento de dados pessoais. Se houver evidência de acesso não autorizado, exfiltração, indisponibilidade relevante em sistemas que tratam dados pessoais ou outro impacto aplicável, a equipe jurídica e de privacidade deve ser envolvida imediatamente.
No Brasil, a necessidade, o prazo e o conteúdo de uma comunicação à ANPD e aos titulares dependem das circunstâncias do incidente, da regulamentação aplicável e da avaliação de risco ou dano relevante aos titulares — não de um prazo automático de 72 horas. Na União Europeia, o GDPR estabelece que a notificação à autoridade supervisora deve ocorrer sem demora injustificada e, quando possível, em até 72 horas após a ciência da violação.
A LGPD prevê sanções administrativas que podem incluir multa de até 2% do faturamento da pessoa jurídica de direito privado, grupo ou conglomerado no Brasil, limitada a R$ 50 milhões por infração, além de outras medidas previstas em lei. Sanções não são automáticas, dependem de apuração e das circunstâncias do caso, e um ataque não implica automaticamente a aplicação de multa.
Playbook inicial de resposta a um RDDoS
O cronograma abaixo é um modelo de priorização inicial. As atividades podem ocorrer em paralelo e devem ser adaptadas ao impacto, à jurisdição, aos contratos, ao setor regulado, à maturidade operacional e à natureza do incidente.
Prioridades iniciais (T+0)
- Preservar todas as evidências antes de qualquer outra ação.
- Verificar se existe ataque em andamento: analisar logs, alertas, relatórios de usuários e dashboards de rede.
- Confirmar cobertura e status da proteção DDoS ativa.
- Acionar SOC, NOC, SRE, equipes de rede e de produto conforme escopo do impacto.
- Verificar indicadores de intrusão e possível exfiltração — um ataque DDoS pode ser vetor de distração.
- Elevar monitoramento e telemetria em serviços críticos.
- Documentar todas as decisões e linha do tempo do incidente.
Contenção técnica imediata
- Ativar ou escalar proteção DDoS junto ao provedor ou serviço de mitigação.
- Aplicar rate limiting, geoblocking ou regras de WAF onde cabível e testado.
- Proteger endpoints e serviços críticos que podem ser alvo de abuso paralelo.
- Verificar status de conectividade de upstreams e provedores de trânsito.
Governança e jurídico
- Envolver liderança executiva para alinhamento e autorização de decisões.
- Envolver jurídico, privacidade e compliance o quanto antes.
- Avaliar exposição à seguradora cibernética, quando aplicável.
- Avaliar obrigações regulatórias e contratuais específicas ao setor e à jurisdição.
- Avaliar exposição internacional e riscos de sanções conforme as circunstâncias.
- Definir responsáveis por comunicação interna, comunicação com clientes e parceiros, e comunicação com autoridades.
Comunicação com o atacante
- Não responder impulsivamente ao agente de ameaça.
- Não negociar nem autorizar pagamento sem coordenação formal com jurídico e liderança.
- Preservar a mensagem original e seus metadados sem alterações.
- Seguir orientação jurídica e das autoridades competentes antes de qualquer ação.
Evidências e análise forense
E-mail de demanda: cabeçalhos e metadados podem auxiliar a investigação de campanhas e infraestrutura. Os elementos a preservar e analisar incluem: cadeia Received, identificadores de mensagem, timestamps, domínios, contas potencialmente comprometidas, serviços intermediários, anexos, links e endereços de carteira mencionados. Cabeçalhos não devem ser interpretados isoladamente como prova da origem real do atacante.
Endereços de criptomoeda: devem ser preservados como evidência e compartilhados com autoridades, jurídico e especialistas autorizados. Ferramentas públicas e plataformas comerciais de análise blockchain podem ajudar na correlação de indicadores, mas a atribuição exige cautela e múltiplas fontes de evidência.
Captura de tráfego: se possível e sem impacto operacional, preservar amostras do tráfego de ataque para análise posterior.
Comunicação com autoridades
Os canais de reporte dependem da jurisdição, do setor e do impacto. No Brasil, pode ser apropriado avaliar:
- CERT.br — para incidentes de Internet com impacto no Brasil.
- Autoridades policiais competentes (Polícia Federal, Polícia Civil) — quando há indício de crime cibernético.
- ANPD — quando houver impacto em dados pessoais, conforme avaliação jurídica das obrigações aplicáveis.
- Reguladores setoriais — em setores como financeiro, saúde e energia, quando aplicável.
- Parceiros contratuais afetados — conforme obrigações contratuais.
Para incidentes com alcance internacional, podem ser relevantes o FBI IC3 (ic3.gov), o Europol EC3 e outros canais conforme jurisdição.
Comunicação pós-incidente
Comunicação pública precipitada durante a crise pode amplificar o impacto reputacional e sinalizar ao agente que a pressão está funcionando. Após a resolução, a transparência pós-incidente com clientes e parceiros é geralmente valorizada e pode ser obrigatória dependendo do setor e da regulação aplicável.
Setores frequentemente visados
| Setor | Motivação do agente | Janela de maior exposição | Exemplos de vetores frequentes |
|---|---|---|---|
| E-commerce | Alta receita por hora online | Datas comemorativas, Black Friday | HTTP Flood em checkout e APIs |
| Serviços financeiros | Regulação de disponibilidade, pressão de SLA | Horário de mercado, fechamento | Volumétrico L3/L4 + L7 em APIs |
| Jogos online | Sensibilidade extrema de usuários | Lançamentos, torneios, eventos | SYN Flood + HTTP Flood |
| Exchanges de cripto | Volatilidade eleva pressão; exigências regulatórias variam por jurisdição | Picos de mercado | Volumétrico + abuso de API |
| Mídia e streaming | Eventos ao vivo com audiência global | Transmissões em tempo real | DNS Flood + HTTP |
| Saúde | Criticidade de sistemas, regulação | Qualquer momento | Volumétrico + extorsão múltipla integrada |
RDDoS e extorsão múltipla: comparativo
| Aspecto | Ransomware | Ransom DDoS | Campanha integrada |
|---|---|---|---|
| Vetor de acesso | Infiltração interna de sistemas | Ataque externo de rede | Ambos, de forma coordenada |
| Dano direto | Criptografia de dados internos | Indisponibilidade de serviço | Criptografia + indisponibilidade |
| Exfiltração de dados | Possível em campanhas com múltiplos vetores | Raro quando isolado | Frequente em campanhas integradas |
| Reversibilidade | Depende de backup e resposta a incidentes | Tende a cessar com o ataque | Complexa — múltiplas frentes |
| Impacto regulatório potencial | Depende de dados pessoais afetados, sistemas e regulação setorial | Depende de dados pessoais afetados e impacto em sistemas críticos | Elevado, dependendo do escopo e jurisdição |
| Risco sob regimes de sanções | Pode ser relevante quando houver nexo com jurisdição ou partes sancionadas | Pode ser relevante quando houver nexo com jurisdição ou partes sancionadas | Idem, potencialmente com maior complexidade |
| Defesa primária | Backups, EDR, MFA, patching, IR | Proteção DDoS, WAF, segurança de APIs, planejamento de continuidade | Todas as estratégias anteriores, integradas |
Erros comuns e orientações
Manter a demanda em segredo para evitar exposição pública: reportar às autoridades é operacionalmente útil e pode ser legalmente obrigatório em setores regulados. A confidencialidade do reporte é geralmente preservada durante investigação ativa.
Negociar com o agente de ameaça sem coordenação: qualquer comunicação direta deve ser precedida de orientação jurídica e alinhamento com liderança. Negociar sem coordenação pode confirmar ao agente que a organização está considerando ceder e aumentar a pressão.
Ativar proteção DDoS apenas após receber a demanda: o intervalo entre a demanda e o ataque pode ser curto — insuficiente para implementar, testar e validar proteção do zero. Proteção proativa precisa estar ativa antes de incidentes.
Assumir que a impersonação de APT indica capacidade equivalente: a maioria dos grupos RDDoS são oportunistas que atribuem campanhas a APTs para inflar credibilidade. Avalie a ameaça pela evidência técnica observada, não pelo nome na mensagem.
Pagar sem avaliação jurídica e de risco: a decisão de pagar ou não deve ser tomada com assessoria jurídica especializada, avaliando riscos criminais, regulatórios, de compliance e de sanções, além do impacto operacional e reputacional de ambas as opções.
Perguntas frequentes
RDDoS é diferente de extorsão por ransomware? Sim, no vetor primário. Ransomware requer infiltração interna e criptografa dados — o dano é interno e direto. RDDoS, em sua forma isolada, ameaça disponibilidade por ataque externo de rede, sem necessariamente acessar sistemas internos. Em campanhas de extorsão múltipla, os dois podem ser combinados — mas a presença de um não implica automaticamente o outro.
Todo ataque DDoS durante uma extorsão é um RDDoS? Não necessariamente. A característica definitória do RDDoS é a demanda explícita de pagamento como condição para cessar ou não iniciar o ataque. Um ataque DDoS sem demanda pode ter motivações ideológicas, competitivas ou outras — e deve ser investigado de forma independente.
Qual é o risco regulatório específico no Brasil? Um ataque DDoS isolado não implica, por si só, violação de dados pessoais ou obrigação automática de notificação. Se o incidente envolveu acesso não autorizado, exfiltração ou indisponibilidade de sistemas que tratam dados pessoais, a organização deve envolver jurídico e privacidade imediatamente para avaliar as obrigações aplicáveis sob a LGPD e regulações setoriais.
Como os cabeçalhos de e-mail ajudam na investigação?
Cabeçalhos e metadados do e-mail de demanda podem auxiliar a investigação de campanhas e infraestrutura — incluindo cadeia Received, timestamps, domínios, identificadores de mensagem e serviços intermediários. Não devem ser interpretados isoladamente como prova definitiva da origem real do agente de ameaça, mas são evidências que autoridades podem usar na investigação.
Grupos RDDoS geralmente atacam mesmo sem receber pagamento? Depende do perfil operacional. Grupos com perfil predominantemente oportunista podem desistir diante de proteção ativa ou ausência de resposta. Grupos com maior capacidade operacional, motivação ideológica ou integração com outras campanhas podem executar o ataque independentemente do pagamento. A preparação técnica prévia é a variável com maior impacto na resiliência, independentemente do tipo de grupo.
Como o QUIC Flood afeta campanhas de RDDoS? O QUIC Flood representa um vetor que pode reduzir a visibilidade de camada 7 para dispositivos que não terminam QUIC/TLS. Em campanhas com ataques de demonstração, o uso de QUIC pode ser empregado para avaliar a cobertura defensiva do alvo. Monitoramento de metadados de fluxo, pressão sobre UDP/443, CPU e duração de conexões pode auxiliar na detecção mesmo sem inspeção de conteúdo.
Referências e orientações oficiais
- CERT.br — Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança no Brasil
- Lei nº 13.709/2018 — LGPD — Lei Geral de Proteção de Dados Pessoais
- ANPD — Autoridade Nacional de Proteção de Dados — orientações sobre incidentes e notificações
- CISA StopRansomware — guias e alertas sobre extorsão cibernética
- OFAC Updated Advisory on Potential Sanctions Risks for Facilitating Ransomware Payments — orientações sobre riscos de sanções
- RFC 9000 — QUIC: A UDP-Based Multiplexed and Secure Transport
- RFC 9001 — Using TLS to Secure QUIC
Como implementar na Azion
A arquitetura distribuída da Azion pode ajudar a aplicar controles de mitigação na borda, reduzindo a exposição da origem a tráfego malicioso. A cobertura e o comportamento efetivo dependem dos produtos contratados, dos protocolos publicados, das políticas configuradas e da arquitetura da aplicação.
- Proteção DDoS integrada à borda: a proteção DDoS da Azion opera na infraestrutura de borda e pode ajudar a mitigar ataques volumétricos e de aplicação, incluindo HTTP Flood em APIs, QUIC Flood e ataques low and slow, conforme os produtos e configurações utilizados.
- Terminação QUIC e HTTP/3 no edge: quando o tráfego QUIC e HTTP/3 é terminado na borda, controles de camada 7 podem ser aplicados após a terminação TLS, incluindo políticas de segurança, limitação de taxa e proteção de APIs, conforme a configuração do ambiente.
- Observabilidade e resposta a incidentes: logs, métricas e recursos de observabilidade podem apoiar a investigação do incidente e o ajuste de políticas de mitigação, conforme os produtos e configurações utilizados.
- Network Shield e filtragem L3/L4: filtra pacotes malformados, padrões anômalos e vetores volumétricos nas camadas 3 e 4, reduzindo a exposição antes de qualquer processamento de aplicação.
Saiba mais na documentação de DDoS Protection da Azion.