CyberStrikeAI in the Wild: un orchestratore LLM ha ottenuto Domain Admin su obiettivi del settore educativo in America Latina e Africa

Il 2 novembre 2026 Kaspersky ha pubblicato un rapporto Securelist e un comunicato stampa che descrivono intrusioni presso organizzazioni del settore educativo in diversi paesi dell'America Latina e dell'Africa, in cui le attività post-sfruttamento sono state dirette da un modello linguistico di grandi dimensioni. Lo strumento era CyberStrikeAI, un framework di penetration testing open source basato su Go, il cui server di comando e controllo ospita un LLM che seleziona gli strumenti e scrive i comandi mentre un normale implant li esegue sull'host vittima. Nell'unico caso che Kaspersky ricostruisce in dettaglio, un operatore umano è entrato attraverso un Microsoft SQL Server compromesso, ha fatto una pausa di due settimane e poi ha lasciato agire l'agente: gli account amministratore di dominio sono stati compromessi nell'arco di tre o quattro giorni, e l'ultima fase — movimento laterale, dump massivo delle credenziali ed esportazione di un database — si è conclusa in meno di un'ora. Kaspersky non nomina alcuna istituzione né alcun paese, non fornisce il numero delle vittime e afferma di aver osservato l'attività tra settembre e ottobre 2026. Il registro completo di questa campagna, con il suo livello di gravità, il grado di confidenza e l'elenco completo delle fonti, è archiviato nel Orca AI Incident Archive, insieme alle altre voci sulle intrusioni assistite dall'IA.

Cosa ha effettivamente pubblicato Kaspersky

Il documento principale è "CyberStrikeAI in the wild: l'uso dell'IA in attacchi reali contro le organizzazioni", pubblicato su Securelist il 2 novembre 2026 e attribuito a Kirill Antonov, Vladislav Vlasov e Dmitry Chizhmak del team di ricerca sulle minacce di Kaspersky. È accompagnato dal comunicato stampa di Kaspersky, diffuso lo stesso giorno, che riassume gli stessi risultati. Il livello di affidabilità A dell'archivio descrive quanto i due documenti siano coerenti tra loro e quanto sia specifico il dettaglio tecnico; non è un'affermazione che una seconda organizzazione abbia verificato l'intrusione in modo indipendente.

La copertura secondaria di questo rapporto non fornisce quella seconda organizzazione. Cybersecuritynews.com, Cyberpress, SecurityOnline e TechTrends Kenya, con sede a Nairobi, hanno tutti pubblicato resoconti tra il 2 e il 3 novembre 2026, e ciascuno deriva dal comunicato di Kaspersky anziché da una propria indagine; l'articolo della testata keniota è costruito attorno alla stessa citazione del comunicato stampa di Nikita Nazarov, responsabile di Threat Exploration presso Kaspersky. Al 9 novembre 2026, nessuna università colpita, nessun ministero dell'istruzione o team nazionale di risposta alle emergenze informatiche aveva confermato pubblicamente le intrusioni, e Kaspersky non ha pubblicato l'identità delle vittime. Tale assenza è essa stessa parte del resoconto: ciò che è documentato in dettaglio sono le tecniche operative, non il danno arrecato a un'istituzione nominata.

La dichiarazione di ambito di Kaspersky è volutamente ristretta. Le vittime confermate, secondo le sue parole, erano «organizzazioni del settore educativo in diversi paesi dell’Africa e dell’America Latina». Non dice quante, quali paesi, né come la campagna sia stata rilevata in primo luogo — solo che il team l’ha trovata «nell’ambito del monitoraggio proattivo delle minacce».

Una distinzione qui è importante, perché è facile confonderla. Organizzazioni indipendenti hanno ora segnalato CyberStrikeAI in intrusioni reali, ma non in queste intrusioni. Team Cymru ha collegato l'infrastruttura che eseguiva lo strumento alla campagna di gennaio–febbraio 2026 contro oltre 600 dispositivi FortiGate, avendo osservato 21 indirizzi IP univoci che lo servivano tra il 20 gennaio e il 26 febbraio 2026. L'unità TrendAI di Trend Micro, in una ricerca pubblicata il 23 ottobre 2026, ha descritto un operatore che gestiva 44 agenti CyberStrikeAI coordinati che hanno sottoposto almeno 19 organizzazioni identificabili, almeno 16 delle quali in Giappone, ad attività di validazione in una breve finestra temporale in quel mese di ottobre. La nota di ricerca della Cloud Security Alliance del 28 ottobre 2026 riunisce entrambi i lavori e conclude che nessuna fonte pubblicata aveva ancora collegato le separate campagne CyberStrikeAI a un unico attore. Questo insieme di lavori corrobora la premessa, ovvero che questo framework viene usato per attaccare reti reali, e non dice nulla sulle vittime nel settore dell'istruzione in America Latina e Africa nel rapporto di Kaspersky.

Lo strumento, e dove si trovava davvero l'AI

CyberStrikeAI, come lo descrive Kaspersky, è "una piattaforma modulare open-source scritta in Go per automatizzare i test di penetrazione". La sua scelta progettuale distintiva è che l'intero strato intelligente risiede sul server di controllo dell'attaccante, non sulla macchina della vittima. Gli strumenti di ricognizione e sfruttamento, la gestione delle webshell, l'assegnazione dei compiti agli agenti e la lettura dei risultati sono tutti esposti al modello come strumenti MCP all'interno di un unico processo server, ed è il modello a decidere quale di essi chiamare successivamente.

L'implant è l'altra metà, ed è volutamente stupido. Kaspersky scrive che è "un classico agente C2 senza alcuna funzionalità di AI — nessuna chiave API, nessuna chiamata alle API dei servizi di AI e nessuna logica autonoma". Interroga periodicamente il listener via HTTP/S, TCP o WebSocket, esegue comandi shell e tocca il file system. Non è un modello in esecuzione nella rete di una vittima e non contatta mai un fornitore di AI. La divisione del lavoro è la frase che Kaspersky usa per spiegare l'intero schema: "Le decisioni sono distribuite su due livelli: l'operatore definisce il compito in termini generali, mentre il modello determina come eseguirlo".

Il controllo umano viene mantenuto anziché rimosso. Kaspersky segnala un meccanismo human-in-the-loop secondo cui «l'operatore mantiene il pieno controllo del processo» e i comandi generati dal modello «possono richiedere un'approvazione o una correzione manuale prima di essere eseguiti». L'AI scrive i passaggi; una persona può comunque rifiutarli.

Un'intrusione ricostruita, nell'ordine in cui Kaspersky la data

Il report segue un singolo incidente all'interno della campagna, e la sua prima fase sembra un normale lavoro manuale da tastiera. I comandi sui sistemi della vittima provenivano dal processo sqlservr.exe, indicando "un SQL Server compromesso (versione 16.0.1000)" come probabile vettore d'ingresso. L'operatore ha poi raccolto informazioni di base sull'host, distribuito strumenti e mappato la rete manualmente. Ciò ha richiesto "quasi un giorno", dopodiché gli attaccanti sono rimasti in silenzio per circa due settimane.

La seconda fase è quella in cui cambia il ritmo. Con l'agente CyberStrikeAI distribuito, la persistenza e la ricognizione locale sono state eseguite "entro 2 minuti" — un'attività pianificata chiamata SystemUpdate che punta all'implant, con una chiave Run del registro sotto HKCU\Software\Microsoft\Windows\CurrentVersion\Run come alternativa del framework su Windows, e una voce crontab @reboot o una riga nohup in ~/.bashrc come sue alternative su Linux. La ricognizione del dominio è stata eseguita "nelle 5 ore successive", usando script PowerShell generati dal modello e query LDAP su Active Directory, incluse le ricerche necessarie per preparare Kerberoasting e AS-REP Roasting e i controlli per LAPS, Azure e le directory .azcopy. Dopo "una breve pausa di diversi giorni," la fase finale — movimento laterale su SMB e WMI, dump massivo delle credenziali e un'esportazione del database — ha richiesto "non più di un'ora."

La riga di riepilogo di Kaspersky è quella che vale la pena conservare: l’intero attacco, «dalla distribuzione dell’agente alla compromissione degli amministratori di dominio», è stato completato nell’arco di 3–4 giorni.

Il lavoro sulle credenziali è un catalogo di tecniche Windows ben note più che qualcosa di nuovo: hive del registro copiati con reg.exe, dump di lsass.exe tramite la funzione MiniDump di comsvcs.dll usando l'ID processo anziché il nome per eludere il matching sulla riga di comando e, una volta compromesso l'account amministratore di dominio predefinito, attacchi DCSync e Golden Ticket eseguiti tramite un binario Mimikatz rinominato, wdiag2.exe. Il movimento laterale ha utilizzato WMIExec di Impacket, cartelle amministrative condivise e WMI, con uno script reverse-shell, p1.ps1, inviato agli host remoti e che effettuava callback a 185.186.245[.]144:5501. I payload sono stati suddivisi in frammenti come d3.b64 e riassemblati con certutil, e un beacon si è mascherato da svchosts.exe.

La raccolta è arrivata per ultima. L'agente ha generato query SQL su misura per l'attività, ma ha verificato i privilegi dell'account del database prima di eseguirle, ha scansionato ricorsivamente le condivisioni di rete prima di prelevare i file e ha restituito tutto sullo stesso canale C2 cifrato, con i dati codificati in Base64 all'interno di JSON. Gli screenshot su Windows e Linux erano disponibili entrambi, ma, secondo il resoconto di Kaspersky, venivano acquisiti solo quando l'orchestratore impartiva il comando. Il rapporto afferma che la raccolta dei dati "è stata la fase finale dell'attacco: la catena è terminata lì e non abbiamo osservato ulteriori attività."

Che cosa è stato preso, e che cosa il verbale non dice

Kaspersky registra che l'agente ha esportato record di database dal server SQL dell'organizzazione educativa e ha raccolto file da risorse di rete, e descrive il meccanismo in dettaglio. Non dice quanti record o file siano usciti, se l'esportazione sia stata completata o di chi fossero i dati nelle tabelle. I riepiloghi secondari su questo punto vanno oltre il rapporto: l'articolo di SecurityOnline afferma che l'agente «ha generato query SQL mirate per rubare record di studenti e personale dalle tabelle del database», mentre il testo di Kaspersky descrive le query contro un server SQL di un'organizzazione educativa senza specificare cosa contenessero le tabelle. I lettori dovrebbero considerare la descrizione «record di studenti e personale» come una caratterizzazione secondaria, non come una conclusione di Kaspersky.

Assenti dal resoconto anche: se una qualsiasi vittima abbia rilevato l'intrusione stessa, cosa abbia fatto ciascuna istituzione in seguito, se le autorità di regolamentazione o di protezione dei dati nei Paesi colpiti siano state notificate e se la campagna sia ancora in corso. Kaspersky afferma soltanto che la raccolta dei dati è stato l'ultimo passo osservato negli incidenti esaminati. Il comunicato stampa non contiene indicazioni di remediation per le organizzazioni colpite: le sue raccomandazioni sono rivolte ai difensori in generale.

Attribuzione: ciò che le prove supportano e ciò che non supportano

Kaspersky afferma esplicitamente di non poter nominare un attore. "I dati disponibili non ci consentono di collegare l'attività a nessun gruppo di attaccanti noto, né di affermare con certezza che lo stesso operatore sia dietro entrambe le campagne." L'artefatto su cui si basa sono i metadati di build Go all'interno degli implant, che contengono hash del controllo di versione, orari dei commit e un flag di copia di lavoro sporca — "un'impronta univoca per una specifica build." Su questa base i campioni si dividono in due gruppi, e all'interno di ciascun gruppo i payload Windows e Linux condividono metadati identici, il che significa che provengono dalla stessa copia di lavoro.

I gruppi non sono collegati. «Non condividono un'infrastruttura C2 comune» e sui due insiemi di server di controllo erano in esecuzione versioni diverse di CyberStrikeAI. Kaspersky indica due ragioni per cui l'attribuzione è difficile in questo caso: il framework è disponibile pubblicamente, quindi operatori diversi potrebbero aver creato payload in modo indipendente in condizioni simili, e i comandi stessi sono generati da modelli, il che ne amplifica la varietà eliminando al contempo le abitudini individuali da cui dipende l'attribuzione comportamentale.

Quel che resta è suggestivo, non conclusivo. Alcuni script contenevano commenti in cinese, gli attaccanti hanno usato il servizio cinese dnslog[.]cn per confermare l'accesso a Internet dagli host vittima, e la maggior parte dei riavvii dei server di controllo — ricostruibili perché il certificato TLS autofirmato viene rigenerato in memoria a ogni avvio, così il suo campo not_before registra l'ora del riavvio — è caduta nelle ore lavorative UTC+8. CyberStrikeAI stesso è stato sviluppato all'interno della comunità cibersicurezza cinese. Il comunicato stampa di Kaspersky traccia chiaramente il confine: questi artefatti "non stabiliscono l'identità o la posizione degli attaccanti", e la società "non è riuscita ad attribuire l'attività a un noto gruppo di minaccia né a confermare che lo stesso operatore controllasse tutta l'infrastruttura identificata". Un operatore di lingua cinese è un'inferenza, non un riscontro.

Perché Kaspersky afferma che non si tratta di un’emergenza di rilevamento

La conclusione del rapporto respinge l'idea che un LLM nella kill chain richieda una nuova classe di difesa. Poiché il modello risiede sul server dell'attaccante, "non ha lasciato tracce della propria presenza nell'infrastruttura (come specifiche richieste API a LLM locali o schemi anomali di consumo di risorse da parte degli host)." Ciò che i difensori vedono invece è un'intrusione dall'impronta umana: le stesse utility, le stesse sequenze, le stesse voci del registro eventi. Il verdetto di Kaspersky è che "l'introduzione dell'IA nella catena di attacco non presenta ancora sfide fondamentalmente nuove per il rilevamento", che "regole classiche e ben calibrate di correlazione e analisi comportamentale sono sufficienti", e che la novità "non risiede nei metodi in sé, ma nella velocità e nella facilità con cui sono stati eseguiti."

Le detection pubblicate seguono quella logica invece di inventarne di nuove. Kaspersky Anti Targeted Attack attribuisce il verdetto di rete Backdoor.CyberStrikeAI.HTTP.C&C al traffico dell'implant; una regola di rilevamento delle anomalie di rete denominata "Scanning domain records via LDAP queries" individua l'attività di ricognizione del dominio; Kaspersky SIEM include più di 100 regole che coprono le tecniche descritte nel report, tra cui DCSync, Golden Ticket, Kerberoasting e Impacket WMIExec; e gli implant sono classificati come HEUR:HackTool.Win64.CyberStrike.gen e HEUR:HackTool.Linux.CyberStrike.gen. Le indicazioni di Kaspersky ai clienti sono convenzionali — rilevamento e risposta sugli endpoint, rilevamento di rete, threat intelligence e monitoraggio al di fuori dell'orario di lavoro o tramite un servizio gestito.

La dichiarazione di Nazarov nel comunicato stampa è lo stesso argomento in una frase: gli attaccanti «hanno usato un agente AI basato su CyberStrikeAI per eseguire una catena di attacco completa e adattare i propri passaggi successivi all’interno delle reti compromesse», ma «il framework si basava ancora su tecniche e procedure familiari, tra cui discovery, credential dumping, movimento laterale e raccolta ed esfiltrazione».

Che cosa è stabilito e che cosa non lo è

Detto chiaramente: il meccanismo è documentato a un livello che consentirebbe a un difensore di dargli la caccia già domani — l'ascendenza dei processi da sqlservr.exe, un'attività pianificata denominata SystemUpdate, l'accesso a LSASS tramite comsvcs.dll, DCSync da un controller non di dominio, l'intestazione HTTP X-Implant-Token e gli indirizzi C2 elencati da Kaspersky. La campagna attorno a quel meccanismo non lo è. Kaspersky non ha pubblicato alcun elenco delle vittime, alcuna ripartizione per paese, alcuna stima del volume di dati e alcun attore. Tutto ciò che un lettore potrebbe voler sapere su chi è stato colpito e quanto gravemente si ferma al settore e alla regione.

Due dettagli meritano di essere segnalati a chiunque consulti il report aspettandosi di più. Innanzitutto, Kaspersky descrive l'attacco come «una delle prime descrizioni pubbliche di una compromissione che coinvolge un LLM in the wild» anziché come la prima — una cautela che limita l'affermazione a ciò che il team è riuscito a trovare nei resoconti pubblici. In secondo luogo, il report osserva che la versione dell'impianto non segue quella del server, che le configurazioni dei listener e le chiavi sopravvivono agli aggiornamenti degli operatori e che la data di build di un campione fornisce solo la data di distribuzione più anticipata possibile, non la durata di una compromissione. La cifra di 3–4 giorni è la misurazione di un singolo incidente ricostruito, non un limite a quanto a lungo una qualsiasi di queste intrusioni sia rimasta attiva prima che qualcuno se ne accorgesse.