Tu SD-WAN no se cae: te lo reconfiguran

Alguien estuvo meses dentro del orquestador SD-WAN de una empresa y no rompió nada. Entró por una conexión de peering que nadie revisaba, escaló a root, se descargó las plantillas de configuración de toda la red usando la API del propio producto y, antes de salir, restauró uno por uno los ficheros de sistema que había tocado. Ni un enlace caído, ni un fichero cifrado, ni una llamada al soporte. Lo cuenta el informe forense que publicó el equipo de inteligencia de amenazas de Google sobre una intrusión real en un Cisco Catalyst SD-WAN Manager, y explica bastante mejor que cualquier CVSS por qué el plano de gestión de una red SD-WAN es el objetivo del año.

Desplegamos SD-WAN multi-sede y somos operador con red propia, así que este tema nos toca de lleno. Hace un tiempo escribimos sobre cuándo compensa poner SD-WAN y cuándo sobra, que es la conversación de antes de firmar. Esta es la otra mitad: la del día después. Y la pregunta que nos interesa hoy no es si tu orquestador está parcheado —eso ya lo sabes o lo averiguas en diez minutos—, sino qué rastro dejaría alguien que entrase en él. Aviso: menos del que crees.

Nueve entradas, un solo sitio

El catálogo KEV de CISA no es una lista de vulnerabilidades graves. Es la lista de las que alguien está usando de verdad, con explotación confirmada, y por eso lleva fecha límite. Descargamos el catálogo publicado el 29 de julio y lo contamos: 172 entradas añadidas en 2026. Nueve apuntan al plano de gestión o de control de una red SD-WAN —el Manager y el Controller, que es donde se escribe la configuración de todas las sedes—. Ocho de Cisco y una de Arista.

Antes de que alguien saque la conclusión fácil: nueve sobre 172 no demuestra que el software de SD-WAN sea peor que el resto, demuestra que es donde hay gente mirando con ganas. Cisco es el segundo fabricante del catálogo en 2026 con trece entradas, por detrás de Microsoft con treinta y dos, y ocho de esas trece son SD-WAN. Eso no es mala suerte repartida: es esfuerzo concentrado en un objetivo concreto, por quien lo ataca y por quien lo audita.

Hay un detalle del catálogo que dice más que cualquier CVSS. Las entradas del KEV llevan plazo de corrección, y en 2026 se reparten así: sesenta y cinco de tres días, sesenta de catorce días, cuarenta y cuatro de tres semanas, una de cinco días… y dos de cuarenta y ocho horas. Esas dos son las dos de SD-WAN del 25 de febrero. No hay ninguna más en todo el año. Ese mismo día CISA emitió una directiva de emergencia —la ED 26-03, «Mitigate Vulnerabilities in Cisco SD-WAN Systems»— con fecha límite el 27, y una guía suplementaria de búsqueda de compromiso y bastionado solo para esa familia de producto. Es la tercera directiva de emergencia de ese ciclo y va dirigida a un producto concreto, no a una categoría.

La última de las nueve, la de Arista del 27 de julio, ya la desmenuzamos aquí cuando salió el aviso —versiones afectadas, mitigación y qué registros preservar—, así que no la repetimos. Lo que aquella semana se leyó como un caso aislado se lee distinto puesto en fila con las ocho anteriores. Y para entender qué significa realmente que alguien entre ahí, el mejor documento no es un aviso de fabricante: es un informe forense.

El atacante que no rompió nada

En junio, el equipo de inteligencia de amenazas de Google publicó el análisis de una intrusión real en un Catalyst SD-WAN Manager. Merece la pena leer la secuencia entera, porque no se parece a lo que la mayoría imagina cuando dice «nos han atacado la red».

• Finales de 2025 y enero de 2026: aparecen conexiones de peering no autorizadas en los equipos de la víctima. Nadie las mira.
• Marzo de 2026: el atacante levanta un peer nuevo y entra por SSH con la cuenta vmanage-admin. Cambia la contraseña de la cuenta admin para trabajar y, antes de cerrar sesión, la deja como estaba.
• El 7 de marzo, lo importante: se descarga la topología y las plantillas de configuración de la red por la propia API del producto —/dataservice/system/device/vedges, /controllers, las plantillas asignadas y en ejecución de cada equipo—. Las peticiones están registradas en el mismo minuto.
• Abril de 2026: explota CVE-2026-20245 subiendo un CSV preparado como si fuera una lista de tenants. El fichero añade a /etc/passwd un usuario troot con UID 0.
• Y limpia. Guardó copias de /etc/passwd, /etc/shadow y del fichero de lista de tenants originales para restaurarlos después, y ejecutó un script que comprobaba uno por uno que no quedaba ninguno de sus ficheros.

Léelo otra vez y quédate con lo que no pasa en esa lista. No hay ransomware, no hay caída, no hay extorsión, no hay usuarios llamando al soporte. Hay alguien con permisos de root leyendo cómo está construida tu red y con capacidad de escribir en ella, comportándose como el administrador más ordenado que has tenido nunca. Y la herramienta que usó para llevarse la configuración no es un exploit: es la API del producto. Es la misma llamada que hace tu equipo cuando saca un inventario.

Por qué tu monitorización se lo pierde

Piensa en lo que mide tu panel de WAN ahora mismo: túnel arriba o abajo, latencia, pérdida, jitter, cumplimiento del SLA por sede. Durante los meses que duró esa intrusión, todo eso estuvo en verde. Tenía que estarlo: el atacante necesitaba la red funcionando tanto como la víctima.

Es la vieja imagen de la aguja de cambio: nadie descarrila el tren y nadie levanta la vía. Alguien mueve una palanca, el tren sigue circulando a su hora y con el mismo ruido, y llega a otro sitio. Un cambio de configuración empujado desde el orquestador es la operación normal del sistema. No hay anomalía que detectar en el plano de datos. La anomalía está en quién pidió el cambio, y esa pregunta no la responde ningún ping.

La señal está en tres sitios que casi nadie vigila. El primero, el diff de configuración contra una fuente de verdad que no viva dentro del propio orquestador —nosotros usamos NetBox como IPAM y DCIM precisamente para eso—, porque si el atacante restaura sus ficheros originales, el «estado actual» del sistema deja de ser fuente fiable de nada. El segundo, el inventario de peers y controladores: un peer nuevo debería generar un evento con nombre y apellidos, no una línea de log que nadie lee. Ahí empezó todo, meses antes del root. Y el tercero, el camino real del tráfico y no el estado del enlace: con NetFlow se ve si el tráfico de una sede ha empezado a salir por otro sitio; con un test de disponibilidad, no. Es la misma idea que defendíamos hablando de la fatiga de alertas: el problema casi nunca es que falten alertas, es que las que hay no significan nada.

Antes de seguir, una aclaración, porque es fácil leer todo esto como «Cisco escribe mal el código». No va de eso. Un fallo de path traversal se corrige y ya está; lo que no se corrige con un parche es que la configuración de tus cuarenta sedes viva en un solo sitio y se escriba desde un solo sitio. Cambia el fabricante y cambia el número de versión: no cambia el ejercicio que hay que hacer.

Lo que preguntamos antes de la próxima ventana de cambios

Son las preguntas que hacemos cuando nos sentamos delante de una red multi-sede ajena. Ninguna se responde con un «sí» a la primera, y esa es exactamente la utilidad que tienen.

• ¿Está el plano de gestión en internet? En febrero, Censys contó unas 600 instancias de SD-WAN Manager accesibles desde internet, y cerca de una cuarta parte con el 22 o el 830 abiertos, que es por donde se llega al SSH y al NETCONF que el salto de autenticación acaba entregando. Si tu orquestador tiene interfaz pública «porque los técnicos entran desde casa», la decisión ya está tomada; solo falta que la escriba alguien.
• ¿Tienes una vía a cada sede que no pase por el orquestador? Si el orquestador cae —o lo apagas tú a propósito, que es lo que toca ante un compromiso—, los equipos siguen reenviando con la última configuración que recibieron, pero tú te quedas sin volante. 4G de gestión, consola, la línea del operador: algo que no dependa de la pieza que estás investigando.
• ¿Dónde vive la configuración buena? Exportada, versionada y guardada donde el orquestador no pueda escribir. Si el atacante restaura los ficheros originales, comparar el sistema consigo mismo no sirve de nada.
• ¿Quién puede empujar configuración, con qué aprobación y con qué registro? Sin una ventana de cambios escrita, no hay forma de distinguir el cambio del atacante del cambio del martes. Y sí, esto es aburrido, y sí, es lo primero que se cae cuando hay prisa.
• Si hubo compromiso, parchear no es limpiar. El orquestador guarda las credenciales y los certificados que autentican a cada equipo del fabric: hay que rotarlos, no solo actualizar el binario. Es la misma lección que ya escribimos sobre el symlink de FortiOS, y se sigue aprendiendo tarde.

Lo que no vamos a decirte

No vamos a decirte que quites el SD-WAN. Sería fácil rematar así un artículo con nueve CVE, y sería una tontería. Lo que sí decimos es dónde lo tienes colocado mentalmente. Casi todo el mundo trata el orquestador como una herramienta de operaciones: la instala el integrador, la usan tres personas y vive en la carpeta de «infraestructura de red». Es un sistema con privilegio de administrador sobre toda tu red, y merece la misma paranoia que el controlador de dominio: acceso restringido, registro que se mira, credenciales que se rotan y un procedimiento escrito para cuando falle. El día que cambie de categoría, la mitad de estas preguntas se responden solas.

Tampoco vamos a decirte cuántos orquestadores de VeloCloud On-Prem hay expuestos ahora mismo en España. No lo hemos medido y no nos lo vamos a inventar. Lo que sí nos encontramos cuando entramos en una red ajena es una regla de firewall «temporal» que lleva tres años ahí y un acceso de mantenimiento del integrador que nadie ha revisado desde la puesta en marcha. Si alguna de las dos te ha sonado familiar, ya tienes por dónde empezar el lunes.

Diseñamos y operamos redes SD-WAN multi-sede con la monitorización y el control de cambios delante, no detrás, y lo hacemos desde la posición de un operador con red propia: BGP, tránsito, NetFlow y un looking glass público. No somos resellers de ninguna plataforma, así que la respuesta a «¿qué orquestador pongo?» depende de tu caso y no de nuestra comisión.

La pregunta con la que cerramos no es si tu SD-WAN está parcheado. Es esta: si mañana un cambio perfectamente legítimo, firmado por tu propio orquestador, mandara el tráfico de una sede por donde no toca, ¿cuánto tardarías en enterarte y por qué vía? Si la respuesta es «lo veríamos», enséñanos la pantalla donde se ve.

Fuentes (verificadas): los recuentos —172 entradas añadidas en 2026, nueve de ellas del plano de gestión de una red SD-WAN, trece de Cisco frente a treinta y dos de Microsoft, y solo dos entradas de todo el año con plazo de 48 horas— son cálculo propio sobre el fichero del catálogo KEV de CISA, versión 2026.07.29, descargado el 1 de agosto de 2026; las descripciones de cada CVE y las fechas de alta y de plazo salen de ese mismo fichero. La directiva de emergencia ED 26-03 y su dirección suplementaria de hunt y bastionado están publicadas por CISA y referenciadas desde las propias entradas del catálogo. La secuencia de la intrusión (peerings no autorizados desde finales de 2025, SSH con vmanage-admin, el CSV de tenants preparado, el usuario troot, la exfiltración vía /dataservice/ y las técnicas antiforenses) procede del análisis «Zero-Day Exploitation of CVE-2026-20245 in Cisco Catalyst SD-WAN Manager» de Google Cloud Threat Intelligence (Mandiant). El CVSS 10.0 de CVE-2026-16812 procede del aviso de seguridad 0144 de Arista y de su cobertura en BleepingComputer. El recuento de instancias expuestas es del aviso de Censys de febrero de 2026 y es una medición de terceros, con la imprecisión propia de un escaneo. Son criterio y opinión nuestros, no de las fuentes: la lectura de que el orquestador es el objetivo por diseño y no por mala programación, los tres sitios donde está la señal, las cinco preguntas y todo lo que no diríamos.