JSCeal rompe il sigillo V8: Check Point ricostruisce lo stealer senza eseguirlo

🛡️ Executive Summary

• JSCeal combina bytecode V8 compilato, stringhe RC4, control-flow flattening e proxy per rendere costosa l’analisi del payload JavaScript.
• Check Point ha sviluppato una pipeline statica che ha prodotto codice analizzabile su 23 payload senza eseguire direttamente il malware.
• Il codice recuperato espone furto di credenziali e wallet, keylogging, screenshot, sessioni Telegram e manipolazione HTTPS tramite certificati locali.

JSCeal non nasconde il proprio codice dietro una singola tecnica di offuscamento, ma combina JavaScript trasformato, bytecode V8 compilato, compressione, funzioni proxy e control-flow flattening per aumentare radicalmente il costo del reverse engineering. Check Point Research ha ora documentato una pipeline capace di attraversare questi strati in maniera completamente statica, trasformando il payload .jsc in pseudocodice sufficientemente leggibile da ricostruirne le capacità senza dover eseguire il malware. Il risultato permette di osservare un infostealer molto più ampio del semplice furto di criptovalute: credenziali browser, sessioni Telegram, keylogging, screenshot e intercettazione HTTPS locale convivono in un’architettura Node.js che continua a evolvere e ha già esteso il proprio raggio operativo a macOS.

JSCeal trasforma Node.js e V8 in uno strato anti-analisi

JSCeal, identificato anche da altri vendor come WEEVILPROXY o MeadowLocust, è attivo almeno da marzo 2024 e viene seguito da Check Point dall’inizio del 2025. Le campagne documentate partono dal malvertising, proseguono attraverso più script PowerShell e terminano con il download di un runtime Node.js e di un archivio contenente app.jsc, moduli nativi e componenti di supporto. Il payload finale non arriva sotto forma di normale sorgente JavaScript: viene preventivamente elaborato con javascript-obfuscator, quindi compilato nella rappresentazione interna del motore V8 e distribuito come code cache compressa con Brotli. L’analista perde così nomi originari, struttura sorgente e gran parte degli elementi sui quali si basano i normali strumenti di deobfuscation JavaScript. È una scelta economicamente vantaggiosa per gli attaccanti, perché sfrutta tecnologie disponibili pubblicamente anziché richiedere una virtual machine proprietaria, ma trasferisce sul difensore il problema di gestire un formato interno strettamente dipendente dalla versione di V8. È una logica che si inserisce nella crescente trasformazione dell’ecosistema JavaScript in superficie offensiva, già visibile nelle campagne npm che infettano toolchain e wallet attraverso pacchetti Node.js. La ricerca tecnica pubblicata da Check Point mostra però che questa barriera può essere smontata senza ricorrere all’esecuzione diretta del payload.

La deobfuscation procede per strati e non tenta di ricreare il sorgente originale

Il punto centrale del lavoro è il metodo. Dopo aver rimosso la compressione Brotli, i ricercatori ottengono il V8 code cache e lo passano a un disassembler compatibile con la versione del runtime incorporato nel malware. La generazione analizzata in profondità utilizza V8 10.2.154.26-node.25, caratteristica decisiva perché i cached data di V8 sono version-sensitive. Check Point parte quindi da View8, decompiler open source per bytecode V8, modificandolo per ottenere output riproducibile e adatto a trasformazioni automatizzate.

La pipeline non promette di ricostruire il JavaScript originale: la compilazione V8 è lossy e ciò che emerge rimane pseudocodice. L’obiettivo è recuperare abbastanza struttura da seguire chiamate, stringhe, API, percorsi e flussi di dati. Il processo deve rispettare un ordine preciso: prima vengono propagate le informazioni disponibili, poi ricostruite le stringhe, quindi eliminato il control-flow flattening, risolte le funzioni proxy e sostituiti gli operation wrapper che nascondono anche semplici confronti, somme o chiamate. Nel principale schema di protezione delle stringhe, i frammenti sono cifrati con RC4, codificati in Base64 e ricomposti soltanto durante l’esecuzione. Recuperarli staticamente espone a sua volta chiavi di dizionari, riferimenti a funzioni e informazioni necessarie ai passaggi successivi. La strategia è quindi l’opposto di una decompilazione monolitica: ogni strato rimosso rende attaccabile il seguente. Una filosofia simile emerge anche nelle analisi delle supply chain npm compromesse che usano più stadi per separare installer e infostealer. Check Point riferisce di aver applicato la pipeline a 23 payload JSCeal, ottenendo output analizzabile in tutti i casi.

Leggi anche: NarwhalRAT e UNK_DeadDrop mostrano come Node.js e ambienti di sviluppo possano diventare vettori per il furto di wallet e credenziali

Dal pseudocodice emergono browser, wallet, Telegram e sorveglianza locale

Una volta rimosse le principali trasformazioni, JSCeal smette di apparire come un insieme opaco di registri e dispatcher e mostra un’architettura molto articolata. Il codice recuperato enumera i browser installati, accede a cookie, password, token OAuth e profili, individua applicazioni presenti sulla macchina e contiene funzioni dedicate alle sessioni Telegram. Il malware integra inoltre componenti per catturare lo schermo, controllare le finestre visibili e intercettare la tastiera, formando un vero sottosistema di sorveglianza anziché un semplice grabber di file. La concentrazione sugli asset crypto resta però evidente: il codice contiene routine per raccogliere informazioni da numerose piattaforme ed exchange, tra cui Binance, Bybit, Kraken, OKX, KuCoin, Gate.io, MEXC, Poloniex e HTX, oltre a riferimenti a wallet e valori dei saldi. Il modello ricorda altre campagne nelle quali il browser è diventato contemporaneamente deposito di credenziali, sessioni e accessi finanziari; gli infostealer capaci di sottrarre cookie di sessione dimostrano infatti come il furto di un token possa aggirare in pratica molte delle protezioni poste esclusivamente sulla password. Con JSCeal il problema è ancora più ampio perché la raccolta non si limita agli artefatti memorizzati: il malware può osservare direttamente ciò che avviene sul sistema attraverso screenshot e input da tastiera.

Il proxy MITM può modificare il traffico di Binance, Bybit e Ledger

La capacità più aggressiva emersa dalla deobfuscation riguarda un proxy HTTPS locale. Il malware può generare un proprio certificato, installarlo nel trust store della macchina usando certutil e indirizzare il traffico attraverso un servizio in ascolto su 127.0.0.1. Questo permette a JSCeal non soltanto di osservare connessioni che l’utente considera protette da HTTPS, ma anche di intervenire attivamente su richieste e risposte. Il codice recuperato contiene handler specifici per Binance, Bybit e Ledger. Per Binance può sostituire il valore qrCode restituito durante il login; per Bybit può catturare componenti di verifica e trasformare risultati di autenticazione; nel caso di Ledger intercetta una risorsa JavaScript e può sostituirla con contenuto controllato. Altri handler consentono di rimpiazzare HTML, bloccare host e cancellare cookie selezionati. La tecnica porta JSCeal nel territorio tipico dei trojan finanziari che manipolano la sessione nel momento stesso in cui la vittima interagisce con il servizio. La difesa non può quindi limitarsi alla protezione dei file dei wallet: deve considerare anche trust store, configurazione proxy, processi Node.js anomali e modifiche locali alla catena TLS. L’interesse crescente dei malware per il settore crypto è visibile anche nelle campagne ClickFix su macOS dotate di funzioni dedicate al drenaggio dei wallet, ma il proxy di JSCeal aggiunge la possibilità di intervenire direttamente sulla comunicazione con piattaforme finanziarie reali.

Gli LLM aiutano a navigare il codice ma Check Point li esclude dalle prove

Dopo la deobfuscation deterministica resta un problema apparentemente banale ma enorme su un payload di queste dimensioni: i nomi originari delle funzioni sono andati persi. JSCeal include migliaia di funzioni e numerose dipendenze bundle, con output che in alcuni casi arriva a 47 MB. Check Point ha quindi aggiunto una fase opzionale di rinomina assistita da LLM, supportando backend Anthropic, OpenAI e Ollama. Il modello non riceve bytecode grezzo e non svolge la deobfuscation: lavora soltanto sul codice già recuperato, proponendo etichette che aiutano l’analista a navigare il grafo delle dipendenze. La distinzione metodologica è rilevante. Nei test su oltre 21.000 funzioni, Claude Sonnet 4.6 e GPT-5.4-mini hanno scelto esattamente lo stesso nome soltanto nel 9,3% dei casi, un dato che non misura direttamente la correttezza ma dimostra quanto possa cambiare il livello di astrazione scelto dal modello. Su 142 radici analizzate manualmente, Check Point ha considerato utili e sufficientemente informative 128 etichette di Sonnet contro 30 di GPT, precisando però che l’esperimento non costituisce una classifica generale dei modelli. Anche Sonnet ha prodotto interpretazioni plausibili ma errate. La regola adottata dai ricercatori è quindi netta: il nome suggerito è un’ipotesi; corpo della funzione, stringhe, API, percorsi e data flow costituiscono la prova. È un confine particolarmente importante nel reverse engineering assistito dall’intelligenza artificiale, dove una descrizione semanticamente convincente può diventare pericolosa se viene scambiata per evidenza tecnica.

Continua con:

• Contagious Interview nasconde payload JavaScript negli SVG e colpisce sviluppatori e wallet crypto
• AgentBaiting usa repository GitHub falsi per consegnare SmartLoader e StealC

JSCeal evolve con AES-256-CBC, una nuova versione V8 e payload per macOS

Il lavoro di reverse engineering fotografa inoltre una minaccia che non è rimasta ferma. Dalle campagne iniziate nel novembre 2025 gli operatori hanno aggiornato il runtime portando V8 a 13.6.233.10-node.28, versione ancora più sensibile alla corrispondenza esatta tra runtime, build e snapshot durante la disassembly. Alla protezione esistente è stato aggiunto un ulteriore livello AES-256-CBC attorno al payload Brotli: la chiave non risiede nel bundle analizzato, ma viene fornita da uno stage precedente attraverso una variabile d’ambiente. Possedere soltanto il payload isolato può quindi non essere sufficiente per recuperare il code cache sottostante. Check Point ha inoltre osservato campagne rivolte a macOS, segnale che JSCeal sta ampliando sia le difese anti-analisi sia la copertura delle piattaforme. Il toolkit jsc_deobfuscator pubblicato su GitHub offre agli analisti una reference implementation della pipeline e, nella versione attuale, copre end-to-end la generazione V8 10.2.154.26-node.25; il supporto alla generazione più recente richiede ulteriore lavoro. Il risultato della ricerca non è quindi la ricostruzione perfetta del sorgente, ma qualcosa di operativamente più utile: un metodo ripetibile per trasformare bytecode V8 compilato e pesantemente offuscato in evidenza leggibile e confrontabile. JSCeal dimostra che gli attaccanti possono ottenere un vantaggio asimmetrico usando componenti standard, ma anche che la compilazione in V8 code cache non costituisce un sigillo inviolabile quando l’analisi statica viene costruita attorno alla struttura reale del formato.