Sequestro de rota BGP costuma aparecer em post-mortem como acidente — alguém anunciou o que não devia, o tráfego foi parar no lugar errado por algumas horas, pede-se desculpa. O caso relatado pela Softaculous entre o fim de agosto e setembro de 2026 é diferente: o desvio foi usado de propósito, pra entregar atualização maliciosa de um software de virtualização.
E o detalhe que importa pro provedor: nada no ataque dependeu de invadir servidor. Bastou anunciar um prefixo.
O que aconteceu
Segundo o relato publicado pela própria empresa:
- Em 28 de agosto de 2026, por volta das 21h UTC, o AS62390 começou a anunciar o 162.55.80.0/24 — um pedaço do bloco /16 da Hetzner onde ficavam servidores de atualização e a área de clientes da Softaculous.
- Por ser mais específico que o /16 legítimo, o anúncio ganhou a seleção de rota em toda rede que o aceitou. No pico, cerca de 72% dos coletores do RIPE RIS viam o caminho desviado.
- O AS da Hetzner continuava aparecendo no AS path, como se fosse a origem — o que faz o anúncio parecer legítimo pra quem só olha o último AS.
- Com o tráfego desviado, a validação automática de domínio da autoridade certificadora também passou pelo caminho errado, e o atacante obteve certificado TLS válido pra cerca de 28 nomes. Quem acessou não viu nenhum aviso no navegador.
- O desvio veio em duas ondas, somando cerca de 22 horas. Parou quando a Hetzner passou a anunciar o /24 ela mesma, empatando a especificidade.
Resultado: algumas instalações que buscaram atualização nesse intervalo receberam um pacote adulterado com persistência no servidor.
Por que isso interessa a um provedor regional
Provedor com ASN próprio e blocos IPv4/IPv6 anunciados está exatamente na mesma posição da Hetzner nessa história. Seus prefixos hospedam o DNS recursivo, o portal do assinante, o sistema de cobrança, o servidor de autenticação. Um /24 seu desviado por algumas horas significa cliente caindo em página falsa, credencial capturada ou serviço simplesmente fora — e o primeiro sinal vai ser o telefone do suporte, não um alarme.
O que conferir hoje
- ROA criado pra todos os prefixos que você anuncia, no sistema do NIC.br/LACNIC. Sem ROA, seu prefixo fica como "desconhecido" pra quem faz validação de origem — ninguém descarta o anúncio falso.
- maxLength apertado. Um ROA pro /22 com maxLength /24 autoriza qualquer /24 dentro dele com a sua origem. Note que, no caso acima, a origem aparente era a legítima: só um ROA que não permitisse aquele /24 marcaria o anúncio como inválido. Autorize exatamente o que você anuncia.
- Validação de origem (ROV) nos seus próprios roteadores de borda, descartando inválidos. Proteger os outros de você é o mínimo; não aceitar rota inválida de upstream e PTT protege seus clientes de sequestros alheios.
- Plano pronto pra reagir: saber anunciar rapidamente os mais específicos do bloco afetado (foi o que encerrou o caso acima) e ter o contato do NOC dos seus upstreams à mão.
Monitorar como o mundo vê seu prefixo
O ponto fraco do incidente foi o tempo: horas até a interceptação ser confirmada. Sessão BGP no ar e tráfego normal no seu trânsito não dizem nada sobre o que outros ASes estão aceitando. Pra isso é preciso olhar de fora:
- Coletores públicos. O RIPEstat tem API aberta que informa, por prefixo, quais origens e quais mais específicos estão visíveis nos coletores do RIS. Um item HTTP agent no Zabbix consultando essa API pros seus blocos, com pré-processamento JSONPath, vira trigger quando aparecer origem diferente da sua ou um mais específico que você não anuncia.
- Ferramentas dedicadas, como o BGPalerter (código aberto), que acompanham o fluxo do RIS em tempo real e alertam sobre mudança de origem, mais específico novo, perda de visibilidade e ROA inválido — e podem mandar o alerta pro mesmo canal do NOC.
- Correlação com a rede: quando o alerta de rota disparar, ver na mesma tela se o tráfego de entrada daquele bloco caiu é o que confirma o desvio em minutos, não em horas.
Esse tipo de verificação raramente está no checklist de monitoramento do provedor porque não é "equipamento". Mas é a parte da sua rede que mais gente vê. Se quiser ver como o NOC Geomap junta alerta de rota e tráfego por POP no mesmo mapa, dá uma olhada em como funciona.
Fontes: Virtualizor — Security incident: BGP hijacking; The Hacker News — BGP Hijack Delivers Malicious Virtualizor Update.