In pochi giorni un threat actor cinese noto come Red Heron ha trasformato un proof-of-concept pubblico in un framework automatizzato di attacco contro Gitea, la piattaforma open source di gestione del codice sorgente. Il risultato è stata la scansione di 1.386 istanze Gitea in sette paesi e compromissioni confermate in Canada, Argentina, Taiwan, Stati Uniti e Sri Lanka. A scoprire quanto accaduto è stata l’Acronis Threat Research Unit (TRU), dopo aver individuato, durante attività di threat hunting di routine, un impianto Linux che soprannominato JITTERLY. I ricercatori sono quindi andati a ritroso nel tempo, fino a trovare il 4 agosto 2026 un server di staging dell'attaccante che era esposto senza autenticazione. All’interno c’erano strumenti di exploitation, database di ricognizione, cronologia dei comandi, repository rubate e malware. Questa scoperta ha offerto una visibilità rara sull'intera catena operativa di Red Heron, dalla selezione dei bersagli fino al post-exploitation.

La falla di Gitea (tutte le versioni dalla 1.17 alla 1.27.0) al centro della campagna è la CVE-2026-60004, apre all’esecuzione di codice da remoto e ha un punteggio CVSS di 9.8. Il problema riguarda la funzione che applica le patch inviate dagli utenti ai repository (diffpatch). Per elaborarle, il software lavora su una copia temporanea "nuda" del repository (un clone bare, cioè privo della normale cartella di lavoro e composto solo dai file interni di gestione di Git) e, quando serve, prova a unire automaticamente le modifiche in conflitto.

Un attaccante può sfruttare questo meccanismo inviando due volte la stessa patch, leggermente modificata per contenere codice malevolo. Il primo invio posiziona il payload in un'area interna di Git normalmente non scritta su disco; il secondo genera un conflitto che costringe il sistema a scriverlo comunque, all’interno della cartella che Git usa per i propri script di automazione interni (gli hook, eseguiti automaticamente in certe fasi del suo funzionamento). Poiché nel clone bare quella cartella coincide con la radice stessa del repository, il file malevolo finisce esattamente dove Git va a cercare uno di questi script, e viene eseguito con i permessi del servizio Gitea alla prima occasione utile.

L'API diffpatch richiede in teoria permessi di scrittura sul repository, ma Gitea ha la registrazione aperta abilitata di default: su istanze configurate in questo modo, un attaccante esterno può completare l'intera catena mediante la registrazione di un account, la creazione di un repository, l’invio di payload, e ottenere come risultato l'esecuzione di codice senza bisogno di credenziali preesistenti. Gitea ha corretto il problema nella versione 1.27.1 pubblicata il 27 luglio 2026, in cui ha cambiato il tipo di clone temporaneo usato per elaborare le patch in modo che la cartella degli hook non coincida più con la radice del repository.

Dal PoC alla scansione di massa

Il 29 luglio l'attaccante ha scaricato da GitHub un proof-of-concept pubblico (HORKimhab/CVE-2026-60004) il giorno successivo alla sua pubblicazione. La cronologia dei comandi digitati nell'editor di testo recuperata dal server di staging dell'attaccante mostra tentativi ripetuti, prima su un ambiente di prova locale e poi contro bersagli reali fuori da Taiwan. Il 30 luglio Red Heron aveva già completato una scansione di 1.386 istanze Gitea in sette paesi, mediante 50 processi in parallelo per verificare i potenziali obiettivi con la registrazione aperta; i risultati sono stati raccolti in un file di elenco. Il giorno seguente è stata compilata una lista separata, focalizzata su Taiwan, con 477 istanze; i dati indicano che la lista è stata fornita dall'esterno e che non era generata dalla scansione dell'operatore, da qui l’ipotesi che dietro a Red Heron operino più persone. Nella cronologia sono stati trovati anche un ulteriore script che sincronizza i dati rubati dal server di staging verso una macchina separata, e un comando di connessione a un secondo server.

All'inizio di agosto lo strumento era già diventato un framework completo, capace di leggere una lista di target, registrare automaticamente account con nomi generati in uno schema fisso, sfruttare ogni target, estrarre i repository direttamente dal disco del server e ripulire le tracce dal database di Gitea. Il 3 agosto è partita una campagna automatizzata contro un sottoinsieme di 50 target taiwanesi, con risultati misti e diversi tentativi falliti nel trasferimento dei repository; il giorno successivo sono comparse cinque nuove vittime tra i dati scaricati, mentre l'operatore otteneva accesso con privilegi massimi tramite il protocollo SSH a un NAS Synology compromesso a Taiwan.

Il precedente

La cronologia dei comandi mostra che, prima ancora di sfruttare Gitea, l'attaccante aveva condotto una campagna contro 18 siti web in 10 paesi, 17 dei quali basati su Joomla (un altro sistema di gestione di contenuti molto diffuso), mediante uno script con un'opzione che apre una shell da remoto. Si tratta di un comportamento coerente con l'installazione di una backdoor a seguito di una compromissione.

La vulnerabilità Joomla specifica non è stata identificata perché il codice dell'exploit non è stato recuperato, ma la finestra temporale coincide con diverse falle critiche divulgate a metà 2026. Tra le papabili vittime figurano una nota società di consulenza educativa indiana e un fornitore statunitense di servizi IT gestiti.

Da notare che ciascun target scansionato è stato classificato in categorie scritte in cinese semplificato, con uno schema tipico dei sistemi di intelligence: difesa/militare, elezioni/sistemi di voto, energia, aerospazio, telecomunicazioni, governo/servizi pubblici, ricerca. I 128 obiettivi sono confluiti in una lista prioritaria di attacco. Tra le vittime compaiono anche server con nomi riferiti a "Voter Dashboard" (pannelli di gestione elettorale), oggetto di 14 sessioni di attacco distinte, e un'organizzazione affiliata a un partito politico statunitense, individuata durante la scansione ma non sfruttabile perché protetta da autenticazione.

Red Heron ha installato una backdoor persistente sulle vittime compromesse, sbloccata da una chiave di autenticazione digitata manualmente  a ogni accesso da parte dell'operatore.

Tra i casi documentati spicca una società energetica canadese attiva nelle rinnovabili, con 22 sessioni di attacco: l'attaccante ha mappato l'intera infrastruttura, individuato un account dipendente legittimo e scaricato l'intero stack applicativo dell'azienda, inclusi il sistema per le risorse umane, il gestionale clienti, i sistemi di autenticazione, le credenziali e le chiavi di accesso conservate nella configurazione di Gitea. Segue per volume di dati rubati un'azienda taiwanese di automazione industriale, da cui sono stati prelevati centinaia di repository che includevano un prodotto di sorveglianza e monitoraggio, uno strumento per la gestione di impianti industriali, integrazioni con dispositivi IoT e uno strumento per intercettare il traffico di rete.

C’è anche un caso particolarmente significativo per il movimento laterale, che riguarda un NAS Synology taiwanese. Partendo da un semplice accesso via Gitea, l'attaccante ha ottenuto un accesso amministrativo completo al software Proxmox usato per gestire un gruppo di tre server virtuali collegati tra loro. Da lì ha caricato file su tutti e tre i server e avviato il backup completo delle macchine virtuali.

Un malware pensato per restare in esecuzione

L'impianto Linux JITTERLY (un malware pensato per restare in esecuzione sul sistema compromesso e ricevere comandi da remoto) è scritto in linguaggio C++ e condivide protocollo, struttura della configurazione e comandi con l'agente Linux del framework open source Adaptix C2, uno strumento pubblico normalmente usato per simulare attacchi in contesti di sicurezza legittimi. All'avvio si nasconde eseguendo la tecnica standard con cui i processi Linux si staccano dal terminale e diventano invisibili all'utente, verifica se ha i permessi massimi sul sistema e, in quel caso, si copia in una posizione di sistema con un nome innocuo, per poi ripartire da lì evitando di ripetere l'operazione ogni volta.

Il traffico verso il centro di comando dell'attaccante viaggia su connessioni di rete dirette, con i dati cifrati mediante crittografia AES-128-GCM e una chiave scambiata al primo collegamento. L'indirizzo del server di comando è scritto in chiaro dentro al file del malware. L'impianto supporta oltre 30 comandi, tra cui l'esecuzione di programmi, il furto di file suddivisi in piccoli pacchetti per non dare nell'occhio, l'apertura di canali di rete per usare il sistema compromesso come ponte verso altri computer della stessa rete, e un terminale interattivo completo che consente all'operatore di lavorare sul sistema come se fosse seduto davanti alla tastiera.

Analizzando JITTERLY, gli esperti di Acronis hanno individuato una funzione che decifra un blocco di dati nascosto nel file del malware: si tratta di una libreria software di 49 KB, mai documentata prima e battezzata SIXZUT. Una volta caricata, questa libreria viene scritta su disco con un nome che imita quello di un componente grafico legittimo di sistema, e il suo percorso viene inserito in un file di configurazione che forza ogni programma avviato nel sistema a caricarla automaticamente all'avvio, riproponendo la stessa tecnica alla base dei rootkit. Un file di blocco, mascherato da elemento tecnico dell'interfaccia grafica, impedisce che due copie del rootkit si modifichino a vicenda per errore.

SIXZUT intercetta quindici funzioni di sistema usate per leggere file, cartelle e connessioni di rete, per nascondere file, processi e collegamenti attivi a chi ispeziona la macchina. La configurazione interna, cifrata e verificata con un controllo di integrità, definisce fino a 128 combinazioni di indirizzo e porta da occultare; nel campione analizzato non conteneva voci già impostate, segno che secondo Acronis TRU può indicare un modello distribuito vuoto, in attesa di essere configurato da remoto. Sul fronte della rete, il rootkit copre tutti e tre i modi in cui un sistema Linux mostra le connessioni attive: intercetta le informazioni lette dagli strumenti di diagnostica di rete più comuni. Anche la funzione che termina i processi viene manomessa: se qualcuno prova a chiudere il malware con un comando standard, il sistema risponde come se quel processo non esistesse, senza mai interromperlo realmente. Se al riavvio il file dell'impianto risultasse assente, lo stesso rootkit lo rilancerebbe in automatico, dato che ogni programma del sistema lo carica appena parte.

Attribuzione e mitigazione

Acronis TRU attribuisce la campagna a un threat actor di lingua cinese nell’ambito di una campagna di tipo statale. Il gruppo si affida esclusivamente a strumenti pubblici e open source e non è stato rilevato alcun collegamento diretto con gruppi già noti.

Per le organizzazioni che gestiscono istanze Gitea in autonomia (self-hosted, cioè installate su server propri e non su un servizio cloud gestito da terzi), Acronis TRU raccomanda l'aggiornamento immediato alla versione 1.27.1 o successiva, la disattivazione della registrazione aperta dove non necessaria e la restrizione dell'accesso alla funzione diffpatch. Chi sospetta una compromissione pregressa dovrebbe verificare account e repository creati dopo la pubblicazione dell'advisory, controllare i log per richieste anomale verso la funzione diffpatch o verso l'endpoint delle metriche con parametri non familiari, e cercare processi shell generati da Gitea, comportamento che il servizio non ha motivo di mostrare in condizioni normali. Vanno inoltre verificate eventuali modifiche al file che forza il caricamento automatico di librerie di sistema, in cerca di artefatti del rootkit. In caso di compromissione confermata, Acronis TRU consiglia la ricostruzione completa dei sistemi proprio per la capacità di SIXZUT di ripristinarsi.