Una vulnerabilidad de Cisco SD-WAN ante malware permitió instalar un malware que roba claves de cifrado

La vulnerabilidad de Cisco SD-WAN ante malware permitió colar un programa capaz de copiar claves de cifrado y ya estaba corregida cuando Cisco Talos publicó su análisis, el 28 de octubre de 2026 [1]. Aun así, el caso deja abierta una pregunta que ninguna actualización responde: qué pasó con esas claves mientras el controlador de la red estuvo en manos del atacante.

Ese es el centro de esta historia. El objetivo no era solo entrar en el sistema que gobierna la red entre sedes, sino llevarse lo que protege el tráfico que circula por ella. Por eso el parche cierra la puerta, pero no aclara lo ocurrido antes.

Talos sitúa la entrada en un fallo de autenticación del controlador SD-WAN

SD-WAN significa red de área extensa definida por software. En la solución Catalyst de Cisco, ese punto central lo forman varios componentes de control. Según Cisco Talos, un actor que denomina UAT-11473 y que describe como una amenaza persistente avanzada (APT) muy sofisticada explotó CVE-2026-20127, un fallo de omisión de autenticación en instancias del Catalyst Controller, para saltarse el control de acceso y entrar sin autorización en los sistemas afectados [1].

The Hacker News, que recoge el análisis de Talos, aporta más contexto sobre la gravedad del fallo. Según thehackernews.com, según este medio, CVE-2026-20127 tiene una puntuación CVSS de 10,0 y permite a un atacante remoto sin credenciales obtener privilegios administrativos en esos sistemas de control [2]. El mismo medio indica que Cisco lo corrigió en febrero, que afecta al Controller, al Manager y al Validator con independencia de su configuración, tanto en instalaciones propias como en los despliegues alojados en la nube de Cisco, y que el fabricante reconoce una explotación limitada sin ofrecer una solución alternativa al parche [2].

Hasta aquí, el relato coincide con el de muchos boletines: un fallo grave y una actualización disponible. Lo distintivo está en lo que el atacante instaló después.

KeyDrift está diseñado para recolectar claves

Talos describe KeyDrift como un marco de malware hecho a medida y compuesto por varias piezas. Unas se dedican a recolectar material de claves sensible, otras funcionan como puerta trasera y otras actúan como servidores intermedios de mando y control (C2) [1]. El laboratorio considera, con alta confianza, que el conjunto busca mantener un acceso persistente a largo plazo y sacar de forma automatizada ese material de claves [1].

Para entender por qué importa, conviene saber cómo circulan las claves en esta arquitectura. The Hacker News explica que, en el esquema tradicional de Cisco, cada router de la SD-WAN genera periódicamente una clave para cifrar su tráfico y se la envía al Controller, que la reparte entre los demás routers [2]. Según el mismo medio, un componente de KeyDrift llamado LittleFilch se engancha al proceso que gestiona esas conexiones de control y lee los mensajes una vez descifrados; de una lista prefijada de routers extrae sus direcciones y un campo que Talos identifica como el material de claves AES que el controlador distribuye [2].

El módulo principal, PolyFlame, reside en memoria dentro de ese proceso legítimo, puede ejecutar órdenes y leer o escribir archivos, y está construido para recibir instrucciones camufladas en el propio tráfico de control, de modo que las muestras analizadas no contenían ninguna dirección de servidor fija, según recoge The Hacker News [2]. Talos añade que las variaciones observadas en los módulos apuntan a que el marco sigue en desarrollo activo [1].

La diferencia con un ataque de ransomware es de fondo. La interrupción del servicio y la posible extracción de claves plantean problemas distintos. Las fuentes no describen qué síntomas permitirían detectar la copia de una clave. Según The Hacker News, KeyDrift está diseñado para copiar las claves que cifran el tráfico entre sedes y guardarlas para un uso posterior.

Lo que las fuentes no aclaran: cuándo ocurrió y si salieron claves

Talos califica la actividad de histórica, y The Hacker News subraya que el laboratorio no precisa cuándo se produjo ni si llegaron a enviarse claves [2]. El mismo medio detalla que LittleFilch cifra lo recogido, lo guarda en un archivo y puede remitirlo a una dirección que figura en un fichero de configuración que se borra tras leerse; Talos no pudo recuperar ese fichero [2]. Con lo publicado, no hay datos sobre el alcance real de la exfiltración.

Conviene además no mezclar cronologías. Según thehackernews.com, según The Hacker News, cuando Cisco publicó el fallo en febrero, Talos atribuyó su explotación a otro grupo de actividad, UAT-8616, que se remontaba al menos a 2023 [2]. El medio precisa que Talos no explica qué relación guarda ese grupo con UAT-11473 [2], así que no hay base para unir ambos episodios en una sola historia.

Algo parecido ocurre con la atribución. Talos sostiene, con alta confianza, que la infraestructura de UAT-11473 se solapa en buena medida con la red de acceso encubierto asociada a Volt Typhoon [1], pero The Hacker News aclara que el laboratorio no afirma que se trate del mismo grupo [2].

Los objetivos observados por Talos fueron servicios espaciales y de satélites, tecnología de defensa y aeroespacial, e investigación de políticas públicas [1]. Talos enumera servicios espaciales y de satélites, tecnología de defensa y aeroespacial e investigación de políticas públicas, sin precisar si las entidades afectadas incluían empresas industriales. Que no estén documentados no significa que el riesgo no exista para ellas, pero sí obliga a no exagerar.

El controlador SD-WAN concentra la confianza entre sedes y plantas

Lo que sigue es una lectura del equipo de Hodeitek, no un hecho de las fuentes. El análisis de este caso se centra en el compromiso del plano de control de Cisco SD-WAN. En el intercambio tradicional de claves de Cisco SD-WAN, el Controller distribuye entre los routers las claves que recibe, como describe The Hacker News [2]. El posible impacto del compromiso del controlador debe evaluarse teniendo en cuenta su participación en el reparto de claves.

Para una pyme industrial con varias plantas, esto tiene una consecuencia práctica. Conviene incluir la protección de las claves en la evaluación de seguridad del cifrado entre sedes. Si se sospecha una exposición de claves, conviene evaluar con el fabricante qué tráfico podría estar afectado, incluido el de producción cuando comparta infraestructura.

De ahí que convenga tratar el plano de control de la red como un activo crítico, al nivel de un controlador industrial: inventario, accesos administrativos restringidos, registros guardados fuera del propio equipo y una revisión de qué tráfico industrial circula realmente por la SD-WAN. Conviene revisar la segmentación entre TI y OT como parte de la seguridad OT industrial.

CISA ha tratado la exposición de los sistemas Cisco SD-WAN como asunto de emergencia

La agencia estadounidense de ciberseguridad, CISA, publicó el 25 de febrero de 2026 la directiva de emergencia ED 26-03, titulada «Mitigate Vulnerabilities in Cisco SD-WAN Systems», actualizada el 11 de marzo de 2026 [3]. Se trata de un instrumento que la sección 3553(h) del título 44 del Código de los Estados Unidos reserva para amenazas que suponen un riesgo sustancial para la seguridad de la información de las agencias federales [3].

En la directiva, CISA afirma ser consciente de una explotación continuada de estos sistemas y menciona CVE-2026-20127 junto con CVE-2022-20775, un fallo de recorrido de rutas que permite escalar privilegios [3]. La norma obliga a las agencias civiles federales y no se aplica a contratistas [3], pero su sola existencia indica cómo valoró CISA la exposición.

No es un caso aislado. El patrón se repite: el equipo que conecta la red es también el más apetecible para quien quiere quedarse dentro.

Parchear cierra la puerta, pero no dice quién entró antes

Como el fallo se corrigió en febrero y Talos describe la actividad como histórica, la pregunta útil para una empresa ya no es solo si ha actualizado, sino qué pasó antes de hacerlo. The Hacker News señala que las recomendaciones de Talos no aclaran si actualizar elimina KeyDrift de un equipo ya comprometido ni si deben sustituirse las claves, y que la guía de remediación de Cisco de febrero advierte de que pueden seguir activos accesos obtenidos antes de la actualización [2]. El mismo medio recuerda que bloquear el acceso a determinados puertos no elimina un malware ya instalado [2].

Como orientación, y siempre a confirmar con el fabricante, una revisión razonable incluye estos puntos:

• Comprobar que el Controller, el Manager y el Validator están en una versión corregida según el aviso de Cisco [2].
• Buscar accesos administrativos desde direcciones desconocidas; The Hacker News recoge que Cisco indica revisar el registro de autenticación en busca de accesos con la cuenta interna vmanage-admin desde direcciones IP no reconocidas [2].
• Ante cualquier indicio, abrir un proceso de respuesta a incidentes; Talos sugiere apoyarse en el centro de asistencia técnica de Cisco (TAC) [2].
• Decidir con Cisco si procede rotar claves o reconstruir el plano de control. Para las agencias federales con una cuenta root comprometida, CISA exige desplegar instancias nuevas desde imágenes parcheadas y migrar a ellas los routers [3].

La idea que conviene retener es sencilla: cuando el fallo afecta al sistema que gestiona el cifrado entre sedes, actualizar es necesario pero no suficiente. Hay que comprobar si el controlador estuvo comprometido y qué claves pudieron quedar expuestas. Conviene valorar registros centralizados y vigilancia continua para apoyar esa comprobación, y evaluar si un SOC gestionado y detección y respuesta (MDR) se ajusta a las necesidades del equipo y de su estrategia de seguridad OT.