Malware AI su Hugging Face e GitHub: Load/Mine e Yoba colpiscono GPU e PC

🛡️ Executive Summary

• Load/Mine: Pluto Security identifica 31 repository malevoli in due ondate su Hugging Face. Includendo altri modelli collegati, i download registrati superano 32.000, senza equivalere a infezioni confermate.
• Yoba: Check Point Research scopre falsi installer di ChatGPT e Claude distribuiti tramite GitHub, capaci di sfruttare eseguibili autentici e firmati per caricare DLL malevole e installare un miner XMRig.
• Supply chain AI: le campagne prendono di mira infrastrutture differenti, dai server GPU Linux ai computer Windows, ma sfruttano entrambe la fiducia riposta in repository, modelli e software apparentemente legittimi.

La distribuzione del malware attraverso l’ecosistema dell’intelligenza artificiale sta assumendo caratteristiche sempre più vicine agli attacchi contro la supply chain software, ma con una differenza sostanziale: il codice malevolo può arrivare direttamente attraverso i modelli utilizzati dagli sviluppatori oppure attraverso applicazioni che imitano strumenti AI conosciuti. Due indagini pubblicate da Pluto Security e Check Point Research ricostruiscono le campagne Load/Mine e Yoba, entrambe orientate al cryptomining ma dotate di funzionalità capaci di mantenere accesso ai sistemi compromessi. Nel primo caso vengono sfruttati repository Hugging Face e l’esecuzione di codice Python durante il caricamento dei modelli. Nel secondo, falsi installer di ChatGPT e Claude utilizzano binari firmati e tecniche di DLL sideloading. Le piattaforme di distribuzione sono legittime; a essere malevoli sono i contenuti pubblicati dagli attaccanti.

Load/Mine trasforma 31 repository Hugging Face in vettori malware

La ricerca Load/Mine di Pluto Security documenta una campagna articolata in due ondate, con 31 repository malevoli distribuiti attraverso sette account Hugging Face. La prima comprendeva 12 repository e aveva registrato 728 download prima della rimozione; la seconda ne comprendeva 19, con 29.090 download rilevati al 28 ottobre 2026. Considerando anche 13 repository collegati, ma non tutti attribuiti con certezza allo stesso operatore, il totale raggiunge 44 repository e 32.376 download.

È una distinzione essenziale: i download non rappresentano necessariamente macchine infette, utenti unici o esecuzioni riuscite. Un solo repository, MENXIANGYU/qwen2-tiny, concentrava 28.412 download, quasi tutto il volume della seconda ondata. I modelli imitavano piccoli checkpoint della famiglia Qwen2, presentandosi come risorse adatte a test e sperimentazioni, mentre il vero contenuto operativo risiedeva nei file Python associati alla configurazione del modello. Dopo la segnalazione iniziale, Hugging Face e ModelScope hanno rimosso gli account individuati, ma la campagna è ricomparsa nel giro di pochi giorni con nuovi repository, loader modificati e capacità di accesso remoto più articolate.

Il bersaglio principale non era il normale utente di un chatbot, ma l’infrastruttura utilizzata per eseguire modelli in locale: server GPU, ambienti Xinference, installazioni GPUStack, notebook condivisi e pipeline di integrazione continua. Il meccanismo sfrutta trust_remote_code=True, un’opzione che permette alla libreria Transformers di caricare implementazioni Python fornite dal repository del modello. Quando la configurazione auto_map richiama un modulo personalizzato, Python ne esegue le istruzioni presenti al livello principale prima ancora che la classe del modello venga inizializzata.

In questo caso, il file modeling_evil2.py invocava una funzione di avvio malevola durante l’importazione. Non servivano pesi manipolati o vulnerabilità nel formato pickle: l’esecuzione del codice derivava da un’autorizzazione esplicita concessa al repository, trasformata dall’attaccante in un punto d’ingresso. Pluto richiama anche precedenti problemi di gestione del codice remoto in vLLM e Unsloth Studio, ma la campagna osservata sfruttava principalmente il comportamento previsto del caricamento di modelli personalizzati.

Da trust_remote_code al miner nascosto come processo Linux

Il payload analizzato da Pluto preparava inizialmente una directory nascosta, /tmp/.cch/, nella quale installava un watchdog denominato svc.py, incaricato di riavviare il miner qualora fosse stato terminato. La persistenza veniva rafforzata attraverso modifiche ai file di inizializzazione della shell, tra cui .bashrc e .profile. Il componente successivo, syscore.bin, veniva recuperato dal repository Hugging Face o da infrastrutture alternative, incluse copie ospitate su ModelScope e servizi mirror. La prima esecuzione sfruttava memfd_create e fexecve, consentendo di caricare il binario da un descrittore di file residente in memoria senza avviarlo direttamente da un normale percorso su disco. Il processo assumeva un nome simile a quello di un thread del kernel, [kworker/u20:1], mentre una copia di riserva rimaneva disponibile per i successivi riavvii. Il miner era inoltre protetto da un eseguibile compresso con UPX, le cui firme erano state alterate da UPX! a PEK! per ostacolare le normali procedure di decompressione utilizzate dagli analisti.

Il malware non si limitava a consumare capacità di calcolo. Alcune varianti inserivano chiavi SSH non autorizzate, altre stabilivano reverse shell verso server controllati dagli aggressori, mentre i componenti più recenti tentavano di accedere all’host sottostante partendo da container privilegiati. Un repository denominato qa-whl-1021 conteneva uno script capace di cercare e montare volumi del sistema host, con particolare attenzione agli ambienti GPUStack. La campagna utilizzava inoltre il registro locale dei modelli Xinference come canale per comunicare lo stato dell’infezione attraverso nomi apparentemente riconducibili a checkpoint Qwen2. Pluto ha collegato la prima ondata a un wallet che aveva ricevuto circa 2.276 PRL, per un valore indicativo vicino a 5.000 dollari, e ha osservato worker attivi riconducibili a macchine GPU e notebook condivisi. Gli indicatori economici dimostrano che almeno una parte dell’operazione produceva ricavi effettivi, senza consentire di calcolare il numero complessivo delle vittime.

Yoba usa falsi ChatGPT e Claude per distribuire malware Windows

La seconda indagine, pubblicata da Check Point Research, riguarda una campagna distinta, denominata Yoba, che sfrutta la popolarità delle applicazioni AI per convincere gli utenti a scaricare installer malevoli. Gli aggressori hanno creato repository GitHub e pagine GitHub.io che pubblicizzavano presunte versioni desktop di GPT-5.6 Sol, GPT-6 Astra e Claude Opus. Le pagine presentavano descrizioni plausibili e collegamenti ad archivi ZIP ospitati attraverso le funzionalità di release di GitHub. Secondo i ricercatori, alcuni progetti comparivano anche tra i risultati di Google, con caratteristiche compatibili con tecniche di SEO poisoning. I primi repository risalivano a luglio 2026, mentre le release malevole individuate erano state pubblicate tra la fine di agosto e l’inizio di settembre. Non risultavano invece prove di manipolazione artificiale di stelle o fork per aumentarne la credibilità.

L’elemento tecnico più significativo era l’impiego di eseguibili autentici e firmati di OpenAI e Anthropic, affiancati a una libreria winmm.dll controllata dagli attaccanti. Quando l’utente eseguiva Setup.exe, il programma legittimo poteva caricare la DLL malevola dalla directory dell’installer, avviando la tecnica di DLL sideloading. La firma digitale del programma ospite non garantiva quindi l’integrità dei componenti caricati accanto a esso. La prima fase, YobaDropper, verificava il nome del processo, applicava controlli contro gli ambienti di analisi e richiedeva privilegi amministrativi.

Il malware escludeva inoltre diversi sistemi con impostazioni linguistiche associate ai Paesi della Comunità degli Stati Indipendenti, mantenendo però un’eccezione per l’ucraino. Check Point considera alcuni elementi compatibili con un’origine russa, ma si tratta di indicatori investigativi e non di un’attribuzione definitiva.

YobaLoader sfrutta Telegram, DNS-over-HTTPS e Tor

Una volta avviato, YobaDropper creava una directory sotto ProgramData, copiava un eseguibile Windows legittimo e preparava una seconda DLL malevola, wmpdui.dll, destinata a essere caricata attraverso un ulteriore sideloading. La persistenza veniva ottenuta mediante un’attività pianificata configurata per l’avvio con l’account Local System, con un ritardo di tre minuti dopo l’accensione del computer. Il secondo componente, YobaLoader, non contattava direttamente un classico server di comando e controllo con un indirizzo statico. Recuperava invece l’immagine del profilo di un canale Telegram e utilizzava gli ultimi 50 byte del file come materiale per generare dinamicamente un dominio. Su quel dominio interrogava un record DNS TXT attraverso il servizio DNS-over-HTTPS di Google, recuperando istruzioni codificate e protette da verifica crittografica. Il contenuto decifrato poteva indicare un payload ospitato su Catbox, che il loader scaricava e avviava attraverso diverse modalità, inclusa l’iniezione in svchost.exe.

Il payload finale osservato dai ricercatori era XMRig 6.26.0, configurato per effettuare mining attraverso un endpoint onion raggiunto mediante un proxy Tor locale. La catena poteva distribuire anche Tor e lyrebird, utilizzare bridge offuscati e sospendere temporaneamente il mining durante l’attività dell’utente, riducendo i segnali visibili di compromissione. Check Point sottolinea tuttavia che YobaLoader è un loader generico: le istruzioni recuperate dal canale DNS possono indicare altri eseguibili o script PowerShell, permettendo agli operatori di cambiare payload senza modificare l’intera catena di distribuzione. Le versioni precedenti, osservate già a giugno 2026, avevano sfruttato anche eseguibili denominati Cursor.exe, indicando un’evoluzione delle esche utilizzate. Non esistono elementi nelle due ricerche che colleghino operativamente Yoba agli autori di Load/Mine.

Il problema comune è la fiducia nelle piattaforme AI

Il confronto tra le due campagne evidenzia come l’attacco alla supply chain AI non richieda necessariamente la compromissione dei servizi centrali di Hugging Face, GitHub, OpenAI o Anthropic. Load/Mine pubblicava repository malevoli su un hub legittimo, mentre Yoba utilizzava GitHub per distribuire software contraffatto insieme a componenti autentici e firmati. Nel primo caso, l’utente o il servizio autorizzava l’esecuzione di codice remoto; nel secondo, la vittima avviava un installer che abusava del comportamento di caricamento delle librerie di Windows. La fiducia iniziale derivava da elementi differenti, ma in entrambi gli scenari il passaggio critico avveniva quando contenuti di provenienza esterna acquisivano capacità operative sul sistema.

Il fenomeno si inserisce in una sequenza di incidenti già documentati. L’abuso di Hugging Face per distribuire malware attraverso repository apparentemente legittimi aveva mostrato come la piattaforma potesse essere sfruttata come canale di consegna, mentre la campagna AgentBaiting contro repository GitHub dedicati agli strumenti AI aveva evidenziato il rischio che contenuti ostili fossero individuati e suggeriti anche dagli agenti software. Un ulteriore precedente riguarda i falsi Custom GPT utilizzati per avviare catene ClickFix, nei quali la credibilità dell’interfaccia veniva sfruttata per indurre l’esecuzione di comandi malevoli. Sono campagne distinte, ma mostrano una progressiva convergenza tra distribuzione di malware, reputazione delle piattaforme e automatizzazione dei flussi di sviluppo.

Scanner insufficienti e persistenza: cosa devono controllare i difensori

La ricerca Pluto individua un limite preciso negli strumenti di scansione dei repository di modelli. Hugging Face esegue controlli antivirus sui file e utilizza strumenti specializzati per individuare rischi nei formati di serializzazione, ma il codice Python della campagna non veniva riconosciuto come dannoso. Il repository principale risultava pulito ai controlli eseguiti, nonostante il modulo contenesse funzioni di esecuzione, comunicazione di rete e persistenza. La misura più importante è quindi analizzare i file Python richiamati da auto_map prima di abilitare trust_remote_code=True, verificare la revisione esatta del repository e limitare privilegi, accesso alla rete e disponibilità di credenziali nell’ambiente di inferenza. Sui sistemi potenzialmente esposti, Pluto raccomanda di controllare directory come /tmp/.cch/, processi svc.py, falsi kworker, modifiche ai file di avvio della shell e registrazioni anomale in Xinference. La sola eliminazione del modello o del miner non garantisce la rimozione di watchdog e backdoor.

Per Yoba, invece, gli indicatori più utili riguardano installer scaricati da repository non ufficiali, DLL winmm.dll collocate accanto a eseguibili firmati, attività pianificate sospette, processi Windows avviati da directory inconsuete e traffico verso infrastrutture Telegram, DNS-over-HTTPS e Tor in combinazioni non coerenti con l’uso ordinario del sistema. Check Point mette a disposizione hash e regole YARA per identificare YobaDropper e YobaLoader. Le organizzazioni dovrebbero impedire l’esecuzione indiscriminata di software proveniente da repository sconosciuti e verificare non soltanto la firma dell’eseguibile principale, ma anche le librerie che esso carica.

Il risultato delle due indagini è particolarmente rilevante per aziende, università e centri di ricerca che utilizzano modelli open-weight e strumenti AI sui propri sistemi. Un repository rimosso non cancella un’infezione già avvenuta, così come un installer firmato non rende automaticamente sicuri i file distribuiti insieme al programma. Load/Mine dimostra che un modello apparentemente innocuo può diventare una porta d’accesso verso server GPU e credenziali cloud; Yoba dimostra che il nome di un assistente AI e un eseguibile autentico possono essere sufficienti a rendere credibile una catena malware. La sicurezza dell’intelligenza artificiale passa dunque anche dalla verifica del codice che la circonda, delle dipendenze che la distribuiscono e dei privilegi concessi ai processi che la eseguono.