Ebury en 333 nodos de salida Tor: contraseñas SSH interceptadas

A principios de octubre de 2026, una parte importante de los relays de salida de la red Tor se utilizó para un ataque man-in-the-middle contra conexiones SSH. La noticia la publican The Hacker News, Ars Technica e Insicurezza Digitale; según estos dos últimos, los relays implicados son 333, comprometidos con Ebury, la backdoor para Linux documentada desde 2014. Los detalles que siguen proceden de Ars Technica e Insicurezza Digitale, que recogen el informe publicado el 20 de octubre por un voluntario de Tor que firma como Kaba y la información del Tor Project.

Qué ha pasado

Según Ars Technica, la intrusión empezó a finales de agosto: el atacante entró en el servidor de gestión de un operador de relays con una contraseña válida y reutilizada. Insicurezza Digitale sitúa el acceso el 28 de agosto de 2026 y añade que la misma contraseña servía para SSH, para sudo y como frase de paso de las copias de seguridad, y estaba guardada en claro en dos máquinas; los privilegios de root llegaron en cinco minutos.

Desde allí el atacante se conectó por SSH a un segundo servidor, «Switzerland2», con una clave RSA que no figura entre las claves autorizadas, e instaló Ebury. No se ha aclarado cómo llegó a controlar los 333 relays: ambos medios citan la hipótesis, no confirmada, de un acceso a nivel del proveedor de hosting.

Cómo funcionaba la interceptación

Los relays comprometidos se modificaron en el archivo de configuración torrc:

• SSH: las conexiones al puerto 22 se desviaban a uno de 12 servidores de interceptación con su propia clave de host. Quien ignoraba el aviso «REMOTE HOST IDENTIFICATION HAS CHANGED» escribía la contraseña en el servidor del atacante, que después reenviaba la sesión al servidor legítimo. Según Insicurezza Digitale, algunos middle relays se convirtieron además en relays de salida con el puerto 22 abierto.
• Correo: se bloqueaban los puertos del correo cifrado y se dejaban abiertos los de texto en claro. Ars Technica enumera los puertos 25, 465, 587, 993 y 995; Insicurezza Digitale cita 465, 587, 993 y 995. No se sabe si algún downgrade tuvo éxito.

Con un honeypot, Kaba observó lo que ocurría tras capturar la contraseña: una primera conexión al servidor de la víctima para ver los comandos tecleados y luego una segunda para instalar Ebury. Insicurezza Digitale recoge los comandos observados (id -u, command -v sudo, sudo -n true), seguidos de un instalador Perl con payload en base64 enviado mediante la biblioteca Python paramiko. Cada contraseña robada se convertía así en un nuevo servidor infectado.

La autenticación con clave pública no está expuesta a este esquema: la firma está ligada a cada sesión y no se puede reenviar.

Cronología y respuesta del Tor Project

Kaba recibió el aviso sobre la clave de host el 2 de octubre y después probó uno a uno los cerca de 3.000 relays de salida, comprobando la huella SSH que devolvía un servidor de prueba. Las fuentes difieren ligeramente sobre la ventana de ataque: Ars Technica indica del 2 al 5 de octubre; Insicurezza Digitale, desde el 1 de octubre, cuando 40 relays de 21 operadores cambiaron de política en cinco minutos y medio.

Según Insicurezza Digitale, el 4 de octubre el Tor Project contactó con los operadores y asignó a los relays afectados los flags BadExit y MiddleOnly; el pico de capacidad de salida comprometida, por peso de consenso, fue del 7,46 %. El 5 de octubre el último relay con la política del atacante salió del consenso.

Ebury: qué buscar en los servidores Linux

Insicurezza Digitale indica que la versión encontrada es la 1.8.3, más reciente que la de los indicadores públicos de ESET (1.8.2). Ebury se hace pasar por la biblioteca del sistema libkeyutils.so, no modifica los binarios de sshd y sudo, supera las comprobaciones dpkg -V y debsums, no deja rastro en los registros de acceso estándar y sobrevive a los reinicios.

Indicadores publicados por Insicurezza Digitale:

• archivo /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2, que no pertenece a ningún paquete (hash distinto en cada host), al que apunta el enlace libkeyutils.so.1;
• socket UNIX abstracto @event-0YsOG9WSOE;
• procesos falsos rsyslogd, systemd-udevd y arpd, y un proceso oculto snf;
• claves SSH de la infraestructura del atacante: ED25519 SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E (la misma del aviso que recoge Ars Technica), ED25519 SHA256:OfLY0uF9SwOW9xVjiMXZGDfk6Atmz6CbHy4epknLm8Y, RSA SHA256:dvACokMYcXJ2om4wuS+TvdtjrAgPK7rC7ZQHDgvBHzk, RSA SHA256:KlICz/B59619CpuQdGzgmmvzWBfTMUJ77EwihTYobuo;
• dirección del primer acceso, el 28 de agosto: 185.225.226.62.

Correspondencia indicativa con MITRE ATT&CK, a partir de los hechos publicados: T1078 (Valid Accounts), T1021.004 (Remote Services: SSH), T1557 (Adversary-in-the-Middle), T1014 (Rootkit), T1036 (Masquerading).

Impacto para las empresas europeas e italianas

El riesgo directo afecta a quien administró servidores con contraseña SSH a través de Tor en los primeros días de octubre, incluidos consultores y proveedores: la contraseña interceptada llevó a una backdoor en el servidor de destino. La causa de fondo, una contraseña reutilizada entre SSH, sudo y copias de seguridad, afecta a cualquier parque Linux. Para las entidades sujetas a NIS2, la autenticación, la ciberhigiene y la seguridad de los proveedores forman parte de las medidas del artículo 21. Y los buzones que aún aceptan IMAP y POP3 en claro exponen las credenciales en cualquier red no confiable, no solo en Tor.

Qué hacer ya

1. Pregunta quién usa Tor para llegar a los servidores de la empresa. Si alguien aceptó una clave de host desconocida entre el 1 y el 5 de octubre, considera la contraseña comprometida, cámbiala dondequiera que se haya reutilizado y revisa el servidor de destino.
2. Desactiva el acceso SSH con contraseña (PasswordAuthentication no) y usa claves o certificados. No reutilices la misma contraseña para SSH, sudo y copias de seguridad.
3. No ignores nunca el aviso de clave de host cambiada: StrictHostKeyChecking yes con known_hosts gestionados de forma centralizada, o certificados de host.
4. Busca los indicadores: comprueba con dpkg -S o rpm -qf a qué paquete pertenece libkeyutils y busca el socket abstracto con ss -xa. Insicurezza Digitale sugiere abrir la shell con H=1 I=1 LD_PRELOAD=":" LD_DEBUG=":" bash para esquivar el rootkit; si es posible, analiza el disco con la máquina apagada.
5. Host comprometido: el Tor Project indica a los operadores que lo desconecten, conserven disco y registros, reinstalen desde cero y roten todas las credenciales que contenga.
6. Correo: rechaza IMAP y POP3 en claro y acepta la autenticación solo sobre TLS.

Cómo ayuda ARXDOME

ARX Expose muestra los puertos abiertos y la configuración del correo visibles desde fuera. En los servidores Linux, el agente de ARX Sentry recoge el inventario de procesos y puertos y controla la integridad de los archivos en las carpetas elegidas, mientras que ARX Shield verifica el hardening según los benchmarks CIS. ARX Horizon enriquece cada conexión con país, operador y listas de amenazas, de modo que un acceso SSH desde una dirección inusual se distingue enseguida.

Última actualización: 22 de octubre de 2026