Operazione Muck and Load: 222 repository GitHub per distribuire malware Windows

Un attore di minaccia ha costruito una rete di 222 repository GitHub su 190 account per distribuire malware Windows, sfruttando il sistema di versioning di Go e piattaforme pubbliche come dead drops. L'operazione, denominata "Operation Muck and Load" dai ricercatori di Socket, ha prodotto oltre 1.200 versioni di un modulo Go a partire dal 24 gennaio 2026, di cui 700 identificate come malevole. Il meccanismo sfrutta la fiducia degli sviluppatori nell'ecosistema open source e la difficoltà di distinguere pseudo-versioni legittime da commit automatizzati.

Il travestimento: un modulo Go che finge di scansionare DNS

Il modulo malevolo si presenta come strumento di scansione DNS e subdomain, impersonando il progetto open source legittimo dnsub. L'impersonificazione non è superficiale: il repository mantiene funzionalità apparentemente coerenti con lo scopo dichiarato, sufficienti a superare una valutazione rapida. La differenza critica risiede in una stringa apparentemente vuota, occultata da whitespace orizzontale eccessivo, che contiene un comando PowerShell.

Il PowerShell si attiva prima dell'esecuzione della logica di scansione legittima. Aggira le restrizioni delle policy di script-execution e recupera ulteriori script da dead drops ospitati su piattaforme pubbliche. Il meccanismo di offuscamento tramite whitespace sfrutta una lacuna di attenzione: gli strumenti di review automatizzati e gli sviluppatori tendono a ignorare stringhe che appaiono vuote o formattate per leggibilità.

La "fattoria di versioni": come GitHub Actions è diventato un'arma

La caratteristica distintiva dell'operazione è l'uso massiccio del versioning automatizzato. Secondo Socket, citato da SecurityWeek, "the likely cause is not normal release engineering, but the threat actor's own GitHub Actions workflow repeatedly generating timestamp commits that could be surfaced as Go pseudo-versions". Le pseudo-versioni di Go — basate su timestamp di commit e hash abbreviati — sono progettate per riferimenti diretti a repository senza tag semantici. L'attore le ha trasformate in un sistema di distribuzione: ogni commit genera una nuova versione referenziabile, moltiplicando le opportunità di propagazione.

Questo approccio supera di gran lunga la tipica operazione di typo-squatting o repository singolo. Con 1.200 versioni disponibili, un attore può variare i riferimenti consigliati in forum, documentazione o risposte a issue, rendendo il tracciamento e il blocco estremamente difficile. La distribuzione su 190 account separati aggiunge resilienza: la rimozione di un account non compromette l'intera rete.

"The public sources are the dead-drop locations embedded in the script, including Pastebin, Rlim, Muck-themed infrastructure, and fallback locations on public platforms such as YouTube, Instagram, Telegram, Google Docs, and GitCode."

I dead drops pubblici: quando le piattaforme trusted diventano infrastruttura C2

La catena di infezione non si affida a infrastruttura proprietaria ma a un ecosistema di piattaforme pubbliche già whitelisted nei firewall aziendali. I dead drops — punti di raccolta temporanei per payload e comandi — includono Pastebin, Rlim, YouTube, Instagram, Telegram, Google Docs e GitCode. Questa architettura rende inefficaci i blocchi di rete basati su reputazione delle destinazioni: un firewall che permette l'accesso a Google Docs o YouTube non può distinguere tra uso legittimo e recupero di script malevolo senza ispezione del contenuto.

Gli script recuperati dai dead drops eseguono una sequenza strutturata: un resolver localizza metadati criptati del payload, decripta gli URL effettivi, recupera un archivio protetto da password, lo estrae ed esegue. La protezione tramite password dell'archivio aggiunge un ulteriore strato di offuscamento per gli analisti automatici.

I payload analizzati: RAT, infostealer e miner in un arsenale multi-stadio

Socket ha identificato almeno 14 file malware unici nei repository workflow dell'attore. I payload finali confermati includono AsyncRAT, Quasar RAT e un RAT in stile Remcos — strumenti di accesso remoto che garantiscono controllo persistente delle macchine compromesse. L'arsenale comprende inoltre infostealer, spyware e trojan loader/downloader. Tra i campioni specifici rientrano Vidar, un infostealer noto per il furto di dati di navigazione e credenziali, e XMRig/BitMiner per il mining di criptovaluta.

La molteplicità dei payload suggerisce operatori interessati sia all'espionaggio che al profitto immediato, o alla vendita di accessi a terzi. La distribuzione attraverso un modulo Go — tipicamente installato in ambienti di sviluppo e build — espone potenzialmente workstation di sviluppatori e, attraverso pipeline CI/CD, server di build e artefatti di produzione.

Tracce di un attore ricorrente: l'overlap con "ischhfd83"

I ricercatori hanno identificato sovrapposizioni con attività precedenti associate all'indirizzo email "ischhfd83" e a domini "Muck-themed". Questa correlazione indica che l'operazione non rappresenta un debutto ma l'evoluzione di una campagna in corso, con l'attore che ha perfezionato il proprio modus operandi nel tempo. Tuttavia, non emergono sovrapposizioni infrastrutturali che colleghino l'attore a gruppi di minaccia noti e documentati allo stato attuale.

L'identità dell'attore rimane sconosciuta. Il dossier non specifica la geografia, il movente primario o eventuali vittime identificate per nome. Non è documentato neppure se i repository siano stati rimossi da GitHub al momento della pubblicazione del report.

Cosa fare adesso

Per team che utilizzano moduli Go in ambienti di sviluppo o produzione, le azioni prioritarie derivano direttamente dal meccanismo dell'attacco:

• Verificare i riferimenti a moduli Go con pseudo-versioni generate da commit recenti e senza tag semantici stabili, specialmente se associati a repository con storia di commit ridotta o ripetitiva.
• Ispezionare il codice sorgente dei moduli prima dell'installazione, con attenzione particolare a stringhe apparentemente vuote o con formattazione whitespace anomala.
• Monitorare le esecuzioni PowerShell in ambienti di sviluppo, dove le policy di esecuzione script sono spesso più permissive che in produzione.
• Segmentare le pipeline CI/CD per impedire che moduli di terze parti eseguano codice con privilegi elevati su server di build.

Perché questo attacco ridefinisce il rischio supply chain

Operation Muck and Load non sfrutta una vulnerabilità zero-day né un errore di configurazione: abusa meccanismi legittimi del più grande ecosistema di sviluppo collaborativo al mondo. La confidenza che gli sviluppatori ripongono nel versioning automatizzato, nel commit history visibile e nella presenza su GitHub diventa il vettore stesso dell'infezione. L'uso di pseudo-versioni come veicolo di distribuzione rende impossibile la difesa basata esclusivamente su blacklist di versioni note: ogni nuovo commit è una nuova versione, ogni nuova versione è un potenziale payload diverso.

La maturazione di questo modello — dalla creazione manuale di repository tipografici all'automazione industriale di versioni via CI/CD — segnala una transizione nel threat landscape della supply chain software. Gli attori di minaccia non imitano più l'open source: lo weaponizzano dalla dentro, sfruttando la stessa infrastruttura che rende l'open source scalabile.

Domande frequenti

Cos'è una pseudo-versione Go e perché è vulnerabile a questo abuso?
Una pseudo-versione è un identificatore generato automaticamente da Go quando un modulo viene referenziato tramite commit senza tag semantico, nel formato v0.0.0-timestamp-commithash. È legittima per sviluppo e dipendenze dirette, ma la sua generazione automatica permette a un attore di produrre illimitate versioni referenziabili senza richiedere approvazione o review da parte della piattaforma.

Come fa il malware a non essere rilevato dagli strumenti di sicurezza?
Il payload iniziale è occultato in stringhe con whitespace eccessivo, un formato che molti scanner superficiali ignorano. La catena di infezione è multi-stadio: il modulo stesso non contiene malware eseguibile ma un comando PowerScript che recupera ulteriori stadi da piattaforme pubbliche whitelisted, rendendo inefficaci le analisi statiche isolate.

Questo incidente è collegato alla vulnerabilità CVE-2026-3854 di GitHub?
No. CVE-2026-3854 è una vulnerabilità RCE distinta, non correlata a Operation Muck and Load. I due incidenti non condividono TTP, infrastruttura o attori.

Fonti

• https://www.securityweek.com/network-of-200-github-repositories-used-for-malware-infection/
• https://thehackernews.com/2026/04/researchers-discover-critical-github.html
• https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/
• https://securityboulevard.com/2026/04/the-growing-abuse-of-github-and-gitlab-in-phishing-campaigns/
• https://www.aikido.dev/blog/glassworm-returns-unicode-attack-github-npm-vscode
• https://github.com/advisories/GHSA-64fw-jx9p-5j24
• https://thehackernews.com/
• https://thehackernews.com/p/upcoming-hacker-news-webinars.html
• https://thehackernews.com/search/label/Threat%20Intelligence
• https://thehackernews.com/search/label/Vulnerability