JSCeal drives your stolen cookie through Google login

Most credential stealers grab a cookie and hand it to a human. JSCeal automates the next step: it launches the victim's own browser, injects the stolen session cookie, and drives Google's real authentication flow with Puppeteer until it walks out holding OAuth tokens. Check Point Research published a static deobfuscation of the payload on August 31 that lays out exactly how it works. The interesting part is not the theft. It is the laundering of a stolen cookie into durable access.

What actually happened

JSCeal ships as compiled V8 bytecode — a .jsc file — executed by a bundled Node.js runtime. Check Point documents the launch line as .\node.exe -r .\preflight.js .\app.jsc, with the payload Brotli-compressed and unpacked by preflight.js at run time. Before compilation, the source is put through javascript-obfuscator: RC4-protected strings, control-flow flattening, proxy functions, operation wrappers.

That stack is chosen to defeat analysis, and it mostly worked. Compiled V8 bytecode sits outside the tooling most analysts reach for. Check Point's answer was to build jsc_deobfuscator and publish it, so the payload can be read statically without detonating it.

What it takes: cookies, saved passwords and OAuth tokens from Chrome, Edge, Brave, Opera, Vivaldi and other Chromium browsers, pulled straight out of the browser databases along with origin and username.

What it does next is the part worth your attention. Rather than exfiltrating a cookie and waiting, the malware replays it through Google's genuine sign-in flow under browser automation built to avoid looking automated. When Google throws a password challenge, it iterates candidate passwords — the ones it already stole from the same browser profile — then collects the resulting OAuth tokens and user IDs. Check Point notes recent samples adding a fresh encryption layer and macOS targeting alongside the Windows focus.

Why browser session theft matters for your business

An OAuth token is not a session cookie. Kill a session and the cookie dies with it. A token issued through a completed login persists, survives the "sign out everywhere" button that saved you last time, and often carries API scope rather than just web access. JSCeal converts a fifteen-minute smash-and-grab into standing access — and does it by passing every check Google actually performs, because from Google's side nothing anomalous happened.

Three things follow.

node.exe is not a safety signal. A legitimately signed Node runtime executing an opaque .jsc is the whole delivery mechanism. If your endpoint policy allowlists Node because developers need it, that allowlist now covers this. Alert on Node processes launched from user-writable directories with -r preloads.

Audit third-party app access, not just sessions. In Google Workspace, that is the connected-apps list per user. Revoking sessions does not revoke tokens. Look at what is authorized, on a schedule, and remove what nobody recognizes.

The browser profile is the crown jewel. Saved passwords, cookies and tokens live in one place that any process running as the user can read. Move business credentials to a real password manager, keep work profiles separate from personal, and treat "log in with Google" as a privilege that needs periodic review — the same lesson as Claude session theft, with a longer tail.

Sources: Check Point Research, The Hacker News.