La red Tor sirve para navegar sin revelar quién eres, pero no hace milagros con lo que viaja por ella. A principios de octubre de 2026 eso quedó bastante claro. Según Ars Technica, un atacante controló 333 nodos de salida de Tor durante unos tres días. Quería dos cosas: las contraseñas de quienes se conectaban a servidores remotos y el correo que viajara sin cifrar. Esos nodos eran más o menos el 10 % de los cerca de 3.000 que tiene la red, una porción enorme para un solo ataque.

Cómo funciona Tor y por qué la salida es el punto débil

Cuando usas Tor, tu tráfico pasa por tres ordenadores de voluntarios, que la red llama relés. Cada uno solo conoce el paso anterior y el siguiente. El último es el nodo de salida, y es el que habla en tu nombre con la web o el servidor al que quieres llegar. Por eso es la pieza delicada. Tor protege tu anonimato dentro de la red, pero lo que sale del nodo de salida va tal cual. Si tu conexión no lleva su propio cifrado, quien controle esa salida puede leerla y también manipularla.

Esos relés los mantienen particulares y organizaciones, y cada uno decide qué tráfico deja salir. Eso se configura en lo que se llama política de salida. Por ejemplo, muchos bloquean el puerto 22, el de SSH, que se usa para administrar servidores a distancia. El atacante entró justo por ahí.

Qué hicieron exactamente los atacantes

Según la reconstrucción que recogen SecureWorld y CyberPress, todo empezó semanas antes. A finales de agosto, el atacante entró en el servidor de gestión de una de las familias de relés más grandes con una contraseña reutilizada. Después instaló Ebury, una puerta trasera para Linux que se conoce desde hace años y está pensada para robar credenciales SSH. Ese servidor de gestión le abrió camino hacia otras máquinas. Había otro patrón llamativo: la mayoría de los relés afectados fuera de esa familia estaban alojados en el mismo proveedor de servidores. Aún no se sabe si el ataque llegó también por el lado del proveedor.

Entre el 1 y el 2 de octubre empezó la fase visible. Los atacantes reescribieron las políticas de salida de cientos de relés:

• Abrieron el puerto 22 en relés que antes lo bloqueaban y convirtieron en nodos de salida a otros que no lo eran.
• Desviaron las conexiones SSH hacia 12 servidores intermediarios. Esos servidores mostraban una clave de identidad falsa, se quedaban con la contraseña y después pasaban la sesión al destino real para no levantar sospechas.
• Cerraron los puertos de correo cifrado (como el 465, el 587, el 993 o el 995) y dejaron abiertos los de POP3 e IMAP sin cifrar. Si un cliente de correo acababa conectándose sin cifrado, los mensajes y credenciales viajaban a la vista.

Un investigador se dio cuenta el 2 de octubre porque su cliente SSH le avisó de que la clave del servidor había cambiado. Ese aviso es justo el que mucha gente ignora con un clic. En su momento de máximo alcance, el ataque llegó a tener cerca del 7,5 % de la capacidad de salida de toda la red.

La respuesta de Tor y la letra pequeña

El equipo que vigila la salud de la red empezó a marcar los relés afectados como BadExit, una etiqueta que impide usarlos como salida. El 5 de octubre ya no quedaba ninguno en el consenso, la lista oficial de relés que usan los clientes. El precio fue alto: la red perdió unos 370 nodos de salida, y a mediados de mes todavía no se había recuperado.

Hay una noticia tranquilizadora: la autenticación SSH con claves no quedó expuesta. Con claves, cada firma vale solo para esa sesión, así que aunque el intermediario la viera no podía reutilizarla. Las víctimas posibles eran quienes entraban con contraseña y además aceptaban el aviso de clave cambiada. Lo que todavía no se sabe:

• De dónde salió la contraseña original.
• Si detrás hay un solo actor o varios.
• Quién es el atacante: las informaciones publicadas no lo atribuyen a ningún grupo.

Ebury también tiene un detalle técnico que preocupa. Pasa las comprobaciones de integridad de paquetes del sistema y apenas deja rastro en los registros. Por eso los operadores afectados han tenido que reinstalar desde cero, porque limpiar las máquinas no daba garantías.

Por qué importa

Este caso deja dos lecciones que valen para cualquiera, use Tor o no. La primera: el anonimato no es lo mismo que el cifrado. Si una conexión no va cifrada de extremo a extremo, alguien en el camino puede leerla o manipularla. La segunda: los avisos que parecen pesados existen por algo. Si SSH dice que la clave del servidor ha cambiado y no sabes por qué, no aceptes. Usa claves en lugar de contraseñas, no repitas la misma contraseña para todo y exige conexiones cifradas en tu correo. Son hábitos aburridos, pero aquí habrían bastado para que los atacantes se fueran con las manos vacías.