Immagine illustrativa generata con AI
Pacchetti npm per calendari nascondono RedShell, il beacon Linux di RedC2 4.0
Pacchetti npm malevoli nascondono RedShell, beacon Linux per RedC2 4.0. Scoperta di Trend Micro sui rischi per sviluppatori e aziende.
Testo generato da intelligenza artificiale, pubblicato senza revisione umana. Trasparenza IA
Un’importazione basta per avviare il malware
Ricercatori di TrendAI, divisione enterprise di Trend Micro, hanno individuato un gruppo di pacchetti npm trojanizzati che si presentano come utility per calendari, date e gestione delle cosiddette “streak”. La scoperta è stata resa nota il 21 agosto 2026.
I moduli svolgono effettivamente le funzioni dichiarate, ma contengono anche il beacon Linux RedShell, componente del framework di comando e controllo RedC2 4.0. Il payload viene eseguito automaticamente quando il modulo viene caricato.
Non serve quindi uno script postinstall, né l’invocazione esplicita di una funzione. È sufficiente che l’applicazione importi il pacchetto, anche indirettamente attraverso una dipendenza transitiva.
Il meccanismo amplia sensibilmente la superficie d’attacco. Uno sviluppatore potrebbe non aver mai aggiunto direttamente una delle utility all’applicazione, ma riceverla comunque nell’albero delle dipendenze e attivare il malware durante l’avvio del processo Node.js.
I pacchetti e i file binari da cercare
I pacchetti e le versioni individuate sono:
[email protected][email protected][email protected][email protected][email protected][email protected][email protected][email protected][email protected][email protected][email protected][email protected][email protected][email protected][email protected]
Il codice malevolo è inserito in dist/index.mjs, che mantiene le esportazioni delle utility legittime e svolge contemporaneamente il ruolo di loader.
Durante il caricamento, il file individua il componente binario incluso nel pacchetto, ne modifica i permessi per renderlo eseguibile e lo avvia come processo distaccato in background. L’applicazione può quindi continuare a usare le funzioni sulle date senza mostrare segnali evidenti all’utente.
Il payload può avere nomi differenti:
math-core.binmath-calc.bincalc-math.datcalc-cache.bincalc.bincalc-mapping.bin
I file si trovano direttamente nella directory dist/ oppure in dist/internal/. Il contenuto, secondo l’analisi, è lo stesso beacon Linux RedShell per RedC2 4.0.
Che cosa può fare RedShell su un host Linux
RedShell raccoglie informazioni di base sul sistema compromesso e le invia all’infrastruttura di comando e controllo durante il primo “check-in”. In seguito rimane in attesa di istruzioni, eseguendole tramite /bin/sh e restituendo i risultati all’operatore.
Le capacità osservate comprendono accesso interattivo al terminale, gestione dei file, trasferimento di dati e distribuzione di payload aggiuntivi. Il beacon può inoltre raccogliere chiavi SSH e credenziali memorizzate nei browser.
Tra le funzioni disponibili figurano anche:
- ricognizione del sistema e della rete;
- esecuzione di comandi;
- meccanismi di persistenza;
- esecuzione in memoria di file ELF;
- esecuzione di Beacon Object Files;
- esecuzione di assembly .NET e shellcode;
- proxy SOCKS5;
- pivoting verso altri sistemi della rete.
L’insieme delle funzionalità va oltre il semplice accesso remoto. Un host infettato può diventare un punto d’appoggio per raccogliere segreti, spostarsi nella rete aziendale, inoltrare traffico e caricare ulteriori componenti.
Le varianti di RedC2 destinate a Windows e macOS offrono capacità analoghe per la ricognizione dell’host, l’enumerazione degli utenti, le operazioni sui file e la raccolta di dati. La versione Windows include anche funzioni per aggirare l’UAC, individuare e manomettere prodotti antivirus ed endpoint detection, eseguire codice in memoria e facilitare il movimento laterale. Queste capacità non risultano disponibili nella variante macOS.
RedC2 4.0 integra un agente basato su LLM
RedC2 4.0 viene promosso come framework multipiattaforma per Windows, macOS e Linux. L’attore “MarlboroMan” lo ha pubblicizzato su Hack Forums all’inizio di giugno 2026, descrivendolo come un prodotto progettato con l’elusione come obiettivo centrale.
La versione 3.0 era stata venduta a gennaio, mentre la 2.0 era stata rilasciata ad agosto 2025. RedShell Linux è stato introdotto con la versione 4.0, segnalando un’evoluzione attiva del toolkit.
Il framework viene inoltre commercializzato attraverso il sito clearnet Red Offsec, dove è proposto a 99,99 dollari come prodotto multi-OS e multilinguaggio. I termini di servizio vietano formalmente l’uso contro sistemi non autorizzati, ma tali clausole non impediscono l’impiego criminale dello strumento.
Il pacchetto comprende RedC2 EXT, un’estensione a riga di comando, e Red Agent, un componente basato su un large language model. Quest’ultimo consente all’operatore di descrivere in linguaggio naturale l’attività desiderata, come una ricognizione della rete o il dumping delle credenziali.
Il sistema converte l’intento in sequenze di comandi da inviare ai beacon. L’automazione non elimina la necessità di accesso iniziale, ma può ridurre le competenze richieste per gestire operazioni post-compromissione articolate e multi-fase.
Rischio per sviluppatori e infrastrutture aziendali
Il rischio riguarda soprattutto i sistemi Linux che installano uno dei pacchetti elencati o lo ricevono attraverso una dipendenza indiretta. La natura funzionante delle utility può ritardare l’individuazione: il modulo produce il risultato atteso, mentre il loader esegue il beacon in parallelo.
La compromissione può causare esecuzione arbitraria di comandi, furto di credenziali, raccolta di chiavi SSH, accesso ai file e installazione di payload successivi. In ambienti aziendali, proxy SOCKS5 e pivoting possono trasformare una singola workstation o un server di build in un punto d’accesso verso sistemi interni.
La scoperta è avvenuta inoltre vicino a un altro attacco alla supply chain che ha coinvolto tre crate Rust legittimi: [email protected], [email protected] e [email protected].
In quel caso, la dipendenza malevola proc-macro1 poteva eseguire automaticamente malware multipiattaforma durante le build Cargo. Il componente profilava il dispositivo, censiva i browser basati su Chromium, stabiliva la persistenza, contattava l’infrastruttura degli attaccanti e scaricava ulteriori payload.
È sospettato il furto delle credenziali usate dal maintainer per pubblicare i pacchetti. Sono state osservate anche sovrapposizioni infrastrutturali con precedenti attacchi alla supply chain contro Mastra e Axios, associati ad attori nordcoreani.
Controlli immediati e bonifica
Non è nota una patch specifica per i pacchetti npm coinvolti. Le organizzazioni dovrebbero bloccarli e rimuoverli, verificando sia le dipendenze dichiarate direttamente sia l’intero albero transitivo.
I controlli prioritari sono:
- analizzare
package-lock.json, altri lockfile npm e le cache locali; - cercare i file sospetti nelle directory
dist/edist/internal/; - controllare processi Linux anomali avviati in background;
- verificare connessioni verso infrastrutture C2 sconosciute;
- esaminare persistenza, uso anomalo di
/bin/sh, proxy SOCKS5 e pivoting; - isolare gli host sospetti prima della bonifica;
- ruotare password, token, chiavi SSH e altri segreti presenti sui sistemi;
- conservare le evidenze utili all’analisi forense.
Per prevenire casi analoghi servono il pinning delle versioni, allowlist dei pacchetti, scansioni prima dell’installazione e controlli sulle modifiche pubblicate nei repository. Gli ambienti Cargo dovrebbero inoltre sottoporre a verifica specifica le dipendenze proc-macro, perché possono eseguire codice durante la compilazione.
Fonti
Questo articolo è una rielaborazione originale basata sulle fonti seguenti.
