Actores de amenazas han sido vistos intentando explotar una vulnerabilidad crítica ya parcheada que afecta al kit de desarrollo de software (SDK) Realtek Jungle para desplegar un malware botnet llamado Cling.
Cling es notable no porque introduzca una nueva técnica de propagación, sino porque reutiliza el comportamiento ordinario de STUN como un canal práctico de comando y control. El resultado es un botnet cuyo tráfico puede parecerse a una actividad legítima de atravesamiento de NAT, mientras sigue soportando propagación, proxy, tunelización y comandos de denegación de servicio.
La empresa de seguridad de tecnología operativa (OT) dijo que observó un pico en los intentos de explotar CVE-2021-35394 (puntuación CVSS: 9.8), una vulnerabilidad crítica de ejecución remota de código (RCE) en Realtek Jungle SDK, a partir del 5 de septiembre de 2026, con un subconjunto de la actividad entregando Cling.
Un análisis de la muestra de malware encontró que incorpora lógica de explotación para varias vulnerabilidades de inyección de comandos y RCE que afectan a routers y DVRs de múltiples fabricantes:
- Realtek SDK RCE (CVE-2014-8361)
- Eir D1000 router RCE (CVE-2016-10372)
- MVPower CCTV DVR RCE (CVE-2016-20016)
- LB-LINK routers RCE (CVE-2023-26801)
- FiberHome SR1041F router / China Mobile HG6543C4 RCE (CVE-2023-41011)
- TBK DVR RCE (CVE-2024-3721)
- Linksys RCE (CVE-2025-34037)
La comprobación de instancia única para ejecutar solo una copia implica enlazar un socket con SO_REUSEADDR al puerto 33957 y salir limpiamente si falla. La muestra se copia a sí misma en /root/.cling y /usr/local/bin/.cling. Ambos ejecutables se añaden a /etc/inittab, /etc/init.d/rcS, /etc/rc.d/rc.boot, logrando así persistencia en sistemas init SysV y BusyBox.
Un mecanismo de persistencia alternativo implica identificar el binario wget en el sistema infectado y luego reemplazarlo con el malware, pero no antes de mover el original a otra ubicación. Esto, a su vez, hace que el malware se ejecute cuando un proceso legítimo invoca el comando "wget".
Un aspecto notable de Cling es su abuso del tráfico STUN de apariencia inofensiva y de la infraestructura pública STUN para registrar hosts infectados, recibir comandos del operador y hacer que la actividad maliciosa sea menos obvia desde la perspectiva de la monitorización de red.
STUN, acrónimo de Session Traversal Utilities for Network Address Translation (NAT), es un protocolo de red estandarizado diseñado para ayudar a los dispositivos detrás de un NAT o cortafuegos a establecer comunicaciones peer-to-peer en tiempo real.
Específicamente, el malware sigue un proceso de cuatro pasos para las comunicaciones de comando y control (C2):
- Envía una solicitud de enlace STUN a una lista codificada de 13 servidores STUN aproximadamente cada 5 segundos. El ID de transacción se establece en todos ceros en lugar de un valor aleatorio, como dicta la especificación.
- Registra los puertos observados externamente devueltos por esos servidores al recibir un mensaje de respuesta exitosa de enlace que contiene la dirección IP pública del endpoint y los números de puerto asociados.
- Envía un mensaje de registro personalizado (es decir, un datagrama UDP) a cada servidor que incluye los puertos mapeados y una etiqueta que denota cómo se infectó el dispositivo (por ejemplo, realtek.selfrep, selfrep.router).
- Sondea paquetes UDP que codifican comandos del operador en el campo de ID de transacción STUN.
Desde la perspectiva de la monitorización de red, la actividad aparece como una interacción inocua con servidores STUN. Dado que el mensaje de registro personalizado se envía a todos los servidores STUN de la lista, es evidente que el operador requiere visibilidad de al menos uno de los servidores, para rastrear nuevos bots que se unen al enjambre y saber dónde enviar comandos.
Cabe señalar que estos mensajes de registro no se ajustan a la definición del protocolo STUN, lo que hace que los servidores STUN legítimos descarten el paquete. Sin embargo, se dice que uno de los 13 servidores ("145.249.115[.]184") devolvió un ID de transacción todo ceros en lugar de hacer eco del ID de transacción de la solicitud de enlace original en la respuesta exitosa de enlace.
Este comportamiento inusual, según Nozomi, sugiere que el servidor STUN está adaptado al propio tráfico STUN del bot y que se utiliza para enviar comandos emitidos por el operador al dispositivo infectado incrustándolos en el campo de ID de transacción STUN.
Los comandos permiten al actor de amenazas escanear y propagar recursivamente la escala del botnet de manera similar a un gusano, generar/detener un túnel TCP, lanzar/detener un proxy y realizar un ataque de denegación de servicio (DoS) contra un objetivo específico durante un tiempo determinado. Algunos de los objetivos de los ataques de inundación son los siguientes:
- 112.151.157[.]222:8080 (ISP de Corea del Sur)
- 192.170.240[.]137:53 (clúster de la Universidad de Chicago)
- 23.81.40[.]193:25565 (Minecraft)
- 147.185.221[.]129:25565 (Minecraft)
La parte más interesante del tráfico C2 es de dónde parecían provenir los comandos. Los paquetes que transportan comandos del operador se originan en 74.125.250[.]129, una dirección IP a la que resuelve stun.l.google.com. En otras palabras, el operador no solo oculta comandos dentro de un paquete que parece STUN, sino que hace que esos comandos parezcan respuestas legítimas de uno de los servicios STUN más reconocibles de internet.
Deja una respuesta