Atacantes secuestran más de 300 relés de salida de Tor para interceptar conexiones SSH

El 21 de octubre de 2026, investigadores informaron de que más de 300 relés de salida de Tor fueron controlados entre el 1 y el 5 de octubre para redirigir conexiones SSH hacia servidores que capturaban credenciales. El investigador kaba identificó 333 relés que enviaban las conexiones a los mismos 12 servidores.

Los atacantes modificaron la configuración torrc para abrir el puerto 22 en 342 relés que lo bloqueaban y convirtieron otros 24 relés en nodos de salida. La misma política cerró los puertos de correo cifrado IMAPS y POP3S y, en la mayoría de los casos, habilitó POP3 e IMAP sin cifrado.

La interceptación solo podía capturar una sesión cuando el usuario aceptaba la clave del servidor interpuesto y utilizaba autenticación mediante contraseña. Las claves SSH no podían retransmitirse de la misma forma porque la firma del cliente está vinculada a cada sesión. El interceptor se conectaba después al servidor legítimo, lo que permitía que la sesión pareciera funcionar y facilitaba observar los comandos.

El Tor Project comenzó a marcar los relés afectados el 4 de octubre. Ese día, los directorios introdujeron las etiquetas BadExit y MiddleOnly, y para las 17:00 UTC del 5 de octubre ningún relé con la política maliciosa figuraba en el consenso de Tor. En el punto máximo, los relés afectados representaban el 7,46 % de la capacidad de salida de la red.

El operador Zimmer confirmó que el cambio no había sido autorizado en la familia de relés Quetzalcoatl, la más afectada. Según su análisis posterior, dos servidores estaban comprometidos con Ebury 1.8.3, una puerta trasera para OpenSSH que roba credenciales. El acceso inicial se produjo mediante una contraseña reutilizada para SSH, sudo y una clave de respaldo, mientras la autenticación por contraseña permanecía habilitada en un servidor expuesto a Internet.

La investigación señaló que no existe una cifra de víctimas. Los usuarios que se conectaron por SSH a través de Tor durante ese intervalo, aceptaron una clave desconocida o modificada y autenticaron con contraseña deberían considerar esa credencial expuesta, cambiarla y revisar el servidor afectado en busca de indicios de Ebury.

Fuente: The Hacker News.