Un nuovo elemento sta cambiando il modo in cui nascono e si muovono gli attacchi ransomware: l’uso di assistenti AI per eseguire attività operative dentro le reti compromesse. Secondo analisi pubblicate il 31 agosto 2026, operatori collegati al ransomware Aurora avrebbero impiegato Cursor per supportare ricognizione, movimento laterale ed exploit su più bersagli tra aprile e luglio 2026.
Per un’azienda italiana il punto non è “l’AI è il problema”, ma che gli attaccanti possono lavorare più velocemente, provare più varianti e automatizzare compiti che prima richiedevano più esperienza. In pratica, anche intrusioni condotte da gruppi non necessariamente sofisticatissimi possono diventare più efficaci.
Che cosa è successo
Le informazioni arrivano da due analisi indipendenti, di CloudSEK e Gambit Security, basate su infrastrutture esposte associate al gruppo Aurora, noto anche come Aur0ra. Dalle evidenze emerse, il gruppo avrebbe utilizzato Cursor, un assistente di coding basato su AI, durante diverse fasi delle operazioni offensive.
CloudSEK riferisce che una directory aperta ha esposto mesi di attività del gruppo, attive contro più di 20 organizzazioni in nove Paesi tra aprile e luglio 2026. Quattro di queste vittime sarebbero poi comparse sul sito di data leak del gruppo. Gambit Security, dal canto suo, afferma di aver osservato l’uso di Cursor Agent contro 10 bersagli tra l’8 aprile e il 21 maggio 2026.
Aurora non è un nome del tutto nuovo. I primi dettagli pubblici sul gruppo erano emersi a fine maggio 2026. I dati citati dalla fonte indicano inoltre 33 vittime censite da Ransomware.Live in Paesi come Stati Uniti, Germania, Paesi Bassi, Canada e Regno Unito.
Perché questa notizia conta davvero
Il fatto più importante non è solo che un gruppo ransomware abbia usato uno strumento AI, ma come lo abbia usato. Non stiamo parlando di un chatbot impiegato per scrivere email generiche: qui l’assistente sarebbe stato coinvolto in compiti tecnici concreti, con istruzioni operative e correzioni successive quando il primo tentativo non funzionava.
In altre parole, l’AI diventa un “collaboratore” dell’attaccante. Questo riduce il tempo necessario per:
- configurare strumenti di accesso remoto;
- eseguire scansioni della rete interna;
- capire quali privilegi ha un utente compromesso;
- suggerire i prossimi passi di attacco;
- adattare comandi e script finché non producono il risultato desiderato.
Per le aziende significa un aumento del ritmo degli attacchi. Un criminale che prima avrebbe impiegato più tempo per preparare script, correggere errori o consultare documentazione tecnica oggi può delegare una parte di queste attività a un agente AI.
Come si è mosso Aurora
Le fonti descrivono una catena di attacco molto concreta. In un caso riportato in precedenza da Black Hills Information Security, l’accesso iniziale sarebbe avvenuto con una combinazione di email bombing aggressivo e telefonate ai dipendenti, con i criminali che si spacciavano per l’help desk IT. Lo scopo era convincere il personale a consentire un accesso remoto tramite Xray-core, un’utility open source.
Una volta ottenuto un punto d’appoggio, l’attacco proseguiva con movimento laterale e abuso di strumenti e protocolli amministrativi comuni, tra cui SMB, LDAP, WinRM, RDP e RPC. L’obiettivo era arrivare ad account con privilegi elevati, eludere i controlli, cancellare tracce, disabilitare Microsoft Defender, sottrarre dati sensibili e infine avviare la cifratura.
Secondo Gambit Security, l’agente AI sarebbe stato incaricato di attività come:
- installare e configurare un client VPN o proxychains;
- collegarsi a una vittima usando credenziali fornite o tunnel SOCKS già disponibili;
- scandire sottoreti interne con Nmap o NetExec;
- enumerare il dominio e verificare i privilegi di un utente;
- tentare attacchi NTLM relay con strumenti come PetitPotam, Coerce Plus, PrinterBug e ntlmrelayx;
- eseguire attacchi basati su certificati con Certipy.
Un aspetto interessante è che molti comandi non avrebbero funzionato al primo tentativo. L’agente avrebbe quindi proposto aggiustamenti, nuove opzioni o passi successivi. Questo è esattamente il punto di svolta: non una magia infallibile, ma una capacità di iterare rapidamente.
Windows, Linux ed ESXi: il rischio non riguarda solo i PC
CloudSEK ha identificato versioni di Aurora per Windows e per Linux, scritte in Zig. Le due varianti deriverebbero dalla stessa base di codice, compilata per target diversi. È un dettaglio tecnico, ma con un impatto pratico chiaro: il gruppo punta a colpire ambienti eterogenei, non soltanto i classici computer Windows.
La variante Windows sarebbe in grado di ostacolare il ripristino cancellando le copie shadow e disabilitando il Ripristino configurazione di sistema tramite Registro. La variante Linux/ESXi, invece, tenterebbe di spegnere forzatamente tutte le macchine virtuali presenti sull’host prima di cifrare.
Questo è un segnale importante per qualsiasi azienda che lavori con server virtualizzati VMware. Se il ransomware raggiunge l’host o i sistemi di gestione, il danno può essere molto più esteso di una singola postazione: si rischia di fermare in un colpo solo più servizi, gestionali, file server e macchine applicative.
Le fonti citano inoltre uno script Python, chiamato “esxi_finder.py”, usato per cercare hypervisor VMware ESXi e server vCenter all’interno della rete della vittima.
Il modello economico dietro gli attacchi
Le analisi riportano anche elementi sul funzionamento economico di Aurora. Sarebbero stati individuati wallet di criptovaluta e una ripartizione dei riscatti tra affiliati e operatori principali. La quota degli affiliati, secondo quanto riportato, varierebbe dal 54% al 79%, con il resto destinato agli amministratori del programma.
Questo dato è utile perché conferma una realtà nota del ransomware moderno: spesso non esiste un singolo “hacker”, ma un ecosistema organizzato. C’è chi sviluppa il malware, chi fornisce infrastruttura, chi gestisce la negoziazione e chi materialmente conduce l’intrusione presso la vittima. Se in questo ecosistema entra anche l’AI come supporto operativo, la barriera d’ingresso può abbassarsi ulteriormente.
Non è l’AI a creare il rischio: è la combinazione con errori umani e sistemi esposti
La notizia può indurre a pensare che il problema sia lo strumento AI in sé. In realtà, dalle informazioni disponibili emerge un quadro più tradizionale: i criminali sfruttano accessi già ottenuti, credenziali, social engineering, strumenti amministrativi e carenze di segmentazione o monitoraggio.
L’AI accelera e semplifica, ma non sostituisce i punti deboli già noti delle aziende:
- utenti convinti con telefonate credibili;
- accessi remoti non governati con rigore;
- privilegi eccessivi;
- log non monitorati;
- protezioni disattivabili con troppa facilità;
- infrastrutture virtuali non isolate a sufficienza;
- backup non realmente separati dall’ambiente di produzione.
Per questo la risposta non è vietare genericamente l’AI, ma rafforzare disciplina operativa, difese e capacità di ripristino.
Cosa significa per la tua azienda
Per una PMI italiana il messaggio è semplice: aspettarsi attaccanti più rapidi, più adattabili e capaci di “improvvisare” meglio dentro la rete. La contromisura deve essere altrettanto pratica.
Primo: rivedi il fattore umano. Se i criminali usano email bombing e telefonate fingendosi supporto tecnico, serve una regola chiara: nessun dipendente deve autorizzare installazioni, accessi remoti o modifiche urgenti solo su richiesta telefonica. Ogni intervento IT va verificato con un canale interno noto.
Secondo: limita i privilegi. Un account utente non deve poter aprire la strada all’intera infrastruttura. Segmentazione di rete, account amministrativi separati, MFA dove possibile e accessi privilegiati concessi solo quando necessari riducono molto l’impatto di un’intrusione.
Terzo: proteggi in modo specifico i server virtuali e i sistemi di backup. Se una variante punta a ESXi e alle macchine virtuali, il backup deve essere isolato, testato e non facilmente raggiungibile con le stesse credenziali dell’ambiente produttivo. Su questo tema ha senso valutare soluzioni di remote backup progettate per garantire continuità e recuperabilità.
Quarto: controlla gli strumenti di amministrazione remota e i protocolli interni. SMB, RDP, WinRM e utility legittime sono spesso la “strada principale” del movimento laterale. Vanno esposti il minimo indispensabile, monitorati e protetti con criteri rigorosi.
Quinto: investi nella prevenzione operativa, non solo nell’antivirus. Oggi servono controllo degli endpoint, gestione continua delle postazioni, aggiornamenti, policy e verifiche periodiche. Un servizio strutturato di sicurezza informatica o di presidio continuativo può fare la differenza soprattutto dove il reparto IT è piccolo o assente.
Sesto: prepara una procedura d’emergenza. Sapere chi chiamare, come isolare un PC, come disconnettere una macchina sospetta dalla rete e come comunicare internamente nelle prime ore riduce i tempi di reazione. Le aziende che improvvisano durante l’incidente quasi sempre subiscono danni maggiori.
Infine, se gestisci molte postazioni e utenti, conviene strutturare meglio governance e manutenzione quotidiana con un approccio di desktop IT management: patching, configurazioni coerenti, controllo del software installato e riduzione delle eccezioni sono ancora tra le difese più efficaci.
Domande frequenti
Aurora ha “automatizzato” completamente gli attacchi con l’AI?
No. Le fonti descrivono un uso dell’AI come supporto operativo: suggerimenti, esecuzione di compiti, correzione di comandi e pianificazione tecnica. L’attaccante umano resta centrale.
Le PMI sono davvero nel mirino o è un problema da grandi aziende?
Le PMI sono esposte eccome, soprattutto se hanno processi poco formalizzati, backup deboli, accessi remoti non governati o personale non formato contro il social engineering.
Qual è la priorità più urgente da verificare subito?
Backup isolati e testati, regole chiare sugli accessi remoti richiesti per telefono o email, e revisione dei privilegi amministrativi. Sono tre controlli concreti che riducono subito il rischio.