Vai al contenuto

RubyGems: 16 pacchetti malevoli rubano credenziali

Redazione Xion IT GroupRubyGemssupply chaincybersicurezzaopen source

Una nuova campagna malevola scoperta il 15 agosto 2026 ha sfruttato RubyGems, il repository dei pacchetti Ruby, per distribuire componenti infetti mascherati da dipendenze legittime. Per le aziende il punto non è solo Ruby: il caso dimostra quanto sia diventato rischioso installare librerie open source senza controlli, perché un semplice errore di battitura può trasformarsi in furto di credenziali, dati aziendali e perfino wallet di criptovalute.

Cosa è successo

Secondo quanto riportato da The Hacker News il 18 agosto 2026, i ricercatori di OpenSourceMalware hanno individuato una campagna di typosquatting su RubyGems, cioè la pubblicazione di pacchetti con nomi molto simili a quelli originali, pensati per ingannare sviluppatori e sistemi automatizzati.

L’attività è tracciata con il nome StubMaker ed è stata scoperta il 15 agosto 2026. I pacchetti individuati sono 16 e, al momento della pubblicazione della notizia, erano già stati rimossi da RubyGems. I nomi segnalati sono:

L’obiettivo era colpire gli utenti che installano dipendenze Ruby, soprattutto in ambienti Windows, inducendoli a scaricare un pacchetto apparentemente plausibile ma in realtà malevolo.

Perché questa campagna è pericolosa

Il rischio non riguarda solo chi sviluppa software. Oggi moltissime aziende usano applicazioni interne, strumenti web, automazioni o servizi di terze parti che dipendono da componenti open source. Quando un pacchetto compromesso entra nella catena di fornitura software, l’impatto può propagarsi ben oltre il reparto IT.

In questo caso il malware era progettato per sottrarre:

Il furto di questi dati può portare a compromissioni molto concrete: accesso non autorizzato agli account aziendali, esfiltrazione di informazioni riservate, frodi finanziarie e ulteriori attacchi mirati.

Come funzionava l’attacco

L’elemento tecnico più interessante, e più insidioso, è il modo in cui il malware veniva eseguito. I pacchetti usavano un file chiamato extconf.rb, un meccanismo che Ruby esegue automaticamente durante l’installazione di alcune gemme, normalmente per configurare estensioni native.

In pratica, l’installazione appariva normale, ma dietro le quinte il pacchetto avviava il download di un loader da un rilascio GitHub. Da lì veniva eseguito un secondo payload, descritto come un infostealer basato su Go, con un componente DLL dedicato all’estrazione delle credenziali dai browser Chromium.

Un dettaglio importante è che l’installazione non mostrava un comportamento apertamente sospetto. Il pacchetto simulava una procedura di build regolare, generando file e script apparentemente innocui che restituivano esito positivo. In questo modo l’operazione sembrava pulita, mentre il lavoro reale avveniva nella fase di installazione automatica.

Per un’azienda, questa è la lezione principale: non basta “fidarsi del repository” o del fatto che un pacchetto si installi senza errori. Un software malevolo può inserirsi proprio nel flusso che gli sviluppatori considerano ordinario.

I punti deboli emersi nel caso RubyGems

La campagna è stata resa più efficace anche da alcune caratteristiche della piattaforma RubyGems evidenziate dai ricercatori.

In almeno due casi, brumdler e brundlef, gli attaccanti hanno sfruttato un comportamento noto del sistema: quando tutte le versioni di una gemma vengono ritirate, il namespace può tornare disponibile ed essere reclamato da altri utenti. Questo ha permesso di “rianimare” nomi che avrebbero dovuto essere considerati chiusi.

Inoltre, i ricercatori hanno segnalato che il campo Author può essere compilato come semplice testo non validato. In pratica, un attaccante può assegnare autori diversi a pacchetti pubblicati dallo stesso account, facendo sembrare scollegate operazioni che in realtà fanno capo allo stesso soggetto.

Questi aspetti contano molto per chi gestisce fornitori software o team di sviluppo interni: l’apparenza di legittimità, da sola, non è una garanzia. Nome del pacchetto, autore visibile e risultato positivo dell’installazione non bastano per parlare di sicurezza.

Non è un caso isolato: il problema è la software supply chain

La notizia si inserisce in una tendenza più ampia. Nello stesso periodo sono emerse anche altre campagne che hanno preso di mira l’ecosistema npm, segno che gli attaccanti continuano a preferire la catena di fornitura software come punto di ingresso.

Il motivo è semplice: colpire una libreria o un pacchetto è spesso più efficiente che colpire direttamente decine o centinaia di aziende. Se un componente malevolo entra in un progetto, può essere distribuito involontariamente in ambienti di sviluppo, test e produzione.

Per le PMI questo è un tema spesso sottovalutato. Si tende a pensare che la supply chain software riguardi solo grandi software house o organizzazioni enterprise. In realtà basta un piccolo gestionale sviluppato su misura, un’integrazione web, un plugin o uno script di automazione per esporre l’azienda allo stesso tipo di rischio.

Cosa significa per la tua azienda

Se la tua impresa ha un gestionale personalizzato, un sito con funzioni evolute, applicazioni interne o collabora con software house esterne, questo episodio è un promemoria molto concreto.

Ecco le misure più utili, in ordine pratico:

  1. Controlla chi installa dipendenze e da dove
    Gli sviluppatori e i fornitori dovrebbero poter installare librerie solo con procedure definite. Evita installazioni “al volo” in produzione o su PC non controllati.

  2. Blocca l’uso di account Windows senza adeguate protezioni
    Questa campagna era orientata a Windows e mirava a browser, wallet e Telegram Desktop. Se su un PC aziendale sono presenti credenziali salvate, dati di pagamento o accessi amministrativi, il danno potenziale cresce molto.

  3. Riduci al minimo le password salvate nel browser
    È una comodità diffusa, ma resta uno dei bersagli più appetibili per gli infostealer. Dove possibile, usa password manager aziendali e autenticazione a più fattori.

  4. Verifica i processi dei fornitori software
    Se un partner sviluppa o manutiene applicativi per la tua azienda, chiedi come controlla le dipendenze open source, come gestisce gli aggiornamenti e quali verifiche esegue prima del rilascio.

  5. Monitora gli endpoint e mantieni un inventario aggiornato
    Sapere quali PC installano strumenti di sviluppo, quali browser sono in uso e quali applicazioni desktop conservano dati sensibili è essenziale. Un buon servizio di gestione centralizzata delle postazioni riduce molto le zone d’ombra.

  6. Prepara un piano di contenimento
    Se un endpoint viene compromesso, servono procedure rapide: isolamento della macchina, reset delle credenziali, verifica delle sessioni attive, controllo dei log e ripristino dei dati se necessario. In quest’ottica sono fondamentali sia la sicurezza informatica sia un sistema affidabile di backup remoto.

  7. Fai formazione anche ai non tecnici
    Responsabili amministrativi, commerciali e di direzione spesso usano gli stessi browser dove sono memorizzate credenziali cruciali. Un attacco partito dal reparto sviluppo può avere conseguenze trasversali su tutta l’organizzazione.

I segnali da non ignorare

Anche senza entrare nei dettagli tecnici, ci sono alcuni indicatori che meritano attenzione da parte di chi coordina l’IT aziendale:

Questi elementi, presi singolarmente, non provano una compromissione. Ma ignorarli significa spesso accorgersi del problema troppo tardi.

La lezione per manager e titolari

Il caso StubMaker mostra che la sicurezza non dipende solo da firewall e antivirus. Oggi una parte del rischio nasce da componenti perfettamente integrati nel lavoro quotidiano: librerie open source, repository pubblici, automatismi di installazione, strumenti di sviluppo e applicazioni desktop.

Per chi guida un’azienda, la domanda giusta non è “usiamo Ruby?” ma “abbiamo un controllo reale sul software che entra nei nostri sistemi?”. Se la risposta è incerta, conviene intervenire ora, prima che un errore di battitura o un aggiornamento apparentemente legittimo si trasformino in un incidente operativo.

Domande frequenti

La mia azienda non sviluppa in Ruby: devo preoccuparmi lo stesso?

Sì, se usi software personalizzato, applicazioni di terzi o fornitori che si appoggiano a componenti open source. Il rischio riguarda la catena di fornitura software nel suo complesso, non solo Ruby.

Basta rimuovere il pacchetto malevolo per stare tranquilli?

Non sempre. Se il componente è stato installato ed eseguito, potrebbe aver già sottratto credenziali o dati. Serve verificare i sistemi coinvolti e reimpostare gli accessi a rischio.

Qual è la misura più urgente per una PMI?

Mettere sotto controllo endpoint, credenziali e procedure di aggiornamento software. Anche poche regole chiare, applicate bene, riducono molto il rischio operativo.

Vuoi proteggere e far crescere l'IT della tua azienda?

Parliamone: un consulente Xion analizza gratuitamente la tua situazione.

Contattaci+39 02 40709414