Cuando el malware se esconde detrás de Tor: cómo funcionan los C2 ocultos y cómo los investigadores los descubren

¿Qué ocurre cuando un malware no quiere que su servidor de control pueda encontrarse fácilmente? Una de las respuestas que algunos grupos de ciberdelincuentes han utilizado es Tor.
Tor no fue diseñado para malware. Es una red de anonimización legítima utilizada por periodistas, investigadores, organizaciones y usuarios que necesitan proteger su privacidad. Sin embargo, precisamente las propiedades que hacen atractivo a Tor para determinados usuarios también pueden resultar útiles para los operadores de malware: ocultar la ubicación de determinados servicios y dificultar el rastreo de su infraestructura.
Y esto no es solamente una posibilidad teórica. Investigadores de seguridad han documentado numerosas familias de malware y campañas que utilizaron Tor para sus comunicaciones.
¿Qué es lo que realmente intenta esconder un atacante?
Imaginemos un malware tradicional con una infraestructura sencilla:
PC infectada
|
| HTTPS
v
example-c2.com
|
v
Servidor del atacante
Los investigadores que analicen el malware pueden encontrar el dominio, resolverlo, observar su certificado, estudiar su historial y relacionarlo con otras campañas.
Con Tor, el modelo puede cambiar:
PC infectada
|
| Tor
v
servicio .onion
|
v
Infraestructura del atacante
En este segundo escenario, el servicio puede estar publicado como un servicio onion y no presentar al cliente una dirección IP convencional del servidor.
MITRE ATT&CK clasifica el uso de Tor y otras redes de múltiples saltos como una técnica que puede utilizarse para ocultar infraestructura de comando y control. La propia documentación de MITRE señala ejemplos en los que adversarios utilizaron Tor para C2. MITRE ATT&CK+1
Pero hay algo fundamental:
Tor oculta una parte de la infraestructura; no hace desaparecer las evidencias del malware.
Y ahí es donde comienzan las investigaciones.
Onion Ransomware: uno de los ejemplos clásicos
Uno de los ejemplos históricos más conocidos es Trojan-Ransom.Win32.Onion, también conocido como Onion ransomware o CTB-Locker.
Kaspersky analizó esta amenaza y documentó que utilizaba la red Tor para comunicarse con servidores de comando y control. El objetivo era dificultar la localización de los operadores y proteger la infraestructura utilizada para manejar el ransomware.
La infección tampoco era necesariamente un único ejecutable que aparecía mágicamente en el equipo.
Kaspersky describió una cadena en la que Andromeda podía descargar y ejecutar un componente de la familia Joleee, que posteriormente descargaba Onion.
Esto es importante porque muestra una realidad frecuente de las campañas de malware:
Infección inicial
|
v
Downloader / botnet
|
v
Segundo componente
|
v
Ransomware
|
v
Comunicación C2
Es decir, el malware que finalmente causa el daño puede ser solamente una etapa de una cadena mucho mayor.
Simplocker: Tor llegó también al malware móvil
Tor tampoco fue exclusivo del malware de Windows.
En 2014, investigadores de ESET analizaron Android/Simplocker, un ransomware para Android que cifraba archivos almacenados en la tarjeta SD.
Lo particularmente interesante era su infraestructura de comando y control.
ESET descubrió que el C2 estaba alojado en un dominio .onion y que el malware se comunicaba con ese servicio para enviar información del dispositivo y esperar instrucciones.
Posteriormente, ESET observó variantes de Simplocker en las que algunas utilizaban Tor mientras otras utilizaban infraestructura de C2 convencional.
Esto demuestra algo importante:
Usar Tor no es una característica obligatoria de una familia de malware. Los operadores pueden cambiar de infraestructura entre versiones.
Troldesh: cuando los investigadores encontraron las huellas de Tor
Otro caso interesante fue el ransomware Troldesh.
ESET analizó el tráfico generado por una campaña y encontró que gran parte de sus comunicaciones pasaban por Tor.
Pero aquí aparece una de las partes más interesantes de la investigación forense: aunque el objetivo del malware era utilizar Tor para ocultar sus comunicaciones, el funcionamiento de Tor dejó artefactos en el propio sistema.
Los investigadores encontraron archivos de caché característicos de Tor, entre ellos:
cached-certs
cached-microdescs
cached-microdescs-consensus
state
El análisis permitió incluso identificar la versión de Tor utilizada por aquella muestra.
Esto es un excelente ejemplo de una idea que suele olvidarse:
Una tecnología que ayuda a ocultar una comunicación puede generar al mismo tiempo nuevas evidencias en el equipo donde se ejecuta.
WannaCry: Tor no era el único camino
WannaCry es otro nombre importante asociado históricamente con Tor. MITRE ATT&CK registra que WannaCry utilizó Tor para tráfico de comando y control.
Sin embargo, WannaCry también demuestra que un ataque puede tener varios mecanismos de comunicación y propagación.
La lección importante no es simplemente “WannaCry utilizaba Tor”, sino que un malware puede combinar diferentes técnicas dependiendo de lo que necesita hacer.
Tor puede servir para una parte de la infraestructura mientras otros mecanismos se encargan de propagarse, descubrir equipos o realizar otras funciones.
Pero no todos los malware sofisticados utilizan Tor
Aquí aparece una comparación fascinante.
Uno de los mejores ejemplos es SUNBURST, el backdoor utilizado en el compromiso de la cadena de suministro de SolarWinds.
SUNBURST no necesitaba esconderse detrás de un servicio .onion.
En lugar de eso, utilizaba una combinación extremadamente sofisticada de DNS y HTTP/HTTPS.
Mandiant descubrió que el malware generaba subdominios mediante un algoritmo DGA bajo avsvmcloud.com. Esos nombres no eran simples dominios aleatorios: podían incorporar información utilizada para identificar la víctima y controlar el comportamiento del malware.
El esquema simplificado era:
SUNBURST
|
v
DNS
|
v
C2 coordinator
|
v
respuesta DNS
|
v
CNAME
|
v
Servidor C2 final
|
v
HTTP/HTTPS
Y aquí viene una de las partes más impresionantes.
SUNBURST podía utilizar las respuestas DNS para cambiar de modo de operación.
Una respuesta podía indicar que debía permanecer pasivo; otra podía llevarlo a comunicarse con el C2 final; determinadas respuestas podían incluso activar el mecanismo que deshabilitaba el malware.
¿Cómo descubrieron SUNBURST?
La investigación no consistió simplemente en encontrar una IP.
Los investigadores analizaron el comportamiento del binario y observaron:
- consultas DNS;
- dominios generados;
- patrones de comunicación;
- comportamiento del malware;
- información codificada en los subdominios;
- conexiones posteriores mediante HTTP;
- y la infraestructura utilizada por el atacante.
Mandiant pudo reconstruir el protocolo y explicar cómo el malware utilizaba DNS como una primera etapa del C2.
Después ocurrió algo todavía más interesante.
El dominio utilizado por el malware fue redirigido a infraestructura controlada por investigadores, un procedimiento conocido como sinkholing. La respuesta fue diseñada para activar el mecanismo de desactivación de SUNBURST.
En otras palabras:
Malware
|
v
DNS del atacante
|
X
|
v
Sinkhole controlado por investigadores
|
v
respuesta especial
|
v
malware se desactiva
La infraestructura de mando se convirtió así en una fuente de información para los investigadores y, al mismo tiempo, en una herramienta para neutralizar parte de la amenaza.
Entonces, ¿Tor hace imposible encontrar al atacante?
No.
Hace algunas investigaciones más difíciles, pero no elimina las demás evidencias.
Supongamos que un malware utiliza Tor:
TOR
|
v
PC víctima ---> .onion
|
v
C2
El investigador puede no obtener directamente la IP del servidor final.
Pero todavía puede estudiar:
MUESTRA
|
+--------+--------+
| | |
v v v
proceso archivos red
| | |
+--------+--------+
|
v
comportamiento
|
v
indicadores de
compromiso
Y eso puede ser suficiente para identificar la familia de malware, encontrar otras máquinas infectadas o bloquear la comunicación.
MITRE incluso documenta técnicas de detección para comportamientos asociados con onion routing y Tor, incluyendo procesos desconocidos que generan conexiones cifradas persistentes hacia infraestructura de anonimización.
Y aquí llegamos a algo todavía más interesante: convertir la máquina víctima en un servicio onion
Esto ya no es solamente utilizar Tor para que el malware salga hacia un C2.
Existen casos documentados en los que los atacantes utilizan Tor para crear acceso remoto hacia una máquina comprometida.
MITRE documenta el uso de un backdoor asociado con APT29 que podía crear un servicio Tor oculto y reenviar tráfico hacia puertos locales como RDP, NetBIOS y SMB, permitiendo acceso remoto a sistemas dentro de una red.
Y existe un ejemplo más reciente y particularmente llamativo.
En 2026, Kaspersky ICS CERT describió actividad atribuida a Sandworm en la que los investigadores encontraron el despliegue de servicios Tor de una manera similar a la herramienta ShadowLink. En el caso descrito, el sistema comprometido quedaba configurado como un servicio Tor y se observó el reenvío hacia RDP. Microsoft había descrito anteriormente ShadowLink en relación con la campaña BadPilot.
El concepto es muy diferente:
ANTES
Atacante ---> C2
|
v
máquina infectada
DESPUÉS
Atacante
|
| Tor
v
.onion de la máquina comprometida
|
v
servicio remoto interno
Aquí Tor no está ocultando únicamente el servidor del atacante.
Puede utilizarse para crear un camino hacia la máquina que ya fue comprometida.
Esto se acerca muchísimo al escenario hipotético que planteábamos al principio de nuestra conversación.
Entonces, ¿por qué un atacante no utiliza siempre Tor?
Porque Tor tiene ventajas y desventajas.
Un C2 convencional puede ser mucho más sencillo:
malware
|
HTTPS
v
dominio.com
|
v
servidor
Es compatible con prácticamente cualquier sistema, puede mezclarse con tráfico web legítimo y no requiere necesariamente desplegar componentes adicionales.
Tor añade una capa de ocultación, pero también puede generar indicadores propios.
Por eso encontramos de todo en investigaciones reales:
| Malware / campaña | Comunicación documentada |
|---|---|
| Onion ransomware | Tor |
| Simplocker | Tor / variantes convencionales |
| Troldesh | Tor |
| WannaCry | Tor para C2 |
| SUNBURST | DNS + HTTP/HTTPS |
| GameOver Zeus | P2P/DGA |
| APT29 | Tor en determinadas operaciones |
| Sandworm / ShadowLink | Tor para acceso remoto |
Las tecnologías no son mutuamente excluyentes. Un mismo actor puede cambiar de estrategia dependiendo de la campaña.
La gran lección: esconder el servidor no significa esconder el ataque
Quizá ésta sea la parte más importante de todo el tema.
Un atacante puede conseguir que su infraestructura sea difícil de localizar.
Puede utilizar:
Tor
VPN
proxies
dominios
DNS
servidores comprometidos
P2P
Pero el malware sigue teniendo que hacer algo en la máquina de la víctima.
Y esas acciones pueden dejar rastros.
Un investigador puede encontrar:
- procesos sospechosos;
- archivos creados;
- servicios nuevos;
- modificaciones de configuración;
- tareas de persistencia;
- conexiones de red;
- consultas DNS;
- artefactos de Tor;
- claves o credenciales;
- patrones de comportamiento;
- y relaciones entre diferentes muestras de malware.
Por eso las investigaciones modernas de malware no dependen exclusivamente de encontrar una IP.
La pregunta ya no es solamente:
“¿A qué IP se conecta este virus?”
También es:
“¿Qué hace, cuándo lo hace, cómo se comunica, qué modifica y qué otros sistemas se comportan de la misma manera?”
Y esa perspectiva es la que permitió reconstruir campañas enormes como SolarWinds/SUNBURST incluso cuando los operadores hicieron un esfuerzo considerable para ocultar su infraestructura.



