Una nuova campagna scoperta nel registro npm mostra quanto sia concreto il rischio della supply chain software: otto pacchetti malevoli, scaricati in totale 40.767 volte, sono stati usati per distribuire trojan di accesso remoto e strumenti per rubare dati. Anche se la vicenda nasce nel mondo degli sviluppatori, riguarda direttamente qualsiasi azienda che usi software web, applicazioni interne o fornitori che lavorano con JavaScript e Node.js.
Il punto pratico è semplice: oggi un attacco non deve più colpire direttamente la vostra azienda. Può entrare attraverso una dipendenza software apparentemente innocua, installata automaticamente durante sviluppo, aggiornamenti o manutenzione.
Cosa è successo
Il 7 ottobre 2026 The Hacker News ha riportato i risultati di un’indagine di CloudSEK e Checkmarx su una campagna ribattezzata MALFEX. Secondo i ricercatori, un singolo attore avrebbe pubblicato 12 pacchetti npm a partire da agosto 2023, di cui otto identificati come malevoli.
I pacchetti individuati sono:
- tlxbnhd
- tldriver
- mxdriver
- img-to-native
- native-runner
- function-flag
- function-color
- cdn-img-fetch
Al momento della segnalazione, alcuni pacchetti risultavano ancora online, tra cui function-flag, function-color e cdn-img-fetch.
Nel complesso, questi pacchetti hanno totalizzato 40.767 download. Il caso più rilevante è function-flag, che da solo conta 37.419 download. La fonte indica che il pacchetto è stato pubblicato per la prima volta a luglio 2024 e che l’ultima versione è stata rilasciata il 4 agosto 2025.
Perché questa campagna è diversa dal solito malware
Non parliamo del classico allegato malevolo o di un link di phishing. Qui il vettore è il meccanismo di fiducia su cui si basa lo sviluppo moderno: librerie condivise, dipendenze, aggiornamenti automatizzati e script eseguiti durante l’installazione.
Nel mondo Node.js e npm è normale importare pacchetti di terze parti per velocizzare il lavoro. Il problema è che questa comodità può trasformarsi in una porta d’ingresso se un modulo contiene codice nascosto o se attiva comandi al momento dell’installazione.
Secondo l’analisi citata, la campagna usava tre percorsi di infezione distinti su sistemi Windows:
- un loader per installare Overlord, un RAT open source scritto in Go;
- una catena che installa movinlike, uno stealer in Node.js rivolto a Discord, browser, Telegram e wallet di criptovalute;
- un downloader, cioè un componente incaricato di recuperare altri payload da remoto.
In altre parole, il pacchetto npm non era necessariamente il malware finale: spesso era il primo anello di una catena più lunga.
Come avveniva l’infezione
L’aspetto più insidioso è l’uso di meccanismi perfettamente compatibili con il funzionamento di npm, come i lifecycle hook e gli script postinstall. Sono funzioni legittime del gestore pacchetti, ma possono essere abusate per eseguire codice senza che lo sviluppatore se ne accorga subito.
Tre pacchetti — tlxbnhd, tldriver e mxdriver — avrebbero funzionato come loader di Overlord RAT, scaricando ed eseguendo un file Windows.
Un secondo gruppo, tra cui img-to-native, dipendeva da cdn-img-fetch per recuperare ed eseguire un binario Go, usato poi per scaricare lo stealer in Node.js.
Il caso più emblematico resta function-flag. Nella versione analizzata dai ricercatori, il pacchetto includeva uno script postinstall che eseguiva un payload JavaScript capace di scaricare altro codice da un server remoto. Ogni versione, inoltre, sarebbe stata collegata a una posizione diversa del payload, un dettaglio che rende più difficile bloccare l’attacco con indicatori statici.
Anche function-color è significativo: non trasportava direttamente un payload, ma dichiarava function-flag come dipendenza. È una tecnica frequente nelle supply chain compromise: il pacchetto “visibile” sembra innocuo, mentre il comportamento malevolo risiede più in profondità.
Cosa installavano i pacchetti malevoli
I due nomi da ricordare sono Overlord RAT e movinlike.
Un RAT consente il controllo remoto del sistema compromesso. Tradotto in termini aziendali, significa che un attaccante può impartire comandi, scaricare altri strumenti, mantenere accesso persistente e muoversi nella rete interna.
Uno stealer, invece, punta soprattutto al furto di informazioni: credenziali salvate nei browser, token di accesso, dati da applicazioni di messaggistica, file di configurazione e, in alcuni casi, portafogli crypto. Anche se la vostra azienda non usa criptovalute, il rischio reale sono account compromessi, accessi riutilizzati e furto di sessioni.
Per una PMI, le conseguenze possono essere molto concrete:
- accesso agli account cloud aziendali;
- furto di credenziali di posta e VPN;
- compromissione di PC usati da sviluppatori o consulenti IT;
- attacchi successivi verso server, NAS o ambienti di produzione.
Un segnale più ampio: la supply chain resta il bersaglio preferito
La notizia non va letta come un caso isolato. È l’ennesima conferma di una tendenza ormai strutturale: gli attaccanti preferiscono colpire un fornitore, una libreria o un componente condiviso, perché da lì possono raggiungere molte vittime con poco sforzo.
La fonte segnala anche che Overlord RAT è stato osservato in altre due campagne a partire da luglio 2026: una legata allo sfruttamento di vulnerabilità WordPress e un’altra su macOS tramite un falso installer di Zoom. Questo non prova un’unica regia, ma mostra come gli stessi strumenti o le stesse famiglie di malware circolino su vettori diversi.
Per chi gestisce un’azienda, il messaggio è chiaro: non basta più pensare alla sicurezza come a un antivirus installato sui PC. Bisogna verificare anche come viene costruito, aggiornato e mantenuto il software che entra in azienda.
Cosa significa per la tua azienda
Anche se non avete un team di sviluppo interno, potreste essere esposti in almeno tre modi: usate software realizzato con Node.js, avete un fornitore che sviluppa portali o integrazioni su misura, oppure affidate manutenzione e aggiornamenti a terzi.
Ecco le misure più utili, in ordine pratico.
1. Chiedete visibilità ai vostri fornitori software
Se un partner sviluppa applicazioni web o strumenti interni per voi, domandate come gestisce le dipendenze di terze parti, chi approva gli aggiornamenti e se esegue controlli automatici sui pacchetti open source.
2. Limitate gli script di installazione dove possibile
Nel mondo npm gli script postinstall sono spesso il punto di ingresso. In ambienti di build o test, ha senso ridurre al minimo l’esecuzione automatica di script non necessari e separare i sistemi di sviluppo dai PC usati per attività amministrative.
3. Proteggete in modo speciale le postazioni tecniche
I computer di sviluppatori, consulenti e amministratori di sistema meritano più attenzione della media: account separati, privilegi ridotti, monitoraggio, backup e policy più rigorose. Sono bersagli ad alto valore.
4. Tenete sotto controllo i download anomali e le esecuzioni da AppData
Nel caso descritto, alcuni file venivano salvati ed eseguiti da percorsi utente come %APPDATA%. È un comportamento da monitorare con strumenti di sicurezza endpoint e con una gestione centralizzata delle postazioni. Se vi serve supporto su questo fronte, può essere utile una soluzione di desktop IT management.
5. Preparatevi al peggiore dei casi: furto credenziali
Se sospettate che una postazione tecnica sia stata compromessa, non basta “pulire il PC”. Occorre ruotare password, token, chiavi API, accessi amministrativi e credenziali salvate nei browser.
6. Verificate backup e ripristino
Anche quando il malware nasce come stealer o RAT, può diventare il punto di partenza per cifratura, sabotaggio o cancellazione di dati. Un piano di remote backup ben gestito riduce tempi di fermo e danni operativi.
7. Rafforzate il presidio di sicurezza continuativo
Questi attacchi non si fermano con una sola attività una tantum. Servono controllo periodico, patching, verifica degli endpoint, analisi degli alert e procedure di risposta. Per molte PMI la strada più realistica è un servizio continuativo di sicurezza informatica.
Come capire se il rischio vi riguarda davvero
Non tutte le aziende hanno la stessa esposizione, ma dovreste alzare subito l’attenzione se vi riconoscete in uno di questi scenari:
- avete applicazioni interne o siti gestiti con stack JavaScript/Node.js;
- uno sviluppatore o un consulente aggiorna spesso dipendenze npm;
- usate pipeline automatiche di build o deploy;
- sulle postazioni tecniche sono presenti credenziali per cloud, hosting, repository Git o ambienti di produzione;
- i fornitori lavorano direttamente con accesso alla vostra infrastruttura.
In questi casi, il tema non è solo “evitare il malware”, ma impedire che un problema su una singola postazione si trasformi in un incidente aziendale più ampio.
La lezione per manager e imprenditori
La sicurezza della supply chain software non è un tema riservato alle grandi software house. Oggi coinvolge anche studi professionali, aziende di servizi, realtà manifatturiere e PMI che hanno un gestionale personalizzato, un e-commerce, un portale clienti o integrazioni sviluppate su misura.
Il vero cambiamento culturale è questo: quando acquistate o fate sviluppare software, dovete considerare anche il processo con cui quel software viene assemblato. Librerie open source, dipendenze, script automatici e aggiornamenti sono parte del rischio operativo tanto quanto firewall e antivirus.
Chi governa l’IT in modo maturo non si limita a chiedere “funziona?”, ma anche “da cosa dipende?”, “chi lo aggiorna?” e “come ce ne accorgiamo se qualcosa va storto?”.
Domande frequenti
Se non sviluppiamo software internamente, possiamo ignorare questa notizia?
No. Se usate applicazioni sviluppate da fornitori o consulenti, il rischio può arrivare comunque tramite aggiornamenti, manutenzione o postazioni tecniche collegate ai vostri sistemi.
Un antivirus basta a fermare questo tipo di attacco?
Non sempre. In campagne di supply chain il codice malevolo può entrare tramite strumenti legittimi e attivarsi durante installazione o aggiornamento. Servono anche controllo degli endpoint, policy e monitoraggio.
Cosa dovremmo fare oggi, in concreto?
Verificate con i fornitori se usano npm o Node.js, controllate le postazioni tecniche più esposte, ruotate le credenziali sensibili se avete dubbi e assicuratevi di avere backup e risposta agli incidenti adeguati.