JSCeal Bypasses Google Authentication with Stolen Session Cookies
Check Point unpacks JSCeal, a compiled V8 JavaScript malware that replays stolen session cookies to open access to Google accounts without a password or second factor. Lock down sessions with security keys and device-bound credentials, and watch for cookie exfiltration.
September 7, 2026. Check Point Research publishes its full analysis of JSCeal, a malware compiled to V8 JavaScript bytecode (JSC) with credential harvesting, surveillance, and traffic-interception capabilities. First documented in July 2025, it is still active through malvertising campaigns. Why it matters: **JSCeal replays stolen session cookies to open access to Google accounts with no password and no second factor. Once a live session is stolen, MFA no longer protects anything.
Session theft that sidesteps MFA
The core of the threat is neither the password nor the one-time code. JSCeal targets session cookies: the tokens that prove to a server your browser is already authenticated. By replaying them, the malware reconstructs the session and mounts session replay attacks to bypass authentication and reach the victim’s Google account.
The consequence is stark for a CISO. An attacker holding a valid session cookie does not need to crack a password or pass two-factor authentication: the session is already open. This is exactly the attack class Google has been trying to neutralize with device-bound session credentials, and JSCeal demonstrates it cleanly.
The theft rides on a module aimed at Chromium browsers: Google Chrome, Microsoft Edge, Brave, Opera, Opera GX, Avast Secure Browser, Vivaldi, and Cốc Cốc. For each, the malware walks to the browser’s user-data directory, enumerates profiles, and extracts cookies and passwords.
Why a cookie is worth more than a password
The focus on cookies is not incidental. A password can be reset, and an MFA code can only be replayed or phished within a narrow time window. A session cookie, by contrast, is the artifact that opens access without re-authentication: as long as it stays valid, it is the key to the house.
JSCeal reflects a mature threat model. Rather than cracking a password, the malware replays an already-established authentication state, which neutralizes every defense built around the original secret. That is precisely the gap Google is trying to close with device-bound credentials — the DBSC project, announced in 2024, binds the cookie to the device through a hardware-anchored secret so a copied cookie fails on another machine.
The lesson for defenders is structural: until sessions are device-bound, any security program that only watches passwords and MFA is letting the attack through at the exact layer where it strikes. This is also why cookie logs dominate criminal marketplaces: a session token outlives the victim’s ability to notice, and it skips the hardest part of an intrusion — proving who you are.
What a SOC should look for
JSCeal’s behavior leaves detectable traces, if you look for them:
- Access to a browser’s user-data directory by a process that is not that browser — the most reliable signal of profile theft.
- New root or intermediate certificates installed in the user’s store, a mark of the interception proxy.
- A local proxy listening on loopback and rewriting responses from cryptocurrency exchanges.
- “Impossible travel” sign-ins: a replayed session arriving from a geography incompatible with the previous one.
These indicators do not replace prevention, but they turn a silent compromise into a traceable incident.
Compiled malware, not a script
JSCeal is no plain JavaScript file. It is compiled V8 code, shielded by javascript-obfuscator with several layers: RC4-encrypted strings, control-flow flattening, proxy functions, and operation wrappers. Check Point had to build a fully static deobfuscation pipeline to decode the bytecode and reconstruct the execution flow.
The operators repeat four families of transformations to obscure the code:
- Renaming functions and variables into short or nonsensical identifiers.
- Splitting important strings into chunks that are then encoded and RC4-encrypted, and rebuilt through decoder functions.
- Control-flow flattening: the flow is turned into a single flat
switchdriven by an infinite loop and a state variable, breaking reverse-engineering readability. - Proxy functions and wrapping of simple operations — addition, comparison, function calls — inside dedicated helpers.
That friction has a real defensive cost. As researcher Aleksandra “Hasherezade” Doniec puts it, “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.”
The stealer module also targets OAuth tokens and other secrets stored by browsers. A second module handles surveillance, recording keystrokes and taking screenshots.
A distribution chain that impersonates trading brands
Distribution runs through counterfeit cryptocurrency trading sites, to which victims are redirected by malicious ads served on Facebook and Google. The fake sites prompt users to download bogus TradingView installers that drop the malware. The activity overlaps with the WEEVILPROXY and MeadowLocust threat clusters.
The malvertising campaigns deliver two ZIP archives via PowerShell: one holding the Node.js runtime, the other the main payload and auxiliary components.
In August 2026, ad-security firm Confiant documented a large operation dubbed SourTrade, impersonating Solana, Luno, and TradingView. Its twist: the landing page does not ship a finished binary. It delivers assembly instructions that order the browser to build the malware in memory from a clean legitimate file fetched separately. “No finished malware ever exists on the network,” Confiant notes. Active since late 2024, the campaign targets retail traders across 12 countries and 25 languages, mostly in Asia-Pacific and Latin America.
A local proxy that rewrites service responses
JSCeal does not stop at stealing. It installs a local proxy, generates and installs certificates, and modifies requests and responses for specific services. Dedicated handlers target Binance, Bybit, and Ledger, with HTML replacement, host blocking, and clearing of selected cookies.
Further handlers, focused on cryptocurrency platforms, capture account data and record balances. The end goal is clear: drain wallets and move funds, not just harvest credentials. That single-minded focus on financial outcomes explains the heavy targeting of trading platforms rather than generic credential theft.
Check Point’s closing assessment is blunt: the JSCeal authors are investing in both harder-to-analyze payloads and broader platform coverage, and with campaigns running into recent months, the malware remains under active development. That trajectory has a practical consequence — static detections tuned for one compiled-V8 version decay quickly, so defense has to lean on behavioral signals rather than signatures alone.
The breadth of the stealer — cookies, passwords, OAuth tokens, keystrokes, and screenshots — means a single infection feeds several criminal uses at once: session replay against Google accounts, and direct interception of crypto exchange sessions. For an individual, losing a Google account is often the first domino before the wallet is drained.
Verdict
If you manage users exposed to trading or crypto, roll out device-bound sessions — security keys, passkeys, and Google device-bound credentials — which make a stolen cookie useless outside the originating device.
If you cannot enforce security keys everywhere, shorten session lifetimes, enable proactive revocation on suspicious sign-ins, and deploy an EDR that detects cookie exfiltration from browser profile directories.
If you are an individual trading crypto, never install software from an ad: type the vendor’s URL, check the certificate, and prefer a passkey-authenticated account wherever you can secure one.