In un’analisi pubblicata il 29 ottobre 2026, Pluto Security ha descritto una campagna di malware di mining in due ondate, diffusa tramite repository di modelli su Hugging Face. Il codice Python del repository poteva essere eseguito durante il caricamento del modello. Al 28 ottobre, Pluto contava 31 repository principali e 13 modelli collegati, con 32.376 download complessivi. L’analisi tecnica di Pluto Security ricostruisce il meccanismo e indica le tracce da controllare.
Dopo la rimozione degli account della prima ondata, Pluto ha riferito la comparsa di una seconda ondata su nuovi account nel giro di pochi giorni. Pluto data al 25 ottobre la pubblicazione di una copia quasi identica di qwen2-tiny da parte dell’account htt0118. Il 29 ottobre BleepingComputer ha riferito di aver esaminato quella copia e di avervi trovato lo stesso miner e una backdoor con accesso remoto.
Che cosa contano i download
I conteggi di repository e download pubblicati da Pluto distinguono la campagna principale dai modelli collegati. Il totale dei download comprende entrambi i gruppi.
| Gruppo | Repository | Download | Periodo del conteggio |
| Prima ondata | 12 | 728 | Registrati prima della rimozione |
| Seconda ondata | 19 | 29.090 | Fino al 28 ottobre 2026 |
| Modelli collegati | 13 | 2.558 | Fino al 28 ottobre 2026 |
I 31 repository della campagna principale sono quelli delle prime due righe; i 13 modelli collegati portano il totale a 44. Pluto ha registrato 32.376 download sommando 728, 29.090 e 2.558. Il numero misura i download, non gli utenti unici o le macchine infette.
Come partiva il codice durante il caricamento
Il passaggio chiave era l’opzione trust_remote_code=True: secondo Pluto, quando veniva attivata, Transformers importava il modulo Python indicato dalla configurazione del repository. Le istruzioni eseguite all’importazione potevano quindi partire durante il caricamento, prima che il modello fosse pronto per l’inferenza, e con i privilegi del processo che lo caricava.
Nel repository MENXIANGYU/qwen2-tiny, Pluto ha descritto un file model.safetensors di 42 byte senza tensori; il comportamento malevolo era nel codice Python del repository. Il miner poteva avviarsi dalla memoria con il nome camuffato [kworker/u20:1]. Un processo di sistema con quel nome non costituisce da solo un indicatore: Pluto segnala come pista gli argomenti di mining associati al processo.
Tracce di persistenza e comportamenti specifici
Tra gli indicatori elencati da Pluto ci sono la directory /tmp/.cch/, un’attività inattesa di svc.py, modifiche agli script di avvio della shell e registrazioni codificate con nomi qwen2-tiny- o ezv- in Xinference. Pluto segnala anche le connessioni alle infrastrutture associate alla campagna. L’assenza di un singolo indicatore non esclude una compromissione.
Nel campione descritto, uno script di controllo in /tmp/.cch/svc.py poteva riavviare il miner mancante ogni 120 secondi. Pluto attribuisce shell inverse riconnettenti a tre build specifiche, qwen2-tiny-5, qwen2-tiny-6 e qwen2-tiny-9, dirette a 212.32.253.3 sulle porte 443 o 9443. Questi comportamenti non sono attribuiti indistintamente a tutti i repository. Separatamente, Pluto descrive MENXIANGYU/qa-whl-1021 come uno script che, da un container privilegiato, poteva montare dischi dell’host e ottenere accesso root al sistema sottostante.
Come indagare su un host sospetto
Pluto raccomanda di indagare anche se il caricamento è fallito o l’uso della GPU sembra normale. La risposta suggerita procede così:
- Isolare l’host e conservare le prove. Salvare gli elementi relativi a processi, connessioni di rete, registri di sistema, cache e script di avvio.
- Controllare i sistemi collegati. Verificare anche le altre macchine che hanno caricato gli stessi repository, usando gli indicatori specifici descritti da Pluto.
- Rimuovere il miner e gli accessi persistenti. Eliminare anche backdoor e meccanismi di riavvio, non soltanto il processo di mining visibile.
- Cambiare le credenziali da una macchina pulita. Pluto consiglia di ruotare quelle raggiungibili dal processo sospetto.
- Ricostruire l’host se non se ne può stabilire l’integrità. La ricostruzione da un’immagine attendibile è la misura indicata quando non è possibile verificare che il sistema sia integro.
