El 13 d'octubre Volexity va publicar l'anàlisi d'una intrusió en un concentrador d'accés remot Ivanti Connect Secure. El titular tècnic cap en una línia: encadenant tres errors diferents, un atacant que anomenen UTA0576 va obtenir execució de codi amb permisos de root, sense autenticar-se, sobre un aparell que l'informe descriu com a «fully patched (22.8R2.4, Build 19097)». Volexity situa l'explotació com a mínim des del 3 d'octubre; l'empresa de detecció Defused diu haver vist els primers intents el dia 1. La correcció va sortir el 13: entre deu i dotze dies.
Si no fas servir aquest producte, el còmode és passar de llarg. Nosaltres tampoc no el venem ni el despleguem. El valor d'aquest informe rau en una altra banda: és dels pocs que explica, pas a pas, què va fer l'atacant un cop a dins. I aquesta llista, llegida a poc a poc, no és un inventari de credencials. És l'índex del teu pla de recuperació.
Tres errors, un CVE, i un que continua sense arreglar
La cadena té tres baules: un salt d'autenticació a welcome.cgi, que permet arribar a fitxers CGI protegits; una execució de codi a wu.cgi, per escriptura de fitxer amb una condició de cursa; i una elevació de privilegis a través del mecanisme de confiança amb què dsinvoked llegeix la configuració emmagatzemada a DSCache. Els dos primers van junts sota CVE-2026-104935, que és el que es va pedaçar el 13 d'octubre a les versions 22.8R2.5, 25.1.1.2, 25.1.3.0 i 25.1.3.1. El tercer, l'elevació de privilegis, no tenia CVE assignat quan es va publicar l'anàlisi i continua sense correcció: segons Volexity, Ivanti treballa en l'arranjament i arribarà en una versió futura «in the coming weeks».
Aquest detall, tot sol, ja descol·loca qualsevol procés de gestió de vulnerabilitats: una baula d'una cadena activament explotada que no apareix en cap canal, perquè no té identificador a seguir. El teu escàner no et pot dir res d'allò que no existeix al catàleg.
Ni porta del darrere ni web shell
La part que canvia el raonament de defensa és aquesta. Segons Volexity, UTA0576 «passed commands and results through the exploit chain's HTTPS requests rather than a separate command-and-control (C2) channel, with no backdoor or web shell deployed to the compromised device». No hi va haver porta del darrere. No hi va haver web shell. No hi va haver canal de comandament separat que un tallafocs de sortida pogués veure estrany. I per a cada ordre que executaven, diu l'informe, «the entire exploit chain is executed»: tornaven a entrar des de zero, una vegada per comanda.
La neteja tampoc no va ser un esborrat brut. El codi llegia els dos registres que importen —/home/runtime/dlogs/debuglog i /var/log/audit/audit.log—, filtrava les entrades de la finestra temporal en què havien estat i tornava a escriure els fitxers amb la resta. No queda un buit evident ni un fitxer a zero, sinó un registre perfectament versemblant al qual li falten uns minuts que ningú no troba a faltar.
Convé no exagerar-ho, perquè el mateix informe acota l'abast: sí que van quedar artefactes, i per això Volexity recomana mirar el directori /tmp/ i buscar peticions a /dana-na/auth/url_default/welcome.cgi amb capçaleres X-DSCGI-PATH sospitoses. Invisibles no van ser. El que van deixar, això sí, és en llocs que cap procediment de revisió rutinària mira.
L'eina que havia de dir-t'ho diu que està net
El fabricant publica una utilitat, l'Integrity Checker Tool, la feina de la qual és exactament aquesta: detectar modificacions no previstes als fitxers de l'aparell. Volexity ho explica sense voltes: «because this exploit chain patches library code in memory only and restores configuration store data, the tool does not detect any modifications». CISA ho va repetir el mateix dia al seu avís, amb la mateixa cruesa: l'eina «may not detect evidence of exploitation of CVE-2026-104935 because threat actor commands execute in memory», i per això recomana anàlisi forense de xarxa i de memòria a qui sospiti.
I la mateixa setmana, el consell del fabricant als seus clients continuava sent revisar l'avís, actualitzar com abans millor i «run the Integrity Checker Tool regularly». Les dues coses poden ser raonables alhora —l'eina continua servint per a altres coses— però cal llegir-les juntes, perquè la conclusió pràctica és incòmoda: un resultat net d'aquesta eina no és una resposta. És l'absència d'una.
Ens apuntem la correcció, perquè la recomanació per defecte nostra, i la de mig sector, després d'un avís sobre un aparell tancat és «passa-li l'eina d'integritat del fabricant». Aquí aquest pas no tanca res. I el forense de memòria que sí que el tancaria exigeix accés que en un aparell tancat no tens, i una eina de la qual gairebé cap pime disposa. Entre «no hi ha indicis» i «no hi ha manera de tenir indicis» hi ha tota la distància que separa tancar un incident d'arxivar-lo sense saber.
LAPS, BitLocker i una eina que no van arribar a fer servir
Que se'n van endur contrasenyes de LAPS i claus de BitLocker ho ha explicat tota la cobertura d'aquesta setmana; no és una troballa nostra ni està amagada. El que gairebé ningú no ha dit és quina mena de material és aquest. Per arribar-hi cal mirar la llista sencera d'activitat posterior a la intrusió que documenta Volexity:
- Van extreure les credencials de domini del compte de servei LDAP amb què l'aparell consulta el directori.
- Van desplegar una eina LDAP en Python que buscava, textualment, contrasenyes de LAPS, informació de recuperació de BitLocker i atributs d'Active Directory amb valors
userPasswordiunixUserPassword. - També van pujar una implementació pròpia de Kerberos en Python amb funcionalitat de Kerberoasting que, diu Volexity, el guió que la cridava no va arribar a fer servir. Tenien la capacitat i van prioritzar una altra cosa.
- Van capturar trànsit filtrant protocols en clar com LDAP (TCP 389), HTTP, FTP o telnet: per allà continuen circulant credencials sense xifrar en una xarxa d'empresa.
- Van intentar extreure noms d'usuari vàlids dels registres d'autenticació del mateix aparell (
log.events.vc0), i amb ells van fer password spraying contra el directori. - I se'n van endur metadades del Directori Actiu i la configuració del concentrador.
Les contrasenyes de LAPS són les d'administrador local de cada equip: les que fas servir quan una màquina no arrenca al domini. Les claus de BitLocker són les de recuperació: les que fas servir quan el disc no munta. Cap de les dues no serveix per treballar un dimarts qualsevol; totes dues són el material amb què recuperes quan alguna cosa ja ha sortit malament. I és el primer que algú va anar a demanar-li al directori així que va tenir permisos per preguntar, tenint a mà un atac Kerberos que ni tan sols va llançar.
El teu pla està escrit contra l'esborrat
Un pla de continuïtat normal mesura una sola cosa: quant trigues a tornar a tenir allò que has perdut. RTO, RPO, còpies immutables, rèplica en un altre lloc, assaig de restauració. Tot l'aparell conceptual està construït contra la destrucció: alguna cosa s'esborra, es xifra, es trenca, i tu la reposes.
Copiar no destrueix res. Una còpia no apaga un servei, no dispara cap alerta de disponibilitat, no obre cap tiquet, no consumeix RTO i no activa cap pla. Les teves claus de recuperació de BitLocker continuen allà després que algú se les endugui: funcionen igual de bé, per a tu i per a ell. Aquesta és la raó exacta per la qual aquest escenari no apareix en gairebé cap pla de continuïtat que hàgim llegit, inclosos els que estan ben fets i el pla de continuïtat que ningú ha assajat: no hi ha res a restaurar, així que no hi ha res a assajar.
I hi ha un segon rellotge corrent. Les obligacions europees de notificació —NIS2 per a qui estigui en el seu àmbit, amb la seva alerta primerenca de 24 hores, i l'RGPD amb les seves 72 si hi ha dades personals— arrenquen quan tens coneixement de l'incident, no quan l'incident passa. És el mateix mecanisme del qual vam escriure a propòsit del Cyber Resilience Act: el rellotge arrenca quan te n'assabentes. Aquí l'eina dissenyada perquè te n'assabentis està documentada, pel fabricant i per CISA, com a incapaç d'assabentar-se'n. Qui decideix llavors que s'ha «tingut coneixement», i amb quina prova, és una pregunta que no es respon bé a les onze de la nit d'un dimarts.
El cens que falta: què passa si es copia
El que sí que es pot fer aquesta setmana, sense comprar res, és un cens de dues columnes. A l'esquerra, el que passa pel teu accés remot. A la dreta, la pregunta que no apareix en cap auditoria de còpies: no «què passa si s'esborra», sinó què passa si es copia. Amb aquestes quatre files es comença:
| Què passa per l'accés remot | Què passa si es copia |
|---|---|
| Compte de servei amb què l'aparell consulta el directori | Algú llegeix el teu directori sencer amb credencials legítimes, i no salta cap alerta perquè no hi ha res anòmal a detectar. Canviar-la obliga a tocar la configuració de l'aparell, així que no és un clic |
| Contrasenyes d'administrador local (LAPS) | Accés local a cada equip sense tornar a passar pel domini, i per tant sense que el domini se n'assabenti. Forçar la rotació completa és una ordre; el difícil és que algú tingui l'encàrrec d'executar-la |
| Informació de recuperació de BitLocker desada al directori | El xifratge en repòs deixa de protegir un portàtil perdut o un disc retirat. La clau no caduca sola, i regenerar protectors es fa equip a equip |
| Configuració de l'aparell, els seus certificats i les seves claus d'API | Es replica la teva política d'accés en un altre lloc i se sap exactament què no vigiles. És justament el que CISA mana revocar i reemetre, i el que ningú no té inventariat |
Falta la tercera columna, que no cap a la taula perquè és un nom propi: qui rota cadascuna d'aquestes quatre coses, i en quant de temps. L'objectiu de l'exercici és poder dir, el dia que un avís digui que el teu aparell d'accés remot va estar exposat i no puguis demostrar res, què dones per copiat i què rotes, sense convocar cap reunió per decidir-ho. Si en omplir-lo descobreixes que ningú no sap quin compte de servei fa servir el concentrador, això ja és el resultat i val l'estona invertida.
Dos apunts de calendari per tancar l'operatiu. El procediment que CISA publica per a qui sospiti acaba en «Reset all passwords and revoke/reissue certificates and API keys», que és exactament la columna dreta de més amunt; aquesta mateixa tensió entre restaurar i rotar la vam veure aquest matí des de l'altre costat: el procediment oficial per recuperar un GitLab comença amb un DELETE. I l'avís hi afegeix un detall que convé mirar abans de celebrar l'actualització: la branca 22.8 arriba a fi de vida el 31 de gener de 2027, així que sortir per 22.8R2.5 compra tres mesos i mig.
El que queda apuntat
L'aparell que mira a internet per disseny és, gairebé sempre, el que menys pots auditar: no li instal·les cap agent, no li llegeixes la memòria, no hi entres per consola a mirar un procés. Explicàvem fa uns dies que només un de cada vuit errors explotats és en un aparell —són pocs en el recompte, i pesen moltíssim en les conseqüències—. Aquest cas hi afegeix el perquè: quan l'error cau allà, el que s'emporta l'atacant no és un servidor, és el permís de preguntar coses al teu directori. I el directori contesta a tot, inclòs on guardes les claus de recanvi.
Fonts (consultades el 14-10-2026): la cadena de tres errors, els components afectats, la compilació 22.8R2.4 Build 19097, el «com a mínim des del 3 d'octubre», la frase sobre l'absència de porta del darrere i canal de comandament, la reexecució de la cadena per comanda, les dues rutes de registre manipulades, la limitació de l'Integrity Checker Tool i tota la llista d'activitat posterior a la intrusió —incloses les contrasenyes de LAPS i les claus de BitLocker— surten de l'anàlisi de Volexity del 13 d'octubre de 2026. L'advertiment de CISA sobre l'eina, la recomanació de forense de xarxa i memòria, el procediment de recuperació i el fi de vida de la branca 22.8 són al seu avís del 13 d'octubre; l'alta al catàleg de vulnerabilitats explotades, a l'avís del mateix dia. Les versions corregides i la situació del tercer error estan recollides per SecurityWeek, la recomanació del fabricant de continuar passant l'eina d'integritat i la data de l'1 d'octubre que aporta Defused, per BleepingComputer. Un matís que el mateix informe marca i nosaltres repetim: Volexity atribueix amb baixa confiança una motivació criminal i no d'espionatge, i amb confiança mitjana l'ús de models de llenguatge per part de l'atacant; són valoracions, no fets. I un flanc de nomenclatura, per si vas a la font oficial: el catàleg KEV titula CVE-2026-104935 només com a Authentication Bypass by Spoofing Vulnerability, mentre que Volexity i la premsa especialitzada el presenten cobrint també l'execució de codi. No hem reproduït la cadena, no despleguem aquest producte i no tenim telemetria pròpia sobre la seva explotació. El que és nostre és la lectura de l'activitat posterior com a índex del pla de recuperació i la taula de «què passa si es copia».
Decidir abans, no el dia de l'avís
Els plans de compliment i continuïtat que muntem a everyWAN portaran aquesta columna a partir d'avui: què es dóna per copiat, qui rota què i en quant, escrit abans de necessitar-ho. Al voltant, reduïm el que una sola porta pot obrir amb Zero Trust, i vigilem amb EDR/MDR gestionat tot el que hi ha darrere de l'aparell, que és justament on l'aparell deixa d'explicar-te coses. No som resellers d'aquest producte ni de cap plataforma concreta: si la teva sortida és quedar-te com estàs, també t'ho direm.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN