Red de bots PolarEdge
Investigadores de seguridad han descifrado recientemente la mecánica de una familia de botnets centrada en routers, denominada PolarEdge. Su combinación de comunicación basada en TLS, trucos de configuración integrados y medidas deliberadas antianálisis la convierten en una amenaza considerable para dispositivos de redes domésticas y de pymes.
Tabla de contenido
Cronología y descubrimiento
Los investigadores documentaron por primera vez PolarEdge en febrero de 2025, vinculándolo con campañas dirigidas a routers y dispositivos NAS de múltiples proveedores. Para agosto de 2025, los analistas habían mapeado gran parte de la infraestructura de la botnet y observado características consistentes con una red de tipo Caja de Retransmisión Operacional (ORB). La telemetría retrospectiva sugiere que parte de la actividad de PolarEdge podría remontarse a junio de 2023.
Objetivos y acceso inicial
Se han identificado como objetivos dispositivos de importantes proveedores, incluidos Cisco, ASUS, QNAP y Synology, lo que destaca que tanto los enrutadores de nivel empresarial como los de nivel de consumidor y los sistemas NAS corren riesgo de explotación.
En las cadenas de ataque de febrero de 2025, los actores de amenazas explotaron una vulnerabilidad conocida de Cisco (CVE-2023-20118) para obtener un pequeño script de shell distribuido por FTP llamado "q". La función de este script era recuperar y ejecutar la puerta trasera ELF de PolarEdge en el host comprometido.
Diseño de implantes centrales
PolarEdge es un implante ELF con capacidad TLS que principalmente:
- Envía una huella digital de host a un servidor de comando y control (C2) y luego
- Espera comandos a través de un servidor TLS integrado implementado mediante mbedTLS v2.8.0.
El comportamiento predeterminado del implante es actuar como servidor TLS mediante un protocolo binario personalizado. Un campo clave del protocolo es HasCommand: cuando este campo equivale al carácter ASCII 1, el implante lee el campo Comando, ejecuta el comando especificado localmente y devuelve la salida del comando sin procesar al C2.
Modos de operación
PolarEdge admite dos modos adicionales:
Modo de conexión posterior : el implante se comporta como un cliente TLS para extraer archivos de servidores remotos.
Modo de depuración : un modo interactivo que permite a los operadores modificar los parámetros de configuración (por ejemplo, direcciones de servidor) sobre la marcha.
Configuración integrada y ofuscación
La botnet almacena su configuración de ejecución en los últimos 512 bytes de la imagen ELF. Este bloque está ofuscado con una clave XOR de un solo byte; los investigadores informan que la clave XOR es 0x11, la cual debe aplicarse para recuperar la configuración.
Operaciones de archivos
Tras la ejecución, el implante realiza movimientos y eliminaciones del sistema de archivos (por ejemplo, mover archivos binarios como /usr/bin/wget y /sbin/curl, y eliminar archivos como /share/CACHEDEV1_DATA/.qpkg/CMS-WS/cgi-bin/library.cgi.bak). La intención operativa precisa de estas acciones no se comprende completamente a partir de los datos disponibles.
Técnicas de evasión y antianálisis
PolarEdge incorpora una gama de sofisticados mecanismos defensivos diseñados para evadir la detección e impedir el análisis, lo que hace más difícil para los investigadores de seguridad y las herramientas automatizadas identificar su comportamiento y diseccionar su funcionamiento interno.
Oculta detalles de las rutinas de inicialización y toma de huellas dactilares de su servidor TLS mediante ofuscación.
Durante el inicio, realiza un enmascaramiento de procesos, eligiendo aleatoriamente un nombre de proceso de una lista incorporada para combinarse con servicios legítimos del sistema.
Algunos de los posibles nombres incluyen:
- proxy igmp
- wscd
- /sbin/dhcpd
- httpd
- upnpd
- iapp
Resiliencia sin persistencia clásica
PolarEdge no parece instalar un mecanismo de persistencia tradicional que sobreviva a los reinicios. En su lugar, realiza un truco en tiempo de ejecución: se bifurca y el proceso hijo sondea cada 30 segundos para comprobar si el directorio/proc/ del proceso padre aún existe. Si ese directorio desaparece (lo que indica que el proceso padre ha desaparecido), el hijo ejecuta un comando de shell para reiniciar la puerta trasera, lo que proporciona una recuperación oportunista en tiempo de ejecución en lugar de una persistencia permanente durante el arranque.
Takeaways defensivos
Las organizaciones que administran enrutadores y dispositivos NAS deben asegurarse de aplicar las actualizaciones y mitigaciones de los proveedores para CVE-2023-20118 y vulnerabilidades de ejecución remota similares. Deben supervisar activamente la actividad TLS inusual de los dispositivos de red y las conexiones salientes a hosts inesperados. Es igualmente crucial estar atentos a indicios de enmascaramiento de procesos y a cualquier cambio o eliminación no autorizados de binarios de red y scripts web.