Vibe coding e pacchetti npm infetti: quando Malware IA e la supply chain ti svuotano i wallet

🛡️ Executive Summary

• Uno script PowerShell generato con IA enumera Active Directory dopo un accesso RDP ottenuto tramite credenziali precedentemente compromesse.
• Versioni malevole di jscrambler distribuiscono un infostealer Rust multipiattaforma durante npm install o l’esecuzione del pacchetto.
• La difesa richiede rilevamento comportamentale, controllo degli script PowerShell, verifica delle dipendenze e protezione dei segreti nelle pipeline CI.

Due operazioni distinte mostrano come l’intelligenza artificiale e la compromissione della software supply chain stiano modificando strumenti e modalità del cybercrime. Nel primo caso, un attore entrato in un server Windows tramite RDP ha distribuito uno script PowerShell apparentemente generato attraverso vibe coding per enumerare in modo aggressivo l’intero ambiente Active Directory, raccogliendo utenti, computer, gruppi, subnet, trust e informazioni sul dominio. Nel secondo, versioni compromesse del pacchetto npm jscrambler hanno distribuito un infostealer Rust multipiattaforma destinato a workstation di sviluppatori, sistemi di build e pipeline CI, con capacità di sottrarre wallet, chiavi cloud, configurazioni di assistenti AI, token di messaggistica e credenziali dei browser. Le due minacce riducono l’efficacia dei controlli basati esclusivamente su firme e hash: gli script generati dall’AI risultano unici, mentre i pacchetti compromessi sfruttano la fiducia riposta nei repository pubblici. La risposta deve quindi concentrarsi sui comportamenti osservabili, dall’enumerazione massiva del dominio all’esecuzione di hook di installazione e all’accesso anomalo ai segreti.

L’accesso RDP precede l’enumerazione completa di Active Directory

L’incidente legato al malware generato con AI è iniziato all’inizio di giugno 2025, quando un attore malevolo ha utilizzato credenziali già compromesse per collegarsi tramite Remote Desktop Protocol a un server Windows unito al dominio. L’accesso potrebbe essere transitato attraverso una connessione VPN, permettendo all’operatore di apparire come un utente autorizzato e di raggiungere direttamente una macchina con visibilità sull’infrastruttura interna. Gli strumenti sono stati depositati nella directory C:\ProgramData\, percorso spesso utilizzato per nascondere file sotto una cartella di sistema apparentemente legittima. Entro pochi minuti è stato eseguito lo script C:\ProgramData\Untitled1.ps1, progettato per raccogliere una quantità estesa di informazioni sul dominio. Circa 30 minuti più tardi l’attore ha aggiunto s5cmd.exe, utility ad alte prestazioni per trasferimenti verso Amazon S3, frequentemente abusata durante operazioni di esfiltrazione. È seguito SharpShares.exe, impiegato per individuare condivisioni accessibili agli utenti ed escludere le comuni share amministrative, preparando la ricerca di dati utili prima del trasferimento all’esterno.

Lo script individua il Domain Controller con cinque metodi differenti

Il comportamento di Untitled1.ps1 rivela un livello di automazione superiore a quello necessario per una semplice ricognizione. Dopo aver cancellato lo schermo e visualizzato un titolo in colore ciano, lo script identifica il dominio interrogando Win32_ComputerSystem tramite Get-WmiObject. Per localizzare il Domain Controller utilizza cinque procedure in cascata: tenta inizialmente una risoluzione DNS con System.Net.Dns.GetHostEntry, esegue poi nltest /dclist, importa il modulo ActiveDirectory e richiama Get-ADDomainController -Discover, legge la variabile LOGONSERVER e, come ultima opzione, utilizza il valore hardcoded Server1.HR.local. La presenza di cinque tecniche ridondanti aumenta la probabilità di successo in ambienti configurati in modo diverso, ma rappresenta anche un esempio evidente di over-engineering. Un operatore esperto avrebbe probabilmente selezionato uno o due metodi affidabili, mentre un modello linguistico tende a produrre procedure più estese per coprire ogni eventualità. Lo script verifica inoltre la disponibilità del modulo Active Directory, suggerisce l’installazione degli strumenti RSAT quando assenti e testa la raggiungibilità del controller attraverso Test-Connection.

Utenti, gruppi, computer e trust vengono esportati in CSV

Una volta identificato il dominio, lo script crea una directory con nome C:\AD_Reports_yyyyMMdd_HHmmss e avvia una ricognizione sistematica. Per gli account utilizza Get-ADUser -Filter * -Properties * ed esporta in AD_Users.csv campi come stato Enabled, nome canonico, SamAccountName, gruppi di appartenenza, azienda e ruolo. I computer vengono raccolti tramite Get-ADComputer, includendo nome, indirizzo IPv4, sistema operativo e hostname DNS. Con Get-ADGroup vengono censiti gruppi, categoria, identificativo e membri, mentre Get-ADOrganizationalUnit produce l’inventario delle unità organizzative. La raccolta prosegue con Get-ADReplicationSubnet per le subnet e Get-ADTrust per i rapporti di trust, informazioni particolarmente rilevanti per individuare percorsi di movimento laterale tra domini. Lo script crea anche un elenco degli utenti dotati di indirizzo email, un file semplificato degli account e un report dedicato alle informazioni generali del dominio. Questa quantità di dati consente a un attaccante di ricostruire rapidamente la struttura aziendale, selezionare account privilegiati, individuare server critici e comprendere le relazioni tra reti e foreste.

DNS, report HTML e archivi ZIP preparano l’esfiltrazione

La ricognizione non si limita agli oggetti Active Directory. Lo script interroga il server DNS per i record di tipo A, ricava le subnet /24 e salva i risultati in DNS_Subnets.txt, ampliando la mappa della rete con indirizzi e sistemi potenzialmente raggiungibili. Genera inoltre Domain_Info.csv, contenente dominio, controller, computer locale, utente in esecuzione, data e versione dello script. Al termine crea AD_Report.html, un report con stile CSS che riassume l’ambiente e indica le dimensioni dei file prodotti. L’intera directory viene poi compressa in un archivio ZIP, semplificando il trasferimento con strumenti come s5cmd. La generazione di un report graficamente curato non è necessaria per un’operazione offensiva, ma riflette una delle caratteristiche tipiche del codice prodotto con assistenti generativi: l’aggiunta di output leggibili, colori, layout e funzioni accessorie. Dal punto di vista dell’attaccante, tuttavia, il risultato resta operativo perché concentra in un unico pacchetto informazioni sufficienti per pianificare escalation, persistenza ed esfiltrazione.

Il vibe coding emerge da artefatti e ridondanze del codice

Diversi elementi indicano che lo script sia stato prodotto mediante vibe coding, processo nel quale il software viene sviluppato attraverso richieste iterative in linguaggio naturale. Il titolo “100% Working AD Information Gathering Script – FULLY FIXED”, associato alla versione v3.0, suggerisce una sequenza di prompt, correzioni e nuove generazioni fino al raggiungimento di un risultato funzionante. Il fallback Server1.HR.local appare come un valore di esempio non rimosso, tipico degli output di un modello linguistico adattati frettolosamente. Anche i numerosi blocchi try/catch, la ripetizione della stessa struttura per ogni comando e l’uso frequente di Write-Host con colori differenti richiamano boilerplate generato automaticamente. L’intelligenza artificiale non ha inventato una nuova tecnica: l’enumerazione di Active Directory è un’attività consolidata. Ha però permesso a un attore potenzialmente poco sofisticato di ottenere rapidamente uno strumento personalizzato, completo e non associato agli hash o alle stringhe dei framework pubblici più conosciuti.

Il rilevamento deve concentrarsi sull’enumerazione e non sulla firma

Gli script generati con AI rappresentano una difficoltà per i sistemi che dipendono da indicatori statici. Un file creato per una singola operazione può non essere mai stato osservato prima e potrebbe non essere riutilizzato nella stessa forma, riducendo l’efficacia di hash, firme e regole fondate su stringhe specifiche. Il comportamento fondamentale resta però riconoscibile: esecuzione di PowerShell, caricamento del modulo ActiveDirectory, interrogazioni massive con Get-ADUser, Get-ADComputer, Get-ADGroup e Get-ADTrust, creazione di numerosi CSV e compressione dei risultati. Il logging di PowerShell, incluso l’Event ID 4104, può mostrare il contenuto degli script eseguiti, mentre la telemetria EDR può correlare RDP, staging in ProgramData, enumerazione LDAP, creazione dell’archivio e avvio di s5cmd. La difesa deve quindi riconoscere il ciclo operativo dell’attacco anche quando la sintassi, i nomi delle variabili e la struttura del file risultano completamente nuovi.

jscrambler viene compromesso con più versioni malevole su npm

Il secondo incidente riguarda la compromissione del pacchetto npm jscrambler, che registra circa 15.800 download settimanali. L’11 luglio 2026 è stata pubblicata la versione malevola 8.14.0, seguita in circa tre ore dalle release 8.16.0, 8.17.0, 8.18.0 e 8.20.0. La versione 8.22.0 risulta invece pulita. La rapidità della sequenza suggerisce un tentativo di aggiornare, adattare o distribuire il payload mantenendo l’apparenza di una normale attività di manutenzione. Il rischio è particolarmente elevato perché l’installazione di un pacchetto npm può avvenire automaticamente su workstation, container di build e pipeline di integrazione continua. In questi ambienti il processo dispone spesso di accesso a token dei repository, credenziali cloud, chiavi di firma e variabili usate per il deployment. Il malware non deve quindi compromettere direttamente l’applicazione finale: è sufficiente eseguirsi nel contesto privilegiato del sistema di sviluppo.

L’hook preinstall attiva il payload prima dell’applicazione

Nella versione 8.14.0, l’attaccante ha aggiunto al file package.json un hook preinstall non documentato che esegue node dist/setup.js. Questo meccanismo viene avviato automaticamente durante npm install, prima che il pacchetto venga importato o utilizzato dall’applicazione. Il loader dist/setup.js legge il container dist/intro.js, grande circa 7,8 MB, dotato di un header personalizzato di cinque byte e del numero di payload contenuti. All’interno sono presenti tre binari compressi con gzip: un eseguibile ELF Linux x86-64, un file PE32+ Windows x86-64 e un binario Mach-O macOS arm64 per Apple Silicon.

Lo script seleziona la variante coerente con il sistema operativo, la estrae in un file nascosto con nome casuale nella directory temporanea, assegna i permessi di esecuzione e la avvia in modalità detached con input e output ignorati. La vittima non deve quindi lanciare esplicitamente alcun comando del pacchetto per subire l’infezione.

Le versioni successive spostano il dropper nei file principali

Nelle release successive l’hook preinstall viene rimosso, ma la logica malevola non scompare. Il dropper viene inserito come funzione autoeseguente all’inizio di dist/index.js e dist/bin/jscrambler.js, attivandosi quando il modulo viene importato o quando viene eseguita la relativa interfaccia a riga di comando. La modifica può essere interpretata come un tentativo di ridurre la visibilità dell’attacco, perché gli hook di installazione vengono spesso controllati dagli strumenti di sicurezza della supply chain. Alcune versioni dichiarano inoltre una dipendenza verso se stesse, meccanismo utilizzato per trascinare transitivamente altre release compromesse. Questa evoluzione mostra una gestione attiva della campagna e un adattamento ai possibili controlli, con più percorsi di esecuzione pensati per raggiungere sia sviluppatori locali sia ambienti CI automatizzati.

L’infostealer Rust cifra le stringhe e comunica tramite TLS

Il payload finale è un infostealer multipiattaforma scritto in Rust, dotato di protezioni avanzate contro l’analisi. Ogni stringa sensibile viene cifrata separatamente con ChaCha20-Poly1305 IETF, utilizzando una chiave da 32 byte, un nonce da 12 byte e un tag Poly1305 da 16 byte. I valori vengono decifrati soltanto quando necessari, riducendo la quantità di indicatori leggibili nel file. L’esfiltrazione avviene tramite connessioni TLS implementate con rustls e richieste HTTP POST /upload con corpo multipart/form-data. Il malware interagisce inoltre con API di servizi cloud e piattaforme di orchestrazione, ampliando la raccolta oltre i file locali. L’uso di Rust facilita la compilazione di binari nativi per più sistemi operativi e offre all’attaccante un singolo codebase capace di colpire ambienti Windows, Linux e macOS.

Wallet, assistenti AI e credenziali cloud sono i bersagli principali

L’infostealer cerca dati appartenenti a MetaMask, Trust Wallet, Coinbase Wallet, Phantom ed Exodus, includendo chiavi HD Tree, mnemonic, seedPhrase e recovery phrase. Il furto di questi elementi consente l’accesso diretto ai fondi senza necessità di compromettere ulteriormente il dispositivo. Il malware raccoglie inoltre configurazioni di Claude Desktop, Cursor, Windsurf, Factory, Zed e Visual Studio Code, con particolare interesse verso chiavi API e credenziali di server Model Context Protocol. Sul fronte cloud raggiunge endpoint metadata di AWS, Google Cloud e Microsoft Azure, tentando di ottenere token di service account, segreti, parametri SSM e dati presenti nei Secret Manager. Vengono colpiti anche Discord, Slack, Telegram Desktop, browser Chromium e Firefox, Steam e keyring come KDE KWallet. La workstation dello sviluppatore diventa così un concentratore di credenziali capace di aprire accessi verso repository, infrastrutture cloud, sistemi di comunicazione e asset finanziari.

Persistenza ed escalation ampliano l’impatto nelle pipeline

Il malware tenta l’escalation locale mediante sudo e systemd-run, stabilendo persistenza con unità systemd, crontab e LaunchAgents su macOS. Esegue inoltre fingerprinting della macchina e controlli verso resolver DNS pubblici per valutare la connettività. In una pipeline CI, il danno può essere maggiore rispetto a una normale workstation: il processo npm può disporre di token per pubblicare pacchetti, credenziali di deployment, accesso a cluster, registri container e ambienti di produzione. L’esecuzione durante l’installazione significa che il codice dell’applicazione non deve mai importare jscrambler affinché la compromissione avvenga. Il semplice aggiornamento della dipendenza può quindi esporre segreti e permettere un pivot verso infrastrutture più ampie.

La difesa deve unire controllo comportamentale e sicurezza delle dipendenze

I due incidenti dimostrano che strumenti personalizzati generati con AI e pacchetti compromessi richiedono controlli complementari. Negli ambienti Windows è necessario limitare RDP e VPN con autenticazione forte, monitorare accessi anomali e attivare logging avanzato di PowerShell, LDAP e processi. Nelle pipeline software occorre bloccare versioni compromesse, verificare lockfile e provenienza dei pacchetti, disabilitare gli script di installazione quando non necessari e isolare i job con credenziali minime. I segreti non dovrebbero essere esposti permanentemente al processo npm e devono essere ruotati quando una dipendenza malevola viene eseguita. Il cambiamento più importante riguarda il modello di rilevamento: la difesa non può dipendere dall’aspetto del codice, ma deve riconoscere enumerazione massiva, esecuzione di binari temporanei, accesso ai wallet, interrogazione dei metadata cloud e trasferimenti anomali. L’AI rende più semplice produrre strumenti unici, mentre la supply chain consente di distribuirli attraverso canali fidati; i comportamenti dell’attacco, tuttavia, restano osservabili e devono diventare il centro delle attività di detection e response.