Em 2 de outubro de 2026, por volta das 9h35, o pesquisador que publica sob o pseudônimo "Kaba" conectou a um de seus servidores por SSH através da rede Tor e recebeu um aviso que todo administrador de sistemas conhece bem: "AVISO: A IDENTIFICAÇÃO DO SERVIDOR REMOTO MUDOU!". Normalmente, essa mensagem significa que você está se reconectando a um servidor que foi reinstalado ou teve suas chaves criptográficas substituídas. Mas, naquele caso, algo estava muito errado. A chave que foi apresentada pertencia a um servidor controlado por atacantes.
O que começou como um alerta solitário de segurança se transformou na descoberta de um dos maiores comprometimentos já registrados contra a rede Tor. Em questão de horas, Kaba identificou 333 nós de saída comprometidos — cerca de 10% de toda a capacidade de saída da rede — redirecionando conexões SSH para 12 servidores controlados pelos atacantes. Por três dias, esses nós interceptaram credenciais de usuários, monitoraram sessões ativas de terminal e tentaram instalar uma versão atualizada do malware Ebury em servidores vítimas.
O ataque não foi apenas notável pela escala. Foi notável pela sofisticação do sigilo operacional, pela escolha deliberada de um backdoor com mais de 17 anos e pela forma como os atacantes exploraram falhas de higiene de segurança que ainda são alarmantemente comuns em infraestrutura de servidores.
A arquitetura de um ataque em duas camadas
Para entender o que aconteceu, é preciso entender como funciona a rede Tor. O Tor roteia o tráfego de usuários através de vários relés operados por voluntários para ocultar os endereços IP. O último desses relés, chamado nó de saída, é o ponto onde o tráfego do usuário deixa a rede Tor e entra na internet pública. Cada nó de saída possui uma "política de saída" que define quais portas e protocolos ele permitirá que o tráfego utilize — tipicamente HTTP, HTTPS e, para muitos, SSH.
Os atacantes reescreveram as políticas de saída dos 333 nós comprometidos para redirecionar todo o tráfego na porta 22 (SSH) para uma nuvem de 12 servidores de interceptação. Esses servidores atuavam como intermediários em um ataque "man-in-the-middle" clássico: quando um usuário se conectava via SSH, o servidor malicioso apresentava seu próprio fingerprint criptográfico, capturava a senha em texto claro quando o usuário autenticava, e então reabria a conexão com o servidor legítimo, encaminhando todos os comandos. Para a vítima, tudo parecia funcionar normalmente — mas os atacantes viam cada tecla digitada.
A segunda camada do ataque era ainda mais maliciosa. Simultaneamente à interceptação SSH, o sistema de interceptação tentava estabelecer uma segunda conexão com o servidor vítima, tentando instalar o Ebury — um backdoor do Linux que se embute no OpenSSH e rouba credenciais de todos que se conectam à máquina comprometida.
O Ebury: um fóssil digital que volta à vida
O Ebury é um dos backdoors mais persistentes e subestimados da história da segurança cibernética. Descoberto pela primeira vez em 2009, o Ebury é especificamente projetado para comprometer o OpenSSH em sistemas Linux. Ao contrário de malware moderno que utiliza técnicas sofisticadas de ofuscação ou criptografia de comunicação, o Ebury opera com uma elegância minimalista: ele injeta um módulo compartilhado no processo sshd usando LD_PRELOAD, interceptando senhas no momento em que o sistema PAM as processa.
A variante utilizada neste ataque, a versão 1.8.3, apresenta uma particularidade que a torna especialmente difícil de detectar. Em vez de modificar os arquivos de pacote instalados pelo gerenciador de pacotes, o Ebury 1.8.3 deixa a biblioteca oficial libkeyutils intacta e coloca um arquivo malicioso falso ao lado dela. Em seguida, reconfigura o link simbólico para apontar para a versão falsa. Ferramentas de verificação de integridade como dpkg -V e debsums veem apenas a biblioteca original — intacta — e reportam tudo como limpo.
Isso não é especulação. Zimmer, operador dos relés Quetzalcoatl comprometidos, publicou uma análise forense detalhada mostrando que a biblioteca empacada permaneceu inalterada em ambos os servidores afetados. O sshd, o sudo e os módulos PAM passaram todas as verificações de pacote. A única maneira de detectar o Ebury é inspecionar diretamente o sistema de arquivos em busca de arquivos setuid incomuns ou verificar o hash da versão em execução na memória.
A linha do tempo do comprometimento dos relés Quetzalcoatl revela a persistência do ataque. Em 28 de agosto de 2026, os atacantes acessaram o servidor de gerenciamento (um VPS da Contabo) usando uma senha que também era usada para sudo e para um backup criptografado — e que estava armazenada em texto claro em um script. A partir daí, fizeram a pivô para o segundo servidor (Switzerland2), executando dois relés Quetzalcoatl em uma VPS da FranTech Solutions (marca BuyVM). Em 1º de outubro, sem nenhuma entrada de login SSH, sudo ou cron registrada nos logs, os atacantes reescreveram os arquivos de configuração do Tor e reiniciaram o serviço. Quando os administradores reiniciaram os servidores rotineiramente em 4 de outubro para limpar o malware, o Ebury simplesmente ressurgiu — porque o arquivo setuid permanecia em disco, aguardando o próximo boot do sshd.
Por que 333? O problema do provedor hospedado
Uma das questões mais intrigantes deste incidente é como os atacantes conseguiram comprometer mais de 300 relés simultaneamente. A teoria mais plausível, levantada por Marc-Étienne M. Léveillé — pesquisador do Ebury que trabalhou no relatório da ESET de 2024 — é que um ou mais provedores de hospedagem foram comprometidos, permitindo aos atacantes implantar o Ebury em servidores alugados pelos operadores sem nenhum aviso.
Os dados fornecidos por Zimmer apoiam essa hipótese. Dentre os relés hospedados na FranTech Solutions, 71 de 101 adotaram a política de ataque, comparado a apenas 13 de mais de 9.000 relés hospedados em outras redes. Essa assimetria sugere fortemente que o ponto de entrada não foi falhas individuais dos operadores, mas sim uma vulnerabilidade na infraestrutura compartilhada que a FranTech oferecia.
A ESET já documentou esse cenário em sua pesquisa de 2024: operadores de Ebury comprometem provedores de hospedagem e implantam o malware em servidores alugados por clientes legítimos, sem nenhum aviso. Nesse cenário, a responsabilidade pelo comprometimento não recai sobre os operadores dos relés, mas sobre o provedor de infraestrutura que falhou em isolar adequadamente os tenants.
A resposta da comunidade
A detecção do ataque foi realizada inteiramente por um pesquisador voluntário. Kaba utilizou o exitmap — uma ferramenta oficial do projeto Tor — para testar cada um dos ~3.000 nós de saída da rede, verificando se o fingerprint SSH apresentado correspondia ao esperado e se a conexão vinha do nó de saída ou de um dos servidores de interceptação. Em questão de horas, ele identificou os 333 relés comprometidos e notificou a equipe de saúde da rede Tor naquela mesma noite.
A resposta da equipe de saúde da rede foi notavelmente rápida. Em 4 de outubro, todos os relés maliciosos foram marcados com o flag BadExit, impedindo que os clientes Tor os utilizassem como nós de saída. Em 5 de outubro, os operadores dos relés comprometidos foram contatados e começaram a desligar seus servidores.
"Nunca vimos um ataque desse tipo", disse a equipe de saúde da rede Tor ao pesquisador, segundo relatado por Dan Goodin na Ars Technica. A análise posterior do Tor at 1AEO identificou 377 relés adicionais em 147 endereços IP — embora essa contagem mais ampla reflita correspondências de política de saída, em vez de infecções confirmadas.
Lições para a comunidade de infraestrutura
Este incidente levanta questões fundamentais que vão muito além do comprometimento específico de 333 relés. Em primeiro lugar, demonstra que a segurança da rede Tor — projetada para fornecer anonimato contra governos e adversários de alta capacidade — é vulnerável a ataques de baixa tecnologia contra a infraestrutura subjacente.
Em segundo lugar, o caso expõe a fragilidade crônica da autenticação baseada em senhas em ambientes corporativos e de infraestrutura. Zimmer documentou que utilizou a mesma senha para login SSH, sudo e o backup criptografado — um erro de engenharia de segurança que praticamente qualquer equipe de DevOps reconheceria hoje como um anti-padrão fundamental. A recomendação padrão da comunidade de segurança — usar autenticação por chave e desativar senhas em hosts expostos à internet — seria suficiente para impedir completamente a exploração inicial.
Em terceiro lugar, o episódio reforça um ponto que a comunidade de segurança já vinha fazendo há anos: ferramentas de verificação de integridade baseadas em pacotes são insuficientes para detectar backdoors kernel-space ou user-space sofisticados. Se um malware pode coexistir com os arquivos originais do pacote sem ser detectado pelo dpkg, o teste de integridade está oferecendo uma falsa sensação de segurança.
O que permanece? O caso dos 333 relés Tor é um lembrete de que a segurança é uma cadeia tão forte quanto seu elo mais fraco. A rede Tor, com seus protocolos criptográficos e sua arquitetura descentralizada, foi mantida vulnerável não por uma falha no Tor em si, mas por operadores que confiaram em senhas reutilizadas armazenadas em texto claro — e por provedores de hospedagem cujos planos de segurança não consideravam o risco de compartilhamento de infraestrutura. Em um mundo onde a anonimidade digital é cada vez mais valorizada, talvez o elo mais fraco não esteja nos protocolos, mas na engenharia humana.
Fontes: Kaba, SecureWorld, Tor Project Forum
✓ Fontes independentes cruzadas e verificadas antes da publicação
