Pluto Security illustra i dettagli della campagna di mining di criptovalute Load/Mine su Hugging Face

Il 29 ottobre 2026, il team di ricerca di Pluto Security ha pubblicato il suo rapporto su Load/Mine, rivelando una campagna di mining di criptovalute e backdoor diffusa tramite repository malevoli di modelli su Hugging Face. Il rapporto conta 31 repository malevoli distribuiti su sette account Hugging Face, oltre a un mirror su ModelScope, con 29.818 download registrati della campagna, che diventano 32.376 includendo 13 repository collegati. Pluto precisa che la cifra misura i download, non le infezioni confermate né le vittime uniche.

Secondo il rapporto, redatto da Shaked Chen, Eitan Chassid e Yotam Perkal, la campagna è ricomparsa pochi giorni dopo la rimozione iniziale: i 19 repository della seconda ondata hanno registrato oltre 29.000 download ed erano ancora attivi otto giorni dopo la segnalazione a Pluto. Il wallet dei pagamenti della prima ondata ha ricevuto circa 2.276 PRL, equivalenti a circa 5.000 dollari, in proventi del mining on-chain.

Come viene eseguito il codice malevolo

La campagna sfrutta un comportamento documentato del caricamento di Transformers, anziché pesi compromessi. Caricare un repository con trust_remote_code=True importa il codice Python del repository con i privilegi del chiamante prima che venga caricato qualsiasi peso. Il repository config.json usa auto_map per indicare il modulo e la classe Python da caricare; Transformers scarica il file indicato nella propria cache dei moduli, e la chiamata exec_module() esegue il codice di primo livello del file prima di restituire la classe del modello richiesta. Il rapporto precisa che si tratta di un comportamento documentato, non predefinito, e che le norme di sicurezza di Transformers invitano gli utenti a verificare il contenuto dei file di modellazione quando utilizzano l’argomento. Il rapporto cita inoltre CVE-2026-22807, relativo alle versioni di vLLM dalla 0.10.1 fino alla correzione introdotta nella 0.14.0, che caricavano auto_map moduli senza verificare l’impostazione trust_remote_code , consentendo a un repository malevolo di eseguire codice all’avvio del server.

Individuazione e collegamento degli account

Pluto ha creato uno scanner che esamina ogni .py file indicato da auto_map in un config.json, oltre ai file Python presenti accanto ai pesi dei modelli, segnalando schemi come subprocess, socket, ctypes, memfd_create e la decodifica base64. La prima segnalazione riguardava dsxk4mr8tq/qwen2-tiny-gpt2, che conteneva un file di 305 righe chiamato modeling_evil.py; l’account ospitava sei repository creati nell’arco di 2,5 ore il 12 ottobre 2026.

La svolta nell’attribuzione è arrivata grazie ai file di backup. Il qwen2-tiny-lite repository conteneva modeling_evil.py.bak-src e modeling_evil.py.bak-sync, versioni precedenti dello stesso malware, i cui URL di download non rimandavano all’account usa e getta, bensì a hhzz667 su Hugging Face e wssb123e su ModelScope. Secondo il rapporto, l’operatore ha copiato il codice di produzione in un account di test, ha aggiornato gli URL nel file principale e si è dimenticato dei backup. La prima ondata comprendeva in tutto 12 repository distribuiti su tre account e due piattaforme; prima della rimozione erano stati registrati oltre 700 download e nessuna segnalazione di sicurezza.

Anatomia del payload

Prendendo MENXIANGYU/qwen2-tiny come esempio rappresentativo, il rapporto descrive un payload che per prima cosa scrive /tmp/.cch/svc.py, un processo di sorveglianza che riavvia ogni 120 secondi un miner non più attivo, con hook di avvio aggiunti a /root/.bashrc, /root/.profile e al file .bashrcdell’utente. Tre versioni aggiungono una shell inversa che si connette a 212.32.253.3 sulle porte 443 o 9443, ritentando dopo ogni disconnessione.

Il binario del miner, syscore.bin, viene avviato tramite memfd_create e fexecve mascherato da processo worker del kernel kworker/u20:1, senza lasciare sul disco il percorso dell’eseguibile al primo avvio; una copia di riserva persiste in /tmp/.cch/sync. Il binario da 40,6 MB è compresso con UPX e presenta due marcatori UPX! modificati in PEK! , così che il normale strumento di decompressione lo rifiuti; Pluto ha ripristinato i marcatori e decompresso un miner chiamato peakminer, avviato con gli endpoint del pool e il login krxXJ2PKQW.worker. Le ricevute di avanzamento vengono scritte nel registro locale dei modelli di Xinference come qwen2-tiny- , seguite da codici di stato in base32; il payload rimuove inoltre le registrazioni dei miner concorrenti e termina i processi corrispondenti.

Due ondate e adattamento dopo la rimozione

Il rapporto riconduce la prima ondata all’account hhzz667, creato il 29 aprile 2026 e rimasto inattivo per cinque mesi. Il 21 settembre 2026 ha pubblicato qwen2-shell, una backdoor SSH di 37 righe che inseriva una chiave ed25519 in authorized_keys , con un segnale di attività diretto a un server Alibaba Cloud; il suo README era stato copiato dalla scheda ufficiale del modello Qwen2.5-0.5B. Entro il 22 settembre, l’operatore aveva distribuito qwen2-final, un miner senza file di 305 righe, camuffato da processo del kernel, dotato di un meccanismo per eliminare i miner concorrenti e di segnalazioni di stato Xinference con nomi innocui come Qwen2Config. I commenti nel codice erano in cinese semplificato.

Pluto ha segnalato la prima ondata a Hugging Face e ModelScope, e gli account sono stati rimossi. La seconda ondata è arrivata nel giro di pochi giorni: 19 repository distribuiti su cinque account, tra cui MENXIANGYU con 13 repository, oltre a wjsbg, soumikmahato, r1r13 e htt0118, quest’ultimo creato il 25 ottobre 2026. Un repository, MENXIANGYU/qa-whl-1021, pubblicato 8,5 ore dopo l’e-mail di segnalazione di Pluto, è uno script di evasione dal container all’host che monta i dischi dell’host e prende di mira la directory di GPUStack /var/lib/gpustack directory e consente l’accesso come root sull’host. Un dropper successivo limita la seconda fase in base all’IP di origine e restituisce agli altri richiedenti una risposta 403 con il testo «static ip.». Il repository di punta MENXIANGYU/qwen2-tiny è passato da 7.354 download il 20 ottobre a 28.412 il 28 ottobre, pari al 97,7% dei download della seconda ondata.

Proventi dell’attività di mining e vittime individuate

Il wallet della prima ondata ha ricevuto circa 2.276 PRL in 716 transazioni e ne ha trasferiti circa 2.241 PRL, ed era ancora attivo nei dashboard pubblici dei pool il 21 ottobre, dopo la rimozione dei repository. Su Kryptex, il wallet mostrava due worker online che segnalavano peakminer/2.16.5 con circa 1.008 PRL, pari a circa 2.237 $, in ricompense nell’arco di 30 giorni al momento dell’acquisizione. Durante l’analisi, nove worker con nomi simili a quelli dei notebook si sono connessi nell’arco di 90 secondi l’uno dall’altro e hanno smesso di inviare share circa sei minuti dopo: secondo il rapporto, un profilo coerente con un cluster GPU condiviso. Una famiglia monitorata separatamente hl che utilizzava un’esecuzione simile al momento dell’importazione mostrava un wallet MoneroOcean con 13 worker e circa 26 $ pagati nell’arco di circa un mese.

Lacune nella copertura degli scanner

Nessuno dei 12 repository della prima ondata è stato segnalato e il payload del repository di punta della seconda ondata modeling_evil2.py è risultato «sicuro» per tutti gli scanner eseguiti; secondo le verifiche di Pluto, JFrog ha indicato che non si trattava di un modello di machine learning. La documentazione di Hugging Face sulla scansione antimalware afferma che, a ogni commit, ogni file del repository di dimensioni inferiori a 2 GB viene sottoposto a una scansione antimalware. La documentazione di Hugging Face sulla scansione dei file pickle spiega che lo scanner esegue scansioni antivirus con ClamAV e scansioni degli import dei file pickle, che ClamAV non rileva gli exploit dei file pickle e che la scansione «non è infallibile al 100%»: la responsabilità di verificare la sicurezza ricade sull’utente. Pluto afferma che esaminare i .py file a cui un auto_map fa riferimento prima che venga impostato il flag avrebbe permesso di individuare tutti i payload della campagna e che un controllo statico al momento del caricamento di subprocess, socket, ctypes o le chiamate a IP grezzi nei auto_map-file referenziati avrebbe permesso di individuarli prima.

Valutazione dell’attribuzione e misure consigliate

Pluto ritiene che l’operatore, o il piccolo gruppo, fosse di lingua cinese e motivato da ragioni economiche. A sostegno di questa valutazione cita i commenti in cinese semplificato, un server di comando e controllo di Alibaba Cloud, la replica dei contenuti su ModelScope e hf-mirror.com, il targeting che presuppone l’uso di Xinference e Tencent Cloud e il raggruppamento delle attività tra le 18:38 e le 21:19 UTC. La build «parasit» di soumikmahato contiene commenti in indonesiano, cosa che, secondo il rapporto, è compatibile sia con un secondo operatore attivo nella stessa nicchia, sia con un unico operatore che conduce una linea volutamente diversa nell’aspetto.

Il rapporto consiglia a chiunque abbia caricato un modello dell’elenco con l’esecuzione del codice personalizzato attivata di controllare gli host per individuare /tmp/.cch/, eventuali svc.py processi, un kworker/u20:1 processo con argomenti relativi al mining, elementi codificati qwen2-tiny- o ezv- registrazioni Xinference e connessioni ai server e ai pool elencati. Pluto raccomanda di isolare le macchine interessate, conservare le prove, rimuovere tutti i meccanismi di persistenza, ruotare le credenziali esposte da una macchina pulita, ricostruire il sistema a partire da un’immagine attendibile quando non è possibile accertare l’integrità dell’host, richiedere l’autenticazione per l’API Xinference e bloccare le revisioni dei modelli sottoposte a verifica. Pluto afferma di aspettarsi altre campagne di questo tipo e di monitorarle.