CryptoJS espone wallet per 5,7 milioni, KHunt vive nei database Oracle

🛡️ Executive Summary

• CryptoJS ha generato seed phrase con appena 39 o 47 bit effettivi, permettendo attacchi brute force contro cinque applicazioni wallet.
• KHunt viene compilato dentro Oracle Database dopo una SQL injection ed esegue comandi Windows con privilegi SYSTEM senza lasciare normali eseguibili.
• Gli utenti devono migrare verso nuove seed sicure; le aziende devono limitare i privilegi JDBC e cercare oggetti Java KHUNT nei database.

Due incidenti mostrano come componenti legittimi e tecnologie consolidate possano trasformarsi in punti di compromissione difficili da riconoscere. Una debolezza introdotta dodici anni fa nel generatore casuale di CryptoJS ha reso prevedibili le seed phrase create da almeno cinque applicazioni wallet, consentendo il furto verificato di circa 5,7 milioni di dollari. In un’intrusione separata, un gruppo non identificato ha sfruttato una normale SQL injection per installare KHunt, toolkit di post-exploitation compilato direttamente dentro un database Oracle. Gli attaccanti hanno quindi raggiunto Windows con privilegi SYSTEM, copiato gli archivi delle credenziali e nascosto gli strumenti tra gli oggetti Java e PL/SQL del database.

CryptoJS riduceva miliardi di miliardi di chiavi a uno spazio enumerabile

La vulnerabilità interessa la funzione CryptoJS.lib.WordArray.random() nelle versioni precedenti alla 4.0.0, quando viene utilizzata per generare valori crittograficamente sensibili. La funzione adottava una variante del generatore pseudocasuale Multiply-With-Carry, inizializzata attraverso Math.random(), invece di affidarsi a una sorgente crittografica nativa del sistema operativo. Secondo la divulgazione tecnica del progetto Ill Bloom, una richiesta nominale di 128 bit di entropia produceva uno spazio effettivo di circa 2³⁹ possibilità, mentre una richiesta da 256 bit scendeva a circa 2⁴⁷. I valori restano elevati per un tentativo manuale, ma sono abbastanza piccoli da essere enumerati con hardware ordinario, soprattutto quando l’attaccante può derivare automaticamente le seed phrase BIP39, generare gli indirizzi associati e confrontarli con le blockchain pubbliche. L’advisory GHSA-rg76-677x-56q9 pubblicato dal manutentore di CryptoJS assegna alla debolezza una gravità Critical e un punteggio CVSS 9.0. La semplice presenza della libreria non rende però vulnerabile un’applicazione: il rischio esiste quando il generatore debole viene impiegato direttamente come sorgente di entropia per chiavi, seed o altri segreti.

Cinque wallet hanno generato recovery phrase prevedibili

La ricerca di Coinspect ha collegato il codice vulnerabile a RRWallet, Bexo Wallet, NanChat, Bitcoin Libre e Milo. RRWallet e Milo risultano fuori produzione e non dispongono di una correzione; NanChat ha risolto il problema nella versione 1.3.0, Bitcoin Libre nella versione 4 del luglio 2024 e Bexo dichiara una correzione nella versione 20.1.0, che al momento delle verifiche non risultava ancora disponibile nei principali store. L’analisi che identifica le applicazioni coinvolte combina codice sorgente, reverse engineering di vecchi APK e analisi delle transazioni on-chain. Uno dei percorsi di propagazione è stato individuato nel fork React Native ferrumnet/bip39, che aveva sostituito la generazione casuale nativa della libreria BIP39 originale con CryptoJS per evitare dipendenze specifiche della piattaforma. Il problema era già emerso nell’indagine Ill Bloom sui wallet crypto e sulle recovery phrase vulnerabili, ma l’attribuzione a CryptoJS chiarisce ora la causa comune che collegava applicazioni, reti e periodi differenti.

Gli attaccanti hanno sottratto almeno 5,69 milioni di dollari

Coinspect ha ricostruito due principali ondate di svuotamento. La prima, avvenuta il 27 maggio 2026, ha sottratto circa 3,14 milioni di dollari da 431 account. La seconda, osservata tra il 30 maggio e il 13 luglio, ha coinvolto 522 seed e causato perdite per altri 2,55 milioni, compreso un singolo trasferimento di circa 2,18 milioni di USDT dalla rete Tron. L’analisi complessiva ha individuato 2.114 seed e indirizzi associati su Bitcoin, Ethereum, Tron, Rootstock, Polygon e reti compatibili con l’Ethereum Virtual Machine. I 5.690.922 dollari rappresentano quindi una soglia minima verificata e non una stima dell’intera esposizione. Una seed generata dal codice vulnerabile rimane prevedibile anche dopo l’aggiornamento dell’applicazione e anche se viene importata in un hardware wallet. Hash, PBKDF2 e derivazioni successive non possono ricreare l’entropia mancante all’origine. L’unica misura efficace consiste nel generare una nuova recovery phrase attraverso una sorgente sicura e trasferire tutti gli asset verso i nuovi indirizzi. Il rischio si aggiunge alle minacce già osservate con OKOBot, capace di rubare direttamente le seed phrase associate a Trezor e Ledger, ma in questo caso non serve infettare il dispositivo: l’attaccante può ricostruire le chiavi offline analizzando lo spazio prevedibile.

Una correzione CryptoJS era stata introdotta e poi rimossa

La cronologia della libreria rende il caso particolarmente significativo. Il generatore debole era stato introdotto nel giugno 2014 con CryptoJS 3.1.2-4 per migliorare una precedente implementazione basata direttamente su Math.random(). Le versioni 3.2.0 e 3.2.1 avevano temporaneamente sostituito il codice con le API crittografiche native della piattaforma, ma la modifica era stata annullata nella versione 3.3.0 perché considerata incompatibile con alcuni ambienti. Un’applicazione che seguiva automaticamente gli aggiornamenti della serie 3.x poteva quindi passare da una versione corretta a una nuovamente vulnerabile. Solo CryptoJS 4.0.0, pubblicata nel febbraio 2020, ha ripristinato definitivamente l’uso della casualità crittografica nativa. La vicenda dimostra che una correzione di sicurezza non resta necessariamente acquisita quando viene trattata come una rottura di compatibilità e rimossa senza valutare tutti gli usi downstream. Gli sviluppatori devono controllare non soltanto la versione della dipendenza, ma il modo in cui la funzione viene utilizzata e l’origine effettiva dell’entropia. Nei software che gestiscono criptovalute, un errore del genere può restare invisibile per anni perché le seed generate hanno forma e lunghezza perfettamente valide.

KHunt viene compilato direttamente dentro Oracle Database

La seconda operazione è iniziata da un endpoint di ricerca autocomplete presente in un’applicazione Java pubblica eseguita su Apache Tomcat. Il campo non validava correttamente l’input e inoltrava le istruzioni SQL al database attraverso una connessione JDBC. Il 27 luglio 2026, Huntress ha rilevato attività di furto credenziali sul server e ha ricostruito le richieste provenienti dall’indirizzo 178.162.151[.]229. Dopo avere sfruttato la SQL injection, gli attaccanti hanno usato l’istruzione CREATE JAVA SOURCE per inserire e compilare KHunt come oggetto dello schema Oracle.

La ricostruzione tecnica dell’incidente pubblicata da Huntress sottolinea che Oracle integra una Java Virtual Machine e permette agli sviluppatori autorizzati di archiviare codice Java nel database. Gli aggressori hanno abusato della stessa funzione per evitare di caricare un normale eseguibile sul filesystem. La tecnica era già conosciuta teoricamente, ma risulta raramente documentata in attacchi reali.

Il toolkit trasforma il database in una testa di ponte Windows

KHunt comprende diversi oggetti Java e wrapper PL/SQL. KhuntCmd avvia cmd.exe e permette di eseguire comandi del sistema operativo attraverso query SQL; KhuntHash consulta le tabelle interne di Oracle e salva nomi utente e dati di autenticazione; KhuntFS e KhuntFS2 esplorano e leggono file; KhuntT verifica che il toolkit sia operativo; KhuntUnzip estrae archivi. Gli attaccanti hanno eseguito whoami attraverso KhuntCmd, verificando che il processo Oracle operasse con privilegi SYSTEM sul server Windows. Hanno poi usato PowerShell, reg.exe ed esentutl.exe per creare copie degli hive SAM, SECURITY e SYSTEM, dai quali possono essere estratti gli hash delle password degli account locali. È stato eseguito anche tasklist /svc, con il risultato salvato nel file khunttasks.txt per enumerare processi e servizi. Huntress non ha confermato l’effettiva esfiltrazione degli hive, ma la preparazione dei file dimostra una fase avanzata di credential dumping. L’uso di un database come deposito del toolkit riduce inoltre la visibilità di antivirus ed EDR, che analizzano normalmente processi, memoria e file del sistema operativo ma non ispezionano sistematicamente classi Java e procedure PL/SQL conservate negli schemi Oracle.

Privilegi JDBC e oggetti Java diventano controlli decisivi

La mitigazione parte dalla correzione dell’applicazione web e non da una patch specifica di Oracle, perché l’accesso iniziale deriva da una SQL injection causata dalla mancata parametrizzazione delle query. I dati ricevuti dagli utenti devono essere validati e le istruzioni SQL separate dai valori attraverso prepared statement. L’account utilizzato dalla connessione JDBC non dovrebbe poter creare sorgenti Java, eseguire procedure amministrative o raggiungere funzioni del sistema operativo. Gli amministratori devono cercare oggetti denominati KhuntCmd, KhuntHash, KhuntFS, KhuntFS2, KhuntT e KhuntUnzip, stringhe KHUNT% nei log SQL e file come khuntSAM.hiv, khuntSECURITY.hiv e khunttasks.txt. L’ultimo elemento comune tra KHunt e CryptoJS è la fiducia concessa a componenti che appaiono normali: un database autorizzato a compilare Java e una libreria crittografica utilizzata da anni possono diventare la parte meno osservata della catena. La ricerca conferma quanto già emerso con JadePuffer, che trasforma database MySQL esposti in piattaforme per ransomware e post-exploitation: il controllo non deve fermarsi al perimetro applicativo o alla dipendenza dichiarata, ma deve verificare quali poteri reali acquisiscono codice e account quando raggiungono il livello più interno del sistema.