FakeGit resuscita 17.610 repository: la pulizia reattiva su GitHub non basta più

La campagna FakeGit è tornata operativa il 4 ottobre 2026. In sole 34 ore ha riattivato oltre 13.000 repository GitHub, raggiungendo un picco di 2.999 in un'ora, per un totale di 17.610 repository malevoli. Il meccanismo è identico a quello di luglio—README convincenti, pulsanti Download che puntano a ZIP con il loader LuaJIT SmartLoader che installa l'infostealer StealC—ma con una differenza sostanziale: nessuno ha creato repository nuovi. La flotta esisteva già.

Questa "resilienza per ri-aimazione", documentata dai ricercatori di Apiiro, espone un limite strutturale delle difese attuali. Quando la rimozione puntuale non distrugge il payload ma ne cambia solo il puntatore, la detection basata su contenuto diventa un gioco del gatto e del topo che il difensore perde per definizione.

Il meccanismo: perché basta modificare un README

Il 97% dei commit analizzati da Apiiro ha modificato solo il file README, secondo il report citato da BleepingComputer. L'88% ha puntato il pulsante "Download" a un archivio ZIP contenente SmartLoader. Questo pattern rivela un'architettura di distribuzione modulare: il repository funziona da vetrina, il payload risiede altrove e il commit non fa che aggiornare il puntatore.

SmartLoader è un loader scritto in LuaJIT che, una volta eseguito, recupera l'indirizzo del server di comando e controllo (C2) interrogando uno smart contract deployato su Polygon, la rete blockchain. Secondo il report di Island del luglio 2026, citato da BleepingComputer, stabilisce quindi persistenza tramite scheduled tasks e scarica il payload finale, l'infostealer StealC.

La distribuzione multipla del payload è ciò che rende la campagna resistente alla rimozione. Gli archivi malevoli sono stati trovati in fork, file più vecchi, release assets, allegati a issue e repository separati dedicati all'hosting dei download. Secondo i ricercatori di Apiiro: "Elimina un file e l'operatore può puntare la esca a una copia di riserva".

"Nessuno ha dovuto creare un singolo repository nuovo. La flotta era già lì. È stata solo ri-aimata."
— Ricercatori Apiiro, citati da BleepingComputer

I numeri della visibilità: URLhaus e le blocklist tradizionali sono in ritardo

Il 71% della flotta di ottobre non era presente su URLhaus prima del report Apiiro, secondo quanto riportato dalla stessa fonte. Questo dato ha un corollario tecnico immediato: una blocklist DNS a livello di dominio non può bloccare un singolo file su GitHub senza bloccare l'intera piattaforma. La granularità della difesa tradizionale si infrange contro la reputazione e la centralizzazione del servizio.

La precedente ondata di luglio 2026, documentata da Island e riportata da The Hacker News e BleepingComputer, aveva già dimostrato la portata del fenomeno: 7.600 repository, 800 dei quali mascherati da AI skills o MCP (Model Context Protocol) servers, con oltre 600 listing su registri pubblici come LobeHub, Glama, MCP.so e MCP Market. I download cumulativi su 335 asset unici in 211 repository hanno raggiunto 14.084.688 eventi, secondo i contatori pubblici di GitHub. Island ha però specificato che questa cifra include richieste ripetute e automatizzate: non è indicativa del numero di infezioni reali.

AgentBaiting: quando l'attaccante non serve più a propagare il malware

La tecnica denominata AgentBaiting da Island introduce un vettore di propagazione che non dipende dalla curiosità o dall'inganno umano. In test controllati, Claude Code—l'agente AI di Anthropic progettato per operare in ambiente di sviluppo—ha clonato repository malevoli e scaricato file infetti sulla macchina di test. L'agente ha poi rilevato indicatori sospetti prima dell'esecuzione, ma il percorso di discovery autonoma è stato completato.

Il meccanismo è lineare: un utente chiede a un agente AI di trovare uno skill o un server MCP per estendere le capacità del proprio workflow. L'agente cerca su repository pubblici, trova il repository FakeGit con un README ben scritto, e lo propone. Come ha osservato Oleg Zaytsev di Island: "FakeGit non ha dovuto violare nulla. Ha pubblicato repository convincenti, preso in prestito identità di sviluppatori reali, diffuso i propri listing su registri pubblici, e lasciato che la scoperta facesse il resto."

Con AgentBaiting, quella scoperta non richiede più una persona: un agente che cerca uno skill o un server MCP può trovare l'esca, leggere il README dell'attaccante e portare avanti le sue istruzioni.

Cosa fare adesso

• Verificare l'origine prima dell'installazione: non basarsi sul numero di stelle o fork di un repository GitHub come indicatore di affidabilità; controllare l'attività storica dell'autore, la coerenza del profilo e la presenza di riconoscimenti verificabili.
• Ispezionare i puntatori di download: quando un README offre un pulsante o un link diretto a un ZIP, verificare l'URL di destinazione prima del download; i repository FakeGit puntano a domini o percorsi che non corrispondono alla struttura standard del progetto.
• Auditare le skill e i server MCP già installati: per le organizzazioni che usano agenti AI, inventariare le estensioni attive e verificarne la provenienza rispetto a cataloghi approvati; non assumere che un listing su registri pubblici implichi validazione di sicurezza.
• Riconsiderare le policy di threat intelligence: le blocklist DNS e i feed URLhaus hanno latenza misurabile contro campagne che riattivano repository esistenti; integrare verifiche di provenienza dell'autore e pattern di commit anomali nei controlli di supply chain.

Il limite che resta: chi controlla la flotta?

Il dossier non chiarisce come gli operatori abbiano acquisito controllo degli almeno 700 account legittimi identificati da Apiiro. Non è documentato se la compromissione avvenga tramite credential stuffing, phishing mirato, acquisto di account su mercati illegali, o tecniche diverse. Questa lacuna ha conseguenze operative: senza conoscere il vettore di acquisizione, è difficile stimare la velocità con cui la flotta possa espandersi oltre i 17.610 repository già contati.

L'attribuzione della campagna precedente a "Water Kurita" da parte di Trend Micro, citata da Island, si riferiva a un'operazione con Lumma Stealer e non è stata estesa con certezza alla presente ondata con StealC. Non emergono sovrapposizioni infrastrutturali che colleghino l'attore attuale a quel gruppo specifico allo stato attuale.

La portata effettiva dell'infezione resta inoltre sconosciuta. I 14 milioni di download cumulativi registrati sui contatori pubblici di GitHub includono richieste ripetute e automatizzate, come avvertito esplicitamente da Island: non sono infezioni verificate. Non è disponibile alcuna stima sul tasso di conversione da download a esecuzione del payload.

Perché questo cambia il perimetro della supply chain

La lezione della riattivazione FakeGit non è tecnica soltanto. È architetturale: quando una piattaforma distribuisce contenuti da milioni di publisher, la verifica ex post del contenuto è insufficiente se il publisher può cambiare il contenuto istantaneamente e se il payload sopravvive alla rimozione del singolo puntatore.

Le difese devono spostarsi dalla domanda "questo file è malevolo?" alla domanda "questo publisher ha intenzione e autorità di distribuire questo codice?". La seconda domanda è più difficile, richiede più dati, e non può essere delegata a un hash o a una firma. Ma è l'unica che rende conto di una campagna che non ha bisogno di creare nulla di nuovo per tornare operativa.

Per gli sviluppatori che usano agenti AI, la conseguenza è immediata: il perimetro di trust si espande dal codice che scrivono al codice che gli agenti scelgono autonomamente. E quel perimetro, oggi, è quasi inesplorato.

Fonti

• https://www.bleepingcomputer.com/news/security/fakegit-malware-campaign-returns-with-17-610-malicious-github-repos/
• https://unit42.paloaltonetworks.com/blinder-tunnel-targets-critical-infrastructure/
• https://blog.netmanageit.com/fakegit-malware-campaign-returns-with-17-610-malicious-github-repos/
• https://thehackernews.com/2026/07/fakegit-campaign-uses-7600-github.html
• https://www.bleepingcomputer.com/news/security/fakegit-campaign-uses-7-600-github-repos-to-push-smartloader-malware/
• https://unit42.paloaltonetworks.com/tracking-iran-apt-screening-serpens/

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

• https://schema.org/FAQPage
• https://schema.org/Question
• https://schema.org/Answer