La mayor campaña de espionaje jamás lanzada contra la red Tor

En la primera quincena de octubre, más de 300 nodos de salida de la red Tor fueron comprometidos y reconfigurados para interceptar conexiones SSH y capturar credenciales en texto plano. El ataque, descubierto por el investigador que publica como "kaba" el 2 de octubre, resultó ser una operación sofisticada y de largo alcance, con la infraestructura inicial ya comprometida desde agosto de 2026.

El descubrimiento

Todo comenzó cuando el investigador kaba notó, el 2 de octubre, que una conexión SSH establecida a través de un nodo de salida de Tor devolvía una alerta de cambio de clave de host — una advertencia que todo administrador de sistemas reconoce como señal de que algo está mal. En lugar de ignorar la alerta y continuar, kaba investigó. Utilizando exitmap, una herramienta desarrollada por el propio Proyecto Tor para monitorear la salud de la red, escaneó los aproximadamente 3.000 nodos de salida activos y encontró un patrón perturbador: más de 300 de ellos enrutaban conexiones SSH al mismo conjunto de 12 servidores de interceptación controlados por los atacantes.

El descubrimiento no fue casual. Kaba había construido un script que fijaba un nodo de salida, abría una conexión SSH entre dos de sus propios servidores y verificaba tanto la huella digital presentada como la dirección de origen de la conexión. El resultado fue inequívoco: cerca de una decena de nodos servía una clave falsa, y más de 300 reenviaban las conexiones a través de la misma infraestructura de interceptación.

Cómo funcionó el ataque

El ataque fue construido en dos fases. La primera — y la más crítica — ocurrió en agosto de 2026, cuando los atacantes obtuvieron el acceso inicial a un servidor de gestión alojado por una familia de operadores de relé Tor. Según un post-mortem publicado por uno de los operadores (Zimmer, en la lista de correo tor-relays), la brecha se dio por medio de una sola contraseña reutilizada: la misma contraseña se usaba para el inicio de sesión SSH, sudo y backup. El servidor también funcionaba como gateway VPN y jump host SSH, accesible desde Internet, con autenticación por contraseña habilitada.

En cinco minutos, el atacante tenía acceso root. En menos de una hora, el malware Ebury — un backdoor para Linux descubierto hace 12 años — ya estaba instalado en los servidores. Ebury se oculta dentro de la propia biblioteca libkeyutils, reemplazando el binario legítimo y haciéndose pasar por una biblioteca no autorizada, lo que permite que el backdoor pase las verificaciones de integridad que normalmente detectarían la manipulación.

La segunda fase ocurrió el 1 de octubre. Los atacantes reescribieron las políticas de salida de los relés comprometidos, abriendo el puerto 22 (SSH) en 342 relés que anteriormente lo bloqueaban, y convirtiendo 24 relés que no eran salidas en nodos de salida activos. Al mismo tiempo, cerraron los puertos cifrados (IMAPS y POP3S) y, en la mayoría de los relés, abrieron los puertos de correo en texto plano (POP3 e IMAP).

Cuando un cliente Tor se conectaba a uno de estos relés, la conexión SSH era redirigida a uno de los 12 servidores de interceptación. El servidor falso presentaba su propia clave de host. Si el usuario aceptaba la clave cambiada y tecleaba una contraseña, la credencial era capturada. A partir de ahí, el interceptor hacía dos cosas simultáneamente: mantenía la sesión SSH viva, retransmitiendo comandos entre el cliente y el servidor legítimo (de modo que el usuario no notaba nada), y abría una segunda conexión para intentar instalar Ebury en el servidor de destino.

El honeypot montado por kaba reveló que los atacantes usaban la biblioteca Paramiko (implementación Python de SSH) y ejecutaban un instalador en Perl codificado en base64 que verificaba privilegios antes de intentar la instalación. El patrón correspondía exactamente al despliegue del Ebury, lo que, si tenía éxito, infectaría el servidor objetivo con la misma backdoor.

Quiénes fueron expuestos

La ventana de exposición fue estrecha y el escenario de ataque específico: para ser víctima, era necesario conectarse a un servidor SSH a través de Tor entre el 1 y el 5 de octubre, caer en un relé secuestrado, aceptar la clave de host cambiada y autenticar con contraseña. El inicio de sesión por clave SSH no era vulnerable a esta técnica, porque el protocolo de autenticación SSH (RFC 4252) es específico por sesión.

No se confirmó ningún número de víctimas. La ausencia de recuento no significa ausencia de impacto — los operadores de servidores que usaban contraseñas para acceder a máquinas remotas vía Tor durante esas fechas deberían tratar sus credenciales como comprometidas e investigar sus servidores en busca de artefactos del Ebury.

Los artefactos incluyen: binarios de OpenSSH manipulados, módulos PAM modificados, bibliotecas compartidas sospechosas en /usr/lib y /usr/local/lib, y la presencia de libkeyutils sin firmar junto a versiones legítimas. Herramientas de detección actualizadas fueron publicadas en la lista de correo del Proyecto Tor.

El post-mortem: "La causa raíz fue nuestra"

Lo que hace que este incidente particularmente instructivo no es la sofisticación del ataque — que es de hecho alta —, sino la vulnerabilidad humana que lo permitió. El operador Zimmer escribió un post-mortem notablemente honesto, sin buscar chivos expiatorios. "La causa raíz fue nuestra", escribió. La misma contraseña en todo. Autenticación por contraseña en servidor visible en Internet. Claves maestras que deberían ser offline, pero estaban en un backup cifrado con la contraseña ya comprometida.

La versión 1.8.3 del Ebury encontrada en este ataque circula desde al menos junio de 2026. Léveillé, que escribió el informe de ESET en 2024 sobre Ebury (que comprometió casi 400.000 servidores), confirmó en la lista de correo que la versión encontrada en los servidores de Tor es consistente con campañas activas. "Probablemente hay otros relés de Tor infectados con Ebury ahí fuera", advirtió.

Qué queda

Este ataque plantea dos lecciones que trascienden el ecosistema Tor. Primero, la seguridad por capas que se colapsa en una sola credencial — lo que los incidentes de auditoría frecuentemente llaman "un único punto de fallo en todas las capas" — sigue siendo la causa raíz de la mayoría de los accesos no autorizados. Segundo, backdoors de 12 años de antigüedad, cuando implantados en infraestructura crítica, siguen siendo una amenaza real y activamente explotada.

La red Tor perdió 370 nodos de salida entre el 3 y el 5 de octubre. Para el 18 de octubre, el número no se había recuperado. La pregunta es: cuántos otros relés Tor están infectados con Ebury hoy, y cuántos administradores continúan usando contraseñas para acceder a servidores por Internet, sin saber que sus credenciales ya fueron capturadas hace meses?

Fuentes: The Hacker News, Kaba, SecureWorld

✓ Fuentes independientes cruzadas y verificadas antes de la publicación