RedC2 infetta Linux via npm e usa l’AI per automatizzare furto credenziali e pivoting

🛡️ Executive Summary

• Pacchetti npm trojanizzati eseguono RedShell Linux al semplice import del modulo, senza lifecycle hook e aggirando quindi controlli basati su –ignore-scripts.
• RedC2 offre shell, furto di credenziali, esfiltrazione, esecuzione fileless, SOCKS5, port forwarding e quattro meccanismi di persistenza su Linux.
• Red Agent integra un LLM nel C2 e converte istruzioni in linguaggio naturale in sequenze operative, abbassando la competenza necessaria agli attaccanti.

RedC2 porta l’intelligenza artificiale direttamente dentro una catena di compromissione Linux distribuita attraverso l’ecosistema npm. L’analisi di TrendAI Research descrive un cluster di pacchetti apparentemente innocui per calcoli di calendario e streak che contiene funzioni realmente operative, ma nasconde anche un binario ELF identificato come RedShell, implant nativo introdotto con RedC2 4.0. La caratteristica più pericolosa è il metodo di esecuzione: non serve uno script postinstall, perché basta importare il modulo, anche come dipendenza transitiva, per avviare il payload. Una volta dentro il sistema, RedShell permette raccolta di credenziali, pivoting, persistenza ed esecuzione fileless, mentre Red Agent traduce prompt in linguaggio naturale in sequenze di comandi offensivi.

I pacchetti npm funzionano davvero mentre eseguono il payload Linux

La catena di infezione analizzata da TrendAI Research sfrutta una tecnica particolarmente efficace perché i pacchetti malevoli non sono semplici contenitori vuoti. Moduli come streak-metrics-math, streak-map-cache, streak-calc-math e streak-kit-map implementano realmente funzioni di calcolo delle date e delle serie temporali dichiarate nella documentazione. Il codice legittimo si trova in dist/internal/daymath.mjs, mentre nella stessa struttura viene inserito un binario Linux con nomi apparentemente compatibili con un acceleratore nativo, tra cui math-core.bin, calc-cache.bin e calc-mapping.bin. Questa strategia rende più difficile individuare il comportamento malevolo con una verifica superficiale del pacchetto. La tecnica si inserisce in una tendenza già osservata negli attacchi npm e NuGet che trasformano normali dipendenze in vettori di compromissione, ma RedC2 aggiunge un elemento particolarmente insidioso: il payload viene eseguito senza dipendere dai tradizionali lifecycle script di npm.

Un semplice import basta e –ignore-scripts non protegge

Il loader è contenuto nel file dist/index.mjs e utilizza una funzione asincrona immediatamente eseguita al caricamento del modulo. Non è necessario chiamare una funzione esportata e non viene utilizzato alcun preinstall o postinstall. Questo significa che il parametro --ignore-scripts, spesso utilizzato per ridurre il rischio derivante da pacchetti npm non fidati, non blocca la catena. Basta che il modulo venga importato direttamente dall’applicazione o indirettamente da una dipendenza transitiva.

Il loader individua il binario attraverso import.meta.url, gli assegna permessi 0755, verifica l’hash SHA-256 contro un valore hardcoded e lo avvia tramite cp.spawn come processo detached. Il figlio viene separato dal processo Node originale e può quindi continuare a funzionare anche dopo la terminazione dell’applicazione che ha importato il pacchetto. È un modello diverso da quello osservato nell’attacco Sapphire Sleet contro oltre 140 pacchetti npm Mastra, dove il payload dipendeva ancora dall’esecuzione automatica di una fase di installazione. RedC2 sposta invece l’attivazione dentro il normale caricamento JavaScript.

RedShell trasforma Linux in un nodo completo del C2

Il binario distribuito dai pacchetti è RedShell, implant Linux introdotto con RedC2 4.0 nel giugno 2026. RedC2 viene pubblicizzato su Hack Forums come framework C2 multipiattaforma con supporto Windows, macOS e Linux, dashboard centralizzata, gestione multi-beacon e strumenti per esecuzione, raccolta e movimento laterale. Sul sistema compromesso RedShell raccoglie informazioni su utente, hostname, kernel, architettura, indirizzi IP e privilegi root, genera un identificativo persistente dell’installazione e apre una sessione verso l’infrastruttura C2.

I comandi principali viaggiano su TCP protetto da TLS, ulteriormente offuscato attraverso una routine custom basata su XOR e rotazione ROR1, mentre esfiltrazione e download di payload possono utilizzare HTTP e servizi esterni. L’architettura ricorda la crescente convergenza tra malware Linux e supply chain già osservata con IronWorm, capace di combinare npm, GitHub, ELF e rootkit eBPF, ma RedShell punta soprattutto sulla modularità operativa del framework.

SSH, browser e database diventano obiettivi immediati

Il set di comandi Linux mostra quanto l’implant sia orientato alla post-exploitation. RedShell può eseguire uname, id, ps, env, ss, enumerare utenti e sessioni, leggere file e trasferire directory complete. I comandi /ssh_keys e /creds cercano rispettivamente chiavi SSH e configurazioni e dati relativi alle credenziali dei browser, mentre /dbfind individua database attivi, porte aperte e file di configurazione. /dataextract raccoglie ricorsivamente i file e li invia al C2, mentre altri comandi permettono di caricare o scaricare archivi attraverso servizi esterni. Per una workstation di sviluppo Linux il rischio è particolarmente elevato: chiavi SSH, token Git, credenziali cloud e file .env possono permettere agli aggressori di passare rapidamente dal singolo host a repository, server e pipeline CI/CD. È lo stesso motivo per cui Atomic Arch aveva trasformato pacchetti AUR e npm in un ponte verso infostealer Linux, mostrando come gli ambienti degli sviluppatori rappresentino ormai bersagli privilegiati proprio per la quantità di segreti che concentrano.

Memfd e mmap permettono di eseguire payload senza salvarli normalmente su disco

RedShell dispone anche di funzioni per esecuzione fileless. Attraverso i comandi /memfd, l’operatore può trasferire un ELF in chunk Base64, ricostruirlo in memoria e lanciarlo utilizzando memfd_create, evitando la normale creazione di un eseguibile persistente nel filesystem. Una modalità analoga utilizza mmap per caricare ed eseguire shellcode. Sono presenti inoltre /stage, per scaricare ed eseguire script da URL, e /dlopen, che permette di caricare librerie condivise ed eseguire simboli specifici. Queste funzioni rendono il framework adatto a consegnare stage aggiuntivi mantenendo RedShell come implant iniziale relativamente stabile. La strategia riflette il progressivo passaggio del malware Linux da semplici script e miner a piattaforme complete di post-exploitation, già evidente nelle campagne npm capaci di selezionare payload nativi differenti per Linux, Windows e macOS.

Quattro sistemi di persistenza coprono shell, systemd e desktop

Per sopravvivere ai riavvii RedShell offre quattro meccanismi integrati di persistenza. /persist cron inserisce una voce @reboot nel crontab, /persist bashrc modifica ~/.bashrc, /persist systemd crea un servizio systemd a livello utente, mentre /persist xdg sfrutta una voce XDG autostart. La varietà permette all’operatore di adattarsi alla distribuzione e all’ambiente desktop presenti sul sistema compromesso. Le modifiche sono relativamente semplici e proprio per questo possono confondersi con configurazioni legittime se non esiste un baseline dell’host.

La presenza di un comando /persist remove consente inoltre di cancellare gli artefatti creati, utile per ridurre le tracce durante operazioni temporanee. In ambienti Linux aziendali il monitoraggio dovrebbe quindi concentrarsi non soltanto sui processi Node, ma anche su nuove unità systemd utente, modifiche anomale a .bashrc, crontab e file .desktop nelle directory di autostart.

SOCKS5 e port forwarding trasformano l’host in un ponte verso la rete interna

RedShell non si limita al furto locale. Il framework può avviare proxy SOCKS5, configurare TCP port forwarding e creare tunnel attraverso beacon presenti su reti differenti. Dalla versione RedC2 4.1 il sistema supporta anche cross-network shell tunnelling, nel quale un host compromesso può funzionare da relay verso un altro beacon senza che tra i due esista una connessione peer-to-peer diretta. In uno scenario aziendale questo significa che una workstation Linux compromessa attraverso una dipendenza npm può diventare un punto di accesso verso sistemi che non sono direttamente raggiungibili da Internet. Il passaggio dalla supply chain al pivoting interno mostra perché i repository open source rappresentino un moltiplicatore di rischio: il pacchetto malevolo non deve necessariamente contenere tutte le funzioni dell’attacco, ma soltanto consegnare un implant capace di aprire il resto dell’infrastruttura. La stessa evoluzione aveva portato Google ad avvertire che gli attacchi supply chain open source sono destinati ad aumentare, soprattutto contro ecosistemi nei quali una sola dipendenza può propagarsi attraverso migliaia di progetti.

Red Agent porta l’LLM direttamente dentro la console offensiva

L’elemento più nuovo è Red Agent. Non si tratta di un chatbot esterno utilizzato dall’operatore per chiedere quale comando eseguire, ma di un layer LLM integrato direttamente nel framework RedC2 e accessibile con il comando /ra. Secondo la documentazione analizzata da TrendAI, il modello conosce i comandi e le capacità dei beacon e applica una forma di keypoint analysis per trasformare un obiettivo espresso in linguaggio naturale in una sequenza ordinata di operazioni.

Una richiesta come individuare credenziali o mappare una rete può quindi essere scomposta automaticamente in ricognizione, enumerazione, raccolta e successiva esecuzione dei comandi necessari. È qui che l’AI modifica realmente la soglia di ingresso: non inventa nuove primitive offensive, ma nasconde la complessità operativa del C2 a chi lo utilizza. Operazioni che prima richiedevano conoscenza della sintassi, pianificazione manuale e familiarità con tool differenti possono essere orchestrate partendo da un obiettivo espresso in linguaggio naturale.

Gli IOC permettono di cercare il payload ma il controllo deve partire dalle dipendenze

TrendAI pubblica anche indicatori utili per il rilevamento. Il campione RedShell analizzato possiede SHA-256 4537B1189CE419F1A595CF47216C03F80E9170CE80DAD8D9227A1E52F9CB3466 e utilizza come indirizzo C2 hardcoded 217.60.77.63. Nei filesystem possono comparire payload con nomi come calc-cache.bin, math-calc.bin, calc.bin, calc-mapping.bin, math-core.bin e calc-math.dat, soprattutto sotto directory dist e dist/internal dentro node_modules. Un altro segnale è l’assegnazione dei permessi eseguibili attraverso chmod su binari apparentemente appartenenti a pacchetti JavaScript. Questi indicatori restano però specifici della campagna osservata e gli operatori possono modificarli rapidamente. La mitigazione più efficace passa quindi anche dal controllo della provenienza delle dipendenze, dal pinning delle versioni, dalla revisione dei lockfile, dall’analisi degli artefatti binari inclusi nei pacchetti e dalla telemetria runtime sulle workstation di sviluppo.

RedC2 mostra dove sta andando il malware assistito dall’AI

Il punto più importante di RedC2 non è che l’intelligenza artificiale abbia creato un malware impossibile da realizzare in precedenza. Shell, furto di credenziali, proxy SOCKS, persistenza e fileless execution esistono da anni. La differenza è che l’AI viene inserita direttamente nel livello di comando e controllo, dove può trasformare il linguaggio naturale in procedure operative sfruttando in tempo reale lo stato della sessione compromessa. Parallelamente la distribuzione attraverso pacchetti npm realmente funzionanti riduce la probabilità che la vittima riconosca immediatamente una dipendenza malevola. Il risultato è una combinazione particolarmente efficace tra supply chain, malware Linux nativo e automazione LLM. Non è l’AI a sostituire l’attaccante: è il framework a rendere l’attaccante meno dipendente dalla propria esperienza tecnica. Ed è proprio questo, più dei singoli comandi di RedShell, il salto qualitativo mostrato da RedC2.