Una contraseña SSH reutilizada y Ebury 1.8.3 en el secuestro de 333 salidas de Tor

La mañana del viernes 2 de octubre de 2026, el cliente SSH de quien firma como kaba avisó de que la clave del servidor al que se conectaba había cambiado, aunque el servidor era el mismo. La conexión salía por la red Tor y el relé de salida la estaba desviando. Ese mismo día, kaba revisó una a una las cerca de 3.000 salidas de la red y, según su análisis publicado el 20 de octubre, encontró 333 que mandaban las conexiones SSH a los mismos 12 servidores de interceptación.

El atacante había entrado en los servidores Linux que alojaban los relés y había cambiado su configuración. En los dos equipos analizados a fondo, los del operador de la familia Quetzalcoatl, apareció Ebury 1.8.3, una versión reciente de una puerta trasera de OpenSSH activa desde 2009 que el script de detección de ESET no reconoce. Allí la entrada fue una contraseña reutilizada en un servidor de administración que aceptaba inicios de sesión SSH con contraseña, aunque cómo la obtuvo el atacante sigue sin saberse.

¿Qué ocurrió en la red Tor entre el 1 y el 5 de octubre?

Entre el 1 y el 4 de octubre, 342 relés que bloqueaban el puerto 22 pasaron a permitirlo, la mayoría el día 2. Lo muestra el análisis de los datos públicos del directorio de Tor que el operador de relés Tor at 1AEO publicó el 9 de octubre en la lista tor-relays, según el cual 24 de los relés afectados no eran de salida hasta entonces. En el momento de mayor alcance, el 4 de octubre, los relés con esa política sumaban el 7,46 % del peso de salida de la red.

El equipo de Tor que vigila el estado de la red (Network Health) recibió el aviso de kaba la noche del viernes 2 y el domingo 4 contactó con los operadores afectados. Esa tarde, desde las 18:00 UTC, las autoridades de directorio empezaron a votar la marca BadExit, que llegó al consenso a las 21:00.

Esa marca impide que los clientes usen el relé para salir. A las 17:00 UTC del 5 de octubre no quedaba en el consenso ningún relé con esa política. El número de relés con la marca de salida cayó en unos 370. Según The Hacker News, que cita Tor Metrics, no se había recuperado el 18 de octubre.

En su aviso a los operadores del 5 de octubre, el Tor Project explicó que el atacante parecía obtener acceso a equipos Linux con relés que no eran de salida y editar su configuración (el fichero torrc) para convertirlos en salidas. Ese mismo día, según kaba, los atacantes reiniciaron muchos de los relés, que al estar ya marcados solo podían funcionar como intermedios. En Switzerland2, según Zimmer, el reinicio salió de la puerta trasera y las autoridades de directorio rechazaron los descriptores de sus dos relés.

¿Cómo funcionaba la interceptación?

Según kaba, las conexiones SSH que salían por un relé comprometido pasaban por uno de los 12 servidores del atacante, que retransmitía la sesión al servidor de destino. Alrededor de una docena de salidas presentaba además una huella de clave de host falsa. En las demás, kaba no vio interceptación, aunque la conexión pasaba igualmente por un servidor del atacante.

¿Por qué caían las contraseñas y no las claves?

Solo caía quien aceptaba una clave de host distinta de la esperada, al borrar la antigua de known_hosts o al conectar por primera vez, y después entraba con contraseña. La contraseña viaja cifrada hasta el servidor con el que se negocia la sesión, que la recibe en claro. Aquí ese servidor era el del atacante. La autenticación por clave pública resistía el desvío porque, según la RFC 4252, la firma del cliente incluye el identificador de esa sesión y no sirve para abrir otra.

¿Qué puertos abría la nueva política de salida?

Según el análisis del directorio, la política abría Telnet, IRC y RDP en la mayoría de los 366 relés afectados y POP3 e IMAP sin cifrar en 309, mientras cerraba POP3S e IMAPS en 334. Kaba cree que el atacante quería reunir todo el correo sin cifrar posible. El autor del análisis advierte, eso sí, de que los datos no explican el cierre de los puertos cifrados.

¿Para qué servía Ebury una vez dentro?

Cuando una víctima entraba con contraseña, el atacante la guardaba y abría dos conexiones al servidor de destino. Una servía para observar los comandos tecleados y la otra para instalar Ebury, lo que convertía a cada víctima en un nuevo punto de apoyo. Kaba lo comprobó con un señuelo SSH. En él, el atacante usó la biblioteca paramiko de Python e intentó instalar la puerta trasera con un instalador en Perl codificado en base64.

¿Cómo entró el atacante en Quetzalcoatl?

El atacante entró con una contraseña reutilizada para el inicio de sesión SSH, para sudo y para la frase de paso de las copias de seguridad. Así lo cuenta el informe post mortem que el operador de Quetzalcoatl, que firma como Zimmer, publicó el 7 de octubre en la lista tor-relays. En ese informe, poco habitual por su franqueza, Zimmer reconoce que "la causa raíz fue nuestra" y explica que la contraseña estaba guardada sin cifrar en un script auxiliar. Quetzalcoatl fue la familia de relés más afectada, con 277 relés que adoptaron la nueva política según el análisis del directorio.

El 28 de agosto a las 03:19 UTC, el atacante entró al primer intento con esa contraseña en un servidor virtual de Contabo. A las 03:24 ya era root. El equipo aceptaba autenticación SSH por contraseña. Además acumulaba funciones de pasarela VPN WireGuard, servidor de salto, puente obfs4 y almacén de una copia del equipo de trabajo del administrador. A las 04:38, según el post mortem, Switzerland2, un servidor virtual alojado en FranTech, aceptó un acceso con una clave RSA que no figuraba en ningún authorized_keys que Zimmer encontrara en ese equipo. Ebury quedó instalado un segundo después.

Pasó más de un mes, con actividad discreta como la instalación de nmap el 31 de agosto o el descifrado de los metadatos de la copia el 6 de septiembre, antes de que el atacante tocara las políticas de salida. Las claves maestras de los relés, que el operador creía fuera de línea, estaban duplicadas en esa copia de seguridad. Un reinicio de Switzerland2 el 4 de octubre, por una actualización del núcleo, eliminó las herramientas ocultas, pero Ebury volvió a cargarse en el arranque. Zimmer retiró todos los relés de la familia y el puente. Después borró los dos servidores.

¿Apunta la concentración de relés a un proveedor de alojamiento?

Sin contar Quetzalcoatl, 71 de los 101 relés alojados en FranTech Solutions, la red de BuyVM, cambiaron de política, según el análisis del directorio. En el resto de la red solo lo hicieron 13 de 9.054, y el 1 de octubre 40 relés de 21 operadores distintos cambiaron en menos de cinco minutos y medio. En un mensaje a la lista del 8 de octubre, kaba señaló que 26 de los 27 relés comprometidos ajenos a Quetzalcoatl que tenía en sus datos del 2 de octubre estaban en ese proveedor. También se preguntó si el acceso se había obtenido desde la infraestructura de alojamiento.

Ninguna fuente ha confirmado esa hipótesis. El acceso inicial a Quetzalcoatl llegó por un servidor de Contabo, aunque Switzerland2, el otro equipo infectado, estaba en FranTech, como 48 de sus relés, y sigue sin saberse cómo se entró en los demás. El análisis del directorio advierte además de que coincidir en la política no prueba el compromiso, porque la adoptaron 377 relés de 59 operadores.

¿Por qué dpkg y el script de ESET no detectan Ebury 1.8.3?

Según el post mortem de Zimmer, la variante 1.8.3 se instala como un único fichero setuid, /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2, que no pertenece a ningún paquete, y redirige hacia él el enlace simbólico libkeyutils.so.1. La biblioteca legítima sigue intacta. Por eso dpkg -V y debsums no señalan ninguna anomalía, y sshd, sudo y PAM coinciden con las sumas de verificación de sus paquetes.

• Cada instalación lleva un identificador de víctima distinto, así que el hash cambia de un servidor a otro y una lista de hashes conocidos no sirve.
• Los procesos infectados no ven la biblioteca en sus mapas de memoria (/proc/self/maps).
• Los accesos por la puerta trasera esquivan PAM, y la configuración que impone el implante (UsePAM no, LogLevel QUIET, HISTFILE=/dev/null) desactiva el historial y silencia el registro de sshd.
• El recolector de credenciales captura las contraseñas tal como se teclean, incluidos los intentos fallidos.

Zimmer comprobó que los indicadores públicos de ESET, actualizados por última vez en mayo de 2024, llegan hasta la versión 1.8.2 y que su script detect_ebury.sh no habría marcado la 1.8.3, aunque la regla YARA libkeyutils_with_ctor de ESET sí la reconoce. Marc-Etienne M. Léveillé, coautor de la investigación de ESET sobre Ebury y que dejó la compañía, escribió en la lista tor-relays el 8 de octubre que la 1.8.3 circula al menos desde junio de 2026 y que muy probablemente hay otros relés comprometidos. También publicó una versión actualizada de su script de detección, que él mismo advierte que no es infalible.

En su informe de mayo de 2024, ESET estimó que Ebury había comprometido unos 400.000 servidores desde 2009 y que más de 100.000 seguían infectados a finales de 2023. El informe describe compromisos de proveedores de alojamiento que acabaron infectando los servidores alquilados a sus clientes, e interceptaciones SSH dentro de centros de datos mediante suplantación ARP desde equipos ya infectados del mismo segmento.

¿Qué señales de comportamiento hay que buscar?

Si los hashes y las comprobaciones de paquetes no sirven, la detección tiene que fijarse en lo que el implante hace o deja en el sistema. Los indicadores que describen Zimmer y el aviso del Tor Project del 5 de octubre son de comportamiento y de configuración, y encajan en una búsqueda proactiva de amenazas que empiece por los servidores de salto.

• Bibliotecas setuid en directorios del sistema que no pertenecen a ningún paquete, en especial variantes de libkeyutils, y enlaces simbólicos que apuntan a ficheros inesperados.
• Sockets abstractos con nombres del tipo @event- y un proceso que se hace pasar por /sbin/rsyslogd, dentro del grupo de control de ssh.service en Debian o de init.scope en Ubuntu 24.04.
• Un nivel de registro de sshd inferior a INFO, como en Switzerland2, donde el 30 de septiembre el atacante reinició sshd desde la puerta trasera y, con el nivel en ERROR, dejaron de registrarse los accesos aceptados.
• Reglas NAT que redirigen el puerto 22 (nft list ruleset, iptables -t nat -S), usuarios nuevos, entradas inesperadas en authorized_keys, tareas cron, unidades systemd o módulos del núcleo desconocidos, y un falso demonio CRON en mayúsculas.
• Comandos como base64 -d | perl en los registros de sudo y accesos SSH aceptados con claves que no figuran en ningún authorized_keys, visibles solo si el registro sale del servidor antes de que el atacante lo altere.

Con Microsoft Defender for Endpoint en Linux, la siguiente consulta orientativa busca bibliotecas con ese nombre creadas o modificadas en los directorios del sistema por procesos ajenos a los gestores de paquetes de Debian.

DeviceFileEvents
| where ActionType != "FileDeleted"
| where FileName startswith "libkeyutils.so" and FolderPath matches regex @"^/(usr/)?lib"
| where InitiatingProcessFileName !in~ ("dpkg", "apt", "rpm", "dnf", "yum")
| project Timestamp, DeviceName, ActionType, FolderPath, SHA1, InitiatingProcessCommandLine

Un resultado vacío no demuestra que el equipo esté limpio. La búsqueda avanzada de Defender conserva 30 días de datos, así que una infección de agosto como la de Quetzalcoatl no aparecería. The Hacker News señala además que los servidores de Zimmer no mostraban varias señales que otros operadores sí vieron, como el falso demonio CRON o las reglas NAT, y no está claro si se trata del mismo actor. Zimmer recomienda capturar la memoria antes de reiniciar, investigar desde una imagen de disco fuera de línea o desde un equipo limpio. Tampoco debe escribirse nunca una contraseña en un servidor sospechoso, porque Ebury la capturaría.

Las comprobaciones en el servidor necesitan además que sus registros se envíen a un sistema central. Un servidor que envía sus eventos de autenticación a un SIEM conserva el rastro aunque el atacante vacíe los registros locales. Una herramienta de EDR aporta poco si la pasarela VPN o el servidor de salto quedan fuera de su cobertura, el mismo hueco que analizamos en los puntos ciegos del EDR en los dispositivos de red.

¿Cuáles son los controles que habrían frenado cada paso?

Cada fase del ataque aprovechó la ausencia de un control, desde el acceso SSH con contraseña hasta la mezcla de funciones en el servidor de salto.

¿Hay que desactivar el acceso SSH con contraseña?

Con la autenticación SSH limitada a claves, el atacante no habría entrado en Quetzalcoatl con la contraseña reutilizada ni habría capturado contraseñas a través de los relés. Revisar qué servidores siguen aceptando contraseñas es una tarea básica de bastionado de sistemas Linux. Las claves ligadas a un dispositivo FIDO2, del tipo ed25519-sk de OpenSSH, exigen además por defecto tocarlo en cada uso. Una misma contraseña no debería servir para SSH, sudo y el cifrado de copias, ni guardarse sin cifrar dentro de un script.

¿Por qué importa verificar la clave de host?

Aceptar sin comprobar una clave de host desconocida o cambiada equivale a entregar la contraseña a quien esté en medio, que es lo que hicieron las víctimas de los relés. Con StrictHostKeyChecking yes y claves de host firmadas por una autoridad de certificación SSH interna, el cliente valida el servidor sin depender de la primera conexión.

¿Dónde está el riesgo del servidor de salto?

El servidor que hacía de pasarela VPN, servidor de salto, puente y almacén de copias era uno de los equipos más valiosos de Quetzalcoatl y estaba mal protegido. Separar esas funciones y tratar el servidor de salto como un activo de máxima criticidad limita el movimiento lateral, y una buena segmentación de la red interna habría dificultado el salto hasta Switzerland2, que el atacante dio 74 minutos después de obtener root.

Léveillé apunta, como hipótesis, a que la contraseña se capturó en un acceso desde un equipo ya infectado por Ebury, lo que refuerza la idea de vigilar primero los equipos desde los que se administra. Las claves que deben estar fuera de línea tampoco pueden viajar en la copia de seguridad del equipo de trabajo.

¿Hay que reinstalar si aparece Ebury?

El aviso del Tor Project recomienda, ante un relé comprometido, desconectarlo, preservar disco y registros, reinstalar en lugar de limpiar, generar una identidad nueva y rotar todas las credenciales del equipo. El caso de Switzerland2 muestra el motivo, porque su persistencia sobrevivió al reinicio. El análisis forense de la imagen preservada ayuda a acotar a qué otros sistemas pudo llegar el atacante.

¿Cuánto depende la defensa del proveedor de alojamiento?

Si la hipótesis de FranTech se confirma, ni la autenticación solo con claves ni la verificación de la clave de host habrían frenado un acceso desde la infraestructura del proveedor. ESET ya documentó ese escenario en 2024. Para una empresa con servidores virtuales alquilados, eso entra en la gestión del riesgo de terceros, que debe aclarar qué acceso tiene el proveedor a las máquinas, cómo lo registra y qué notificaría ante un compromiso. La dependencia del proveedor quedó a la vista, por otra vía, en el secuestro BGP de Virtualizor.

¿Cuáles son las preguntas abiertas?

A 26 de octubre de 2026 sigue sin saberse cómo obtuvo el atacante la contraseña de Quetzalcoatl ni cómo entró en los demás equipos. Tampoco se sabe si se trata de una sola campaña o de varias, ni cuántas contraseñas capturó entre el 1 y el 5 de octubre. Quien escribiera una contraseña SSH a través de Tor en esas fechas debe darla por robada.

Las condiciones que hicieron posible el caso se dan también fuera de Tor, en servidores Linux con salida a Internet que aceptan SSH con contraseña, comparten credenciales entre funciones y confían en herramientas de integridad que no ven esta puerta trasera. Revisar qué servidores siguen aceptando contraseñas y repetir la búsqueda de Ebury donde solo se usaron los indicadores de 2024 son las dos tareas inmediatas, empezando por los servidores de salto.

Este análisis recoge la información disponible a 26 de octubre de 2026. Sus fuentes son la investigación de kaba y sus mensajes a la lista tor-relays, el aviso del Tor Project a los operadores, el post mortem del operador de Quetzalcoatl, el análisis del directorio publicado por Tor at 1AEO, el mensaje de Marc-Etienne M. Léveillé, el informe de ESET de 2024 sobre Ebury y la cobertura de The Hacker News.

La hipótesis de un compromiso del proveedor de alojamiento no está confirmada y la atribución de la campaña sigue abierta. Ninguna mención a proveedores de alojamiento implica que se haya confirmado un fallo de seguridad en su infraestructura. La consulta y las comprobaciones citadas son orientativas, un resultado negativo no descarta la infección y deben validarse en un entorno de pruebas antes de automatizarlas.