Ciberdelincuentes están explotando fallos críticos en el SDK de Realtek y otros dispositivos para desplegar el malware Cling. Esta botnet destaca por disfrazar su tráfico de mando y control como comunicaciones STUN legítimas, simulando incluso respuestas de servidores de Google. El malware permite realizar escaneos recursivos, crear túneles y ejecutar ataques de denegación de servicio.





Se ha observado que diversos actores de amenazas han intentado explotar un fallo de seguridad crítico, ya parcheado, que afecta al kit de desarrollo de software (SDK) Realtek Jungle para desplegar un malware de botnet llamado Cling.

"Cling destaca no porque introduzca una nueva técnica de propagación, sino porque reutiliza el comportamiento ordinario de STUN en un canal práctico de comando y control", afirmó Nozomi Networks en un informe publicado la semana pasada. "El resultado es una botnet cuyo tráfico puede parecer una actividad legítima de salto de NAT, mientras sigue admitiendo comandos de propagación, proxy, túneles y denegación de servicio".

La empresa de seguridad de tecnología operativa (OT) señaló que observó un aumento en los intentos de explotar el CVE-2021-35394 (puntuación CVSS: 9.8), un fallo crítico de ejecución remota de código (RCE) en el SDK Realtek Jungle comenzando alrededor del 5 de septiembre de 2026, donde una parte de la actividad entregaba Cling.

Un análisis de la muestra del malware ha revelado que incluye lógica de explotación para diversas vulnerabilidades de inyección de comandos y RCE que afectan a routers y DVRs de múltiples proveedores:

* RCE de Realtek SDK (CVE-2014-8361)
* RCE de router Eir D1000 (CVE-2016-10372)
* RCE de MVPower CCTV DVR (CVE-2016-20016)
* RCE de routers LB-LINK (CVE-2023-26801)
* RCE de router FiberHome SR1041F / China Mobile HG6543C4 (CVE-2023-41011)
* RCE de TBK DVR (CVE-2024-3721)
* RCE de Linksys (CVE-2025-34037)

"La comprobación de instancia única para ejecutar solo una copia implica vincular un socket con SO_REUSEADDR al puerto 33957 y salir limpiamente si falla", explicó Nozomi Networks. "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í la persistencia en los sistemas de inicio SysV y BusyBox".

Un mecanismo de persistencia alternativo consiste en identificar el binario wget en el sistema infectado y sustituirlo por el malware, pero no sin antes mover el original a otra ubicación. Esto, a su vez, provoca 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 la infraestructura STUN pública 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, abreviatura 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 firewall 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 vinculación STUN a una lista predefinida de 13 servidores STUN aproximadamente cada 5 segundos. El ID de transacción se establece en ceros en lugar de un valor aleatorio.
* Registra los puertos observados externamente devueltos por esos servidores al recibir un mensaje de respuesta de vinculación exitosa que contiene la IP pública del endpoint y los números de puerto asociados.
* Envía un mensaje de registro personalizado (un datagrama UDP) a cada servidor que incluye los puertos mapeados y una etiqueta que indica cómo se infectó el dispositivo.
* Realiza sondeos de paquetes UDP que codifican los comandos del operador en el campo de ID de transacción STUN.

"Desde la perspectiva de la monitorización de red, la actividad parece una interacción inocua con servidores STUN", dijo Nozomi Networks. "Dado que el mensaje de registro personalizado se envía a cada servidor STUN de la lista, es evidente que el operador requiere visibilidad en al menos uno de los servidores para rastrear los nuevos bots que se unen al enjambre y saber dónde enviar los comandos".

Cabe destacar que estos mensajes de registro no cumplen con 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 de ceros en lugar de hacer eco del ID de la solicitud original.

Este comportamiento inusual 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 recursivamente y extender la escala de la botnet al estilo de un gusano, crear o detener un túnel TCP, lanzar o 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:

* 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 parecen provenir los comandos", explicó Nozomi Networks. "Los paquetes que llevan los 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 se limita a ocultar comandos dentro de un paquete con apariencia de STUN, sino que hace que esos comandos parezcan respuestas legítimas de uno de los servicios STUN más reconocibles de internet".

Fuente:
THN