A maior operação de espionagem já realizada contra a rede Tor

Na primeira quinena de outubro, mais de 300 nós de saída da rede Tor foram comprometidos e reconfigurados para interceptar conexões SSH e capturar credências em texto puro. O ataque, descoberto pelo pesquisador que publica como "kaba" em 2 de outubro, revelou-se uma operação sofisticada e de longo prazo, com a infraestrutura inicial já comprometida desde agosto de 2026.

A descoberta

Tudo começou quando o pesquisador kaba percebeu, em 2 de outubro, que uma conexão SSH estabelecida através de um nó de saída do Tor retornava um alerta de chave de host alterada — um aviso que todo administrador de sistemas reconhece como sinal de que algo está errado. Em vez de ignorar o alerta e continuar, kaba investigou. Utilizando a ferramenta exitmap, desenvolvida pelo próprio projeto Tor para monitorar a saúde da rede, varreu os aproximadamente 3.000 nós de saída ativos e encontrou um padrão perturbador: mais de 300 deles roteavam conexões SSH para o mesmo conjunto de 12 servidores de interceptação controlados pelos atacantes.

A descoberta não foi casual. Kaba havia construído um script que fixava um nó de saída, abria uma conexão SSH entre dois de seus próprios servidores e verificava tanto a impressão digital da chave apresentada quanto o endereço de origem da conexão. O resultado foi inequívoco: cerca de uma dúzia de nós servia uma chave falsa, e mais de 300 encaminhavam as conexões pela mesma infraestrutura de interceptação.

Como funcionou o ataque

O ataque foi construído em duas fases. A primeira — e a mais crítica — ocorreu em agosto de 2026, quando os atacantes ganharam acesso inicial a um servidor de gerenciamento hospedado por uma família de operadores de relé Tor. Segundo um post-mortem publicado por um dos operadores (Zimmer, no fórum tor-relays), a brecha se deu por meio de uma única senha reutilizada: a mesma senha era usada para login SSH, sudo e backup. O servidor também funcionava como gateway VPN e jump host SSH, acessível pela internet, com autenticação por senha habilitada.

Em cinco minutos, o atacante tinha acesso root. Em menos de uma hora, o malware Ebury — uma backdoor para Linux descoberta há 12 anos — já estava instalado nos servidores. O Ebury se esconde dentro da própria biblioteca libkeyutils, substituindo o binário legítimo e se passando por uma biblioteca não autorizada, o que permite que o backdoor passe por verificações de integridade que normalmente detectariam a adulteração.

A segunda fase ocorreu em 1º de outubro. Os atacantes reescreveram as políticas de saída dos relés comprometidos, abrindo a porta 22 (SSH) em 342 relés que antes a bloqueavam, e convertendo 24 relés que não eram saídas em nós de saída ativos. Ao mesmo tempo, fecharam as portas criptografadas (IMAPS e POP3S) e, na maioria dos relés, abriram as portas de e-mail em texto puro (POP3 e IMAP).

Quando um cliente Tor se conectava a um desses relés, a conexão SSH era redirecionada para um dos 12 servidores de interceptação. O servidor falso apresentava sua própria chave de host. Se o usuário aceitava a chave alterada e digitava uma senha, a credencial era capturada. A partir daí, o interceptor fazia duas coisas simultaneamente: mantinha a sessão SSH viva, repassando comandos entre o cliente e o servidor legítimo (de modo que o usuário não percebesse nada), e abria uma segunda conexão para tentar instalar o Ebury no servidor de destino.

O honeypot montado por kaba revelou que os atacantes usavam a biblioteca Paramiko (implementação Python de SSH) e executavam um instalador em Perl codificado em base64 que verificava privilégios antes de tentar a instalação. O padrão correspondia exatamente ao deploy do Ebury, o que, se bem-sucedido, infectaria o servidor alvo com a mesma backdoor.

Quem ficou exposto

A janela de exposição foi estreita e o cenário de ataque específico: para ser vítima, era necessário conectar-se a um servidor SSH através do Tor entre 1º e 5 de outubro, cair em um relé sequestrado, aceitar a chave de host alterada e autenticar com senha. Login por chave SSH não era vulnerável a essa técnica, pois a assinatura criptográfica do protocolo SSH (RFC 4252) é específica por sessão.

Nenhum número de vítimas foi confirmado. A ausência de contagem não significa ausência de impacto — operadores de servidores que usavam senhas para acessar máquinas remotas via Tor entre aquelas datas devem tratar suas credências como comprometidas e investigar seus servidores em busca de artefatos do Ebury.

Os artefatos incluem: binários OpenSSH adulterados, módulos PAM modificados, bibliotecas compartilhadas suspeitas em /usr/lib e /usr/local/lib, e a presença de libkeyutils não assinado ao lado de versões legítimas. Ferramentas de detecção atualizadas foram publicadas na mailing list do projeto Tor.

O post-mortem: "A causa raiz foi nossa"

O que torna este incidente particularmente instructivo não é a sofisticação do ataque — que é de fato alta —, mas a vulnerabilidade humana que o permitiu. O operador Zimmer escreveu um post-mortem notavelmente honesto, sem buscar bodes expiatórios. "A causa raiz foi nossa", escreveu. A mesma senha em tudo. Autenticação por senha em servidor visível na internet. Chaves mestras que deveriam ser offline, mas estavam em um backup criptografado com a senha já comprometida.

A versão 1.8.3 do Ebury encontrada neste ataque tem circulado desde pelo menos junho de 2026. Léveillé, que escreveu o relatório da ESET em 2024 sobre o Ebury (que comprometeu quase 400.000 servidores), confirmou na mailing list que a versão encontrada nos servidores de Tor é consistente com campanhas ativas. "Provavelmente há outros relés comprometidos com Ebury por aí", alertou.

O que fica

Este ataque levanta duas lições que transcendem o ecossistema Tor. Primeiro, a segurança por camadas que colapsa em uma única credência — o que incidentes de auditoria frequentemente chamam de "um único ponto de falha em todas as camadas" — continua sendo a causa raiz da maioria dos acessos não autorizados. Segundo, backdoors com 12 anos de idade, quando implantados em infraestrutura crítica, continuam sendo uma ameaça real e ativamente explorada.

A rede Tor perdeu 370 nós de saída entre 3 e 5 de outubro. Até 18 de outubro, o número não se recuperou. A pergunta que fica: quantos outros relés Tor estão infectados com Ebury hoje, e quantos administradores continuam usando senhas para acessar servidores via internet, sem saber que suas credenciais já foram capturadas há meses?

Fontes: The Hacker News, Kaba, SecureWorld

✓ Fontes independentes cruzadas e verificadas antes da publicação