Ilustración abstracta de pintura fluida en tonos violeta, magenta y negro para la noticia: KeyDrift roba las claves del SD-WAN de Cisco desde dentro del controlador

Malware

KeyDrift roba las claves de Cisco SD-WAN desde dentro del controlador

Cisco Talos describe KeyDrift, el framework que UAT-11473 inyecta en vdaemon tras explotar CVE-2026-20127 para extraer las claves IPsec de la SD-WAN.

El script que arranca el servicio SSH de un controlador Cisco Catalyst SD-WAN comprometido sigue haciendo su trabajo, pero antes de lanzar sshd vuelve a montar el sistema de ficheros como ejecutable y deja corriendo en segundo plano un programa llamado conf_sshd. Así empieza KeyDrift, el framework que Cisco Talos describió el 28 de octubre de 2026 y que el grupo UAT-11473 instaló tras explotar CVE-2026-20127 para leer, desde dentro del proceso vdaemon, las claves con las que la red SD-WAN cifra su plano de datos.

  • Talos publicó el 28 de octubre de 2026 el análisis de KeyDrift, un framework con dos módulos que se inyectan en vdaemon para dar acceso remoto y extraer las claves IPsec del plano de datos.
  • La entrada es CVE-2026-20127, un bypass de autenticación de peering con CVSS 10,0 en el Controller, el Manager y el Validator, en KEV desde el 25 de febrero y con parches en 20.9.8.2, 20.12.5.3, 20.12.6.1, 20.15.4.2 y 20.18.2.1.
  • Las víctimas descritas son de los sectores espacial, de satélite, defensa, aeroespacial e investigación de políticas, y Talos ve un solapamiento de infraestructura con Silent Train, la red que Lumen atribuye a Volt Typhoon.
  • No hay hashes ni direcciones IP: la detección pasa por los ficheros de runit, /var/tmp/vdaemon.bin, el authorized_keys de vmanage-admin, los eventos de peering y las reglas Snort nuevas.
  • Un controlador parcheado no está limpio hasta que se auditan los peers y las claves SSH, y si hay artefactos hay que abrir caso con el TAC y renovar las claves de los vEdges afectados.

Dos líneas añadidas al runit de sshd y un inyector llamado rsshd

Los controladores de Cisco Catalyst SD-WAN (el Controller, antes vSmart, el Manager, antes vManage, y el Validator, antes vBond) gestionan sus servicios con runit, y ahí es donde KeyDrift se ancla. Según el informe de Talos, el atacante modifica el script de arranque del servicio sshd para añadir dos líneas antes de la ejecución legítima: una vuelve a montar /rootfs.rw con permiso de ejecución y la otra lanza en segundo plano el script conf_sshd. Después arranca el sshd de siempre, de modo que el servicio responde con normalidad.

Script runit de sshd de un controlador Cisco SD-WAN con las dos líneas añadidas por KeyDrift que remontan rootfs.rw y lanzan conf_sshd
Fuente: Cisco Talos, «Inside KeyDrift: Analyzing historical UAT-11473 activity on Cisco SD-WAN»

La figura de Talos muestra el lanzador de sshd con las dos líneas intrusas resaltadas en rojo. conf_sshd enumera los procesos vdaemon en ejecución, anota sus PID en /tmp/system-vdaemon y llama a un inyector, rsshd, que carga la biblioteca libdssl.so en cada uno de esos procesos mediante ptrace. Esa biblioteca es PolyFlame, el módulo principal del framework.

Talos ha recuperado además una segunda vía de despliegue en un Validator afectado. En ella el atacante crea un servicio runit propio bajo /etc/sv/aaamgr/ con un binario llamado aaamgrd. El aaamgr legítimo de Cisco es un paquete de Python y nunca aparece como un ELF compilado, así que el nombre busca pasar por un componente del sistema. El binario es un ELF64 enlazado estáticamente, sin cabeceras de sección, con un único segmento de carga con permisos de lectura, escritura y ejecución y un payload ELF embebido cifrado con RC4. Antes de descifrarlo comprueba el campo TracerPid de /proc/%d/status y sale si hay un depurador enganchado. El lanzador de este servicio borra también las configuraciones PAM de sshd y login de la capa de escritura.

Secuencia de comandos con la que KeyDrift despliega el loader aaamgrd como servicio runit y copia fechas con touch --reference
Fuente: Cisco Talos, «Inside KeyDrift: Analyzing historical UAT-11473 activity on Cisco SD-WAN»

La secuencia de preparación que publica Talos termina con varios touch y chmod con la opción --reference, que copian las fechas y permisos de los ficheros originales de Cisco a los ficheros del atacante. Es timestomping clásico, pensado para que un listado por fecha de modificación no delate los binarios nuevos.

PolyFlame y LittleFilch, los dos módulos que viven dentro de vdaemon

PolyFlame no es un backdoor que llame a casa cada pocos minutos. Una vez inyectado en vdaemon, el demonio que mantiene las sesiones DTLS del plano de control, intercepta las funciones recvfrom, sendto, getpeername, dlopen, dlsym y mprotect, y analiza /proc/%d/maps para orientarse en la memoria del proceso. Desde ahí ve todo el estado interno: claves de sesión DTLS, topología de vEdges, rutas OMP y tablas de políticas. Talos no ha encontrado en las muestras ninguna dirección IP, puerto, dominio ni intervalo de sondeo escritos en el código, porque el tasking llega dentro del propio tráfico de control de la SD-WAN.

El gancho sobre recvfrom primero ejecuta la función original para conocer la dirección del C2 y después aplica una comprobación de tiempo: el C2 envía el MD5 de una fecha concreta y el implante calcula el MD5 de la fecha local del equipo en formato año-mes-día. Si no coinciden, no hace nada. Si coinciden, lee un código administrativo. El código 1 devuelve bytes aleatorios a modo de latido, el 2 fija el tipo de implante (backdoor o C2 intermedio) y el 3 prepara el manejador de comandos del C2 intermedio.

Como backdoor, PolyFlame copia las capacidades de TinyShell con códigos de comando distintos: 0x100 ejecuta una orden con /bin/sh -c, 0x200 escribe un fichero en disco y 0x300 lee un fichero y lo envía al C2. No ofrece shell interactiva. Como C2 intermedio funciona como un multiplexor de uno a muchos: se conecta a un solo C2 y atiende a varios peers, con códigos para abrir una conexión a una IP (0x403), reenviar datos a un peer (0x404), eliminarlo de la lista (0x405), devolver la respuesta al C2 (0x407) y fijar un valor en memoria (0x408). Un controlador comprometido puede así servir de relé para otros controladores de la misma red o de otras víctimas.

LittleFilch, el segundo módulo, es la pieza que da nombre al framework. Se carga como libcommon.so e instala un gancho sobre SSL_read dentro de vdaemon. Cada vez que el demonio descifra un mensaje del plano de control, el módulo inspecciona el buffer, extrae la IP pública de transporte y la system-IP del peer, y busca para una lista predefinida de nodos de borde un campo de 32 bytes que Talos valora como material de clave AES-256 distribuido por OMP para el plano de datos IPsec.

Formato de registro de LittleFilch con fecha, IP pública, system-IP y bytes de clave en hexadecimal de cada nodo Cisco SD-WAN
Fuente: Cisco Talos, «Inside KeyDrift: Analyzing historical UAT-11473 activity on Cisco SD-WAN»

El formato del registro que Talos reconstruye es una línea por nodo con fecha, IP pública, system-IP y los bytes de la clave en hexadecimal. LittleFilch cifra cada registro con RSA y lo escribe en /var/tmp/vdaemon.bin, desde donde puede enviarlo por UDP imitando un registro de datos de aplicación de DTLS 1.2, el mismo aspecto que tiene el tráfico legítimo entre controladores. Los extremos local y remoto los lee de /var/tmp/vdaemon.conf, un fichero que borra nada más leerlo y que Talos no ha conseguido recuperar. Quien tenga esas claves puede descifrar el tráfico entre sedes sin tocar un solo router de borde, y esa es la razón por la que el fabricante no da por limpio un controlador parcheado sin una revisión posterior.

CVE-2026-20127, el fallo de peering explotado desde 2023

La puerta de entrada no es nueva. Cisco publicó el aviso cisco-sa-sdwan-rpa-EHchtZk el 25 de febrero de 2026 y lo ha revisado cuatro veces desde entonces. La versión 2.0, del 16 de junio, añadió el Validator a la lista de productos afectados, y la 2.1, del 28 de octubre, incorpora el enlace al análisis de KeyDrift. La frase sobre explotación no ha cambiado: «The Cisco PSIRT is aware of limited exploitation of this vulnerability» (el PSIRT de Cisco tiene constancia de una explotación limitada de esta vulnerabilidad). El fabricante agradece el informe al Australian Cyber Security Centre, dependiente del Australian Signals Directorate.

Dato

Valor

CVE

CVE-2026-20127

CVSS y vector

10,0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H), misma puntuación en Cisco y en NVD

Tipo de fallo

CWE-287, autenticación incorrecta en el peering del plano de control

Producto

Cisco Catalyst SD-WAN Controller (vSmart), Manager (vManage) y Validator (vBond), on-prem y en la nube alojada por Cisco

Versiones afectadas

Anteriores a 20.9.8.2, de 20.11 a 20.12.5.2, 20.12.6, de 20.13 a 20.15.4.1 y de 20.16 a 20.18.2.0

Versiones corregidas

20.9.8.2, 20.12.5.3, 20.12.6.1, 20.15.4.2 y 20.18.2.1 (antes de 20.9, migrar)

Explotación activa

Sí. En KEV desde el 25 de febrero de 2026 con plazo el 27 de febrero; Cisco reconoce explotación limitada

Gravedad

Crítica

El fallo está en la autenticación de peering del plano de control, que vdaemon atiende por DTLS y TLS en el puerto 12346. Según el análisis de Rapid7, publicado el 16 de junio de 2026 y firmado por Jonah Burgess, el despachador de mensajes tenía una lista de excepciones que permitía a un peer sin autenticar enviar un mensaje CHALLENGE_ACK_ACK, y el manejador de ese mensaje se fiaba de un byte de estado para marcar la sesión como autenticada sin comprobar ninguna firma. A continuación un mensaje VMANAGE_TO_PEER añade una clave pública SSH al fichero authorized_keys de la cuenta vmanage-admin, y el atacante entra por SSH al servicio NETCONF del puerto 830 con permiso para reconfigurar toda la fabric. El parche elimina la excepción del despachador. Rapid7 probó la explotación contra la versión 20.12.5 y confirmó la corrección en 20.12.6.1.

Prueba de concepto de Rapid7 para CVE-2026-20127 con la clave SSH inyectada y la sesión NETCONF abierta en Cisco SD-WAN Manager
Fuente: Rapid7, «Rapid7 Analysis: CVE-2026-20127»

La captura del laboratorio de Rapid7 recoge el final de la prueba de concepto, con la clave SSH inyectada y la sesión NETCONF abierta contra un Manager en la versión 20.15.3. Los pasos siguientes que Talos documentó en febrero en su primer informe sobre UAT-8616 consistían en degradar el software del controlador a una versión vulnerable a CVE-2022-20775, un path traversal de la CLI que da root, y restaurar después la versión original para borrar el rastro. Talos escribió entonces que la actividad maliciosa se remontaba al menos a 2023.

La cronología del fallo explica por qué ocho meses después sigue dando noticias.

Fecha

Hecho

2023

Primeras intrusiones que Talos atribuye a UAT-8616 en controladores Cisco SD-WAN, según su informe del 25 de febrero de 2026

Diciembre de 2025

Inicio de la explotación de CVE-2026-20127 como zero-day por Volt Typhoon, según la cronología de Black Lotus Labs

25 de febrero de 2026

Cisco publica el aviso y Talos el informe sobre UAT-8616; CISA añade CVE-2026-20127 y CVE-2022-20775 a KEV y emite la directiva ED 26-03; INCIBE-CERT publica su aviso

27 de febrero de 2026

Plazo de corrección de KEV y de la directiva de CISA para las agencias federales

14 de mayo de 2026

Talos informa de que UAT-8616 pasa a explotar CVE-2026-20182 y de otros grupos que atacan el Manager desde marzo

16 de junio de 2026

Cisco añade el Validator al aviso (versión 2.0) y Rapid7 publica el análisis de la causa raíz

28 de octubre de 2026

Talos publica el análisis de KeyDrift y UAT-11473, Lumen el informe de Silent Train y Cisco la versión 2.1 del aviso

CISA incluyó CVE-2026-20127 y CVE-2022-20775 en su catálogo KEV el mismo 25 de febrero, con plazo de corrección el 27, y publicó la directiva de emergencia ED 26-03, que obligaba a las agencias federales a inventariar y recoger snapshots y logs antes de las 23:59 del 26 de febrero y a parchear antes de las 17:00 del 27, hora del este. Madhu Gottumukkala, director en funciones de CISA, lo resumió así: «We urge all entities to implement the measures outlined in this Emergency Directive without delay» (instamos a todas las entidades a aplicar sin demora las medidas de esta directiva de emergencia). Desde febrero, el catálogo ha sumado nueve entradas de Cisco SD-WAN en 2026, la última el 30 de septiembre. En España, INCIBE-CERT publicó su aviso sobre el fallo el 25 de febrero con importancia crítica y lo actualizó el 16 de junio.

Satélites, defensa y think tanks, con Silent Train de Volt Typhoon al fondo

Talos describe las víctimas de UAT-11473 por sectores, sin nombres: «Observed targeting spans across space and satellite services, defense and aerospace technology, and policy research» (los objetivos observados abarcan servicios espaciales y de satélite, tecnología de defensa y aeroespacial, e investigación de políticas públicas). El informe no da fechas de las intrusiones analizadas ni número de organizaciones afectadas, y tampoco publica hashes ni direcciones IP, porque las muestras de PolyFlame no las contienen.

Lo que sí afirma, con confianza alta, es que la infraestructura operativa de UAT-11473 se solapa de forma considerable con Silent Train, la red de acceso encubierto que Black Lotus Labs, el equipo de investigación de Lumen, atribuye a Volt Typhoon. Talos mantiene su propio nombre para el cluster y no afirma que sean el mismo grupo. El informe de Black Lotus Labs, firmado por Michael Horka y publicado también el 28 de octubre, es el que da contexto a esa frase.

Esquema de los saltos de Silent Train desde los operadores de Volt Typhoon por dos VPS y dos routers SOHO hasta la víctima en EE. UU.
Fuente: Black Lotus Labs (Lumen), «Silent Train: uncovering Volt Typhoon's operational framework for zero-day exploitation and strategic access»

Black Lotus Labs dice haber seguido Silent Train durante tres años y haber enviado cientos de notificaciones a víctimas. Cada sesión empezaba en un VPS fuera de Estados Unidos, saltaba por dispositivos comprometidos en otros países y terminaba pivotando por equipos dentro del país hasta llegar al objetivo, como resume el esquema del informe. Los operadores montaban la cadena en menos de dos minutos, trabajaban de lunes a viernes entre las 09:00 y las 22:00 hora de China y desmontaban todo al salir. Las sesiones duraban unas cuatro horas de media. Los módems Intelbras solo aparecían como relés en el extranjero y los Netgear Orbi como saltos dentro de Estados Unidos, entre más de 27 clases de dispositivo que incluyen routers TP-Link, equipos Zyxel y Cambium, appliances Fortinet y servidores CyberPanel.

Cronología de Black Lotus Labs con las cinco campañas de zero-day de Volt Typhoon por Silent Train, de Quest KACE a VeloCloud Orchestrator
Fuente: Black Lotus Labs (Lumen), «Silent Train: uncovering Volt Typhoon's operational framework for zero-day exploitation and strategic access»

La cronología de Lumen sitúa cuatro campañas de zero-day confirmadas a través de Silent Train: Versa Director (CVE-2024-39717, entre junio y agosto de 2024), N-able N-central (CVE-2025-8875 y CVE-2025-8876, de agosto de 2024 a julio de 2025), Cisco Catalyst SD-WAN (CVE-2026-20127, de diciembre de 2025 a febrero de 2026) y VeloCloud Orchestrator (CVE-2026-16812, entre junio y julio de 2026), más una quinta probable contra Quest KACE con más de 30 víctimas. Sobre el fallo de Cisco escribe: «By late 2025, Volt Typhoon was exploiting Cisco Catalyst SD-WAN through CVE-2026-20127» (a finales de 2025, Volt Typhoon ya explotaba Cisco Catalyst SD-WAN mediante CVE-2026-20127), y añade que la explotación continuó bastante después de la divulgación de febrero. Ese dato enlaza con la explotación activa de VeloCloud Orchestrator que contamos el 23 de octubre: la primera de las tres vulnerabilidades de ese orquestador aparece ahora en la lista de Lumen con nombre de actor.

Las víctimas que Lumen describe son estadounidenses: Administración federal, operadores de telecomunicaciones, contratistas de defensa, universidades con programas ROTC, proveedores de comunicaciones por satélite y de emergencia, MSP y empresas de TI, concentradas en Hawái, California y Texas. Ninguna de las dos firmas menciona víctimas en Europa. El producto, en cambio, sí está en Europa: Cisco Catalyst SD-WAN es una de las plataformas habituales para unir sedes en empresas y operadores españoles, y el plano de control que KeyDrift intercepta es el mismo en cualquier despliegue. Cuando escribimos esta noticia no existe un recuento público de exposición en España. Censys contó alrededor de 600 instancias de SD-WAN Manager expuestas a internet en todo el planeta en su aviso del 27 de febrero, la mayoría en Estados Unidos, y casi una cuarta parte con el puerto 22 o el 830 también expuestos.

Rutas, reglas Snort y comandos para buscar KeyDrift en un controlador

Sin hashes ni IP, la detección descansa en los artefactos de disco y en las reglas de red. Talos tiene desde febrero las reglas Snort 65938 y 65958 para la explotación de CVE-2026-20127 y ha publicado el 28 de octubre las SID 67387 a 67416 de Snort 2 y 7:44 a 7:73 de Snort 3 para los artefactos de KeyDrift. Talos, Cisco y Rapid7 recogen estos indicadores.

Tipo

Valor

Contexto

ruta de archivo

/etc/sv/sshd/run

Lanzador runit de sshd modificado con el remontaje de /rootfs.rw y la llamada a conf_sshd

ruta de archivo

/rootfs.rw/etc/sv/sshd/conf_sshd

Script que enumera los procesos vdaemon y lanza la inyección

ruta de archivo

/tmp/system-vdaemon

Lista de PID de vdaemon que escribe conf_sshd antes de inyectar

ruta de archivo

rsshd

Inyector que carga libdssl.so en vdaemon mediante ptrace

ruta de archivo

libdssl.so

PolyFlame, módulo residente en memoria con backdoor y C2 intermedio

ruta de archivo

libcommon.so

LittleFilch, gancho sobre SSL_read que extrae el material de claves

ruta de archivo

/etc/sv/aaamgr/aaamgrd

Loader empaquetado de PolyFlame que se hace pasar por el servicio aaamgr

ruta de archivo

/var/tmp/vdaemon.bin

Registros de claves cifrados con RSA a la espera de exfiltración

ruta de archivo

/var/tmp/vdaemon.conf

Extremos UDP local y remoto de LittleFilch; se borra tras leerse

ruta de archivo

/home/vmanage-admin/.ssh/authorized_keys

Clave SSH añadida por la explotación de CVE-2026-20127

Estas comprobaciones, ejecutadas con la shell del controlador, cubren los artefactos de la tabla y la clave SSH que deja la explotación.

grep -n "conf_sshd\|rootfs.rw" /etc/sv/sshd/run
ls -la /etc/sv/aaamgr/ /tmp/system-vdaemon /var/tmp/vdaemon.bin /var/tmp/vdaemon.conf 2>/dev/null
find / -xdev \( -name libdssl.so -o -name libcommon.so -o -name rsshd -o -name aaamgrd \) 2>/dev/null
cat /home/vmanage-admin/.ssh/authorized_keys
grep "Accepted publickey for vmanage-admin" /var/log/auth.log

Cualquier dirección que aparezca en la última línea debe compararse con las System IP configuradas, que el Manager muestra en la columna System IP del menú de dispositivos. Cisco pide además revisar a mano cada evento de peering de los logs, con atención a los de tipo vmanage: una conexión que llega a una hora rara, desde una IP que no es de un controlador conocido o con un tipo de dispositivo que no encaja en la arquitectura es la huella que dejó UAT-8616 en febrero. Rapid7 añade un indicador barato de buscar: eventos Connection UP cuyo peer-system-ip sea :: o 0.0.0.0. Y el informe de febrero de Talos apunta a los logs truncados a cero o dos bytes, a un historial de CLI sin su bash_history correspondiente y al mensaje Software upgrade not confirmed. Reverting to previous software version, que delata la degradación de versión usada para llegar a root.

Buscar un implante que vive en la memoria de un demonio y toma sus órdenes del tráfico legítimo no se parece a buscar un webshell, y exige el threat hunting por comportamiento que ya defendimos en el blog. Es el mismo problema que planteó PEERSTITCH en los FortiGate con FortiManager: el dispositivo de red no lleva EDR y el tráfico de control está cifrado por diseño. Los indicadores de detección de APT que ya repasamos siguen siendo la guía, con un matiz que esta campaña deja claro: el controlador es el que reparte las claves, así que la evidencia hay que buscarla en él y en el comportamiento de los peers, no en las sedes.

Parchear a 20.12.6.1 y auditar los peers antes de dar el controlador por limpio

La tabla de software corregido del aviso de Cisco fija el destino de cada rama.

Rama de Cisco Catalyst SD-WAN

Primera versión corregida

Anterior a 20.9

Migrar a una rama corregida

20.9

20.9.8.2

20.11 (fuera de mantenimiento)

20.12.6.1

20.12

20.12.5.3 o 20.12.6.1

20.13 y 20.14 (fuera de mantenimiento)

20.15.4.2

20.15

20.15.4.2

20.16 (fuera de mantenimiento)

20.18.2.1

20.18

20.18.2.1

Por orden de urgencia, esto es lo que conviene hacer en una red con Catalyst SD-WAN.

  1. Comprueba la versión del Controller, el Manager y el Validator y actualiza a la primera versión corregida de la tabla. Las ramas 20.11, 20.13, 20.14 y 20.16 están fuera de mantenimiento y deben migrar a una rama soportada. Antes de 20.9 no hay parche.
  2. Si el despliegue es on-prem y no puedes parchear hoy, restringe el acceso a los puertos 22 y 830 de los controladores a las direcciones de los demás controladores y a las IP de administración, con ACL o reglas de firewall, como indica la mitigación del aviso de Cisco. En la nube gestionada por Cisco ese filtro ya existe.
  3. Ejecuta las comprobaciones del bloque anterior en cada controlador y revisa /var/log/auth.log y los eventos de peering desde, como mínimo, diciembre de 2025, la fecha en que Lumen sitúa el inicio de la explotación.
  4. Despliega las reglas Snort 65938, 65958, 67387 a 67416 y 7:44 a 7:73 en los sensores que vean el tráfico del plano de control.
  5. Si encuentras cualquiera de los artefactos, no limpies: lanza request admin-tech en cada componente de control, abre un caso con el TAC de Cisco con ese fichero y trata como comprometidas las claves del plano de datos de los vEdges que aparezcan en los registros. CISA pide en su directiva, cuando hay root, desplegar instancias de gestión nuevas y parcheadas y migrar los equipos de borde a ellas.
  6. Notifica el incidente a INCIBE-CERT si eres empresa y al CCN-CERT si eres organismo público, y prepara la comunicación a los clientes cuyas sedes cuelguen de ese controlador si eres operador o MSP.

Un controlador SD-WAN concentra lo que un atacante necesita para llegar a cientos de sedes sin moverse lateralmente, y por eso Volt Typhoon ha encadenado tres plataformas de ese tipo en dos años. La arquitectura SASE prometía simplificar la red de sedes, y lo hace, pero también convierte al orquestador en el activo que decide la seguridad de todas ellas. Microsoft acaba de atribuir a otro grupo alineado con China un ataque a la cadena de suministro de un MSP con la misma lógica de acceso escalable. Si tu Manager o tu Controller responden en el puerto 12346 desde internet, el inventario de peers y el authorized_keys de vmanage-admin son lo primero que hay que leer esta semana, antes incluso de programar la ventana de actualización.

Temas

No hay comentarios todavía