Ivanti Connect Secure: UTA0576 e il furto di credenziali da AD

Nella prima settimana di ottobre 2026 Volexity ha individuato un gruppo finora sconosciuto, che chiama UTA0576, mentre comprometteva un’appliance Ivanti Connect Secure (ICS) aggiornata all’ultima versione allora disponibile, la 22.8R2.4. Il gruppo ha concatenato tre vulnerabilità zero-day (bypass di autenticazione, esecuzione di codice remota ed escalation di privilegi) fino a ottenere i privilegi di root senza credenziali.

Il 13 ottobre Ivanti ha pubblicato l’avviso e le correzioni per le prime due falle, riunite nella CVE-2026-104935 (CVSS v3.1 8,6). L’escalation di privilegi non è ancora corretta: secondo Help Net Security e Security Affairs arriverà in una versione successiva. Ivanti parla di sfruttamento limitato a un numero ristretto di clienti. La CISA ha inserito la CVE nel catalogo KEV lo stesso giorno e ha chiesto alle agenzie federali statunitensi di aggiornare e fare un’analisi forense entro il 16 ottobre. Hanno pubblicato avvisi anche BSI/CERT-Bund (Germania), CCB (Belgio), INCIBE-CERT (Spagna) e KISA/KrCERT (Corea del Sud).

Questo articolo si concentra su quello che il gruppo ha fatto dopo l’accesso, perché è lì che si trovano le tracce più utili per chi difende.

Cronologia

• 1° ottobre: secondo Defused Cyber, citata da Help Net Security, è la prima attività confermata di questa campagna.
• 3 ottobre: secondo Security Affairs l’attaccante era già nell’appliance del cliente di Volexity.
• 5 ottobre: Volexity inizia l’indagine su attività sospette e le riconduce alla VPN.
• 13 ottobre: avviso e correzioni di Ivanti, inserimento nel catalogo KEV (data riportata da CSO Online).

Ivanti aveva già trovato «una parte» della vulnerabilità con il proprio programma di sicurezza e l’aveva corretta a luglio nella 25.1.3.0; stava portando la correzione negli altri rami supportati quando sono iniziati gli attacchi.

Perché l’Integrity Checker non basta

Secondo Volexity la catena modifica il codice solo in memoria e poi ripristina i dati di configurazione: l’Integrity Checker Tool (ICT) di Ivanti, che controlla i file su disco, non vede niente. Per ogni comando il gruppo ripeteva l’intera catena e riceveva i risultati nelle normali risposte HTTPS, senza web shell né backdoor persistenti. I file temporanei venivano rimossi subito e alcune righe dei log di debug di Ivanti e dei log di audit di Linux venivano cancellate. Per capire se un’appliance è stata compromessa serve quindi un’analisi forense, come ricordano Volexity e la CISA.

Cosa ha cercato in Active Directory

Il dettaglio più rilevante per le aziende riguarda i bersagli. Secondo il rapporto di Volexity, ripreso da Security Affairs e Help Net Security, subito dopo l’accesso UTA0576:

• ha usato uno strumento LDAP scritto in Python che si autenticava a un domain controller con l’account di servizio della VPN stessa;
• ha cercato in Active Directory le password LAPS degli amministratori locali, le chiavi di ripristino BitLocker e gli attributi con password in chiaro;
• ha catturato il traffico LDAP che passava dall’appliance per raccogliere credenziali in chiaro, con uno strumento rinominato e nascosto e otto file di cattura a rotazione;
• ha eseguito attacchi di Kerberoasting con una propria implementazione di Kerberos e campagne di password spraying contro gli account di dominio;
• ha esfiltrato configurazione e risultati, compressi e codificati, attraverso lo stesso canale.

Volexity ritiene con alta confidenza che il gruppo stesse preparando movimenti laterali e una compromissione più ampia, interrotta dalla scoperta. Sulle motivazioni la confidenza è bassa: più probabilmente criminali che di spionaggio. Solo Security Affairs riporta anche che, secondo Volexity (confidenza media), il gruppo usa modelli linguistici di grandi dimensioni per sviluppare exploit e attività successive all’accesso.

In termini MITRE ATT&CK: T1190 per l’accesso iniziale, T1068 per l’escalation, T1070 per la cancellazione delle tracce, T1040 per la cattura del traffico, T1558.003 (Kerberoasting), T1110.003 (password spraying) e T1041 per l’esfiltrazione.

Versioni colpite e corrette

Secondo gli avvisi di INCIBE-CERT e KISA:

• 22.8R2.4 e precedenti del ramo 22.8: aggiorna alla 22.8R2.5, poi Ivanti consiglia di passare al ramo 25.1;
• 25.1.1.1 e precedenti: aggiorna alla 25.1.1.2;
• 25.1.2.2 e precedenti: aggiorna alla 25.1.3.0, alla 25.1.3.1 o a una versione successiva.

La 22.7R2.14 e le precedenti non sono colpite dalla CVE-2026-104935. Secondo CSO Online, Ivanti afferma che indicatori di compromissione affidabili non sono ancora disponibili e rimanda a quelli pubblicati da Volexity.

Nello stesso bollettino di ottobre, riassunto da INCIBE-CERT, Ivanti corregge anche due falle critiche non sfruttate: CVE-2026-106042 in Xtraction (aggiorna alla 2026.4) e CVE-2026-109412 in Neurons Patch for Intune, già corretta nel cloud il 16 settembre; per quest’ultima Ivanti consiglia di ruotare il segreto client dell’applicazione registrata in Microsoft Entra ID.

Impatto per le aziende europee e italiane

La VPN è il punto d’ingresso di dipendenti, fornitori e manutentori, e il suo account di servizio ha spesso accesso in lettura a gran parte di Active Directory. Il punto chiave è che le credenziali rubate restano valide dopo l’aggiornamento: password LAPS, chiavi BitLocker, account con SPN e account indovinati con lo spraying vanno considerati esposti se l’appliance è stata compromessa.

Per i soggetti NIS2 l’aggiornamento rientra nella gestione delle vulnerabilità con tempi documentati; una compromissione accertata va valutata ai fini della notifica al CSIRT Italia dell’ACN (preallarme entro 24 ore per gli incidenti significativi). Nella sanità, dove la VPN serve spesso all’accesso remoto di medici e fornitori di dispositivi, le chiavi BitLocker e le password degli amministratori locali aprono la strada alle postazioni cliniche.

Cosa fare subito

1. Conserva le prove prima di aggiornare un’appliance sospetta: log, copie della configurazione e immagini di sistema (indicazione di INCIBE-CERT).
2. Aggiorna ogni appliance e ogni nodo dei cluster alla versione corretta del tuo ramo; esegui l’ICT, ma non considerare un esito pulito come prova di integrità.
3. Controlla Active Directory dal lato dei domain controller: interrogazioni LDAP dell’account di servizio della VPN verso attributi LAPS, oggetti di ripristino BitLocker e attributi con password; picchi di richieste di ticket Kerberos dall’indirizzo interno della VPN; raffiche di accessi falliti su molti account.
4. In caso di compromissione segui le istruzioni di ripristino di Ivanti e ruota: password dell’account di servizio della VPN, password LAPS, chiavi di ripristino BitLocker, password degli account con SPN e degli account presi di mira dallo spraying.
5. Riduci l’esposizione: limita i permessi dell’account di servizio della VPN al minimo indispensabile e usa connessioni LDAP cifrate, così il traffico che attraversa l’appliance non contiene credenziali in chiaro.
6. Segui l’avviso di Ivanti per la correzione dell’escalation di privilegi e installala appena esce.

Come aiuta ARXDOME

ARX Expose mostra quali servizi la tua azienda espone su Internet e quali hanno vulnerabilità note, così sai subito se un gateway di accesso remoto è raggiungibile da fuori. ARX Sentry porta i log di firewall e dispositivi di rete in un collettore centrale, fuori dall’appliance: cancellare i log locali non elimina quello che è già stato inviato. Le pagine SOC sulle identità evidenziano raffiche di tentativi, accessi privilegiati e modifiche agli account, utili per riconoscere spraying e uso di credenziali rubate.

Ultimo aggiornamento: 14 ottobre 2026