DeafNews
// 1 CRITICAL · 11 ZERO-DAY · 9 CVE · 10 EXPLOIT NELLE ULTIME 24H→
Malware

JSCeal ruba cookie di sessione e bypassa l'autenticazione Google

Published: Updated: By Samuel Segato 9 min read Malware
Condividi
WhatsApp Facebook X (Twitter) LinkedIn Reddit Telegram Email
Il malware JSCeal compila JavaScript in bytecode V8 per rubare cookie di sessione e aggirare i sistemi di autenticazione Google. La ricerca di Check Point svela

Check Point Research ha pubblicato l'analisi definitiva di JSCeal, un infostealer JavaScript che compromette sessioni già autenticate sui servizi Google rubando cookie di sessione dal browser della vittima. Il malware, tracciato attivamente da marzo 2024, utilizza una doppia trasformazione tecnica — offuscamento multi-layer seguito da compilazione in bytecode V8 — che ne rende l'analisi praticamente impossibile con gli strumenti standard di reverse engineering. La ricerca è stata presentata a Black Hat USA 2026 e accompagnata dal rilascio di un toolkit open-source per la deobfuscation statica.

Punti chiave
  • JSCeal ruba cookie di sessione dal browser per bypassare l'autenticazione Google senza credenziali statiche
  • Il codice malevolo viene offuscato con javascript-obfuscator e poi compilato in bytecode V8 (.jsc), rendendo inutili gli strumenti di analisi JavaScript convenzionali
  • Il malware installa un proxy MITM locale su 127.0.0.1 con certificati auto-generati per intercettare e modificare traffico HTTPS
  • Check Point ha analizzato 23 payload e rilasciato una pipeline di deobfuscation basata su View8, ma gli autori stanno già evolvendo verso nuove versioni V8 e il targeting di macOS

La catena d'infezione: da Facebook al runtime Node.js nascosto

La campagna documentata da Check Point inizia con malvertising su piattaforme come Facebook e Google. Il clic pubblicitario reindirizza la vittima verso siti falsi di trading di criptovalute, che a loro volta distribuiscono installer contraffatti di TradingView. L'esecuzione finale avviene via PowerShell con il comando node.exe -r preflight.js app.jsc — un dettaglio che rivela l'architettura fondamentale del malware: un runtime Node.js bundled che esegue bytecode V8 precompilato.

Questa scelta non è casuale. La compilazione in formato .jsc elimina il codice sorgente JavaScript, sostituendolo con istruzioni bytecode specifiche per versione del motore V8. Gli analisti che aprono il file con strumenti standard trovano dati binari illeggibili, non testo offuscato da deoffuscare. Il problema si sposta da un dominio dove la sicurezza ha decenni di esperienza — l'analisi JavaScript — a uno dove gli strumenti pubblicamente disponibili sono scarsi e frammentati.

Come funziona il furto di identità senza password

Il meccanismo che interessa maggiormente il lettore è il bypass dell'autenticazione Google. Secondo il dossier di Check Point, JSCeal non cerca di rubare la password dell'utente. Estrae invece i cookie di sessione dal browser — quei token temporanei che mantengono attiva un'identità già verificata — e li trasmette agli operatori del malware. Con questi cookie, l'attaccante può impersonare la vittima sui servizi Google fino alla scadenza naturale della sessione o fino a quando l'utente non ne invalida esplicitamente l'accesso.

Il dossier non specifica se il malware gestisca attivamente il rinnovo delle sessioni o se operi solo sul token iniziale. Ciò che è documentato è la capacità aggiuntiva di keylogging, screenshot, furto di credenziali browser ed estrazione di dati da wallet cryptocurrency (Binance, Phantom). A questa componente di esfiltrazione si aggiunge il proxy MITM locale: JSCeal crea un server su 127.0.0.1, genera coppie di chiavi RSA e certificati, e intercetta il traffico HTTPS per modificarlo in transito. Il pattern è quello classico dei banking trojan, applicato qui a un ecosistema di servizi cloud e finanziari.

"JSCeal combines two forms of analysis friction: a version-specific compiled V8 format and several layers of JavaScript obfuscation applied before compilation. Neither makes the malware impossible to reverse, but together they move it outside the workflows that analysts normally rely on" — Aleksandra 'Hasherezade' Doniec, Check Point Research

L'offuscamento come architettura: tre livelli di invisibilità

Prima ancora della compilazione V8, il codice sorgente JavaScript subisce un trattamento intensivo con javascript-obfuscator. Le tecniche documentate includono: stringhe cifrate con RC4, control-flow flattening che annulla la linearità del codice, proxy functions che mascherano le chiamate reali, e operation wrappers che rendono opache anche le operazioni aritmetiche più semplici. Il risultato è un codice che, anche deoffuscato, richiede ricostruzione manuale della logica.

Dopo questa fase, interviene la compilazione V8 con versione specifica — nel campione analizzato in dettaglio, V8 10.2.154.26-node.25. Il bytecode risultante è lossy: non conserva nomi di variabili, commenti, o struttura del codice originale. Check Point ha esteso il progetto open-source View8 per generare pseudocodice analizzabile, ma il dossier è esplicito nel sottolineare che l'output non è il sorgente originale. La pipeline ha funzionato su tutti e 23 i payload esaminati nel corso di diversi mesi, ma la fonte non garantisce efficacia su varianti future.

Evoluzione attiva: da Windows a macOS, con nuove versioni V8

Il campione JSCeal non è un artefatto statico. Check Point documenta sviluppo continuo: nuove versioni del motore V8, layer di cifratura aggiuntivi, e — elemento che amplifica il rischio — espansione del targeting verso macOS. Quest'ultimo dato è particolarmente rilevante perché il contesto di esecuzione Node.js bundled funziona cross-platform con modifiche minime, e la comunità di analisi macOS ha ancora meno familiarità con artefatti .jsc rispetto a quella Windows.

Il malware è tracciato anche con i nomi WEEVILPROXY e MeadowLocust, che il dossier presenta come etichette operative di tracciamento vendor — non come attribuzione a un gruppo threat actor identificato. Non emergono sovrapposizioni infrastrutturali che colleghino gli operatori a campagne note a livello di attribuzione geopolitica. Resta invece documentata una sovrapposizione tecnica con la campagna SourTrade riportata da Confiant nell'agosto 2026: malvertising diffuso in 12 paesi principalmente di Asia Pacific e America Latina, con landing page in 25 lingue, che utilizza tecniche di assemblaggio in-memory del payload nel browser.

Cosa fare adesso

  • Invalidare le sessioni attive sui servizi Google dopo aver rilevato compromissione sospetta: il cookie rubato resta valido fino a revoca esplicita
  • Includere artefatti .jsc e runtime Node.js bundled nei workflow di triage forense, che gli strumenti standard JavaScript non analizzano nativamente
  • Valutare l'adozione della pipeline Check Point View8 estesa per la deobfuscation statica di bytecode V8, disponibile pubblicamente
  • Monitorare l'evoluzione del toolkit e delle varianti JSCeal: la ricerca indica attivo sviluppo su nuove versioni V8 e piattaforme aggiuntive

Perché JSCeal cambia il perimetro della minaccia JavaScript

La lezione di JSCeal va oltre il singolo malware. Per anni, l'ecosistema di sicurezza ha trattato JavaScript come codice sorgente — offuscabile, ma sempre reversibile con tecniche mature. La compilazione V8 sposta il problema in un registro dove l'analisi richiede conoscenze di engine-specific bytecode, versione per versione. Il rilascio del toolkit Check Point è un primo correttivo, ma la dinamica è quella di una corsa: ogni avanzamento difensivo sulla decompilazione può essere controbilanciato da aggiornamenti del motore target o da migrazione a piattaforme meno monitorate.

Il dato più inquietante resta la facilità con cui una sessione autenticata — il risultato di anni di investimento in autenticazione a due fattori e passwordless — diventa merce rubabile attraverso un cookie. JSCeal non viola Google: abusa di una caratteristica architetturale del web, la persistenza della sessione, che gli utenti considerano convenienza e gli attaccanti considerano superficie d'attacco. La domanda che il settore deve porsi è quanto del proprio workflow analitico sia pronto per codice che non è più JavaScript, ma ne conserva tutta la pericolosità.

FAQ

JSCeal sfrutta una vulnerabilità di Google o di Node.js?

No. Il malware utilizza meccanismi legittimi: la compilazione V8 come tecnica di offuscamento, e i cookie di sessione come meccanismo di autenticazione già valida. Non è documentato alcun zero-day nel runtime.

Possono gli antivirus rilevare JSCeal?

Il dossier non documenta tassi di rilevamento. La struttura .jsc e l'offuscamento multi-layer riducono la visibilità per le firme basate su pattern di codice sorgente, ma Check Point non formula valutazioni sulle capacità degli endpoint security esistenti.

Il toolkit Check Point decripta il sorgente originale?

No. La pipeline genera pseudocodice analizzabile dalla decompilazione del bytecode V8. La compilazione è lossy: nomi di variabili, commenti e parte della struttura originale sono irrecuperabili.

Per approfondire

Fonti

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti
  1. thehackernews.com
  2. gbhackers.com
  3. research.checkpoint.com