JSCeal contourne l’authentification Google avec des cookies de session volés
Check Point détaille JSCeal, un malware JavaScript V8 compilé qui rejoue les cookies de session dérobés pour ouvrir un accès à des comptes Google sans mot de passe ni double authentification. Sécurisez les sessions avec des clés de sécurité et une liaison d’appareil, et surveillez l’exfiltration de cookies.
7 septembre 2026. Check Point Research publie l’analyse complète de JSCeal, un malware compilé en bytecode V8 JavaScript (JSC) doté de capacités de vol d’identifiants, de surveillance et d’interception de trafic. Documenté une première fois en juillet 2025, il est toujours actif via des campagnes de malvertising. Pourquoi c’est important : **JSCeal rejoue les cookies de session volés pour ouvrir un accès à des comptes Google sans mot de passe ni double authentification. La MFA ne protège plus rien une fois la session déjà authentifiée dérobée.
Un vol de session qui court-circuite la MFA
Le cœur de la menace n’est ni le mot de passe ni le code à usage unique. JSCeal cible les cookies de session : ces jetons qui prouvent au serveur que votre navigateur est déjà authentifié. En les rejouant, le malware reconstruit la session et mène des attaques de session replay pour contourner l’authentification et accéder au compte Google de la victime.
La conséquence est brutale pour un RSSI. Un attaquant qui détient un cookie de session valide n’a pas besoin de casser le mot de passe ni de franchir la double authentification : la session est déjà ouverte. C’est précisément la classe d’attaque que Google tente de neutraliser avec les informations d’identification liées à l’appareil, et que JSCeal illustre de façon pédagogique.
Le vol s’appuie sur un module dédié aux navigateurs Chromium : Google Chrome, Microsoft Edge, Brave, Opera, Opera GX, Avast Secure Browser, Vivaldi et Cốc Cốc. Pour chacun, le malware se rend dans le répertoire user-data, énumère les profils et en extrait cookies et mots de passe.
Pourquoi le cookie vaut plus que le mot de passe
Cette focalisation sur le cookie n’a rien d’anecdotique. Un mot de passe peut être réinitialisé, et un code MFA peut être rejoué ou hameçonné dans une fenêtre de temps limitée. Le cookie de session, lui, est l’artefact qui ouvre l’accès sans réauthentification : tant qu’il reste valide, il est la clé de la maison.
JSCeal illustre un modèle de menace mûri. Plutôt que de casser un mot de passe, le malware rejoue l’état d’authentification déjà établi, ce qui rend inopérantes les défenses construites autour du secret initial. C’est exactement la faille que Google tente de refermer avec les informations d’identification liées à l’appareil — le projet DBSC, annoncé en 2024, lie le cookie à l’appareil via un secret ancré dans le matériel, de sorte qu’un cookie copié échoue sur une autre machine.
La leçon pour la défense est structurelle : tant que les sessions ne sont pas liées à l’appareil, tout parc qui ne surveille que les mots de passe et la MFA laisse passer l’attaque au niveau même où elle frappe.
Ce qu’un SOC doit surveiller
Le comportement de JSCeal laisse des traces détectables, pour peu qu’on les cherche :
- Accès au répertoire user-data d’un navigateur par un processus qui n’est pas ce navigateur — le signal le plus fiable d’un vol de profil.
- Nouveaux certificats racine ou intermédiaires installés dans le magasin de l’utilisateur, signe du proxy d’interception.
- Proxy local en écoute sur loopback qui modifie les réponses de plateformes d’échange de cryptomonnaies.
- Connexions « impossible travel » : une session rejouée depuis une géolocalisation incompatible avec la précédente.
Ces indicateurs ne remplacent pas la prévention, mais ils transforment une compromission silencieuse en incident traçable.
Un malware compilé, pas un script
JSCeal n’est pas un simple script JavaScript. C’est du code V8 compilé, protégé par javascript-obfuscator à l’aide de plusieurs couches : chaînes chiffrées en RC4, control-flow flattening, fonctions proxy et enveloppes d’opérations. Check Point a dû construire un pipeline de désobfuscation entièrement statique pour décoder le bytecode et reconstituer le flux d’exécution.
Les opérateurs répètent quatre familles de transformations pour obscurcir le code :
- Renommage des fonctions et variables en identifiants courts ou absurdes.
- Découpage des chaînes importantes en morceaux, encodés puis chiffrés en RC4, et reconstruits via des fonctions de décodage.
- Control-flow flattening : le flux est transformé en une seule instruction
switchà plat, pilotée par une boucle infinie et une variable d’état, pour casser la lisibilité de la rétro-ingénierie. - Fonctions proxy et enveloppement des opérations simples — addition, comparaison, appel de fonction — dans des fonctions dédiées.
Cette friction a un coût réel pour la défense. Comme le résume la chercheuse Aleksandra Doniec, surnommée Hasherezade, « JSCeal combine deux formes de friction d’analyse : un format V8 compilé propre à une version et plusieurs couches d’obfuscation appliquées avant la compilation. Ni l’un ni l’autre ne rend le malware impossible à rétroconcevoir, mais ensemble, ils le placent hors des flux de travail que les analystes utilisent normalement. »
Le module voleur cible aussi les jetons OAuth et autres secrets stockés par les navigateurs. Un second module assure la surveillance : enregistrement des frappes clavier et captures d’écran.
Une chaîne de distribution qui imite les marques de trading
La distribution passe par des sites de trading de cryptomonnaies contrefaits, vers lesquels les victimes sont redirigées par des publicités malveillantes diffusées sur Facebook et Google. Les faux sites invitent à télécharger de faux installateurs TradingView qui déploient le malware. L’activité recoupe les clusters WEEVILPROXY et MeadowLocust.
Les campagnes de malvertising livrent deux archives ZIP via PowerShell : l’une contient le runtime Node.js, l’autre le payload principal et ses composants auxiliaires.
En août 2026, la plateforme Confiant a documenté une opération massive baptisée SourTrade, qui usurpe les marques Solana, Luno et TradingView. Sa particularité : la page d’accueil ne distribue pas de malware fini, mais des instructions d’assemblage qui ordonnent au navigateur de construire le malware en mémoire, à partir d’un fichier légitime récupéré séparément. « Aucun malware fini n’existe jamais sur le réseau », précise Confiant. La campagne, active depuis fin 2024, cible des traders particuliers dans 12 pays et 25 langues, principalement en Asie-Pacifique et en Amérique latine.
Un proxy local qui modifie les réponses des services
JSCeal ne se contente pas de voler. Il installe un proxy local, génère et installe des certificats, puis modifie les requêtes et les réponses de services précis. Des gestionnaires dédiés ciblent Binance, Bybit et Ledger, avec des remplacements de HTML, des blocages d’hôtes et la suppression de cookies sélectionnés.
D’autres gestionnaires, spécialisés sur les plateformes de cryptomonnaies, capturent les données de compte et enregistrent les soldes. L’objectif final est clair : vider des portefeuilles et détourner des fonds, pas seulement collecter des identifiants.
Verdict
Si vous gérez un parc d’utilisateurs exposés au trading ou à la cryptomonnaie, déployez la liaison d’appareil des sessions (clés de sécurité, passkeys, informations d’identification liées à l’appareil de Google), qui rend un cookie volé inutilisable hors de l’appareil d’origine.
Si vous ne pouvez pas imposer les clés de sécurité partout, réduisez la durée de vie des sessions, activez la révocation proactive sur les connexions suspectes et déployez un EDR capable de détecter l’exfiltration de cookies depuis les répertoires de profil des navigateurs.
Si vous êtes un particulier qui négocie des cryptomonnaies, ne téléchargez jamais un installateur via une publicité : tapez l’URL de l’éditeur, vérifiez le certificat et préférez l’application authentifiée par passkey à tout compte que vous pouvez sécuriser ainsi.