Il 26 febbraio 2026 i ricercatori hanno intercettato un passaggio tattico che vale più della singola ondata di pacchetti malevoli: FAMOUS CHOLLIMA, attore associato alla Corea del Nord, ha iniziato a usare steganografia testuale su Pastebin come livello di “dead-drop” per risolvere gli indirizzi di comando e controllo in modo che, a un’analisi superficiale, sembri tutto innocuo. Il risultato è una campagna supply-chain che colpisce direttamente l’ecosistema npm: diciassette pacchetti pubblicati con nomi che imitano librerie legittime attivano il payload già in fase di installazione, recuperano testi benigni da Pastebin, estraggono caratteri nascosti con un decoder personalizzato e ricostruiscono un elenco di domini Vercel da usare come infrastruttura C2 resiliente. La parte più rilevante non è solo “Pastebin usato come staging”, cosa che la threat landscape conosce da anni. La parte nuova è l’uso di steganografia testuale, una scelta che abbassa drasticamente la probabilità che scanner automatici segnalino il contenuto come malevolo: a occhio umano il paste è una frase normale con piccoli refusi, mentre per il decoder è un flusso strutturato che contiene URL completi. In un mondo in cui la detection si appoggia ancora molto su pattern espliciti, questa tecnica sposta l’asticella: l’artefatto malevolo non è la pagina, ma l’interpretazione della pagina.
Cosa leggere
Diciassette pacchetti npm: stessi file, stesso hash, stessa catena di esecuzione
La scoperta viene attribuita a un monitoraggio continuo pubblicato dal blog kmsec.uk, che tra il 25 e il 26 febbraio 2026 individua un cluster di pacchetti con caratteristiche quasi industriali. Ogni pacchetto contiene lo stesso file vendor/scrypt-js/version.js, con hash SHA256 da1775d0fbe99fbc35b6f0b4a3a3cb84da3ca1b2c1bbac0842317f6f804e30a4, un indicatore statico che diventa immediatamente utile per hunting e blocchi a monte. Gli account di pubblicazione imitano nomi plausibili di sviluppatori reali, con handle e indirizzi Gmail che sembrano costruiti per superare controlli superficiali e dare l’illusione di legittimità. La lista include pacchetti come daytonjs 1.11.20, corstoken 2.14.7, jsnwebapptoken 8.40.2, iosysredis 5.13.2, sequelization 6.40.2, undicy-lint 7.23.1, expressjs-lint 5.3.2, loadash-lint 4.17.24, promanage 6.0.21, vitetest-lint 4.1.21, prism-lint 7.4.2, fastify-lint 5.8.0, typoriem 0.4.17, argonist 0.41.0, uuindex 13.1.0, bcryptance 6.5.2 ed ether-lint 5.9.4. La varietà dei nomi è studiata per intercettare ricerche frettolose e typosquatting, soprattutto su pacchetti “utility” e “lint” che gli sviluppatori installano spesso senza pensarci troppo. Il comportamento malevolo viene garantito da uno script di installazione comune: node ./scripts/test/install.js. È un dettaglio cruciale, perché sposta l’esecuzione dal runtime dell’applicazione al momento dell’installazione via npm. In pratica, l’attore non aspetta che il pacchetto venga importato e usato: sfrutta la fase di install per ottenere esecuzione immediata, riducendo la dipendenza dai percorsi applicativi e aumentando l’affidabilità dell’infezione.
Lo stager: tre Pastebin hardcoded e un decoder che “vede” ciò che non si vede
Dentro version.js ci sono tre URL Pastebin hardcoded, interrogati in sequenza per ottenere il contenuto raw. Il primo è pastebin.com/CJ5PrtNk, indicato come modificato l’11 febbraio 2026 e associato all’utente davidsouza23, con 353 visualizzazioni. Gli altri due, 0ec7i68M e DjDCxcsT, risultano creati dall’utente Edgar04231 e hanno poche visualizzazioni, quindi funzionano come fallback.
La logica è semplice ma robusta: il malware prova a recuperare il paste in ordine, passa il testo al decoder e, quando riconosce un formato valido, interrompe il ciclo e ignora gli altri link. In questo modo gli operatori possono aggiornare la configurazione C2 sostituendo un paste o cambiandone il contenuto senza modificare il pacchetto pubblicato su npm. È un classico pattern “dead-drop resolver”, ma reso più invisibile dall’occultamento steganografico.
Steganografia testuale: refusi minimi, dati massimi
Il cuore della tecnica è il decoder custom, progettato per estrarre dati nascosti da testi apparentemente normali. Il paste contiene frasi coerenti, ma con piccoli errori o refusi che, per un lettore umano, sembrano casuali. Per il decoder, invece, quei caratteri in posizioni specifiche o secondo pattern deterministici diventano un canale di trasmissione. La descrizione indica che il decoder può ignorare spazi bianchi o usarli come delimitatori, selezionare caratteri in posizioni predefinite, gestire Unicode e perfino omoglifi per garantire l’estrazione precisa. Questa attenzione a Unicode è un segnale di maturità: gli attori stanno costruendo stager che resistono a normalizzazioni, cambi di encoding e varianti linguistiche dei testi ospitati. L’output finale del decoder è un array di trenta domini Vercel, concepiti come infrastruttura C2 “a grappolo”. Un solo dominio, ext-checkdin.vercel.app, risponde con HTTP 200, mentre gli altri restituiscono 404 e servono da riserva. C’è anche un comportamento condizionale sullo User-Agent: se non corrisponde a curl, il server restituisce il messaggio “Permanently suspended”, un trucco che può disorientare analisti e automatismi che non riproducono esattamente la richiesta attesa.
Vercel come C2: resilienza, rotazione rapida e superficie “legittima”
L’elenco di domini decodificati è lungo e strutturato, con coppie “ext” e “app” che suggeriscono una nomenclatura intenzionale. Tra quelli riportati compaiono, oltre al dominio attivo, nomi come cleverstack-ext301, brightlaunch-app615, primevector-ext483, zenithflow-app877, cloudharbor-ext664, sparkforge-app790, logicfield-app681, atlasnode-app204, signalbase-ext369, neuraldock-app734, orbitstack-ext592, fusionlayer-app463, quantapath-ext275, visiondock-app157, openmatrix-ext539. L’obiettivo non è che tutti funzionino sempre, ma che basti che uno funzioni perché la catena prosegua, e che il resto permetta rotazione e sostituzione in caso di takedown parziali.
L’uso di una piattaforma come Vercel ha anche un valore operativo: il traffico verso domini di hosting e deployment è spesso “rumoroso” e quindi più difficile da distinguere dal normale, soprattutto in ambienti di sviluppo dove richieste a servizi web vari sono quotidiane. Questo è un tratto tipico delle campagne supply-chain moderne: scegliere infrastrutture che sembrano normali per la categoria di vittima.
Payload multi-OS: esecuzione silenziosa e persistenza tramite script
Una volta scelto il dominio corretto, entra in gioco la funzione executeRemotePayload, che adatta la consegna al sistema operativo. Su macOS scarica da /api/m con curl e passa direttamente a bash. Su Linux usa wget per recuperare /api/l ed esegue con bash. Su Windows scarica /api/w con curl e passa a cmd.exe. Tutto avviene in modalità silenziosa, con stdio ignorato e processi detached, così da mantenere il payload in esecuzione senza segnali evidenti. I ricercatori descrivono anche il comportamento di drop e rinomina: su Linux un file tokenlinux.npl diventa tokenlinux.sh ed esegue in background, su macOS finisce nella Library, su Windows in APPDATA come token.cmd. Questa parte completa il quadro: non si tratta solo di ricognizione, ma di un loader che consegna componenti successivi specifici per piattaforma.
Perché questa campagna conta: dal typosquatting al “resolver invisibile”
Il valore strategico di questa ondata è che unisce tre livelli di evasione in una catena semplice. Il primo livello è la distribuzione via npm con nomi credibili e script install. Il secondo livello è l’uso di Pastebin come configurazione remota. Il terzo livello è la steganografia testuale, che rende la configurazione stessa difficile da classificare come malevola. In altre parole, l’attore sta cercando di rendere “banale” ogni singolo elemento osservato isolatamente: un pacchetto che sembra utility, un paste che sembra testo, un dominio che sembra deployment. Solo la correlazione tra eventi racconta la storia completa. Questo è anche un segnale di accelerazione: la campagna viene descritta come parte di una sperimentazione rapida, con passaggi da meccanismi precedenti a questo stager in pochi giorni. È il tratto di attori che imparano velocemente dalle rimozioni e dall’attenzione della community, e che cercano un canale di controllo meno fragile del classico URL hardcoded.
Cosa controllare subito: indicatori e punti di osservazione utili
La parte operativa, in un contesto Node.js, si gioca su due piani: blocco e rilevamento. A livello di blocco, ha senso impedire l’installazione dei pacchetti sospetti e bloccare i domini noti, ma soprattutto introdurre policy che limitino l’esecuzione di script di installazione non necessari. A livello di rilevamento, gli indicatori più forti sono quelli comportamentali: processi node che effettuano lookup verso pastebin.com, e subito dopo contattano domini vercel.app, spesso seguiti da spawn di curl o wget. Sul piano degli IOC statici, il file vendor/scrypt-js/version.js con hash da1775d0fbe99fbc35b6f0b4a3a3cb84da3ca1b2c1bbac0842317f6f804e30a4 è l’elemento di riconoscimento principale. Sul piano infrastrutturale, il dominio ext-checkdin.vercel.app come endpoint che risponde realmente è un indicatore ad alta priorità, mentre la presenza di contatti verso paste specifici e poi verso Vercel rappresenta un pattern di catena utile per regole SIEM e EDR. Questa campagna, in definitiva, mostra come la supply chain JavaScript stia diventando un terreno dove gli attori non cercano solo di infilare codice, ma di costruire resolver invisibili che si nascondono dentro contenuti apparentemente innocui. E quando il controllo remoto diventa indistinguibile dal testo, la difesa non può più limitarsi a cercare stringhe sospette: deve osservare sequenze, correlazioni e anomalie di flusso.
Iscriviti alla Newsletter
Non perdere le analisi settimanali: Entra nella Matrice Digitale.
Matrice Digitale partecipa al Programma Affiliazione Amazon EU. In qualità di Affiliato Amazon, ricevo un guadagno dagli acquisti idonei. Questo non influenza i prezzi per te.
