El 2 de octubre de 2026, alrededor de las 9:35 a.m., el investigador que publica bajo el seudónimo "Kaba" se conectó a uno de sus servidores vía SSH a través de la red Tor y recibió una advertencia que todo administrador de sistemas conoce bien: "¡ADVERTENCIA: LA IDENTIFICACIÓN DEL SERVIDOR REMOTO HA CAMBIADO!". Normalmente, este mensaje significa que te estás reconectando a un servidor que ha sido reinstalado o que ha cambiado sus claves criptográficas. Pero en este caso, algo estaba profundamente mal. La clave presentada pertenecía a un servidor que Kaba no reconocía — un servidor controlado por atacantes.
Lo que comenzó como una alerta de seguridad aislada se convirtió en el descubrimiento de uno de los compromisos más significativos jamás registrados contra la red Tor. En cuestión de horas, Kaba identificó 333 nodos de salida comprometidos — aproximadamente el 10% de toda la capacidad de salida de la red — redirigiendo conexiones SSH a 12 servidores controlados por los atacantes. Durante tres días, estos nodos interceptaron credenciales de usuarios, monitorizaron sesiones activas de terminal e intentaron instalar una variante actualizada del malware Ebury en servidores víctimas.
El ataque fue notable no solo por su escala, sino por su sigilo operacional, su elección deliberada de un backdoor de 17 años de antigüedad y la forma en que los atacantes explotaron fallos de higiene de seguridad que siguen siendo alarmantemente comunes en infraestructura de servidores.
La arquitectura de un ataque en dos capas
Para entender lo que ocurrió, es necesario comprender cómo funciona la red Tor. Tor enruta el tráfico de los usuarios a través de varios relés operados por voluntarios para ocultar las direcciones IP. La última de estas relés, llamada nodo de salida, es el punto donde el tráfico del usuario sale de la red Tor y entra en internet pública. Cada nodo de salida tiene una "política de salida" que define qué puertos y protocolos permitirá usar al tráfico — normalmente HTTP, HTTPS y, para muchos, SSH.
Los atacantes reescribieron las políticas de salida de los 333 nodos comprometidos para redirigir todo el tráfico en el puerto 22 (SSH) hacia un grupo de 12 servidores de interceptación. Estos servidores actuaban como proxies clásicos de ataque "man-in-the-middle": cuando un usuario se conectaba vía SSH, el servidor malicioso presentaba su propia huella criptográfica, capturaba la contraseña en texto plano cuando el usuario se autenticaba y luego restablecía la conexión con el servidor legítimo, reenviando todos los comandos. Para la víctima, todo parecía funcionar normalmente — los atacantes veían cada tecla pulsada.
La segunda capa del ataque era aún más insidiosa. Simultáneamente con la interceptación SSH, el sistema de interceptación intentaba establecer una segunda conexión con el servidor víctima, intentando instalar Ebury — un backdoor de Linux que se incrusta en OpenSSH y roba credenciales de cualquiera que se conecte a la máquina comprometida.
Ebury: un fósil digital que vuelve a la vida
Ebury es uno de los backdoors más persistentes e insuficientemente valorados en la historia de la ciberseguridad. Descubierto por primera vez en 2009, Ebury está específicamente diseñado para comprometer OpenSSH en sistemas Linux. A diferencia del malware moderno que utiliza ofuscación sofisticada o comunicaciones encriptadas, Ebury opera con elegancia minimalista: inyecta un módulo compartido en el proceso sshd usando LD_PRELOAD, interceptando contraseñas en el momento en que el sistema PAM las procesa.
La variante utilizada en este ataque, la versión 1.8.3, tiene una característica particular que la hace excepcionalmente difícil de detectar. En lugar de modificar los archivos instalados por el gestor de paquetes, Ebury 1.8.3 deja la librería oficial libkeyutils intacta y coloca un archivo falso malicioso a su lado. Luego reconfigura el enlace simbólico para apuntar a la versión falsa. Herramientas de verificación de integridad como dpkg -V y debsums ven solo la librería original — intacta — y reportan todo como limpio.
Esto no es especulación. Zimmer, el operador de los relés Quetzalcoatl comprometidos, publicó un análisis forense detallado mostrando que la librería empacada permaneció sin modificar en ambos servidores afectados. sshd, sudo y los módulos PAM pasaron todas las verificaciones de paquete. La única manera de detectar Ebury es inspeccionar directamente el sistema de archivos en busca de archivos setuid inusuales o verificar el hash de la versión ejecutándose en memoria.
La línea temporal del compromiso de los relés Quetzalcoatl revela la persistencia del ataque. El 28 de agosto de 2026, los atacantes accedieron al servidor de gestión (un VPS de Contabo) usando una contraseña que también era usada para sudo y un backup encriptado — y que estaba almacenada en texto plano en un script. Desde allí, hicieron pivoteo al segundo servidor (Switzerland2), ejecutando dos relés Quetzalcoatl en un VPS de FranTech Solutions (marca BuyVM). El 1 de octubre, sin ningún registro de login SSH, comando sudo o entrada cron registrada en los logs, los atacantes reescribieron los archivos de configuración de Tor y reiniciaron el servicio. Cuando los administradores reiniciaron los servidores el 4 de octubre para limpiar el malware, Ebury simplemente reapareció — porque el archivo setuid permaneció en disco, esperando el próximo arranque de sshd.
¿Por qué 333? El problema del proveedor de hosting
Una de las preguntas más intrigantes de este incidente es cómo los atacantes lograron comprometer más de 300 relés simultáneamente. La teoría más plausible, planteada por Marc-Étienne M. Léveillé — el investigador de Ebury que escribió el informe de ESET de 2024 — es que uno o más proveedores de hosting fueron comprometidos, permitiendo a los atacantes desplegar Ebury en servidores alquilados por los operadores sin ningún aviso.
Los datos de Zimmer respaldan esta hipótesis. Entre los relés alojados en FranTech Solutions, 71 de 101 adoptaron la política del atacante, en comparación con solo 13 de más de 9.000 relés alojados en otras redes. Esta asimetría sugiere fuertemente que el punto de entrada no fueron fallos individuales de los operadores, sino una vulnerabilidad en la infraestructura compartida ofrecida por FranTech.
ESET documentó exactamente este escenario en su investigación de 2024: los operadores de Ebury comprometen proveedores de hosting y despliegan malware en servidores alquilados por clientes legítimos, sin ningún aviso. En ese escenario, la responsabilidad del compromiso no recae sobre los operadores de los relés, sino sobre el proveedor de infraestructura que falló en aislar adecuadamente los tenants.
La respuesta de la comunidad
La detección fue realizada enteramente por un investigador voluntario. Kaba utilizó exitmap — una herramienta oficial del proyecto Tor — para probar cada uno de los ~3.000 nodos de salida de la red, verificando si la huella SSH presentada coincidía con lo esperado y si la conexión provenía del nodo de salida o de uno de los servidores de interceptación. En cuestión de horas, identificó los 333 relés comprometidos y notificó al equipo de Health de la red Tor esa misma noche.
La respuesta del equipo de Health de la red fue notablemente rápida. El 4 de octubre, todos los relés maliciosos fueron marcados con el flag BadExit, impidiendo que los clientes Tor los usaran como nodos de salida. El 5 de octubre, los operadores de los relés comprometidos fueron contactados y comenzaron a apagar sus servidores.
"Nunca hemos visto un ataque de este tipo", dijo el equipo de Health de la red Tor al investigador, según informó Dan Goodin en Ars Technica. El análisis posterior de Tor at 1AEO identificó 377 relés adicionales en 147 direcciones IP — aunque este recuento más amplio refleja coincidencias de política de salida en lugar de infecciones confirmadas.
Lecciones para la comunidad de infraestructura
Este incidente plantea preguntas fundamentales que van mucho más allá del compromiso específico de 333 relés. En primer lugar, demuestra que la seguridad de la red Tor — diseñada para proporcionar anonimato contra gobiernos y adversarios de alta capacidad — es vulnerable a ataques de baja tecnología contra la infraestructura subyacente.
En segundo lugar, el caso expone la fragilidad crónica de la autenticación basada en contraseñas en entornos corporativos e infraestructurales. Zimmer documentó que utilizó la misma contraseña para login SSH, sudo y backup encriptado — un error de ingeniería de seguridad que virtualmente cualquier equipo de DevOps moderno reconocería como un anti-patrón fundamental. La recomendación estándar de la comunidad — usar autenticación por clave y desactivar contraseñas en hosts expuestos a internet — habría sido suficiente para prevenir completamente la explotación inicial.
En tercer lugar, el episodio refuerza un punto que la comunidad de seguridad ha estado planteando durante años: las herramientas de verificación de integridad basadas en paquetes son insuficientes para detectar backdoors sofisticados de espacio de kernel o de espacio de usuario. Si el malware puede coexistir con los archivos originales del paquete sin ser detectado por dpkg, la prueba de integridad está proporcionando una falsa sensación de seguridad.
El compromiso de Ebury de los 333 relés Tor es un recordatorio de que una cadena de seguridad es tan fuerte como su eslabón más débil. La red Tor, con sus protocolos criptográficos y su arquitectura descentralizada, fue mantenida vulnerable no por una falla en Tor en sí, sino por operadores que confiaron en contraseñas reutilizadas almacenadas en texto plano — y por proveedores de hosting cuyos planes de seguridad no contemplaron los riesgos del uso compartido de infraestructura. En un mundo donde el anonimato digital es cada vez más valorado, quizás el eslabón más débil no esté en los protocolos, sino en la ingeniería humana.
Fuentes: Kaba, SecureWorld, Tor Project Forum
✓ Fuentes independientes cruzadas y verificadas antes de la publicación
