AryStinger: la red de reconocimiento que nace de routers olvidados y NAS fuera de soporte

Un nuevo árbol de infraestructuras maliciosas ha florecido aprovechando lo que muchos creían inofensivo: routers domésticos olvidados y cajas NAS fuera de soporte. QiAnXin XLab bautizó la familia como AryStinger, y describe un despliegue que no busca convertir cada equipo en un arma de saturación, sino en una red de reconocimiento y proxy que opera en la fase previa a una intrusión: escaneo masivo, huella de servicios, enumeración de subdominios, tunelización de tráfico y ejecución de comandos a demanda desde un operador remoto.

La diferencia con los botnets tradicionales es crucial. Mientras que los viejos árboles de bots terminaban alimentando campañas de DDoS o minería, AryStinger construye una malla de nodos que ocultan el origen del atacante y hacen el trabajo sucio de la exploración: cada router o NAS infectado actúa como un nodo de footprinting y un relay para el tráfico, permitiendo dividir barridos en tareas paralelas y encubrir la procedencia de sondas y conexiones.

Las víctimas principales son equipos antiguos basados en el chipset Realtek RTL819X (modelos fabricados alrededor de 2012–2015) y ciertos dispositivos D‑Link y Linksys, explotando vulnerabilidades ya conocidas como CVE-2013-3307 y CVE-2016-5681. Ese patrón —aprovechar fallos n‑day en firmware nunca actualizado— es la receta para convertir hardware en desuso en infraestructura opaca y duradera; una unidad concreta, el modelo DIR‑850L de D‑Link, supone una porción desproporcionada de la piscina infectada reportada por XLab.

Los investigadores reportan al menos 4.300 routers comprometidos y un sesgo geográfico claro hacia Corea del Sur y China, y detectaron además una segunda cepa que afectó a cajas QNAP mediante CVE-2025-11837, una inyección de código contra la herramienta de eliminación de malware de QNAP. La táctica es especialmente inquietante: la propia utilidad pensada para limpiar equipos se convierte en vector de entrada cuando contiene una vulnerabilidad y el fabricante ya parcheó el fallo meses antes de que fuese explotado en la naturaleza.

Técnicamente, AryStinger adopta un enfoque pragmático: el binario para routers está escrito en C, muy ligero para caber en hardware limitado, y se centra en escaneos DNS y tunelización; el build para NAS, escrito en Go, incorpora herramientas de reconocimiento como fscan, ksubdomain y httpx, y añade una funcionalidad llamada “ScriptWork” que permite ejecutar código Go, Java o Python suministrado por el atacante sin necesidad de compilar por objetivo. La comunicación con el C2 usa HTTP/HTTPS con tráfico codificado por Protobuf y ofuscado mediante XOR —suficiente para evadir controles triviales— y en algunos casos gzip. La persistencia se refuerza con un servidor Dropbear escuchando en un puerto fijo (2332) y una clave SSH codificada (sh_#@!_2024_secret), un indicio de antigüedad operativa que sugiere actividad previa a 2026.

Este patrón no es nuevo en forma, sí en escala y en objetivos. Operaciones anteriores con servicios de proxy residenciales (como la desarticulación de 5socks y Anyproxy por parte de autoridades) o las denominadas Operational Relay Boxes (ORB) documentadas por equipos de respuesta han mostrado cómo redes de dispositivos domésticos sirven a actores que necesitan furtividad y capacidad de reconocimiento sin atar sus herramientas a servidores fácilmente señalables.

Las implicaciones para empresas y usuarios son múltiples. Para un atacante, disponer de miles de relays repartidos por países distintos reduce enormemente la capacidad de rastrear y atribuir actividad, y acelera el reconocimiento a escala con bajo coste de infraestructura. Para defensores y equipos de respuesta, estos nodos significan falsos positivos y ruido, necesitan correlación de telemetría más fina y bloqueo a nivel de red para mitigar escapes y túneles. Además, la misma capacidad de escaneo puede redirigirse para generar tráfico hacia resolutores y forzar degradación o estados tipo DoS dirigidos.

Si administras o dependes de hardware doméstico, las verificaciones prácticas son sencillas pero obligatorias: audita el tráfico saliente desde la LAN en busca de conexiones a dominios y C2 conocidos (los IOCs iniciales citados por XLab incluyen dominios de descarga como ajb8.com), inspecciona /tmp/bin en dispositivos en busca de ejecutables no autorizados, y vigila procesos inusuales con nombres como syswapd0h o syswapd0w. Para confirmar muestras y reputación, herramientas como VirusTotal pueden ayudar, pero no sustituyen un análisis de red y de integridad local.

La solución definitiva, sin embargo, es política y de gestión de activos: retirar equipos que llevan años sin parches, reemplazarlos por modelos con soporte, o aislarlos en segmentos de red con reglas estrictas de egress. Desactivar administración remota expuesta, cambiar credenciales por defecto, desactivar UPnP cuando no sea necesario y limitar el acceso SSH son medidas que reducen la superficie de ataque mientras se planifica la sustitución. En entornos corporativos y de proveedores de servicios, conviene instrumentar detección para escaneos DNS masivos y patrones de tunelización, y preparar listas de bloqueo para dominios e IPs asociados a campañas activas.

Este incidente es un recordatorio de que la seguridad no es solo parches: es gestión de ciclo de vida. Un equipo que dejó de recibir actualizaciones en 2016 no va a volverse seguro por arte de magia. Convertir un router doméstico en parte de una red de espionaje demuestra que la amenaza mira hacia los dispositivos más humildes y permanentes de nuestras infraestructuras. La respuesta debe combinar detección más fina, políticas de reemplazo y, sobre todo, conciencia sobre que el hardware olvidado puede ser la primera trinchera de la siguiente intrusión.