La leva non è una vulnerabilità “classica”, ma la fiducia. Smartloader torna a colpire con una tattica che sposta il bersaglio verso il punto più prezioso della filiera digitale: le workstation degli sviluppatori. La campagna descritta da Kaspersky parte da un elemento che sembra innocuo e anzi utile, un server MCP per collegare un assistente AI ai dati di Oura Ring, e lo trasforma in un vettore supply chain capace di distribuire l’infostealer StealC. In pratica, gli attaccanti clonano un progetto legittimo, lo replicano su repository GitHub falsi, lo “spingono” dentro registri e market legati all’ecosistema MCP, e aspettano che la community faccia il resto installando, testando e integrando il codice. È un cambio di scala. Un infostealer sul PC di un utente qualunque ha valore. Un infostealer su una macchina di uno sviluppatore può diventare un moltiplicatore: accessi a repository, token di CI/CD, credenziali cloud, chiavi API, segreti applicativi, e una porta d’ingresso verso ambienti enterprise. In questo scenario, l’obiettivo non è solo rubare password, ma spostarsi lungo la catena del software.
Dal 2024 al 2026: Smartloader cambia pelle e si concentra sulla supply chain
Smartloader viene descritto come operazione consolidata dal 2024, inizialmente legata a installatori ingannevoli e dropper progettati per distribuire infostealer. La fase più recente, attiva da gennaio 2026, mostra invece un pivot netto: il focus diventa la compromissione supply chain tramite open source e “market” di componenti. È una direzione coerente con il modo in cui oggi gli ambienti di sviluppo consumano software: librerie, tool, plugin, server “pronti”, snippet e integrazioni installate rapidamente, spesso senza un controllo profondo della provenienza. Qui entra in gioco MCP, un ecosistema che sta crescendo insieme agli assistenti AI e ai connettori verso servizi esterni. Se un componente MCP viene considerato “utile” e finisce nei canali giusti, può diventare una scorciatoia perfetta per la distribuzione di malware: non è l’utente finale a cercarlo, è lo sviluppatore che lo adotta nel proprio workflow.
Il bersaglio: il MCP server per Oura Ring e l’effetto “health optimization”
Il progetto legittimo preso di mira è un server MCP che espone accesso alle API di Oura Ring per interrogare dati come sonno, readiness e metriche di benessere. È esattamente il tipo di progetto che può attirare sviluppatori interessati a demo, automazioni personali e integrazioni “AI + dati salute”. L’attrattiva del tema è parte dell’attacco: più il componente sembra utile e di tendenza, più è probabile che venga installato in fretta. La campagna sfrutta questo appetito costruendo una rete di repo e account che simulano un ecosistema vivo. Non serve violare il repository originale: basta clonarlo, farlo sembrare più “popolare” o più “pronto all’uso”, e inserirlo nei posti in cui gli sviluppatori cercano soluzioni.
La rete di GitHub fake: fork credibili e repo trojanizzato
La ricostruzione descrive una strategia a più livelli. Gli attaccanti creano una costellazione di account GitHub, con pattern ricorrenti come creazione recente, attività simile, commit history “coerente” ma artificiale. Il repository legittimo viene forkato per apparire autentico, mentre una versione trojanizzata viene pubblicata come se fosse un fork come gli altri, ma con differenze cruciali nel contenuto delle release. Nel caso riportato, emergono account e fork che hanno la funzione di “scenografia” e uno o più repository che fungono da payload carrier. La scelta di non attribuire correttamente l’autore originale in alcuni repo trojanizzati viene indicata come segnale di coordinamento e tentativo di rendere la pagina “propria” anziché un semplice fork. Il punto non è l’elenco degli URL, ma la tecnica: gli attaccanti costruiscono reputazione sintetica per aumentare la probabilità che uno sviluppatore selezioni il repo sbagliato, soprattutto se lo scopre tramite ricerca rapida o tramite un marketplace/registro MCP che lo mostra accanto a contributi reali.
La catena di infezione: LuaJIT obfuscato, persistenza e download di StealC
Il vettore operativo è descritto come una release che contiene uno script LuaJIT offuscato, presentato come risorsa innocua, ad esempio un file come resource.txt. Una volta eseguito, il dropper deposita interpreti e componenti in percorsi non sospetti dell’utente, tipicamente in %LOCALAPPDATA%, e avvia l’esecuzione del secondo stadio.
La persistenza punta su un trucco ricorrente nelle campagne moderne: mascherare i task schedulati come componenti di sistema o driver, in questo caso con nomi che richiamano Realtek audio. È un dettaglio importante perché lavora sulla disattenzione: un analista che scorre attività e pianificazioni potrebbe non fermarsi su un “AudioManager” apparentemente legittimo.
Il secondo stadio, come socket3.lua nella descrizione, stabilisce la comunicazione con il C2 e scarica l’infostealer StealC, con un livello di evasione superiore: una VM custom con centinaia di stati, encoding e ricostruzione a runtime delle stringhe sensibili. È il tipo di offuscamento pensato per sopravvivere a detection statiche e per rendere costoso il reverse engineering.
StealC: perché la posta in gioco è più alta sulle macchine developer
StealC è un infostealer progettato per raccogliere credenziali e token ad alto valore. Nella descrizione compaiono obiettivi come password dei browser, token Discord, wallet crypto e altri elementi utili alla monetizzazione e al pivot. In un contesto developer, però, la lista si estende implicitamente a tutto ciò che su una workstation di sviluppo tende a esistere: token GitHub, chiavi API, accessi cloud, credenziali di servizi SaaS, segreti di pipeline CI/CD, sessioni e cookie che aprono porte a strumenti interni.
È questa la logica supply chain: il malware non deve necessariamente compromettere subito un prodotto finale. Basta rubare le chiavi giuste e sfruttarle per contaminare repository, build, pacchetti o ambienti in cui il codice viene prodotto e distribuito.
Il ruolo di MCP: quando il mercato dei connettori diventa superficie d’attacco
Il dettaglio strategico è l’“avvelenamento” di registri e market MCP. Se un componente compare in un elenco consultato dagli sviluppatori, l’attaccante sfrutta un comportamento standard: installare, provare, integrare. Il problema è che, in molti ecosistemi open, la verifica della provenance è spesso superficiale: si guarda il numero di stelle, il README, la presenza di issue, la “sensazione” di legittimità. Smartloader dimostra che questi segnali possono essere replicati. Gli account possono essere creati in massa, i fork possono simulare community, la cronologia commit può essere resa plausibile. Il risultato è una supply chain sociale, dove la sicurezza viene sostituita dall’impressione di autenticità.
Indicatori pratici: cosa rende riconoscibile una campagna come questa
Il pattern descritto lascia una serie di tracce tipiche. Sul piano operativo, compaiono file e percorsi in AppData con nomi non correlati al progetto installato, task schedulati mascherati da componenti audio, e una rete che porta a infrastrutture C2. Sul piano “social”, emergono account GitHub creati di recente, fork con attività uniforme e repository che non citano correttamente l’autore originale.
È proprio l’unione di questi due mondi a rendere l’attacco pericoloso: non è solo malware, è un’operazione di credibilità costruita attorno a un progetto reale.
Mitigazioni: il punto non è “non usare open source”, ma verificare la provenienza
La difesa non può essere ideologica, perché il software moderno vive di open source. La risposta è procedurale e tecnica. In ambienti aziendali, la prima misura è un audit dell’inventario dei componenti MCP adottati, specialmente quelli introdotti negli ultimi mesi senza revisione formale. Subito dopo serve un processo di vetting che includa controllo di provenance, verifica dell’autore, confronto con il repository originale e analisi delle release, non solo del codice visibile. Sul piano endpoint, la caccia deve concentrarsi su task schedulati anomali, binari in %LOCALAPPDATA% con nomi e percorsi sospetti, e comportamento di rete coerente con esfiltrazione. L’egress control resta decisivo: se un host developer può parlare liberamente verso qualunque destinazione, un infostealer avrà sempre un canale per uscire. La citazione di tool come quelli di Straiker, con funzioni di analisi comportamentale e spotting di fake account, indica un trend chiaro: servono controlli specifici per questi nuovi mercati di connettori AI, perché le vecchie euristiche “guardiamo il pacchetto” non bastano quando il pacchetto è socialmente camuffato.
Un segnale sulla nuova fase della supply chain: gli attacchi inseguono gli ecosistemi AI
Questo caso è un indicatore di maturità criminale. Gli attaccanti non inseguono più solo framework popolari o librerie mainstream, ma i nuovi snodi dove nasce valore: i connettori per AI assistants, i server MCP, i market che aggregano integrazioni. È un passaggio coerente con il 2026: più l’AI entra nei workflow, più i suoi “pezzi” diventano superficie d’attacco. Smartloader, clonando un MCP apparentemente innocuo come quello per Oura Ring, mostra un principio che vale oltre questo singolo episodio: quando la fiducia viene delegata a un elenco, un marketplace o a un repo “simile”, la supply chain diventa vulnerabile per design. E le workstation degli sviluppatori restano il punto più redditizio per colpire.
Iscriviti alla Newsletter
Non perdere le analisi settimanali: Entra nella Matrice Digitale.
Matrice Digitale partecipa al Programma Affiliazione Amazon EU. In qualità di Affiliato Amazon, ricevo un guadagno dagli acquisti idonei. Questo non influenza i prezzi per te.
