Índice de contenidos
Claves de la noticia
- FortiGuard Labs documenta ClingSTUN, una puerta trasera para Linux que convierte dispositivos vulnerables en nodos proxy controlados a distancia.
- El informe diferencia 24 vulnerabilidades de acceso inicial y siete de autopropagación: sus listas no comparten ningún identificador CVE.
- El malware utiliza servidores STUN públicos legítimos; contactar con ellos no basta para demostrar una infección.
FortiGuard Labs ha publicado este 5 de octubre un análisis de ClingSTUN, un malware que aprovecha fallos conocidos y sin corregir en dispositivos expuestos a internet. Su particularidad es apoyarse en servicios utilizados también por comunicaciones legítimas para mantener conectividad. El informe permite entender qué debe buscar un administrador, pero conserva una incógnita relevante sobre cómo el operador alcanza los equipos detrás de NAT.
Un proxy malicioso en equipos que siguen sin parchear
El análisis técnico de Vincent Li para FortiGuard Labs describe una puerta trasera de conexión inversa. El dispositivo comprometido pasa a funcionar como un nodo proxy que los atacantes pueden controlar remotamente. El punto de entrada son vulnerabilidades conocidas en equipos accesibles desde internet, no una capacidad demostrada para vulnerar cualquier máquina Linux.
Los investigadores distinguen tres períodos de la campaña, con un servidor de descarga diferente en cada uno. La primera etapa, de solo dos días, explotaba una inyección de comandos en routers Hytec Inter HWL-2511-SS, identificada como CVE-2022-36553. Después aparecieron ataques contra el servicio Enshare de EnGenius y UPnP de D-Link, antes de ampliar el repertorio a otros fabricantes y servicios.
Ese recorrido importa para valorar la exposición. La campaña no depende de un único producto ni de una única generación de procesadores. Los descargadores obtienen variantes para ARM, Intel 80386, MIPS R3000, PowerPC y AMD x86-64. El análisis detallado de las últimas evoluciones se centra, sin embargo, en muestras x86-64; no demuestra que todos los dispositivos de cada arquitectura hayan sido atacados.
Dos listas de fallos que exigen dos comprobaciones
El informe contiene una tabla de vulnerabilidades empleadas como entrada y otra de fallos integrados en el malware para propagarse. Un recuento propio de los identificadores CVE de ambas tablas y de la descripción de incidentes arroja 24 de acceso inicial y siete de autopropagación, sin coincidencias. Se excluye del cálculo la lista comercial de firmas de protección, que vuelve a mencionar muchos de esos fallos.
| Función | CVE distintos | Ejemplos del informe |
|---|---|---|
| Acceso inicial | 24 | Hytec Inter, EnGenius, D-Link, TP-Link |
| Autopropagación | 7 | Realtek, MVPower, TBK, Linksys |
| Coincidencias entre listas | 0 | Conjuntos diferentes |
Por tanto, revisar únicamente las siete vulnerabilidades de propagación dejaría fuera todos los identificadores del repertorio de entrada descrito. La unión reúne 31 CVE distintos, pero eso no significa que una misma máquina necesite presentar los 31 ni que un ataque los utilice simultáneamente. Cada fallo debe cruzarse con el modelo, el servicio y la versión de firmware concretos.
Entre los ejemplos de entrada figura CVE-2023-1389 en TP-Link Archer AX21; entre los de propagación, CVE-2014-8361 en Realtek y CVE-2024-3721 en DVR de TBK. Las fechas de esos identificadores muestran que parte de la exposición procede de deuda de mantenimiento acumulada. Un dispositivo veterano puede seguir siendo útil como proxy aunque ya no sea un producto atractivo para su propietario.
STUN descubre el mapa; la orden llega por otra conexión
STUN ayuda a conocer la dirección y el puerto visibles desde fuera de una red con traducción de direcciones, o NAT. ClingSTUN abre un socket UDP y envía solicitudes de enlace estándar de 20 bytes. La segunda evolución descrita utiliza 24 endpoints públicos y exige que al menos la mitad funcionen; la tercera reduce la lista a 13 y comprueba todos.
Tras esos intercambios, el malware envía periódicamente su identificador de grupo y la lista de puertos mapeados a los mismos endpoints. Los investigadores no identificaron un registro separado en un servidor de coordinación en esa ruta. Además, dejan explícitamente sin verificar cómo obtiene el operador ese mapa externo y cómo entrega el tráfico de control a través de NAT.
La ejecución remota sí tiene una secuencia analizada: cuando un datagrama de control alcanza un socket UDP conservado, una orden determinada provoca una conexión TCP saliente al destino indicado. Por esa conexión se recibe y ejecuta un comando. El servicio STUN público y el destino que entrega la orden no deben tratarse automáticamente como la misma infraestructura.
Esta separación cambia la lectura de una alerta. Bloquear todos los servidores STUN contactados puede perjudicar usos legítimos de VoIP o WebRTC y no resuelve por sí solo el acceso inicial. Lo defendible es correlacionar la conexión UDP con el proceso que la origina, su persistencia y las conexiones posteriores; una dirección de un servicio público aislada no acredita control del atacante.
El reinicio y la lista de procesos pueden engañar
ClingSTUN copia su ejecutable en archivos ocultos y añade órdenes a scripts de arranque para volver a ejecutarse. También termina procesos competidores y manipula el temporizador watchdog. Esas acciones explican por qué reiniciar un equipo sin investigar su firmware y sus mecanismos de inicio no constituye una limpieza demostrada.
El malware borra sus argumentos originales para que su línea de comandos aparezca vacía. Cuando dispone de privilegios de administrador, emplea información del proceso inicial del sistema y montajes sobre su directorio en /proc para ocultar sus propios metadatos. Revisar solo el nombre mostrado por una herramienta de procesos deja, por ello, una comprobación incompleta.
Para una organización española con cámaras, routers o servicios de administración remota, el primer paso operativo es cruzar inventario, soporte y exposición exterior con las dos listas del informe. Después corresponde aplicar las actualizaciones disponibles, restringir servicios innecesarios y aislar o sustituir dispositivos sin soporte. FortiGuard no publica un recuento de víctimas españolas ni una dimensión global de la infección; no cabe deducirlos de la variedad de fabricantes.
La conclusión práctica es doble: corregir la puerta de entrada sigue siendo prioritario, y detectar este proxy exige unir señales de red y del sistema. La incertidumbre sobre la entrega de control a través de NAT limita lo que puede afirmarse sobre su coordinación, sin borrar los mecanismos de persistencia y ejecución que sí han sido analizados.
Imagen: escena conceptual generada con IA para Tecnología Today; no muestra un dispositivo infectado real.
