L'allarme CISA del 13 ottobre su Ivanti Connect Secure non era una precauzione contro un problema ipotetico. Gli aggressori avevano già concatenato aggiramento dell'autenticazione ed esecuzione contro un'appliance allora completamente aggiornata per il proprio ramo. L'agenzia ha inserito CVE-2026-104935 nel catalogo delle vulnerabilità sfruttate, fissando il 16 ottobre come termine di intervento per le agenzie civili federali.
Correzione immediata e incidente irrisolto sono problemi diversi. Volexity descrive sfruttamento ripetuto, modifiche temporanee alla memoria, raccolta di credenziali e cancellazione selettiva dei log, senza una normale web shell persistente. Aggiornare chiude l'ingresso documentato, ma non revoca segreti rubati né dimostra l'assenza di accessi precedenti.
Scadenza e versioni interessate
La vulnerabilità ha CVSS 8,6. Consente comandi remoti con bassa complessità, senza account esistente o interazione dell'utente. Connect Secure collega internet, applicazioni interne e servizi d'identità: un difetto di autenticazione offre quindi una posizione fidata di grande valore.
I resoconti completati indicano come vulnerabili 25.1.1.1 e precedenti nel relativo ramo, 25.1.2.2 e precedenti e 22.8R2.4 e precedenti. Le versioni corrette comprendono 25.1.1.2, 25.1.3.0, 25.1.3.1 e 22.8R2.5. Non sono rami intercambiabili liberamente: installazione e percorso supportato vanno verificati nel bollettino Ivanti.
L'eccezione per le versioni vecchie ha precisione diversa nelle fonti: il testo principale parla di 22.7.x e precedenti, il resoconto incorporato basato sul CVE di 22.7R2.14 e precedenti. Nessuna formulazione garantisce sicurezza generale o giustifica un downgrade. Altre vulnerabilità e fine del supporto rimangono questioni separate.
L'aggiornamento KEV del 13 ottobre includeva anche Windows Shell CVE-2026-96951. È un problema distinto che richiede interazione dell'utente, diversamente dal percorso Ivanti diretto e non autenticato. Per entrambe le voci, le agenzie Federal Civilian Executive Branch avevano scadenza il 16 ottobre secondo i requisiti BOD 26-04 citati. Le organizzazioni private non ereditano automaticamente gli obblighi, ma condividono l'esposizione tecnica. Windows è qui contesto, non una seconda vulnerabilità Ivanti.
L'inclusione KEV prova sfruttamento osservato, non che ogni dispositivo esposto sia stato violato o che la scala sia massiva. Il campo ransomware era sconosciuto, non un legame confermato. Anche l'affermazione Ivanti di sfruttamento noto limitato descrive la visibilità dell'azienda, non un limite affidabile delle vittime.
Un gateway allora aggiornato è stato colpito prima della divulgazione
Volexity ha iniziato l'indagine il 5 ottobre e ricostruito sfruttamenti dal 3 ottobre contro Connect Secure 22.8R2.4, Build 19097, allora corrente nel suo ramo. Un altro fornitore d'intelligence avrebbe osservato segnali correlati dal 1° ottobre. Sono osservazioni diverse: la data precedente non va presentata come confermata direttamente da Volexity.
L'azienda segue l'attività non identificata come UTA0576. È un'etichetta analitica, non un'identità reale o uno sponsor governativo dimostrato. Con bassa confidenza ha ipotizzato motivazioni criminali anziché spionistiche. L'operazione è stata interrotta prima di chiarire l'obiettivo finale.
Ivanti ha dichiarato di avere trovato parte del problema attraverso il programma di sicurezza del prodotto e corretto nella versione 25.1.3.0 di luglio 2026. Lo sfruttamento è avvenuto durante il trasferimento della correzione ad altri rami supportati. C'era una lacuna reale tra rami, ma il resoconto pubblico non stabilisce quando l'azienda comprese l'intera catena o seppe degli attacchi. Attività di compatibilità e porting non autorizzano accuse infondate di ritardo deliberato.
Il contesto comprende CVE-2025-0282, overflow del buffer sullo stack sfruttato a gennaio 2025, e CVE-2025-22457, poi associata a spionaggio legato alla Cina. Non identificano UTA0576 né provano l'insicurezza di ogni appliance. Volexity ha confrontato anche il recupero di credenziali dalle catture di pacchetti con attacchi a dispositivi SonicWall, mostrando l'attrattiva generale delle infrastrutture fidate di confine.
Tre debolezze hanno portato dall'accesso pubblico a root
La catena ricostruita iniziava con una divergenza tra autorizzazione e instradamento. Una richiesta al componente pubblico welcome.cgi poteva specificare un'altra destinazione nell'header X-DSCGI-PATH. L'appliance verificava l'URL pubblico ma inoltrava al gestore protetto di caricamento wu.cgi.
Il gestore scriveva il file prima di accertare che fosse uno ZIP valido. Uno script Perl mascherato dall'estensione esisteva brevemente prima del rifiuto e della cancellazione. Richieste parallele gareggiavano con quella finestra di pulizia, permettendo esecuzione nell'account limitato cgi-server. È un errore temporale di gestione dei file, non prova che i normali ZIP siano intrinsecamente eseguibili.
Ivanti ha raggruppato aggiramento dell'autenticazione ed esecuzione remota sotto CVE-2026-104935. Una vulnerabilità distinta di elevazione coinvolgeva un servizio privilegiato che si fidava di configurazioni manipolate e una modifica in memoria di una libreria. Un'attività legittima di manutenzione veniva deviata verso uno script malevolo ed eseguita come root. L'operatore verificava accesso a informazioni protette sulle password e ripristinava configurazione e istruzione di memoria.
Al momento delle pubblicazioni concluse, Ivanti prevedeva una successiva correzione dell'elevazione separata. Ciò non significa che l'aggiornamento del 13 ottobre lasci aperta la via non autenticata documentata: bloccare ingresso ed esecuzione interrompe quella catena specifica. Le successive versioni del produttore restano comunque importanti.
L'operatore riutilizzava il canale della vulnerabilità per scambiare comandi e risultati via HTTPS invece di lasciare una backdoor iniziale. Alcune fasi vivevano solo in memoria, incluso un payload Python compresso e codificato. Venivano cancellate voci selezionate di debug e audit Linux, rimossi file e risultati temporanei e ripristinato lo stato modificato.
Secondo Volexity il metodo eludeva l'Integrity Checker Tool Ivanti. Lo strumento cerca modifiche inattese dei file; alterazioni temporanee della memoria e configurazioni ripristinate vanno oltre ciò che un controllo del disco pulito può escludere. Questo limita il significato dell'esito, senza rendere inutile il controllo.
I dati d'identità hanno esteso l'impatto
L'accesso del gateway al servizio di directory permetteva interrogazioni di un domain controller Active Directory interno. Gli investigatori hanno recuperato uno strumento LDAP personalizzato e script Python per credenziali LAPS degli amministratori locali, recupero BitLocker, attributi contenenti password, metadati utenti e percorsi di script di accesso. I log d'autenticazione fornivano anche nomi validi.
Le credenziali LAPS possono aprire accesso amministrativo locale; i dati BitLocker sbloccare dischi cifrati. Volexity ha valutato con alta confidenza l'esfiltrazione delle informazioni disponibili attraverso le query mirate. Non dimostra che ogni segreto cercato esistesse o che tutte le intrusioni successive riuscissero.
L'operatore esaminava inoltre catture di rete per credenziali LDAP in chiaro, materiale HTTP Basic e hash NTLM challenge-response. Un programma rinominato in una directory nascosta monitorava LDAP, HTTP, FTP e Telnet usando otto file a rotazione. Abusi degli hash e attacchi offline dipendono da configurazione e robustezza delle password, ma la raccolta genera conseguenze che aggiornare la VPN non annulla.
Altre attività comprendevano ricognizione DNS e dei nomi interni, ricerca di configurazioni VPN e log d'accesso e password spraying sugli account di directory. Insieme sostenevano la preparazione a movimento laterale e accesso più ampio. Non sono stati stabiliti obiettivo finale e successo di ogni tecnica.
Serve prudenza anche sull'AI. Nel materiale incorporato Volexity valutava con confidenza media l'uso di grandi modelli linguistici nello sviluppo o dopo l'intrusione, citando script adattati, credenziali fisse, riuso del canale e complessità. È un'inferenza, non prova diretta. Iterazioni umane o strumenti privati possono produrre gli stessi schemi: non comprova un attacco autonomo dell'AI.
Che cosa deve dimostrare una chiusura difendibile
Shadowserver ha contato oltre 5.500 istanze apparentemente esposte di Connect Secure dopo la divulgazione. È un'osservazione dell'esposizione, non il numero di clienti vulnerabili o compromessi. Può includere honeypot, duplicati e sistemi aggiornati. L'inventario deve comprendere gateway attivi e di riserva, nodi di recupero e test dimenticati, verificando la build effettiva.
Ivanti raccomandava aggiornamento immediato e verifiche regolari; Rapid7 sottolineava inoltre la ricerca di compromissione dopo la patch. Date di esposizione, connessioni dal gateway, log d'identità e directory, firewall, DNS e memoria conservata rispondono a domande diverse dalla versione. Volumi anomali su welcome.cgi e divergenze URL/header sono indizi, ma modificabili dagli aggressori. L'assenza di indicatori pubblicati non costituisce assoluzione universale.
Contenimento e conservazione delle prove possono confliggere. Riavvio o ricostruzione distruggono tracce volatili, ritardare l'isolamento può estendere l'accesso. Rischio attivo, ridondanza e capacità forense determinano l'ordine. I responsabili devono coordinare la raccolta senza prolungare inutilmente l'intrusione e documentare azioni e orari.
La rotazione delle credenziali deve seguire integrazioni, segreti accessibili e attività osservate. Credenziali di servizio, password amministrative locali, chiavi di recupero, token e segreti riutilizzabili richiedono valutazioni separate. Reset indiscriminati possono interrompere dipendenze e trascurare elementi meno visibili. Le connessioni successive originate dal gateway fidato meritano un'indagine autonoma.
Nel lungo periodo occorre ridurre esposizioni esterne e amministrative non necessarie, centralizzare log, limitare privilegi degli account di directory, segmentare accessi interni e rimuovere autenticazione in chiaro dove possibile. Non elimina gli zero-day, ma limita ciò che un dispositivo compromesso può raggiungere e cancellare.
I prossimi segnali sono nuove vittime o sfruttamenti, copertura verificata dei rami supportati, correzione dell'elevazione separata e uso successivo delle credenziali rubate. Volexity ha trattenuto codice pronto all'impiego offensivo, ma l'analisi può comunque aiutare imitatori. Nessun nuovo caso pubblico non significa nessuna ulteriore compromissione.
La chiusura richiede risposte distinte su versione vulnerabile, esposizione nella finestra d'attacco, prove di accesso e sistemi o segreti raggiungibili dopo. Una patch completata risponde alla prima domanda. È un passaggio necessario, non sostituisce gli altri tre.