Todos los artículos

Noticias5 de octubre de 20265 min de lectura

ClingSTUN: dispositivos IoT convertidos en proxies con STUN

Una backdoor Linux explota 24 vulnerabilidades conocidas de routers, cámaras y DVR y usa servidores STUN públicos para seguir accesible. Qué hacer.

Mapa del mundo con dispositivos conectados en red, un monitor con un escudo y filas de servidores

El 5 de octubre de 2026 FortiGuard Labs, el equipo de investigación de Fortinet, publicó el análisis de una backdoor Linux a la que llama ClingSTUN. El malware entra en routers, cámaras, grabadores de vídeo y otros dispositivos expuestos a Internet aprovechando vulnerabilidades conocidas y sin corregir, y los convierte en nodos proxy controlados a distancia. Para seguir accesible detrás del NAT usa servidores STUN públicos y legítimos, los mismos que usan VoIP y WebRTC.

La noticia la recogieron The Hacker News, Dark Reading, Infosecurity Magazine y CSO Online. The Hacker News la presenta como la botnet “Cling” y destaca los intentos de explotación del Realtek Jungle SDK; los demás medios usan el nombre ClingSTUN.

Qué ha pasado

Según la investigación recogida por Infosecurity Magazine, FortiGuard siguió la campaña en tres periodos, cada uno con un servidor de descarga distinto:

  • primer periodo, de dos días: una sola vulnerabilidad, CVE-2022-36553, en los routers Hytec Inter;
  • segundo periodo: CVE-2025-34035 en el servicio cloud IoT de EnGenius y CVE-2024-23625 en el servicio UPnP de D-Link; después, vulnerabilidades de command injection en dispositivos Linear, Realtek, TP-Link, AVTECH y D-Link;
  • tercer periodo: nuevos puntos de entrada, hasta 24 vulnerabilidades en total. Entre ellas están las de Ivanti Connect Secure CVE-2023-46805 y CVE-2024-21887 y otras más recientes como CVE-2026-36356 y CVE-2025-67038.

CSO Online cita también entre los objetivos los routers TP-Link Archer AX21 y las cámaras AVTECH, y habla de vulnerabilidades de command injection, code injection y buffer overflow. Las fuentes no nombran a ninguna víctima.

Detalles técnicos

El papel del dispositivo. ClingSTUN es una backdoor de tipo back-connect proxy: el dispositivo comprometido reenvía tráfico por cuenta de los operadores y ejecuta sus órdenes. Como señala Jason Soroko, de Sectigo, a CSO Online, un dispositivo no necesita contener datos sensibles para ser útil a un atacante.

El uso de STUN. El malware envía peticiones binding STUN estándar a servidores públicos (24 en la segunda versión, 13 en la tercera) para descubrir su dirección externa y el mapeo de puertos, y para mantener abiertas las asociaciones del NAT. Después comunica periódicamente a esos mismos servidores un identificador de grupo y los puertos mapeados. El tráfico se parece al de comunicaciones VoIP y WebRTC normales. FortiGuard aclara que aún no se ha verificado cómo obtiene el operador los mapeos y cómo hace llegar las órdenes a través del NAT, y advierte de que no hay que considerar los servicios STUN como infraestructura de los atacantes.

Persistencia y ocultación. Tras la instalación, ClingSTUN:

  • termina los procesos competidores y desactiva el watchdog del dispositivo;
  • se copia en rutas ocultas del sistema;
  • se añade al arranque modificando /etc/inittab, /etc/init.d/rcs y /etc/rc.d/rc.boot (rutas indicadas por CSO Online);
  • hace que su entrada en /proc parezca la del proceso init del sistema.

Ejecución y propagación. Admite la ejecución remota de órdenes y lleva exploits para otras siete vulnerabilidades, entre ellas fallos del SDK de Realtek y de tres productos DVR, con los que se propaga a otros dispositivos. Está compilado para ARM, Intel 80386, MIPS, PowerPC y x86-64.

Indicadores públicos. Los artículos consultados no incluyen hashes ni direcciones: los indicadores de compromiso están en la investigación original de FortiGuard Labs.

MITRE ATT&CK (mapeo a partir de los hechos publicados): T1190 (Exploit Public-Facing Application), T1105 (Ingress Tool Transfer), T1037.004 (Boot or Logon Initialization Scripts: RC Scripts), T1036 (Masquerading), T1059.004 (Unix Shell), T1090 (Proxy), T1210 (Exploitation of Remote Services).

Impacto para las empresas europeas e italianas

Las fuentes no citan víctimas en Europa, pero los dispositivos afectados son comunes también aquí: routers de pequeñas oficinas, cámaras y grabadores de videovigilancia, equipos de red olvidados en un armario. Cuando un dispositivo así se convierte en proxy, el tráfico de otros sale por tu conexión, y tu dirección IP puede aparecer en los registros de ataques contra terceros.

La presencia de Ivanti Connect Secure en la lista recuerda que el mismo operador no apunta solo al IoT: los concentradores VPN sin actualizar son una puerta de entrada a la red corporativa. Para las entidades sujetas a NIS2, el artículo 21 exige la gestión de vulnerabilidades y la seguridad en la adquisición y el mantenimiento de los sistemas: las cámaras y los routers sin soporte forman parte del perímetro que debes gestionar.

Sobre el método hay opiniones distintas. Louis Eichenbaum, de ColorTokens, propone controles compensatorios y microsegmentación para los dispositivos que no se pueden actualizar de inmediato; John Gallagher, de Viakoo, cree en cambio que la segmentación por sí sola no basta y apuesta por la actualización automática del firmware en parques IoT de varios fabricantes.

Qué hacer ya

  1. Haz el inventario de los dispositivos expuestos a Internet, con modelo, versión de firmware y estado del soporte del fabricante.
  2. Actualiza primero los dispositivos afectados por las CVE citadas y, en particular, Ivanti Connect Secure por CVE-2023-46805 y CVE-2024-21887.
  3. Sustituye o aísla los dispositivos que ya no reciben actualizaciones: nada de interfaces de gestión ni UPnP expuestos a Internet.
  4. Filtra el tráfico de salida de las redes de cámaras, DVR e IoT: permite solo los destinos que realmente necesitan.
  5. Busca tráfico STUN donde no tiene sentido. Un DVR o una cámara que contacta a intervalos regulares con servidores STUN públicos, o que abre conexiones UDP inesperadas con keepalive recurrentes, debe revisarse. Como dice Soroko, lo que cuenta es el comportamiento del dispositivo, no la reputación del destino.
  6. En los dispositivos donde tengas una shell, revisa las entradas de arranque en /etc/inittab y en los scripts de /etc/init.d/ y /etc/rc.d/, y comprueba si hay más de un proceso que se presenta como init.
  7. Compara tus registros con los indicadores de compromiso publicados por FortiGuard Labs.

Cómo ayuda ARXDOME

ARX Expose muestra desde fuera los puertos abiertos, los productos reconocidos y las vulnerabilidades conocidas de los servicios públicos: ahí aparecen las interfaces de gestión y los dispositivos expuestos por error. ARX Watch encuentra en la red los dispositivos sin sonda, como cámaras y grabadores de vídeo, y avisa cuando aparece uno nuevo. ARX Sentry recoge los registros de los firewalls y los lleva a las páginas del SOC y al mapa del NOC, con las conexiones rechazadas y el tráfico de salida bloqueado. En los dispositivos IoT no se instala un agente: la visibilidad llega a través de la red y del firewall.

Última actualización:

¿Tienes preguntas?

Hablemos de las necesidades de tu empresa, sin compromiso.

Contáctanos

Artículos relacionados