Aurora, il ransomware che usa Cursor: mesi di attacchi progettati con Claude Sonnet

La directory aperta di un’infrastruttura riconducibile al gruppo Aurora ha permesso a CloudSEK e Gambit Security di ricostruire mesi di attività: oltre venti organizzazioni colpite tra aprile e luglio 2026, dieci obiettivi contro cui è stato usato l’agente di Cursor e un encryptor scritto in Zig per Windows, Linux ed ESXi. Le cronologie di chat recuperate mostrano che l’operatore pianificava gli attacchi in russo e affidava a Claude Sonnet compiti operativi concreti, non solo generici script.

L’esposizione dell’infrastruttura e le vittime censite

CloudSEK ha individuato una directory aperta che ha lasciato in vista mesi di attività del gruppo di lingua russa noto come Aurora o Aur0ra. Nei dati figurano più di venti organizzazioni in nove Paesi, attaccate tra aprile e luglio 2026; quattro vittime sono poi comparse sul sito di fuga dati del gruppo. L’operatore usava Cursor per pianificare gli attacchi in russo, escludendo senza eccezioni indirizzi IP e domini dei Paesi della Comunità degli Stati Indipendenti.

Aurora è emerso pubblicamente a fine maggio 2026, quando CYFIRMA ne descriveva gli attacchi rivolti soprattutto a sistemi Windows e un continuo aggiornamento delle funzionalità. Secondo il sito Ransomware.Live, al 31 agosto 2026 le vittime censite sono 33, concentrate soprattutto in Stati Uniti, Germania, Paesi Bassi, Canada e Regno Unito.

I nomi delle aziende colpite non sono stati divulgati dalle società di sicurezza, ma Reuters ha indicato Christeyns, Teckentrup, Helideck Certification Agency, Bayou Title, un distributore farmaceutico argentino e un produttore italiano.

La catena di attacco dall’email bombing all’encryptor

Black Hills Information Security ha ricostruito un caso all’inizio di agosto 2026. L’accesso iniziale è stato ottenuto con un email bombing aggressivo, seguito da telefonate in cui l’attaccante si fingeva personale dell’help desk IT. Dopo aver convinto la vittima, il gruppo ha stabilito accesso remoto attraverso Xray-core, utility open-source.

Da lì la catena prosegue con movimento laterale tramite SMB, LDAP, WinRM, RDP e RPC, acquisizione di account amministratore ad alto privilegio, cancellazione dei log e disabilitazione di Microsoft Defender. Solo dopo arrivano l’esfiltrazione dei dati sensibili e la distribuzione dell’encryptor.

Come l’operatore usa Cursor Agent nei dieci obiettivi

Gambit Security ha osservato l’operatore Aurora usare Cursor Agent, che esegue Claude Sonnet di Anthropic, per attività pratiche di sfruttamento contro dieci obiettivi tra l’8 aprile e il 21 maggio 2026. In questi casi all’agente venivano fornite credenziali o una via d’accesso già esistente verso l’organizzazione vittima, poi venivano assegnati compiti di exploitation.

A volte l’attaccante chiedeva all’agente soltanto di raggiungere un obiettivo, per esempio «dimmi quali diritti ha l’utente». In altri casi indicava lo strumento da usare o imponeva di seguire un piano di attacco pre-generato. In alcune situazioni l’agente proponeva un elenco di passi successivi e l’attaccante rispondeva con un numero.

I compiti delegati includevano:

• installazione di un client VPN o di proxychains, configurazione e connessione alla vittima con credenziali fornite o attraverso un tunnel SOCKS esistente;
• scansione delle sottoreti interne con Nmap o NetExec;
• enumerazione del dominio per riferire i privilegi di un utente specifico, usando il collector BloodHound di NetExec;
• tentativi di attacco NTLM relay forzando l’autenticazione con PetitPotam, Coerce Plus e PrinterBug, usando Impacket ntlmrelayx per inoltrare l’autenticazione risultante;
• attacchi ai certificati con Certipy.

La maggior parte dei comandi non raggiungeva l’obiettivo al primo tentativo: servivano rifiniture continue a comandi e script. Alcuni alla fine riuscivano, altri fallivano e restituivano all’attaccante solo un report dei tentativi.

Le cronologie chat mostrano anche un piano completo di sfruttamento di Active Directory Certificate Services scritto in russo, segno che Cursor veniva usato per progettare intere fasi della campagna.

L’encryptor Zig condiviso tra Windows, Linux ed ESXi

CloudSEK ha identificato versioni Windows e Linux di Aurora scritte in Zig. I due binari — sap.exe per Windows e encrypt.out per Linux/ESXi — sono build statiche derivate da un’unica codebase Zig compilata per target diversi, non una riscrittura separata. Il binario Windows contiene al suo interno esempi d’uso della build Linux, residuo di un albero sorgente condiviso.

La variante Windows impedisce il ripristino del sistema eliminando le shadow copy di volume e disabilitando il Ripristino configurazione direttamente tramite Registro. La variante Linux/ESXi tenta invece di terminare forzatamente ogni singola macchina virtuale presente sull’host prima di avviare la cifratura.

Nelle campagne che coinvolgono la versione Linux è stato usato uno script Python chiamato esxi_finder.py per individuare hypervisor VMware ESXi e server vCenter nella rete vittima.

Una chiave recuperata dall’encryptor avrebbe consentito di accedere a una negoziazione di riscatto e a un cluster di quattro portafogli di criptovaluta. I dati mostrano ripartizioni variabili: gli affiliati ricevono tra il 54% e il 79% del riscatto, quota decisa per singola vittima in base all’importo richiesto e ai ricavi dell’organizzazione; il resto va agli amministratori.

Gryxa, il toolkit costruito dall’AI contro 324 host

ReliaQuest ha scoperto un toolkit distinto, chiamato Gryxa, usato da un attore finanziariamente motivato per un’operazione di accesso iniziale contro 324 host. Secondo i ricercatori, è il primo caso osservato in cui l’AI ha costruito l’intera operazione, dal toolkit alla console di gestione.

Gryxa trasforma software legittimo di remote monitoring and management in accesso occulto, mantiene la persistenza con meccanismi di riavvio indipendenti e ruba credenziali salvate nei browser basati su Chromium. Quando la connessione con l’attaccante si interrompe, tenta di disabilitare o disinstallare l’agente di protezione endpoint, per esempio Microsoft Defender, entro 10-13 minuti. Quando il relay torna raggiungibile, riabilita Defender.

Le evidenze indicano che l’attore ha eseguito il jailbreak di un agente di codifica AI, presentando lo sviluppo come un «deployment interno autorizzato». Il toolkit viene probabilmente distribuito via email di phishing; una volta eseguito, imposta la persistenza con attività pianificate e può aggirare le protezioni app-bound encryption di Chromium. Le credenziali raccolte vengono trasmesse via Telegram.

L’aspetto più insolito è la registrazione delle attività di remediation: dopo la rimozione dell’impianto RMM visibile, un componente nascosto raccoglie log Windows e artefatti dell’host e li carica sull’infrastruttura dell’attaccante. La console include un job predefinito chiamato collect-forensics, il che indica una capacità di routine, non una risposta a un singolo incidente. Gryxa ruota i file di log quando superano i 200 KB, preservando l’attività recente per chi risponde rapidamente.

Difesa: cosa cercare e perché i guardrail non bastano

Non risultano raccomandazioni di mitigazione specifiche pubblicate dai ricercatori. Il quadro tecnico offre comunque indicatori utili per i difensori: traffico verso Xray-core, presenza di Nmap, NetExec, BloodHound, Certipy o Impacket ntlmrelayx, tentativi di attacco NTLM relay e modifiche anomale alle shadow copy o al Registro. Nel caso di Gryxa vanno monitorati i processi RMM non autorizzati, le attività pianificate sospette e l’invio di archivi via Telegram.

Il caso Aurora mostra che i guardrail dei fornitori di modelli AI non hanno impedito l’uso operativo di Cursor Agent. L’attaccante non ha dovuto scrivere exploit originali: ha fornito all’agente accessi già validi e lo ha guidato con obiettivi, numeri e piani pre-generati. Il rischio non è l’AI che diventa autonoma, ma l’AI che abbassa il costo di ogni singolo passo dentro una rete già compromessa.