Ivanti Connect Secure: catena zero-day concede root non autenticato su appliance aggiornate

Il 3 ottobre 2026 il threat actor UTA0576 ha iniziato a sfruttare una catena di tre vulnerabilità zero-day in Ivanti Connect Secure per ottenere esecuzione di codice remoto con privilegi di root su appliance completamente patchate. La disclosure stagerizzata — patch del punto di ingresso rilasciata il 13 ottobre, mentre l'escalation dei privilegi restava aperta fino al 29 ottobre — ha generato una finestra di rischio per i difensori. Le tecniche di attacco esclusivamente in memoria hanno reso inefficace lo strumento di integrità del vendor, complicando la verifica della compromissione sui dispositivi perimetrali.

Come funziona la catena: tre bug per un unico obiettivo

La ricostruzione forense di Volexity documenta una catena in tre stadi che non lascia traccia su disco. Il primo stadio sfrutta CVE-2026-104935: l'attaccante invia una richiesta a /dana-na/auth/url_default/welcome.cgi con l'header X-DSCGI-PATH impostato su /home/webserver/htdocs/dana/fb/smb/wu.cgi. Il server utilizza l'URL per il controllo di accesso ma l'header per il routing effettivo, consentendo di raggiungere endpoint protetti senza autenticazione.

Il secondo stadio attacca wu.cgi attraverso una race condition: il gestore di upload scrive il file in /home/runtime/tmp/<MD5(filename)> prima della validazione ZIP, creando una finestra temporale in cui l'attaccante può inviare richieste di esecuzione parallele prima della cancellazione. Il payload viene eseguito con i privilegi dell'utente cgi-server.

Il terzo stadio eleva i privilegi manipolando il servizio dsinvoked, che esegue task di manutenzione come root. L'attaccante modifica in memoria la libreria libdsplibs.so per alterare la configurazione DSCache, inducendo dsinvoked a eseguire uno script Perl controllato con privilegi di root. I file di log e la memoria vengono immediatamente ripristinati per eliminare le tracce.

"Questa catena di exploit combina un bypass di autenticazione, un'esecuzione di codice remota (RCE) e una vulnerabilità di escalation di privilegi per ottenere esecuzione di codice non autenticata a livello di root" — Volexity, via The Hacker News

L'effetto collaterale della disclosure stagerizzata

La tempistica della disclosure Ivanti ha creato una condizione di rischio particolarmente insidiosa. Il 13 ottobre 2026 il vendor ha rilasciato le versioni 25.1.1.2 e 22.8R2.5 correggendo CVE-2026-104935, il punto di ingresso della catena. Secondo la dichiarazione Ivanti riportata da The Hacker News, al momento della scoperta dell'exploitation attivo era già in sviluppo una fix per questa vulnerabilità, in QA per le versioni supportate. La decisione di non ritardare il rilascio per risolvere anche l'escalation di privilegi ha consegnato ai clienti una patch che eliminava solo il primo anello della catena.

L'effetto pratico: le appliance aggiornate al 13 ottobre sono rimaste vulnerabili a CVE-2026-111357 e CVE-2026-118527. Come evidenzia Ciphers Security nella sua advisory: «Se hai applicato la patch il 13 ottobre (a 25.1.1.2 o 22.8R2.5), sei ancora esposto. Aggiorna a 25.1.1.3 o 22.8R2.6 ora, poi cerca segni di compromissione, perché il controllo di integrità di Ivanti può mancare questo attacco». La patch completa è arrivata il 29 ottobre 2026.

Secondo quanto riportato da Cybernews citando l'analista Yordan Ganchev di watchTowr, Ivanti aveva già parzialmente corretto il componente interessato da CVE-2026-104935 nella release 25.1.3.0 del luglio 2026, ma il backporting era in corso quando è iniziata l'exploitation. WatchTowr segnala inoltre che Ivanti Connect Secure e Pulse Connect Secure contano 14 precedenti voci nel catalogo KEV di CISA.

La memoria come campo di battaglia: quando l'integrità del disco non rileva l'attacco

La tecnica anti-forense impiegata da UTA0576 rappresenta un'evoluzione nel tradecraft degli attori di minaccia che colpiscono dispositivi perimetrali. Nessun malware persistente, nessuna web shell, nessuna modifica ai file su disco: l'intera catena di exploit viene rieseguita per ogni comando, con i risultati restituiti tramite risposte HTTPS. Le modifiche alla libreria libdsplibs.so avvengono esclusivamente in memoria; i dati di configurazione alterati vengono ripristinati immediatamente.

Questo approccio annulla lo strumento di verifica che Ivanti distribuisce ai propri clienti. La voce di Volexity è inequivocabile: «Dato che questa catena di exploit modifica il codice della libreria solo in memoria e ripristina i dati del configuration store, lo strumento non rileva alcuna modifica». CISA conferma nella sua advisory che lo strumento «può non rilevare evidenze di exploitation». La conseguenza è che un'appliance che supera il controllo di integrità può comunque essere compromessa.

Le attività post-exploitation documentate da Volexity includono l'estrazione delle credenziali dell'account di servizio LDAP, il dump dei metadati Active Directory, la ricerca di password amministrative e chiavi di recupero BitLocker, il Kerberoasting, il password spraying e la cattura del traffico LDAP. L'attaccante ha inoltre rimosso voci dai log di debug di Ivanti e dai log di audit Linux per ostacolare l'analisi forense.

Cosa fare adesso

Le organizzazioni che utilizzano Ivanti Connect Secure devono agire su tre fronti interdipendenti. Il primo è l'aggiornamento immediato alle versioni 25.1.1.3 o 22.8R2.6, uniche che chiudono tutte e tre le vulnerabilità della catena. Le versioni 25.1.1.2 e 22.8R2.5 rilasciate il 13 ottobre lasciano aperte CVE-2026-111357 e CVE-2026-118527: chi si è fermato a quella patch rimane esposto.

Il secondo fronte è la ricerca attiva di indicatori di compromissione, che non può affidarsi al solo Integrity Checker Tool. Volexity e Ciphers Security hanno pubblicato regole di rilevamento in formato Sigma, KQL e SPL che analizzano il traffico di rete e i log di sistema per identificare le anomalie associate alla catena di exploit. L'analisi deve concentrarsi sulle connessioni sospette a welcome.cgi con header X-DSCGI-PATH anomali e sulle attività del servizio dsinvoked al di fuori delle finestre di manutenzione programmate.

Il terzo fronte è la verifica delle credenziali esposte. Le organizzazioni devono considerare compromesse le credenziali dell'account di servizio LDAP utilizzato da Ivanti Connect Secure e procedere alla loro modifica, oltre a controllare l'eventuale esposizione di chiavi di recupero BitLocker e password LAPS. L'analisi del traffico LDAP catturato dall'attaccante può rivelare ulteriori account a rischio.

Il contesto: una superficie d'attacco ricorrente

La catena UTA0576 si inserisce in un pattern di vulnerabilità critiche che ha colpito ripetutamente Ivanti Connect Secure e il suo predecessore Pulse Connect Secure. I 14 precedenti inserimenti nel catalogo KEV di CISA documentano una superficie d'attacco consolidata, con exploit che hanno colpito dispositivi perimetrali che per definizione sono esposti a Internet e gestiscono l'accesso privilegiato alle reti interne.

La scelta di UTA0576 di non installare malware persistente ma di rieseguire l'intera catena per ogni comando riflette una consapevolezza delle limitazioni degli strumenti di rilevamento tradizionali. L'attaccante ha costruito un'operazione che massimizza l'accesso e minimizza la visibilità, sfruttando la fiducia che i difensori ripongono nei controlli di integrità del vendor.

L'analista Yordan Ganchev di watchTowr ha commentato che, data la storia di questa piattaforma, ci si attende un passaggio rapido da attacchi mirati a exploitation indiscriminata di massa. La combinazione di vulnerabilità con impatto elevato, tecniche di elusione efficaci e una base di installazione ampia rende questo scenario plausibile.

Chiusura editoriale

Il caso Ivanti Connect Secure esemplifica una tensione strutturale nella gestione delle vulnerabilità zero-day: la pressione per rilasciare rapidamente una patch parziale contro la necessità di una soluzione completa. La decisione di Ivanti di distribuire il 13 ottobre una correzione che chiudeva solo il punto di ingresso, lasciando aperta l'escalation dei privilegi, ha creato una trappola per i difensori che hanno applicato l'aggiornamento ritenendosi protetti.

La risposta efficace richiede ora che le organizzazioni superino la logica del patching come unico baluardo. L'integrazione di rilevamento comportamentale, l'analisi del traffico perimetrale e la verifica indipendente degli indicatori di compromissione sono diventati elementi non opzionali di una difesa in profondità. Il tradecraft di UTA0576 dimostra che gli attaccanti conoscono gli strumenti dei difensori e li aggirano sistematicamente: la contromisura deve essere altrettanto sistematica nella sua diversificazione.