Hackers explotaron una vulnerabilidad de Cisco SD-WAN para instalar malware destinado a robar claves de cifrado

Atacantes explotaron una vulnerabilidad crítica en Cisco Catalyst SD-WAN, corregida en febrero, para instalar un malware diseñado a medida dentro de los sistemas que gobiernan la red SD-WAN de una organización.

El programa, denominado KeyDrift, tiene como objetivo copiar las claves que cifran el tráfico entre sedes y guardarlas para utilizarlas más adelante, según informó Cisco Talos el 28 de octubre. Talos califica estos ataques como históricos, pero no precisa cuándo ocurrieron ni si alguna clave llegó a ser exfiltrada.

La falla está identificada como CVE-2026-20127 y cuenta con una puntuación CVSS de 10.0. Permite a un atacante remoto no autenticado eludir la autenticación y obtener privilegios administrativos en estos sistemas de control. En un Controlador, el atacante puede iniciar sesión con una cuenta interna de altos privilegios que no es root.

Cuando Cisco reveló la vulnerabilidad en febrero, Talos siguió su explotación bajo la designación UAT-8616, un conglomerado de actividad que, según la compañía, se remonta al menos a 2023.

Cómo funciona el intercambio de claves y el robo

En el intercambio de claves tradicional de Cisco, cada router SD-WAN genera periódicamente una clave AES para su tráfico y la envía al Catalyst SD-WAN Controller (antes vSmart). El Controlador transmite esas claves a los demás routers. Un proceso del Controlador llamado vdaemon gestiona las conexiones de control cifradas que transportan dichas claves.

En un Controlador comprometido, un componente de KeyDrift llamado LittleFilch se engancha a vdaemon y lee los mensajes de control una vez descifrados. Para una lista predefinida de routers de borde, extrae sus direcciones IP y un campo de 32 bytes. Talos evalúa que ese campo corresponde al material de la clave AES-256 que el Controlador intercambia entre routers.

LittleFilch cifra lo que recopila con RSA y lo escribe en un archivo. Después puede enviar esos datos por UDP a una dirección indicada en un archivo de configuración, que elimina tras leerlo. Talos no pudo recuperar ese archivo de configuración.

Vínculos con otros grupos y campañas

El grupo detrás de KeyDrift, que Talos designa como UAT-11473, ha atacado a servicios espaciales y de satélites, a tecnologías de defensa y aeroespaciales y a la investigación de políticas.

La infraestructura del grupo se solapa de forma considerable con Silent Train, según la evaluación de alta confianza de Talos. Silent Train es el nombre que Black Lotus Labs, de Lumen, da a una red de dispositivos comprometidos de pequeña oficina, hogar, IoT y empresas.

Lumen sostiene que Volt Typhoon utilizó esa red para ocultar su actividad. La CISA, la NSA y el FBI afirmaron en 2024 que Volt Typhoon es un grupo cibernético patrocinado por el Estado chino.

Talos relaciona a UAT-11473 con Volt Typhoon únicamente por ese solapamiento de infraestructura. No afirma que ambos sean el mismo grupo ni aclara cómo se relaciona UAT-11473 con UAT-8616, el conglomerado que reportó en febrero.

Por separado, Lumen informó el 28 de octubre de que Volt Typhoon estaba explotando CVE-2026-20127 a finales de 2025 y siguió haciéndolo después de que Cisco divulgara la falla en febrero. Lumen no vincula esa actividad con KeyDrift.

Mecanismos de persistencia: scripts de runit y servicios falsos

Según Talos, KeyDrift se inicia principalmente mediante scripts de runit modificados que los dispositivos Cisco SD-WAN emplean para lanzar sus servicios. En una de las variantes, el script del servicio SSH arranca un script cargador, conf_sshd, antes del servidor SSH real. El script conf_sshd escribe los identificadores de proceso de vdaemon en un archivo, y una herramienta llamada rsshd inyecta el módulo principal de KeyDrift, PolyFlame, en cada uno de esos procesos.

PolyFlame se ejecuta en memoria dentro de vdaemon. Puede actuar como una puerta trasera tipo TinyShell que ejecuta comandos y lee y escribe archivos, o como un repetidor que reenvía comandos entre su servidor de mando y otras máquinas. Está diseñado para aceptar órdenes dentro del tráfico de control SD-WAN, y las muestras analizadas no contenían ninguna dirección de servidor codificada de forma fija.

En un Validador comprometido (antes vBond), un servicio falso llamado aaamgr bajo /etc/sv/aaamgr/ ejecuta un cargador empaquetado, aaamgrd, que descifra y pone en marcha PolyFlame. El componente real aaamgr de Cisco es un paquete de Python y normalmente no se ejecuta como servicio compilado.

También hay indicios de manipulación de marcas de tiempo: los comandos ejecutados por el grupo copiaron las fechas de modificación y los permisos de archivos existentes a sus propios archivos.

Versiones afectadas y correcciones

CVE-2026-20127 afecta al Catalyst SD-WAN Controller (antes vSmart), al Manager (antes vManage) y al Validator (antes vBond), con independencia de su configuración. Están afectados los sistemas locales y las implementaciones en la nube de SD-WAN alojadas por Cisco, incluidos los entornos Cisco Managed y FedRAMP. Cisco añadió el Validator a su aviso el 16 de junio.

Cisco afirma estar al tanto de una explotación limitada de la falla. No existe solución alternativa, y las primeras versiones corregidas son:

  • Las versiones anteriores a la 20.9 y las ramas 20.11, 20.13, 20.14 y 20.16 han alcanzado el fin del mantenimiento de software.

Hasta que puedan actualizar, los clientes con sistemas locales pueden limitar el acceso a los puertos 22 y 830 a las direcciones IP de los controladores conocidos y de otros sistemas de confianza. Cisco señala que esta medida funcionó en un entorno de prueba, pero que los clientes deben comprobar su eficacia en sus propias redes. Esas restricciones ya están aplicadas en las implementaciones en la nube de SD-WAN alojadas por Cisco.

Bloquear los puertos no elimina el malware que ya esté presente en un dispositivo.

Cómo detectar KeyDrift

Talos aconseja a las organizaciones instalar las correcciones de Cisco, seguir la guía de endurecimiento de Catalyst SD-WAN de la compañía y vigilar posibles indicios de actividad posterior al compromiso. Quien detecte esos indicios debe iniciar la respuesta a incidentes y puede solicitar ayuda al Centro de Asistencia Técnica (TAC) de Cisco.

Ese consejo no aclara si la actualización elimina KeyDrift de un dispositivo ya comprometido ni si deben reemplazarse las claves. La guía de remediación de Cisco de febrero para esta falla advierte de que podrían existir exploits previos que sigan activos tras una actualización.

KeyDrift utiliza estos archivos y ubicaciones, algunos indicados solo por su nombre:

  • Archivo: el script de arranque en etc/sv/sshd/, modificado para iniciar conf_sshd
  • Directorio: /etc/sv/aaamgr/, un servicio falso en un Validador comprometido
  • Archivo: aaamgrd, el cargador empaquetado
  • Archivo: conf_sshd, el script cargador
  • Archivo: rsshd, el inyector
  • Archivo: libdssl.so, PolyFlame
  • Archivo: libcommon.so, LittleFilch
  • Archivo: /tmp/system-vdaemon, la lista de identificadores de proceso de vdaemon
  • Archivo: /var/tmp/vdaemon.bin, los registros cifrados de LittleFilch
  • Archivo: /var/tmp/vdaemon.conf, la configuración de envío de LittleFilch, eliminada tras su lectura

El informe de Talos no incluye una lista de hashes de archivos, direcciones IP ni dominios asociados a KeyDrift.

Talos publicó el 28 de octubre reglas Snort que detectan conexiones entrantes de mando y control de KeyDrift: de la 67387 a la 67416 para Snort 2, y de la 7:44 a la 7:73 para Snort 3. Las reglas 65938 y 65958, ya disponibles, cubren la propia CVE-2026-20127.

La actualización de reglas del 28 de octubre indica que las reglas de Snort 2 están desactivadas por defecto, por lo que los usuarios del conjunto de reglas de pago Snort Subscriber deben activarlas. Las reglas de Snort 3 aparecen sin estado predeterminado.

Para comprobar la explotación de la falla en sí, Cisco recomienda buscar en /var/log/auth.log entradas del tipo Accepted publickey for vmanage-admin procedentes de direcciones IP desconocidas. Antes de abrir un caso con el TAC, los clientes deben ejecutar request admin-tech en cada componente de control. La guía de remediación también recomienda volver a analizar esos archivos admin-tech con la función Check Bug Applicability en la página del Bug Search Tool correspondiente al bug CSCws52722.

Para las agencias federales civiles de Estados Unidos, la directiva de emergencia de la CISA del 25 de febrero establece qué hacer si se detecta un compromiso de la cuenta root. Deben notificarlo a la CISA, desplegar instancias nuevas de Manager, Controller y Validator a partir de imágenes corregidas y trasladar sus routers de borde a los nuevos sistemas.

Cybersecurity
Cybersecurity
Cybersecurity
Cybersecurity

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *