Los sistemas de control Cisco Catalyst SD-WAN comprometidos se convirtieron en un punto de recolección de claves de cifrado en ataques que usan malware personalizado llamado KeyDrift, según los hallazgos de Cisco Talos publicados por The Hacker News. Los atacantes obtuvieron acceso mediante CVE-2026-20127, una omisión de autenticación corregida en febrero.
Talos describió los ataques como históricos en su comunicado del 28 de octubre, pero no ofreció fechas de incidentes. Sus hallazgos documentan malware diseñado para recopilar y transmitir material de claves sospechoso. No establecen que las claves llegaran a los atacantes ni que el tráfico de red fuera descifrado.
Recolección de claves dentro del proceso de control
KeyDrift coloca su componente LittleFilch dentro de vdaemon, el proceso del Controller responsable de las conexiones de control cifradas. Desde allí, LittleFilch examina los mensajes después del descifrado y selecciona direcciones IP y un campo de 32 bytes para un conjunto predefinido de routers de borde. Talos evalúa que ese campo contiene material de claves AES-256 distribuido a través del Controller.
El punto de recolección corresponde a la arquitectura tradicional de intercambio de claves de Cisco. La documentación técnica de Cisco describe routers que generan una clave AES para cada ubicación de transporte, o TLOC, y la envían en paquetes de rutas del Overlay Management Protocol (OMP). El Controller redistribuye esa información en anuncios de alcance para que los routers puedan establecer rutas de datos cifradas. Las claves AES se regeneran cada 24 horas por defecto, y las políticas de control pueden limitar qué routers reciben las claves de los demás.
Esa arquitectura difiere de la opción de claves por pares de Cisco. Con claves por pares, el Controller distribuye valores públicos de Diffie-Hellman, mientras que los routers de borde derivan sus claves IPsec mediante ECDH y una curva P-384. El comportamiento reportado de LittleFilch se refiere al material de claves transportado por el intercambio tradicional. No demuestra la recolección de claves derivadas de pares.
LittleFilch protege sus registros recopilados con cifrado RSA antes de guardarlos en /var/tmp/vdaemon.bin. Una capacidad separada envía los registros por UDP a un destino especificado en /var/tmp/vdaemon.conf. El malware borra ese archivo de configuración después de leerlo, y Talos no pudo recuperarlo. Si la transmisión llegó a producirse sigue sin resolverse.
Cómo operan los implantes
El análisis de Talos, según lo reportado por The Hacker News, describe scripts de inicio de servicios alterados como el principal mecanismo de lanzamiento de KeyDrift. Una variante modifica el script de ejecución bajo etc/sv/sshd/ para que conf_sshd se ejecute antes del servidor SSH genuino. Ese cargador escribe los IDs de proceso de vdaemon en /tmp/system-vdaemon. Después, un inyector llamado rsshd coloca PolyFlame, el módulo principal de KeyDrift, en esos procesos.
PolyFlame opera en memoria. Su backdoor de tipo TinyShell admite ejecución de comandos y lectura y escritura de archivos, mientras que un modo de retransmisión pasa comandos entre un servidor de comandos y otras máquinas. Los comandos pueden llegar dentro del tráfico de control de SD-WAN. En las muestras analizadas no apareció ninguna dirección de servidor codificada.
Un implante Validator sigue un camino diferente. Un servicio fabricado en /etc/sv/aaamgr/ inicia el cargador empaquetado aaamgrd, que descifra y ejecuta PolyFlame. La distinción importa para la detección: el componente real aaamgr de Cisco es un paquete de Python y normalmente no funciona como servicio compilado. Los nombres de módulo reportados son libdssl.so para PolyFlame y libcommon.so para LittleFilch.
Talos también observó comandos que transfieren las marcas de tiempo y los permisos de archivos existentes a archivos creados por los atacantes, lo que indica manipulación de marcas de tiempo (timestomping) destinada a alterar su historial aparente.
La falla de acceso y las correcciones disponibles
El aviso de Cisco identifica una autenticación de peering defectuosa como la vulnerabilidad subyacente. Solicitudes manipuladas de un atacante remoto no autenticado pueden producir privilegios administrativos. En un Controller, la cuenta interna resultante tiene privilegios muy altos, pero no es root. Permite el acceso NETCONF y cambios en la configuración de la red SD-WAN.
Los productos afectados son Catalyst SD-WAN Controller, Manager y Validator, anteriormente conocidos como vSmart, vManage y vBond, independientemente de la configuración. El alcance del despliegue abarca instalaciones locales y Cisco Hosted SD-WAN Cloud, incluidos los entornos Cisco Managed y FedRAMP. Cisco reconoce una explotación limitada y recomienda actualizar, porque ninguna medida alternativa resuelve la falla.
Sus correcciones específicas por versión son:
| Línea de versiones de Catalyst SD-WAN | Primera versión corregida o migración requerida |
|---|---|
| Anteriores a 20.9 | Migrar a una versión corregida |
| 20.9 | 20.9.8.2 |
| 20.11 | 20.12.6.1 |
| 20.12 | 20.12.5.3 o 20.12.6.1 |
| 20.13 | 20.15.4.2 |
| 20.14 | 20.15.4.2 |
| 20.15 | 20.15.4.2 |
| 20.16 | 20.18.2.1 |
| 20.18 | 20.18.2.1 |
Cisco indica que las versiones anteriores a 20.9 y las líneas 20.11, 20.13, 20.14 y 20.16 han llegado al fin del mantenimiento de software, y recomienda a los clientes elegir una versión compatible.
Para los clientes locales que esperan una actualización, Cisco recomienda restringir los puertos 22 y 830 a los controladores conocidos y a otros sistemas especificados que necesitan acceso. Esta mitigación funcionó en un entorno de prueba. Los clientes deben evaluar su eficacia y sus posibles efectos sobre la funcionalidad o el rendimiento de la red en sus propios despliegues. Cisco afirma que estas barreras de acceso ya existen en los entornos alojados enumerados. Esa afirmación establece la presencia de restricciones, no el estado de parcheado de cada instancia alojada.
La detección también debe abordar el compromiso existente
Cisco recomienda revisar /var/log/auth.log en busca de entradas Accepted publickey for vmanage-admin asociadas con direcciones IP desconocidas o no autorizadas, y comparar luego esas direcciones con las System IP configuradas en Manager. También exige validar manualmente los eventos de peering de conexiones de control, especialmente los pares vmanage, usando los roles de dispositivo, las direcciones, la actividad de mantenimiento y los registros de autenticación esperados.
Antes de abrir un caso en el Technical Assistance Center, los clientes deben ejecutar request admin-tech en cada componente de control. The Hacker News también informa que la guía de remediación de Cisco recomienda volver a analizar esos archivos mediante Check Bug Applicability en la página Bug Search Tool para CSCws52722.
Para la detección en red, la actualización de Talos del 28 de octubre introdujo las reglas Snort 2 de la 67387 a la 67416 y las reglas Snort 3 de la 7:44 a la 7:73 para conexiones entrantes de comando y control de KeyDrift. Las reglas Snort 2 están deshabilitadas por defecto y requieren activación por parte de los usuarios de conjuntos de reglas Snort Subscriber de pago. La actualización no especifica un estado predeterminado para las reglas Snort 3. Las reglas 65938 y 65958 cubren la explotación de CVE-2026-20127 en sí.
Talos recomienda aplicar las correcciones, la guía de endurecimiento de Cisco y la respuesta a incidentes cuando aparezcan señales posteriores a un compromiso. Las restricciones de puertos no eliminan el malware ya instalado. Según cita The Hacker News, la guía de remediación de Cisco de febrero advierte que una explotación establecida antes de una actualización puede persistir después de ella.
Para las agencias civiles del Poder Ejecutivo federal de EE. UU. (FCEB), la ED 26-03 de CISA, emitida el 25 de febrero y actualizada el 11 de marzo, exige informar de inmediato cuando se identifique un compromiso de la cuenta root. Las agencias deben reconstruir el plano de gestión de control con instancias nuevas de Manager, Controller y Validator, a partir de imágenes OVA o qcow2 parcheadas, y migrar a ellas los dispositivos de borde.
El solapamiento de infraestructura limita la atribución
Talos atribuye la actividad de KeyDrift a UAT-11473, un operador que apunta a servicios espaciales y satelitales, tecnología de defensa y aeroespacial, e investigación de políticas públicas. Según The Hacker News, Talos evalúa con alta confianza que su infraestructura se solapa sustancialmente con Silent Train, el nombre que Lumen Black Lotus Labs da a una red de dispositivos comprometidos de pequeñas oficinas y oficinas domésticas (SOHO), IoT y empresas.
Lumen afirma que Volt Typhoon usó esa red para ocultar actividad. CISA, la NSA y el FBI identificaron a Volt Typhoon como patrocinado por el Estado chino en 2024. La conexión de infraestructura no equivale a que Talos identifique a UAT-11473 como Volt Typhoon, y Talos no ha explicado su relación con UAT-8616, el clúster de explotación descrito en febrero como originado al menos en 2023.
Por separado, The Hacker News informa que Lumen dijo el 28 de octubre que Volt Typhoon explotó CVE-2026-20127 a finales de 2025 y continuó después de la divulgación de febrero. Lumen no atribuyó KeyDrift a esa actividad.
