El teu SD-WAN no cau: te'l reconfiguren

Algú va estar mesos dins de l'orquestrador SD-WAN d'una empresa i no va trencar res. Va entrar per una connexió de peering que ningú revisava, va escalar a root, es va descarregar les plantilles de configuració de tota la xarxa fent servir l'API del mateix producte i, abans de sortir, va restaurar un per un els fitxers de sistema que havia tocat. Ni un enllaç caigut, ni un fitxer xifrat, ni una trucada al suport. Ho explica l'informe forense que va publicar l'equip d'intel·ligència d'amenaces de Google sobre una intrusió real en un Cisco Catalyst SD-WAN Manager, i explica força millor que qualsevol CVSS per què el pla de gestió d'una xarxa SD-WAN és l'objectiu de l'any.

Despleguem SD-WAN multiseu i som operador amb xarxa pròpia, així que aquest tema ens toca de ple. Fa un temps vam escriure sobre quan compensa posar SD-WAN i quan sobra, que és la conversa d'abans de signar. Aquesta és l'altra meitat: la de l'endemà. I la pregunta que ens interessa avui no és si el teu orquestrador està pedaçat —això ja ho saps o ho esbrines en deu minuts—, sinó quin rastre deixaria algú que hi entrés. Avís: menys del que et penses.

Nou entrades, un sol lloc

El catàleg KEV de la CISA no és una llista de vulnerabilitats greus. És la llista de les que algú està fent servir de debò, amb explotació confirmada, i per això porta data límit. Vam descarregar el catàleg publicat el 29 de juliol i el vam comptar: 172 entrades afegides el 2026. Nou apunten al pla de gestió o de control d'una xarxa SD-WAN —el Manager i el Controller, que és on s'escriu la configuració de totes les seus—. Vuit de Cisco i una d'Arista.

Abans que ningú tregui la conclusió fàcil: nou sobre 172 no demostra que el programari d'SD-WAN sigui pitjor que la resta, demostra que és on hi ha gent mirant amb ganes. Cisco és el segon fabricant del catàleg el 2026 amb tretze entrades, darrere de Microsoft amb trenta-dues, i vuit d'aquestes tretze són SD-WAN. Això no és mala sort repartida: és esforç concentrat en un objectiu concret, per part de qui l'ataca i de qui l'audita.

Hi ha un detall del catàleg que diu més que qualsevol CVSS. Les entrades del KEV porten termini de correcció, i el 2026 es reparteixen així: seixanta-cinc de tres dies, seixanta de catorze dies, quaranta-quatre de tres setmanes, una de cinc dies… i dues de quaranta-vuit hores. Aquestes dues són les dues d'SD-WAN del 25 de febrer. No n'hi ha cap més en tot l'any. Aquell mateix dia la CISA va emetre una directiva d'emergència —l'ED 26-03, «Mitigate Vulnerabilities in Cisco SD-WAN Systems»— amb data límit el 27, i una guia suplementària de cerca de compromís i bastionatge només per a aquesta família de producte. És la tercera directiva d'emergència d'aquell cicle i va dirigida a un producte concret, no a una categoria.

L'última de les nou, la d'Arista del 27 de juliol, ja la vam esmicolar aquí quan va sortir l'avís —versions afectades, mitigació i quins registres preservar—, així que no la repetim. El que aquella setmana es va llegir com un cas aïllat es llegeix diferent posat en fila amb les vuit anteriors. I per entendre què significa realment que algú hi entri, el millor document no és un avís de fabricant: és un informe forense.

L'atacant que no va trencar res

Al juny, l'equip d'intel·ligència d'amenaces de Google va publicar l'anàlisi d'una intrusió real en un Catalyst SD-WAN Manager. Val la pena llegir-ne la seqüència sencera, perquè no s'assembla al que la majoria s'imagina quan diu «ens han atacat la xarxa».

• Finals del 2025 i gener del 2026: apareixen connexions de peering no autoritzades als equips de la víctima. Ningú no les mira.
• Març del 2026: l'atacant aixeca un peer nou i entra per SSH amb el compte vmanage-admin. Canvia la contrasenya del compte admin per treballar i, abans de tancar sessió, la deixa com era.
• El 7 de març, el més important: es descarrega la topologia i les plantilles de configuració de la xarxa per la pròpia API del producte —/dataservice/system/device/vedges, /controllers, les plantilles assignades i en execució de cada equip—. Les peticions estan registrades en el mateix minut.
• Abril del 2026: explota la CVE-2026-20245 pujant un CSV preparat com si fos una llista de tenants. El fitxer afegeix a /etc/passwd un usuari troot amb UID 0.
• I neteja. Va desar còpies de /etc/passwd, /etc/shadow i del fitxer de llista de tenants originals per restaurar-los després, i va executar un script que comprovava un per un que no quedava cap dels seus fitxers.

Llegeix-ho un altre cop i queda't amb el que no passa en aquesta llista. No hi ha ransomware, no hi ha caiguda, no hi ha extorsió, no hi ha usuaris trucant al suport. Hi ha algú amb permisos de root llegint com està construïda la teva xarxa i amb capacitat d'escriure-hi, comportant-se com l'administrador més ordenat que has tingut mai. I l'eina que va fer servir per endur-se la configuració no és un exploit: és l'API del producte. És la mateixa crida que fa el teu equip quan treu un inventari.

Per què al teu monitoratge se li escapa

Pensa en el que mesura el teu panell de WAN ara mateix: túnel amunt o avall, latència, pèrdua, jitter, compliment de l'SLA per seu. Durant els mesos que va durar aquella intrusió, tot això va estar en verd. Havia d'estar-hi: l'atacant necessitava la xarxa funcionant tant com la víctima.

És la vella imatge de l'agulla de canvi: ningú no descarrila el tren i ningú no aixeca la via. Algú mou una palanca, el tren continua circulant a la seva hora i amb el mateix soroll, i arriba a un altre lloc. Un canvi de configuració empès des de l'orquestrador és l'operació normal del sistema. No hi ha anomalia a detectar al pla de dades. L'anomalia és en qui va demanar el canvi, i aquesta pregunta no la respon cap ping.

El senyal és a tres llocs que gairebé ningú vigila. El primer, el diff de configuració contra una font de veritat que no visqui dins del mateix orquestrador —nosaltres fem servir NetBox com a IPAM i DCIM precisament per això—, perquè si l'atacant restaura els seus fitxers originals, l'«estat actual» del sistema deixa de ser font fiable de res. El segon, l'inventari de peers i controladors: un peer nou hauria de generar un esdeveniment amb nom i cognoms, no una línia de log que ningú llegeix. Allà va començar tot, mesos abans del root. I el tercer, el camí real del trànsit i no l'estat de l'enllaç: amb NetFlow es veu si el trànsit d'una seu ha començat a sortir per un altre lloc; amb un test de disponibilitat, no. És la mateixa idea que defensàvem parlant de la fatiga d'alertes: el problema gairebé mai és que faltin alertes, és que les que hi ha no signifiquen res.

Abans de continuar, un aclariment, perquè és fàcil llegir tot això com «Cisco escriu malament el codi». No va d'això. Un error de path traversal es corregeix i prou; el que no es corregeix amb un pedaç és que la configuració de les teves quaranta seus visqui en un sol lloc i s'escrigui des d'un sol lloc. Canvia el fabricant i canvia el número de versió: no canvia l'exercici que cal fer.

El que preguntem abans de la propera finestra de canvis

Són les preguntes que fem quan ens asseiem davant d'una xarxa multiseu aliena. Cap no es respon amb un «sí» a la primera, i aquesta és exactament la utilitat que tenen.

• El pla de gestió és a internet? Al febrer, Censys va comptar unes 600 instàncies d'SD-WAN Manager accessibles des d'internet, i prop d'una quarta part amb el 22 o el 830 oberts, que és per on s'arriba a l'SSH i al NETCONF que el salt d'autenticació acaba lliurant. Si el teu orquestrador té interfície pública «perquè els tècnics hi entren des de casa», la decisió ja està presa; només falta que algú l'escrigui.
• Tens una via a cada seu que no passi per l'orquestrador? Si l'orquestrador cau —o l'apagues tu a propòsit, que és el que toca davant d'un compromís—, els equips continuen reenviant amb l'última configuració que van rebre, però tu et quedes sense volant. 4G de gestió, consola, la línia de l'operador: alguna cosa que no depengui de la peça que estàs investigant.
• On viu la configuració bona? Exportada, versionada i desada allà on l'orquestrador no pugui escriure. Si l'atacant restaura els fitxers originals, comparar el sistema amb si mateix no serveix de res.
• Qui pot empènyer configuració, amb quina aprovació i amb quin registre? Sense una finestra de canvis escrita, no hi ha manera de distingir el canvi de l'atacant del canvi del dimarts. I sí, això és avorrit, i sí, és el primer que cau quan hi ha pressa.
• Si hi va haver compromís, pedaçar no és netejar. L'orquestrador desa les credencials i els certificats que autentiquen cada equip del fabric: cal rotar-los, no només actualitzar el binari. És la mateixa lliçó que ja vam escriure sobre el symlink del FortiOS, i encara s'aprèn tard.

El que no et direm

No et direm que treguis l'SD-WAN. Seria fàcil rematar així un article amb nou CVE, i seria una ximpleria. El que sí que diem és on el tens col·locat mentalment. Gairebé tothom tracta l'orquestrador com una eina d'operacions: l'instal·la l'integrador, l'utilitzen tres persones i viu a la carpeta d'«infraestructura de xarxa». És un sistema amb privilegi d'administrador sobre tota la teva xarxa, i mereix la mateixa paranoia que el controlador de domini: accés restringit, registre que es mira, credencials que es roten i un procediment escrit per quan falli. El dia que canviï de categoria, la meitat d'aquestes preguntes es responen soles.

Tampoc no et direm quants orquestradors de VeloCloud On-Prem hi ha exposats ara mateix a Espanya. No ho hem mesurat i no ens ho inventarem. El que sí que ens trobem quan entrem en una xarxa aliena és una regla de tallafocs «temporal» que fa tres anys que hi és i un accés de manteniment de l'integrador que ningú no ha revisat des de la posada en marxa. Si alguna de les dues t'ha sonat familiar, ja tens per on començar dilluns.

Dissenyem i operem xarxes SD-WAN multiseu amb el monitoratge i el control de canvis al davant, no al darrere, i ho fem des de la posició d'un operador amb xarxa pròpia: BGP, trànsit, NetFlow i un looking glass públic. No som resellers de cap plataforma, així que la resposta a «quin orquestrador poso?» depèn del teu cas i no de la nostra comissió.

La pregunta amb què tanquem no és si el teu SD-WAN està pedaçat. És aquesta: si demà un canvi perfectament legítim, signat pel teu propi orquestrador, enviés el trànsit d'una seu per on no toca, quant trigaries a assabentar-te'n i per quina via? Si la resposta és «ho veuríem», ensenya'ns la pantalla on es veu.

Fonts (verificades): els recomptes —172 entrades afegides el 2026, nou del pla de gestió d'una xarxa SD-WAN, tretze de Cisco davant de trenta-dues de Microsoft, i només dues entrades de tot l'any amb termini de 48 hores— són càlcul propi sobre el fitxer del catàleg KEV de la CISA, versió 2026.07.29, descarregat l'1 d'agost del 2026; les descripcions de cada CVE i les dates d'alta i de termini surten d'aquest mateix fitxer. La directiva d'emergència ED 26-03 i la seva direcció suplementària de hunt i bastionatge estan publicades per la CISA i referenciades des de les mateixes entrades del catàleg. La seqüència de la intrusió (peerings no autoritzats des de finals del 2025, SSH amb vmanage-admin, el CSV de tenants preparat, l'usuari troot, l'exfiltració via /dataservice/ i les tècniques antiforenses) prové de l'anàlisi «Zero-Day Exploitation of CVE-2026-20245 in Cisco Catalyst SD-WAN Manager» de Google Cloud Threat Intelligence (Mandiant). El CVSS 10.0 de la CVE-2026-16812 prové de l'avís de seguretat 0144 d'Arista i de la seva cobertura a BleepingComputer. El recompte d'instàncies exposades és de l'avís de Censys del febrer del 2026 i és una mesura de tercers, amb la imprecisió pròpia d'un escaneig. Són criteri i opinió nostres, no de les fonts: la lectura que l'orquestrador és l'objectiu per disseny i no per mala programació, els tres llocs on és el senyal, les cinc preguntes i tot el que no diríem.