FakeGit colpisce 17.610 repository GitHub: il ri-puntamento elude i takedown

La campagna malware FakeGit è tornata attiva il 4 ottobre 2026 con una flotta di 17.610 repository GitHub ri-puntati alla distribuzione di SmartLoader e dell'infostealer StealC. Secondo il report di Apiiro diffuso da BleepingComputer, gli operatori non hanno creato ex novo alcun repository: hanno modificato i link di download nei README di progetti già esistenti, inclusi fork, release asset e allegati issue. Questo meccanismo elude i sistemi di takedown basati su URL e rende impraticabile il blocco DNS selettivo della minaccia.

Il meccanismo del ri-puntamento: architettura della resilienza

Gli operatori di FakeGit hanno adottato una tattica che Apiiro definisce "re-aiming": invece di generare nuovi repository — operazione che richiederebbe account freschi e attirerebbe l'attenzione dei sistemi di rilevamento — hanno modificato i README di progetti già presenti sulla piattaforma. Questi progetti, in alcuni casi fork di software legittimo, in altri repository storici di sviluppatori reali, sono stati convertiti in punti di ingresso per il payload.

La modifica è minimale e mirata. Il 97% dei commit campionati ha interessato esclusivamente il README, alterando il pulsante o il link di download per puntare a un archivio ZIP ospentato altrove sulla stessa infrastruttura GitHub. L'88% di questi ZIP installa SmartLoader, un downloader che a sua volta distribuisce StealC. La catena di compromissione si articola quindi in almeno due stadi: il README come lure, il ZIP come first-stage, SmartLoader come second-stage, StealC come payload finale.

Il dato cruciale è la distribuzione dei payload. Secondo Apiiro, citato da BleepingComputer, gli archivi malevoli si trovano in "fork, file più vecchi, release asset, allegati issue e repository separati di hosting". Questa frammentazione significa che la rimozione di un singolo file non disarma il repository compromesso: l'operatore può immediatamente ri-puntare il link verso una copia di riserva, preservando l'infrastruttura di ingegneria sociale.

Velocità e scala: 2.999 repository all'ora

La campagna ha raggiunto una velocità di proliferazione eccezionale. Tra l'8 e il 9 ottobre 2026, FakeGit ha ri-puntato oltre 13.000 repository in un arco di 34 ore, con un picco di 2.999 operazioni all'ora. Questa cadenza esclude intervento umano diretto nella modifica dei singoli README: l'operazione è automatizzata, probabilmente tramite token o sessioni compromesse degli account legittimi.

Almeno 700 degli account coinvolti appaiono appartenere a sviluppatori reali. La fonte non specifica il metodo di iniziale compromissione di questi account, né quanti di essi siano stati riacquisiti dai legittimi proprietari o rimangano sotto controllo degli operatori della campagna. Questa ambiguità complica ogni tentativo di classificazione netta tra repository "buoni" e "cattivi" sulla base della sola identità dell'account.

"Nessuno ha dovuto creare un singolo nuovo repo. La flotta era già lì. È stata solo ri-puntata." — Ricercatori Apiiro, via BleepingComputer

Il fallimento strutturale delle difese perimetrali

Il report Apiiro evidenzia un limite architetturale delle difese tradizionali: il 71% della flotta era assente da URLhaus, il database di rilevamento malware basato su URL, prima della pubblicazione dell'analisi. Questo gap non dipende da ritardi di indicizzazione, ma dalla natura stessa dell'hosting: GitHub non è un dominio generico che si può bloccare selettivamente a livello DNS.

Un blocco a livello di dominio di github.com impedirebbe l'accesso all'intera piattaforma, con un impatto inaccettabile per milioni di sviluppatori e pipeline CI/CD. Al contempo, bloccare singoli file su un dominio che impiega HTTPS con condivisione di indirizzi IP dinamica è tecnicamente impraticabile per la maggior parte delle infrastrutture di sicurezza aziendali. Il commento dei ricercatori è esplicito: un blocklist DNS a livello di dominio non può bloccare un singolo file su GitHub senza bloccare GitHub nella sua interezza.

Questa condizione trasforma la piattaforma di hosting distribuito più grande al mondo in un singolo punto di fallimento per la supply chain software. La fiducia che gli sviluppatori ripongono in GitHub — legitimità per associazione, visibilità della community, presenza di fork e stelle come indicatori di reputazione — viene strumentalizzata contro di loro. La campagna sfrutta proprio questa asimmetria: il costo di verifica manuale di ogni repository supera di gran lunga il costo di un singolo click su un README apparentemente autorevole.

L'escalation verso AI skills e MCP server

La campagna non si limita a software tradizionale. Nel report di luglio 2026 di Island, 800 repository malevoli si mascheravano come AI skills o MCP (Model Context Protocol) server, sfruttando l'ondata di adozione degli strumenti di intelligenza artificiale nel workflow di sviluppo. Questa evoluzione indica una consapevolezza precisa del target: gli sviluppatori che integrano rapidamente nuove capability AI sono meno propensi a verificare la provenienza di repository apparentemente collegati a ecosistemi emergenti.

Il dato non è aggiornato alla riattivazione di ottobre, ma il pattern è coerente con la logica di FakeGit: colpire segmenti di alta velocità di adozione, dove la curatela della community è inferiore e la pressione per prototipare è massima. L'impostore di un MCP server ha un vantaggio rispetto al fake di una libreria JavaScript storica: il pubblico target è meno familiare con i canali ufficiali di distribuzione e più incline a seguire link da documentazione o tutorial.

Perché è importante

Il dossier non specifica misure correttive adottate da GitHub né interventi di law enforcement sugli operatori della campagna. Non emergono sovrapposizioni infrastrutturali che colleghino FakeGit ad altri gruppi tracciati pubblicamente. Il metodo di iniziale compromissione dei 700 account legittimi-appearing non è documentato: potrebbe derivare da credential stuffing, phishing mirato, o acquisto di sessioni su mercati underground, ma il brief non fornisce evidenza a favore di alcuna di queste ipotesi.

La fonte non quantifica il numero di download effettuati dei payload SmartLoader/StealC, né il volume di dati trafugati tramite l'infostealer. Non è documentato lo stato attuale di eventuali azioni di takedown sui 17.610 repository identificati, né se GitHub abbia implementato rilevamenti specifici per il pattern di ri-puntamento descritto da Apiiro.

La discrepanza terminale tra "pushed" (il linguaggio di BleepingComputer per i 13.000 repository) e "re-aimed" (la spiegazione tecnica di Apiiro) lascia un margine di ambiguità: il push indica un'operazione di commit attiva, mentre il ri-puntamento potrebbe avvenire anche tramite modifiche ai metadati di release o redirect a livello di issue attachment, senza necessariamente generare commit visibili nei log standard. Il brief non chiarisce se Apiiro abbia normalizzato questa terminologia o se i due verbi descrivano fasi distinte della stessa operazione.

Domande frequenti

Cos'è SmartLoader e che rapporto ha con StealC?

SmartLoader è il payload iniziale identificato nella catena di compromissione FakeGit. Secondo le fonti, SmartLoader distribuisce "altro malware, incluso StealC infostealer". Il dossier non specifica se SmartLoader distribuisca esclusivamente StealC o altri payload, né fornisce dettagli tecnici sul meccanismo di caricamento.

Posso identificare un repository FakeGit dalla sola analisi del README?

Il 97% dei commit campionati ha toccato solo il README, ma questo dato descrive il pattern osservato, non un invariante. La fonte non fornisce firme specifiche o indicatori di compromissione automatizzabili oltre l'analisi del link di download e della sua destinazione. La natura del ri-puntamento implica che un README precedentemente pulito possa diventare malevolo senza alterare la struttura visiva del file.

Perché i repository non vengono rimossi più rapidamente?

La rimozione reattiva è rallentata dalla distribuzione dei payload in fork, release asset, allegati issue e repository separati. Anche se GitHub rimuovesse un repository contenitore, le copie del payload permarrebbero attive altrove sulla piattaforma. Inoltre, il ri-puntamento consente agli operatori di reattivare istantaneamente l'infrastruttura di ingegneria sociale senza ricostruire la flotta da zero.

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://github.com/SecOpsNews/news/issues/74920
• https://daily.dev/posts/fakegit-malware-campaign-returns-with-17-610-malicious-github-repos-m5lmz662i
• https://www.scworld.com/brief/fakegit-campaign-reactivates-distributing-smartloader-malware-via-github
• https://support.github.com/
• https://github.com/SecOpsNews/news/issues
• https://github.com/SecOpsNews/news/pulls
• https://github.com/SecOpsNews/news/security
• https://www.bleepingcomputer.com/