FakeGit riattiva 17.610 repository GitHub senza crearne di nuovi

🛡️ Executive Summary

• Apiiro identifica 17.610 repository FakeGit attivi e oltre 13.000 riarmati in appena 34 ore senza bisogno di ricrearli.
• La tecnica RePointing conserva repository e reputazione modificando soprattutto i link nei README verso nuove copie di SmartLoader.
• Almeno 219 account di sviluppatori risultano compromessi con evidenze dirette, mentre Apiiro stima che quelli reali coinvolti possano essere circa 700.

FakeGit non ha ricostruito da zero la propria infrastruttura: l’ha semplicemente riarmata. Apiiro ha identificato 17.610 repository GitHub esca ancora attivi, gran parte dei quali già esistenti da mesi, e ha osservato che il 79% della flotta è stato ripubblicato il 4 e 5 ottobre cambiando soprattutto i link presenti nei README. Dietro il pulsante “Download” ricompare SmartLoader, che può consegnare StealC e trasformare una visita a un progetto apparentemente legittimo in furto di sessioni, credenziali e accessi cloud. Il punto nuovo è quindi la resilienza: il repository sopravvive, il file cambia posizione e l’attaccante conserva reputazione, cronologia e visibilità.

17.610 repository restano vivi perché FakeGit cambia soltanto il bersaglio

Nella ricerca originale di Apiiro il conteggio arriva a 17.610 repository esca live e 18.864 repository complessivamente coinvolti contando host di download e copie forkate. Il 4 e 5 ottobre più di 13.000 repository sono stati aggiornati in 34 ore, con picchi di 2.999 push in un’ora. Nel campione analizzato, il 97% delle modifiche interessava soltanto il README e nell’88% dei casi il pulsante di download veniva reindirizzato verso uno ZIP verificato come parte del kit SmartLoader. Apiiro definisce questa tecnica RePointing: invece di creare una nuova esca dopo ogni takedown, l’operatore mantiene il repository e sostituisce semplicemente la destinazione del download. È l’evoluzione dell’infrastruttura già osservata nell’operazione AgentBaiting, costruita per distribuire SmartLoader e StealC attraverso repository GitHub falsi.

Leggi anche: 292 repository GitHub falsi usati per distribuire BoryptGrab

La reputazione di GitHub diventa una risorsa che l’attaccante conserva

Il vantaggio del RePointing non è soltanto operativo. Un repository vecchio, con nome plausibile, cronologia e magari interazioni precedenti, appare più affidabile di un clone appena creato. Apiiro non ha trovato prove che il re-push migliori il ranking nelle ricerche GitHub: la convenienza è più semplice, perché ricreare l’infrastruttura costa più che cambiare un link.

Il problema diventa più grave quando il controllo passa da account usa-e-getta a identità reali. La ricerca conta 15.225 account dietro la flotta, 14.219 dei quali classificati come throwaway, ma identifica 219 account di sviluppatori compromessi con evidenze dirette e stima che il totale reale possa essere vicino a 700. Gli aggressori hanno inoltre pubblicato il kit in almeno 269 repository che non appartenevano direttamente alla propria infrastruttura. Il dominio github.com, da solo, non certifica quindi né l’identità del maintainer né la sicurezza del contenuto.

Il takedown di un file non elimina una campagna costruita per avere riserve

La parte più critica riguarda la difesa. Prima della pubblicazione del report, il 71% della flotta non compariva nello snapshot URLhaus confrontato da Apiiro, mentre il 99,96% degli ZIP elencati risultava ancora scaricabile. I ricercatori hanno trovato copie dei payload in fork, file più vecchi, release asset, issue attachment e repository separati utilizzati soltanto come download host.

Eliminare un singolo archivio o bloccare un URL risolve quindi un puntatore, non l’infrastruttura: l’operatore può modificare nuovamente il README e indirizzare l’utente verso una copia già pronta. La dinamica richiama gli incidenti supply-chain in cui AsyncAPI e pacchetti npm compromessi sfruttavano workflow e infrastrutture considerate affidabili: l’elemento fidato resta legittimo, ma viene trasformato nel contenitore attraverso cui l’attaccante sposta payload e credenziali.

SmartLoader usa GitHub e Polygon per arrivare alle sessioni degli sviluppatori

Dopo l’esecuzione dello ZIP, la catena resta coerente con le analisi precedenti di FakeGit. SmartLoader profila il sistema, recupera l’indirizzo del command-and-control attraverso uno smart contract Polygon e scarica gli stage successivi da altri repository GitHub. Le analisi tecniche richiamate da Apiiro collegano la catena a StealC, infostealer capace di sottrarre password, cookie e soprattutto sessioni attive. Per uno sviluppatore una sessione GitHub, un portale cloud o un SSO già autenticato può valere più della password, perché un cookie sottratto può evitare il normale passaggio di login e quindi anche la nuova richiesta MFA. Il problema si avvicina a quello dell’AgentJacking contro coding agent con accesso a repository, terminali e credenziali: l’obiettivo non è soltanto compromettere una workstation, ma ottenere accessi riutilizzabili per raggiungere nuovi repository e ambienti di sviluppo.

Le esche AI restano dentro una flotta molto più grande

Apiiro ha trovato il kit nascosto anche in 167 cartelle presentate come AI skill, ma il nuovo conteggio non significa che tutti i 17.610 repository abbiano un tema AI. La campagna precedente aveva già mostrato come falsi tool, skill e server MCP potessero essere indicizzati nei cataloghi pubblici e suggeriti agli sviluppatori. Il nuovo report sposta però il problema a monte: anche quando l’esca è stata identificata una volta, il repository può riapparire con un nuovo ZIP senza cambiare identità. Per questo la verifica non può fermarsi al nome del progetto, alle stelle o alla presenza in un catalogo. Deve includere proprietario, cronologia dei commit, provenienza delle release e destinazione reale dei pulsanti di download. Il rischio cresce ulteriormente quando un coding agent trasforma direttamente il README in istruzioni operative, perché la documentazione avvelenata entra nel percorso decisionale dell’utente.

Continua con:

GitHub Actions trasformato in infrastruttura operativa contro server e pipeline

ViteVenom usa la blockchain per rendere resiliente il comando e controllo

La risposta deve partire dalle sessioni e non soltanto dal file scaricato

Apiiro raccomanda di trattare l’esecuzione di SmartLoader come un possibile compromesso dell’account GitHub: revocare sessioni attive e token di accesso, passare alle passkey e verificare i repository sui quali l’account può scrivere. È una conseguenza importante perché la rimozione dello ZIP dalla macchina non chiude automaticamente il rischio creato da cookie o token già sottratti. Sul piano preventivo, repository per skill AI, integrazioni e server MCP dovrebbero essere accettati soltanto quando riconducibili a registri ufficiali o ai repository del vendor. La lezione di FakeGit è quindi più ampia del singolo infostealer: una piattaforma di sviluppo può diventare una rete di distribuzione persistente quando l’attaccante conserva identità e contenitore e sostituisce soltanto il punto verso cui indirizza la fiducia.