El malware KeyDrift convierte los controladores Cisco SD-WAN en recolectores de claves de cifrado

Los atacantes han aprovechado una vulnerabilidad de severidad máxima en Cisco Catalyst SD-WAN para instalar un implante diseñado a medida en los sistemas que orquestan la red de área amplia de una organización. El malware, identificado como KeyDrift, no roba documentos ni credenciales. Roba las claves criptográficas que cifran el tráfico entre sedes y las guarda para más adelante.

Qué ocurrió

La puerta de entrada es CVE-2026-20127, una omisión de autenticación en el plano de control de Catalyst SD-WAN con puntuación CVSS 10.0. Un atacante remoto no autenticado puede saltarse el inicio de sesión y obtener privilegios administrativos en el Controller (antes vSmart), el Manager (antes vManage) y el Validator (antes vBond). En un Controller, el atacante aterriza en una cuenta interna de alto privilegio que no es root, pero que tiene permisos de sobra para instalar software.

Cisco publicó correcciones en febrero de 2026 y amplió el aviso para incluir el Validator el 16 de junio. El fabricante reconoce una explotación limitada en entornos reales. Las intrusiones de KeyDrift documentadas ahora se describen como históricas, y el análisis público no precisa cuándo ocurrieron ni si alguna clave recolectada llegó a salir de las redes afectadas.

Cómo funciona KeyDrift

En un despliegue de Catalyst SD-WAN, cada router de borde genera periódicamente una clave AES para su propio tráfico y la envía al Controller, que la distribuye al resto de routers. El proceso que gestiona estas sesiones de control cifradas se llama vdaemon. KeyDrift vive dentro de él.

El implante tiene dos piezas principales:

• PolyFlame, el módulo central, se inyecta en cada proceso vdaemon en ejecución y funciona por completo en memoria. Puede actuar como un shell de comandos ligero que ejecuta órdenes y lee o escribe archivos, o como un relé que reenvía las órdenes del operador a otras máquinas. Recibe instrucciones dentro del tráfico de control SD-WAN habitual, y las muestras analizadas no contenían ningún servidor de mando fijado en el código, lo que dificulta la detección a nivel de red.
• LittleFilch se engancha a vdaemon en un Controller comprometido y lee los mensajes de control una vez descifrados. Para una lista predefinida de routers de borde, extrae la dirección IP de cada uno y un valor de 32 bytes que se evalúa como el material de clave AES-256 que el Controller distribuye. Cifra lo recolectado con RSA, lo escribe en disco y puede enviarlo por UDP a una dirección leída de un archivo de configuración, que borra en cuanto lo ha leído.

La persistencia se consigue manipulando los scripts de servicio runit que los equipos usan para arrancar sus demonios. En una variante, el script que lanza el servicio SSH ejecuta primero un cargador llamado conf_sshd, que registra los ID de proceso de vdaemon y se los pasa a un inyector, rsshd, que carga PolyFlame en cada proceso. En un Validator comprometido, un servicio falso llamado aaamgr ejecuta un cargador empaquetado que descifra y arranca PolyFlame. El componente aaamgr real es un paquete de Python y nunca se ejecuta como servicio compilado, así que la mera presencia de ese directorio es un indicador contundente. Los operadores también copiaron las marcas de tiempo y los permisos de archivos legítimos sobre los suyos para pasar desapercibidos.

Quién está detrás

La actividad se rastrea como UAT-11473. Entre sus objetivos conocidos figuran servicios espaciales y satelitales, tecnología de defensa y aeroespacial, y organizaciones de investigación en políticas públicas. Su infraestructura se solapa de forma considerable con Silent Train, una red de dispositivos comprometidos de pequeñas oficinas, oficinas domésticas e IoT que el grupo Volt Typhoon, vinculado a China, ha utilizado para ocultar sus operaciones. Las agencias estadounidenses atribuyeron públicamente Volt Typhoon al Estado chino en 2024.

Ese vínculo merece una advertencia. Se apoya en infraestructura compartida, no en herramientas compartidas, y nadie ha afirmado que UAT-11473 y Volt Typhoon sean el mismo grupo. También es distinto de un clúster de explotación anterior, UAT-8616, relacionado con esta vulnerabilidad desde al menos 2023. Además, se informa de que el propio Volt Typhoon ya explotaba CVE-2026-20127 a finales de 2025 y siguió haciéndolo tras la divulgación de febrero, aunque esa actividad no se ha relacionado con KeyDrift.

Por qué importa

Los controladores SD-WAN son el ancla de confianza de todo el overlay. Quien posea las claves que distribuyen puede descifrar y, potencialmente, reproducir o manipular el tráfico entre cada sucursal, centro de datos y punto de acceso a la nube de la red. Como las claves se recolectan de mensajes de control ya descifrados en memoria, no hay ruido de exploit en el cable una vez instalado el implante. Y como KeyDrift guarda las claves "para después", un compromiso descubierto hoy puede haber expuesto tráfico capturado hace meses.

La vulnerabilidad afecta a más que los equipos locales. Los despliegues SD-WAN alojados por Cisco en la nube, incluidos los entornos Managed y FedRAMP, están dentro del alcance, aunque Cisco ya ha aplicado restricciones de acceso allí.

Qué hacer

1. Actualice a una versión corregida. No existe solución alternativa.

Las ramas 20.11, 20.13, 20.14 y 20.16, y cualquier versión anterior a 20.9, han llegado al fin del mantenimiento de software, por lo que hace falta saltar de rama.

2. Restrinja los puertos 22 y 830 en los componentes de control a las direcciones IP de los controladores y sistemas de gestión conocidos hasta que pueda actualizar. Cisco validó esta medida en laboratorio; pruébela en su propia red. Recuerde que bloquear puertos no hace nada contra un implante ya instalado.

3. Busque KeyDrift. No se han publicado hashes, IP ni dominios, así que la búsqueda se basa en archivos y comportamiento:

• el script run de runit bajo /etc/sv/sshd/ modificado para invocar conf_sshd;
• un directorio /etc/sv/aaamgr/ y un binario aaamgrd en un Validator;
• conf_sshd, rsshd, libdssl.so (PolyFlame) y libcommon.so (LittleFilch);
• /tmp/system-vdaemon, /var/tmp/vdaemon.bin y /var/tmp/vdaemon.conf.

Desconfíe de las marcas de tiempo de estos artefactos, ya que el grupo acostumbra a falsificarlas.

4. Compruebe la explotación de la propia vulnerabilidad. Revise /var/log/auth.log en busca de entradas "Accepted publickey for vmanage-admin" desde IP de origen inesperadas. Ejecute request admin-tech en cada componente de control y vuelva a analizar la salida con la función Check Bug Applicability para el bug CSCws52722 antes de abrir un caso de soporte.

5. Active la cobertura IDS. Las reglas Snort 2 de la 67387 a la 67416 y las reglas Snort 3 de la 7:44 a la 7:73 detectan las conexiones de mando y control de KeyDrift; las reglas 65938 y 65958 cubren la vulnerabilidad. Las nuevas reglas de Snort 2 vienen desactivadas por defecto, así que actívelas.

6. Planifique la expulsión, no solo el parche. La guía de remediación de Cisco advierte de que las explotaciones ya presentes pueden sobrevivir a una actualización. Si encuentra algún indicador, inicie la respuesta a incidentes, siga la guía de endurecimiento de Catalyst SD-WAN y considere seriamente el enfoque que CISA impuso a las agencias federales estadounidenses en febrero: redespliegue Manager, Controller y Validator desde imágenes limpias y parcheadas, y migre los routers de borde a las nuevas instancias. Rotar las claves entre sedes es la suposición prudente, ya que la única finalidad del implante es conservar copias de ellas.

Vulnerabilidades como esta suelen vivir en equipos que nadie escanea porque son "equipos de red", no servidores. Nuestro servicio de escaneo de vulnerabilidades inventaría las interfaces de gestión expuestas por sus planos de control SD-WAN, VPN y cortafuegos, y señala las versiones sin parchear y los puertos de gestión accesibles antes de que un atacante con un exploit funcional los encuentre primero.