A newly published deobfuscation effort reveals how a cryptocurrency-focused stealer reconstructs browser sessions from stolen cookies. The capability is real and documented in recovered code — but "can replay a session" and "defeats Google's account security" are not the same claim.

Most credential-stealing malware ships what it steals somewhere else and lets a human operator do something with it later. JSCeal, according to a technical report Check Point Research published on August 31, 2026, does more of the work itself. Recovered code shows the malware taking cookies straight out of a victim's own browser and using them, on the spot, to rebuild a live session with Google — the same trick a human attacker would perform manually with a stolen cookie and a browser extension, except automated.

That detail is the headline of a broader piece of research: a static deobfuscation pipeline that finally makes JSCeal's compiled bytecode readable. The malware itself isn't new. It's been running cryptocurrency-focused ad campaigns since at least March 2024. What changed this year is that researchers can now actually see what the code does, instead of inferring it from behavior alone.

What happened

Check Point has tracked JSCeal since early 2025 as a stealer built around compiled V8 JavaScript — .jsc files executed by a bundled Node.js runtime rather than ordinary interpreted scripts.[1] That packaging choice is deliberate. Compiled V8 bytecode isn't something most antivirus engines or malware analysts read comfortably, and Check Point's own researcher noted that the format sits outside the workflows analysts normally rely on.[2] On top of that, the JavaScript source is run through the open-source javascript-obfuscator tool before compilation, layering on renamed identifiers, RC4-encrypted string chunks, control-flow flattening, and proxy-wrapped function calls.[2]

To get past that, Check Point built what it calls a fully static deobfuscation pipeline — one that recovers readable pseudocode from the compiled bytecode without ever executing the malware.[1] They applied it to 23 collected JSCeal payloads and used an optional LLM-assisted renaming pass to make the recovered code easier to navigate.[1] The toolkit, called jsc_deobfuscator, is publicly available on GitHub, and the methodology was first presented at Black Hat USA 2026 before the detailed write-up followed.[1]

How the campaign gets on a machine

JSCeal doesn't arrive as a drive-by exploit. It arrives through malvertising — paid ads on Facebook and, more recently, Google and YouTube, that impersonate cryptocurrency trading platforms.[3] The original July 2025 Check Point disclosure described threat actors promoting roughly 35,000 malicious ads impersonating nearly 50 crypto trading apps in the first half of 2025 alone, generating a few million views in the EU.[3] Clicking one of these ads sends a victim through a redirect chain to a fake landing page — often styled to look like TradingView — which fingerprints the visitor's IP and referrer before deciding whether to serve the real payload or a harmless decoy.[3]

 

The actual delivery uses two ZIP archives, distributed through PowerShell: one carries the Node.js runtime, the other the JSCeal payload and its supporting components.[2] Splitting the infection this way — some functionality living in the malicious site's own JavaScript, some in the downloaded installer — is a pattern Check Point flagged in its original 2025 report as a deliberate anti-analysis measure, since it requires both pieces running in parallel for the infection to complete.[3] This activity overlaps with clusters other vendors track as WEEVILPROXY and MeadowLocust, and some of the campaign's early activity was independently documented by Microsoft and WithSecure in April and July 2025.[3]

A separate but related operation is worth noting for context, without conflating it with JSCeal itself. Ad-security firm Confiant disclosed a campaign called SourTrade in July 2026 that impersonates trading and crypto brands including Solana, Luno, and TradingView.[4] What makes SourTrade distinct is that it doesn't distribute a finished malware binary at all — the landing page hands the victim's browser assembly instructions, fetches a legitimate file from separate infrastructure, and has the browser construct the final malware in memory, so nothing complete ever touches the network.[4] Confiant assessed this campaign as active since late 2024 across 12 countries and 25 languages, and found technical overlap with a JSCeal campaign Bitdefender described in September 2025.[2] The overlap is evidence of a shared or adjacent operation, not proof that SourTrade and JSCeal are the identical codebase — that distinction matters, and neither Check Point's report nor Confiant's disclosure claims otherwise.

What the obfuscation actually does

It's worth being precise about the obfuscation layer, because "obfuscated malware" gets used loosely. Four techniques recur across JSCeal samples, according to Check Point's technical writeup: identifier renaming to strip meaningful names from functions and variables; splitting sensitive strings into RC4-encrypted chunks reassembled by decoder functions at runtime; control-flow flattening, which collapses a program's logical structure into a single loop driven by a state variable and a switch statement; and routing of ordinary operations — addition, comparison, function calls — through dedicated wrapper functions.[2]

None of these techniques are exotic on their own — javascript-obfuscator is a legitimate, publicly available tool, and each transformation shows up in ordinary commercial code-protection use. What's notable is the combination: obfuscated source compiled into a version-specific V8 bytecode format. Researcher Aleksandra "Hasherezade" Doniec, who led the deobfuscation work, put it this way: the two layers together don't make the malware impossible to reverse, but they push it outside the tooling most analysts already have on hand.[2]

What the malware can do once it's running

The deobfuscated code exposes three broad capability groups. The first is browser and credential theft. JSCeal enumerates installed Chromium-based browsers — Chrome, Edge, Brave, Opera, Opera GX, Avast Secure Browser, Vivaldi, and the Vietnamese browser Cốc Cốc are all named in the report — locates each browser's user-data directory, lists available profiles, and extracts cookies and passwords from them.[2]

The second capability is the one driving most of the coverage: session replay. The recovered code shows JSCeal using stolen cookie data to reconstruct a browser session and conduct what Check Point describes as an active session replay attack, aimed at bypassing authentication and gaining unauthorized access to a victim's Google account.[2] This is the mechanism worth being exact about. Session replay using a stolen cookie is a well-understood attack category — it doesn't require cracking a password or defeating multi-factor authentication, because it reuses a token that already represents an authenticated session. What Check Point's report establishes is that this workflow exists in JSCeal's code and has been recovered through static analysis. The report does not claim this succeeds against every account configuration or every stage of Google's login flow, and it stops short of asserting the technique defeats hardware security keys or session-bound protections uniformly.[5] Treat "can replay a session" as the accurate framing — not "defeats Google account security" as a blanket claim.

A second module adds surveillance: keystroke logging and screenshot capture, giving the operators a fallback data source independent of what cookies happen to be available.[2]

The third capability is a local man-in-the-middle proxy. Check Point compared this to a technique long used by banking trojans: installing a local proxy, generating and installing a certificate, and rewriting web traffic for selected services.[2] JSCeal's recovered code includes dedicated handlers for modifying requests and responses tied to specific platforms — a configuration function exposes distinct overrides for Binance, Bybit, and Ledger, alongside generic handlers capable of replacing HTML content, blocking specific hosts, or clearing selected cookies.[2] Additional handlers focus specifically on cryptocurrency platforms, including one built to capture account data and record wallet balances.[2]

Why the compiled-bytecode angle matters

It's tempting to read this as "yet another info-stealer," but the delivery format is the actual news. Malware compiled to V8 bytecode isn't unheard of, but it remains rare enough that most detection pipelines and manual analysis workflows are built around interpreted JavaScript or native binaries — not this middle format. Earlier Check Point research into the broader technique found that thousands of malicious applications, spanning RATs, stealers, miners, and ransomware, had used compiled V8 JavaScript with unusually low detection rates on VirusTotal, largely because so few analysts examine compiled V8 output directly.

What Check Point's newer static deobfuscation pipeline changes is the cost of that evasion. Rather than requiring a researcher to execute the sample in a monitored sandbox and observe its behavior — slow, and easy for the malware to detect and evade — the pipeline recovers a version-specific disassembler built directly against the V8 API, consumes the code cache, and reconstructs pseudocode without ever running the payload. Doniec noted the toolkit also required debugging V8 itself to fix a string-printing bug that was corrupting the disassembly output, underlining how much low-level work this kind of analysis actually takes.

Ongoing development

Check Point frames JSCeal as an actively maintained project rather than a static tool. The report closes by pointing to recent additions: V8 code caches generated for a newer Node.js/V8 version, an added payload-encryption layer, and expansion of targeting to macOS.[1] Doniec's assessment is that the JSCeal operators are simultaneously investing in making the payload harder to analyze and broadening the platforms it can run on, and that continuing campaign activity into recent months indicates the project remains under active development.[2]

What defenders and crypto users should actually do

None of JSCeal's delivery mechanism depends on exploiting a software vulnerability — it depends on a person clicking an ad and running an installer. That changes where the useful controls sit.

• Don't install trading or crypto apps from ad links. Go directly to the vendor's known domain instead of following a Facebook, Google, or YouTube ad, even if the ad uses a familiar brand name and logo.
• Treat unexpected Node.js runtimes as a signal. A consumer trading-app installer bundling its own Node.js runtime and a separate payload archive is an anomaly endpoint tooling can flag.
• Watch for newly installed root certificates. Since JSCeal's proxy module depends on generating and installing a certificate locally, an unexpected new trusted root CA is a concrete, checkable indicator.
• Assume cookie theft means session compromise, not just password compromise. If a machine is suspected of infection, rotating a password alone isn't sufficient — active sessions and OAuth grants should be reviewed and revoked, since the malware's value comes from replaying cookies rather than cracking credentials.
• Hardware-bound authentication reduces the payoff. Passkeys and hardware security keys that bind a session to a specific device make a replayed cookie less useful on its own, though this article makes no claim about how JSCeal's replay technique performs against any specific implementation, since that wasn't tested or asserted in Check Point's report.

Security takeaway

The interesting part of this story isn't that another stealer targets crypto users — that's been true of JSCeal since 2024. It's that a piece of malware has moved from stealing credentials to actively acting on them inside the compromised browser, and that researchers had to build new tooling just to read what it was doing. The session-replay capability is documented in recovered code, which is a meaningfully different evidence bar than a claim inferred from network traffic or vendor telemetry alone. That's also exactly why the wording matters: "can replay a session using stolen cookies" is what the evidence supports. Broader claims about defeating specific account protections at scale go beyond what's been published.

Sources & References

1. Check Point Research — "Breaking the Seal: Static Deobfuscation of JSCeal's Compiled V8 Bytecode" — August 31, 2026 — research.checkpoint.com
2. The Hacker News — "JSCeal Malware Can Bypass Google Authentication Using Stolen Session Cookies" — September 7, 2026 — thehackernews.com
3. Check Point Research — "Sealed Chain of Deception: Actors Leveraging Node.JS to Launch JSCeal" — July 29, 2025 — research.checkpoint.com
4. Confiant — "SourTrade: Browser-Assembled Malware" — July 2026 — blog.confiant.com
5. This article's own analysis of the cited primary reporting; no independent claim beyond what sources 1–3 establish is made regarding the scope of the session-replay technique.