KeyDrift: el malware que roba claves en Cisco SD-WAN

Hay incidentes que pasan de largo porque no salen en portada, pero que tocan exactamente la fibra de la que cuelga la red de una empresa. Es lo que ha ocurrido con un fallo crítico en Cisco Catalyst SD-WAN: según ha detallado Cisco Talos, se aprovechó para introducir en los sistemas que gobiernan la red SD-WAN de una organización un malware hecho a medida, bautizado como KeyDrift. El fallo estaba corregido desde febrero, pero eso no impidió que alguien lo usara antes de que la actualización llegara a todos los equipos afectados.

La parte que más debería inquietar a cualquier responsable de IT es qué hace exactamente ese programa. No se limita a abrir una puerta ni a dejar un acceso remoto: su objetivo es copiar las claves que cifran el tráfico entre sedes y almacenarlas para usarlas más adelante. Dicho de otro modo, el atacante no solo entra, sino que se lleva la llave maestra con la que se protege la comunicación interna de la compañía.

Por qué el robo de claves es peor que el acceso inicial

Cuando se habla de una brecha, la conversación suele centrarse en el primer acceso: cómo entraron, qué servidor quedó expuesto, cuánto tardaron en detectarlo. El caso de KeyDrift desplaza el foco a una fase posterior y bastante más incómoda. Si un atacante tiene las claves de cifrado del tráfico entre sedes, puede leer comunicaciones que se suponían protegidas o preparar un movimiento lateral sin necesidad de romper nada en tiempo real. La confianza depositada en la VPN o en el enlace cifrado deja de ser un escudo y pasa a ser un activo en manos ajenas.

En una pyme con varias oficinas, un almacén o una plantilla en remoto, el SD-WAN es a menudo la columna vertebral que une todo. Por eso un incidente así no se queda en el departamento de redes: afecta a cómo se autentican los usuarios, a qué datos cruzan entre ubicaciones y a la tranquilidad con la que se puede afirmar que la información está a salvo.

El detalle que no debe pasarse por alto

Talos califica estos ataques como históricos, pero no concreta cuándo se produjeron. Esa falta de fecha exacta no resta gravedad al hallazgo; más bien al contrario. Obliga a las organizaciones a revisar hacia atrás, no solo hacia delante. Si el parche llegó en febrero y el malware estuvo plantado en los sistemas de control, cualquier empresa que gestionara su SD-WAN con versiones sin actualizar durante ese periodo debería preguntarse qué pasó por su red.

La lección se parece a la que ya vimos con el aluvión de parches de Oracle: tener el boletín de seguridad no equivale a tener el sistema protegido. Entre la publicación del aviso y la aplicación efectiva del parche hay una ventana que los atacantes conocen perfectamente y explotan sin prisa.

Qué recomendamos desde ForgeNEX

No hace falta montar un centro de operaciones de la noche a la mañana para reducir este riesgo. Lo que sí conviene es ordenar unas cuantas prioridades y tratarlas como rutina, no como excepción:

• Revisa el inventario de Cisco SD-WAN. Identifica qué versiones de Catalyst SD-WAN hay en producción y confirma que ninguna sigue por debajo del parche de febrero. Si hay equipos sin actualizar, esa es la primera tarea del día.
• Rota las claves de cifrado entre sedes. Si existe la mínima sospecha de que el entorno de control pudo estar expuesto, cambiar las claves y revisar los certificados de los túneles es una medida proporcionada y rápida.
• Vigila el plano de gestión, no solo el de datos. Los sistemas que orquestan la red son un objetivo de alto valor. Revisa accesos, registros y cuentas con privilegios sobre ellos.
• Comprueba la telemetría de los últimos meses. Aunque el ataque sea histórico, los registros pueden seguir ahí. Buscar conexiones anómalas hacia los controladores SD-WAN ayuda a confirmar o descartar exposición.
• Integra la gestión de parches en el SOC. Herramientas como las que comentamos en Wazuh e IA para afinar un SOC permiten detectar equipos desactualizados sin ampliar plantilla ni presupuesto.

El factor humano del parche

Hay una tentación recurrente en las pymes: pensar que un fabricante como Cisco ya lo tiene todo resuelto y que el aviso llegará solo. La realidad es que el aviso llega, pero la decisión de aplicarlo depende de alguien concreto. Si ese alguien está desbordado, la ventana se alarga. Por eso conviene asignar un responsable claro de actualizaciones de red y fijar una cadencia de revisión, aunque sea mensual.

También merece la pena revisar cómo se compran y despliegan estas soluciones. La propia Cisco ha estado moviendo ficha para agilizar las compras del segmento SMB, como contamos en la alianza con Ingram Micro. Esa facilidad para adquirir tecnología debería ir acompañada de la misma facilidad para mantenerla al día; si no, el coste de la comodidad se paga en forma de incidente.

Una señal de hacia dónde va el ataque

KeyDrift no es solo una anécdota sobre un fabricante concreto. Es una muestra de que los atacantes cada vez apuntan más a la infraestructura que garantiza la confianza: claves, certificados, túneles. Robar esas piezas permite operar con calma y sin ruido, justo lo que menos interesa a una empresa que necesita saber, sin dudas, que sus sedes hablan entre sí de forma segura.

La recomendación final es sencilla de enunciar y algo más trabajosa de ejecutar: trata el SD-WAN como lo que es, un sistema crítico, y no como un simple router grande. Parchear, rotar claves y mirar los registros con regularidad cuesta menos que descubrir, meses después, que alguien estuvo leyendo el tráfico entre tus oficinas.

Fuente: The Hacker News. Análisis y adaptación: ForgeNEX.