Check Point svela la pipeline che legge JSCeal senza eseguirlo

Check Point Research ha pubblicato il 31 agosto 2026 la descrizione completa di una pipeline di deobfuscation statica per JSCeal, uno stealer JavaScript distribuito come bytecode V8 compilato. La ricerca, presentata a Black Hat USA 2026, dimostra che è possibile recuperare struttura e semantica del malware senza esecuzione in sandbox, aggirando una barriera anti-analisi che finora ha rallentato l'ecosistema di threat intelligence. Il toolkit è disponibile pubblicamente su GitHub.

Il doppio strato che nasconde lo stealer

JSCeal non arriva come sorgente JavaScript leggibile. Il payload è distribuito come bytecode V8 compilato in file .jsc, eseguito da un runtime Node.js incluso nel pacchetto di distribuzione. Questa scelta architetturale rappresenta un salto qualitativo rispetto agli infostealer JavaScript tradizionali: la compilazione V8 è intrinsecamente lossy, elimina nomi di variabili originali, appiattisce strutture di controllo e rende inapplicabili gli strumenti di deobfuscation source-level convenzionali.

A ciò si aggiunge un'intensa attività di obfuscation pre-compilazione. Secondo l'analisi di Check Point Research, gli operatori utilizzano javascript-obfuscator con quattro tecniche principali: stringhe cifrate con RC4, control-flow flattening che disperde il flusso logico in uno state machine, proxy functions che mascherano chiamate a funzione, e operation wrappers che offuscano operazioni aritmetiche e logiche. Il risultato è un "double transformation problem": il codice viene offuscato come sorgente, poi compilato in bytecode, perdendo ulteriore informazione semantica.

La generazione analizzata in maggiore profondità impiegava Node.js basato su V8 10.2.154.26-node.25. Il file app.jsc era compresso con Brotli e decompresso da un preflight.js prima del caricamento nel runtime. Questa catena di trasformazioni rende l'analisi dinamica in sandbox insufficiente per recuperare la struttura logica originale: il malware funziona, ma la sua organizzazione interna resta opaca agli analisti.

Come funziona la pipeline statica di CPR

La risposta di Check Point Research è un approccio completamente statico che inverte le trasformazioni senza mai eseguire il payload malevolo. Il punto di partenza è View8, il decompilatore V8 sviluppato da Moshe Marelus (anch'egli CPR), che converte il bytecode in pseudocodice. Da questo stadio intermedio, la pipeline applica una serie di trasformazioni semantico-strutturali dedicate.

I passi documentati sono quattro. Il primo è value propagation: i valori costanti vengono tracciati attraverso il grafo del flusso di dati per ricostruire espressioni semplificate. Il secondo è string reconstruction: le stringhe cifrate con RC4 vengono decifrate ricostruendo la chiave e l'algoritmo dai pattern del bytecode decompilato. Il terzo è control-flow unflattening: il grafo del controllo viene ripristinato dall'appiattimento del state machine. Il quarto è proxy/wrapper resolution: le funzioni interposte tra chiamante e chiamato vengono inlineate per ripristinare i collegamenti semantici originali.

Check Point Research ha esteso View8 con tre miglioramenti specifici: serializzazione pickle per gestire strutture dati intermedie, identificatori funzione normalizzati deterministicamente per abilitare il confronto tra campioni, e controlli di visibilità a livello di funzione per gestire lo scope in presenza di offuscamento. È stato inoltre identificato e corretto un bug nella stampa stringhe originale di View8, relativo al trattamento di code unit a 16 bit come sequenze byte-oriented.

"The goal is not perfect source recovery — V8 compilation is lossy, and the output of decompilation remains pseudocode. Instead, we aimed to recover enough structure and semantics to read the malware as code again." — Check Point Research

Cosa è emerso dai 23 campioni analizzati

L'applicazione sistematica della pipeline a 23 payload JSCeal raccolti in diversi mesi ha prodotto output analizzabile in tutti i casi, secondo la documentazione di Check Point Research. Questa consistenza è rilevante perché indica che le tecniche di obfuscation di JSCeal, pur essendo multi-strato, seguono pattern sufficientemente regolari da essere invertibili algoritmicamente una volta compresa la struttura del generatore.

Il codice recuperato ha permesso di mappare le capacità operative del malware con dettaglio tecnico. JSCeal implementa keylogging catturando eventi di input a livello applicativo. Esegue furto credenziali da browser individuando path specifici dei database SQLite di Chrome, Firefox e varianti. Intercetta applicazioni cryptocurrency attraverso API e path riconoscibili. Esegue screenshot capture. Infine, attiva un proxy MITM HTTPS locale per intercettare il traffico della macchina compromessa.

La comparazione tra i campioni ha inoltre consentito di tracciare l'evoluzione del malware. Le generazioni più recenti includono l'uso di V8 code cache per versioni più recenti di Node.js/V8, uno strato aggiuntivo di cifratura del payload, e il targeting di macOS. Il malware è anche noto come WEEVILPROXY o MeadowLocust da altri vendor di sicurezza, indicando una frammentazione nella nomenclatura che la deobfuscation sistematica potrebbe aiutare a ridurre.

Cosa fare adesso

Per gli analisti di threat intelligence che incontrano payload JSCeal o campioni simili basati su bytecode V8, il toolkit hasherezade/jsc_deobfuscator fornisce un punto di partenza operativo immediato. La pipeline richiede come input il file .jsc e produce pseudocodice View8 deoffuscato, abilitando la comparazione strutturale tra campioni raccolti in periodi diversi.

Le 23 applicazioni documentate da Check Point Research indicano che la metodologia è stabile per le generazioni di JSCeal analizzate fino al primo trimestre 2025. Gli analisti dovrebbero verificare la versione del runtime Node.js/V8 del campione: la generazione studiata in dettaglio utilizzava V8 10.2.154.26-node.25, mentre le evoluzioni con V8 code cache per versioni più recenti potrebbero richiedere adattamenti del flusso di decompilazione.

Per i team di sicurezza aziendale, la ricerca segnala che la detection basata su firme di sorgente JavaScript è inadeguata per questa classe di payload. JSCeal non esiste mai come sorgente leggibile in fase di distribuzione: il file .jsc compilato e il runtime Node.js bundled richiedono controlli a livello di artefatto binario, non di pattern di codice sorgente.

Domande frequenti

La pipeline recupera il sorgente JavaScript originale?

No. Il processo genera pseudocodice View8: la compilazione V8 è lossy e i nomi originali delle variabili sono persi irrimediabilmente. L'obiettivo è recuperare struttura e semantica sufficienti per l'analisi, non la ricostruzione fedele del sorgente.

Il toolkit funziona su qualsiasi malware JavaScript compilato?

Il toolkit è specifico per i pattern di obfuscation di JSCeal su pseudocodice View8. Le trasformazioni implementate (control-flow unflattening, proxy resolution, string reconstruction RC4) sono tarate sulle tecniche documentate di javascript-obfuscator come applicate da questo specifico malware.

Perché l'analisi statica è preferibile alla sandbox per questo caso?

Secondo Check Point Research, l'esecuzione in sandbox permette di osservare il comportamento del malware ma non di recuperare la sua organizzazione interna. La compilazione V8 elimina le strutture di alto livello necessarie alla comprensione del codice: la pipeline statica inverte le trasformazioni prima che questa perdita di informazione renda l'analisi impossibile con strumenti convenzionali.

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti

• https://research.checkpoint.com/2026/breaking-the-seal-static-deobfuscation-of-jsceals-compiled-v8-bytecode/
• https://github.com/hasherezade/jsc_deobfuscator
• https://github.com/suleram/View8
• https://github.com/j4k0xb/View8/