Entre 2 e 5 de outubro de 2026, relays de saída do Tor redirecionaram conexões SSH para servidores de interceptação, segundo relatos de Kaba e do Tor Project. Em 20 de outubro, o voluntário Kaba informou que testou cerca de 3 mil relays de saída e encontrou 333 que desviavam SSH para 12 servidores.
O que os números 333 e 377 medem
Kaba usou o exitmap e dois servidores de teste: um verificava o fingerprint da chave SSH apresentada; o outro conferia se a conexão chegava pelo relay escolhido ou por um servidor de interceptação. O teste identificou 333 relays que redirecionavam SSH. Em cerca de uma dúzia, a chave apresentada tinha um fingerprint falso; mais de 300 desviavam a conexão sem alterar o fingerprint por conta própria.
Uma análise separada de dados de diretório contou 377 relays com políticas de saída que correspondiam ao padrão associado à campanha. Essa cifra mede correspondências de política, não conexões SSH testadas como redirecionadas.
| Medição | Resultado | Método | O que a cifra descreve |
| Redirecionamentos SSH | 333 relays | Teste com exitmap em cerca de 3 mil relays de saída, comparando fingerprint e origem da conexão | Relays observados redirecionando conexões SSH |
| Correspondências de política | 377 relays | Análise de dados de diretório e das políticas de saída | Relays com um padrão de política associado à campanha |
Quando uma conexão SSH podia expor a senha
Um relay de saída é o último ponto do circuito Tor antes de uma conexão seguir para um destino fora da rede. No método relatado, uma conexão SSH redirecionada podia chegar a um servidor de interceptação. Para expor uma senha, o usuário precisava aceitar a chave desse servidor e digitar a senha.
Na primeira conexão com um servidor, o SSH pode exibir o aviso normal para aceitar sua chave. Se a chave de um servidor já conhecido muda, o programa apresenta um alerta. São situações diferentes, mas ambas exigem atenção antes de aceitar uma chave desconhecida ou alterada.
A autenticação por chave pública protege contra essa forma específica de captura de senha: a assinatura do cliente fica vinculada à sessão SSH e não pode ser simplesmente reutilizada para entrar no servidor real. Uma conexão SSH com um serviço onion permanece dentro da rede Tor; a interceptação descrita afetava conexões que saíam do Tor rumo a destinos que não eram serviços onion.
O que mudou nas conexões de e-mail
Nos dois relays Switzerland2 examinados pelo operador Zimmer, a política bloqueava as portas 25, 465, 587, 993 e 995, usadas por serviços de e-mail criptografados, e permitia POP3 e IMAP pelas portas 110 e 143, que podem transmitir dados sem criptografia. A interceptação bem-sucedida de mensagens não foi confirmada.
O que Zimmer encontrou em dois servidores
Zimmer relatou que um invasor acessou o servidor de administração em 28 de agosto de 2026 usando uma senha reutilizada, obteve acesso root em cinco minutos e instalou o malware Ebury 1.8.3. A mesma senha era usada para SSH, sudo e a senha de backup, e a autenticação SSH por senha permanecia habilitada no servidor de administração exposto à internet. Zimmer também relatou Ebury 1.8.3 em Switzerland2. Esses achados se referem aos dois servidores investigados por ele.
Nos mesmos dois hosts, Zimmer não encontrou redirecionamentos NAT nem binários do Tor modificados; verificações de pacotes também não detectaram o implante. O relato mostra que esses sinais específicos não apareceram na investigação dos dois servidores.
O que o Tor Project recomendou aos operadores
O Tor Project recomendou que operadores de relays Linux auditassem os arquivos torrc e seus arquivos incluídos, as políticas de saída, as regras de NAT para a porta 22, os processos, as conexões de saída, os pacotes instalados, os usuários e as chaves, além de tarefas cron e unidades systemd.
Para um relay sob suspeita, o aviso do Tor Project aos operadores recomenda tirar o sistema do ar, preservar discos e logs, reinstalar o sistema, substituir a identidade do relay e trocar as credenciais presentes no host.
