Un grupo comprometió 333 nodos de salida de Tor, lo que representa aproximadamente una décima parte del total, para redirigir las conexiones SSH hacia servidores diseñados para robar contraseñas. La campaña, iniciada el 2 de octubre, se centró en interceptar inicios de sesión en servidores remotos y tráfico de correo electrónico no cifrado.

Comprometieron 333 nodos de salida de Tor y redirigieron las conexiones SSH a servidores diseñados para robar contraseñas, según el relato de un investigador publicado el 20 de octubre de 2026. La campaña comenzó el 2 de octubre y tuvo como objetivo el tráfico de correo electrónico no cifrado junto con los inicios de sesión en servidores remotos.

Los nodos afectados representaban aproximadamente uno de cada diez de los cerca de 3.000 relés de salida de Tor citados en el informe. Según se informa, los atacantes obtuvieron acceso a los servidores Linux subyacentes en agosto e instalaron Ebury 1.8.3, un backdoor de OpenSSH y robador de credenciales.

Los relés de salida transportan el tráfico desde la red Tor hacia su destino. En esta campaña, los relés comprometidos reenviaban el tráfico web cifrado con normalidad, pero redirigían las conexiones SSH en el puerto 22 a uno de los 12 servidores de interceptación.

El investigador descubrió la actividad después de que una conexión SSH produjera una advertencia de “REMOTE HOST IDENTIFICATION HAS CHANGED” (la identificación del host remoto ha cambiado). Ese mensaje significaba que la clave del servidor presentada no coincidía con la clave confiable previamente.

Secuestran 333 nodos de salida de Tor

Según el relato, los usuarios que ignoraron la advertencia y continuaron con la autenticación por contraseña expusieron sus credenciales. Los atacantes podían entonces conectarse al servidor previsto, observar los comandos introducidos durante la sesión y abrir otra conexión para intentar instalar Ebury.

Por lo tanto, el ataque dependía de vencer la verificación, en lugar de simplemente romper el cifrado SSH. El cambio de la clave del host era la advertencia visible de que la conexión podría ya no llegar al servidor esperado.

El informe también describió cambios en los puertos permitidos que dirigían las salidas afectadas hacia el tráfico de correo no cifrado, proporcionando a los atacantes otra fuente de datos legibles.

Para identificar las salidas comprometidas, el investigador creó una prueba basada en exitmap, una herramienta para comprobar el comportamiento de las salidas de Tor. Cada prueba seleccionaba un relé de salida y abría una conexión SSH entre dos servidores controlados.

Un servidor comprobaba la huella digital (fingerprint) de SSH. El otro comprobaba si la conexión entrante procedía de la salida seleccionada o de un servidor de interceptación. Alrededor de una docena de salidas devolvieron huellas falsas, mientras que más de 300 enrutaron las conexiones a través de la misma infraestructura de interceptación.

Una prueba de honeypot independiente utilizando sshesame reveló presuntamente el uso de Paramiko, una librería de SSH en Python, por parte del atacante. Los comandos capturados comprobaban los privilegios del usuario y el acceso sudo antes de intentar ejecutar un instalador de Perl codificado en Base64.

El papel de Ebury encaja con su historial establecido. Anteriormente se informó sobre infecciones de Ebury que afectaron a más de 400.000 servidores Linux, incluyendo el robo de credenciales y la interceptación de tráfico SSH dentro de entornos de alojamiento.

El investigador kaba informó de los hallazgos al equipo de salud de la red de Tor el 2 de octubre, y los operadores alertaron a los relés afectados con la etiqueta BadExit el 4 de octubre.

La guía de relés defectuosos de Tor confirma que BadExit impide que un relé funcione como salida. El proyecto también acepta informes que contengan identificadores de relés y pruebas de comportamiento sospechoso.

Según se informa, los atacantes reiniciaron varios relés el 5 de octubre, pero las etiquetas les impidieron funcionar como salidas. El relato indica que todos los servidores infectados identificados fueron apagados ese mismo día.

El método de acceso inicial sigue siendo desconocido. Una brecha en el proveedor de alojamiento es una teoría, no un hallazgo confirmado. La atribución también sigue sin resolverse.

El caso refuerza por qué es importante la monitorización de los relés, un tema tratado en el informe sobre las medidas de seguridad de la red de Tor. Para ti, que uses SSH, la lección central del investigador es que investigues las advertencias de la clave del host en lugar de omitirlas y que reemplaces los inicios de sesión con contraseña por claves SSH.