Check Point Research has published analysis of JSCeal, a compiled V8 JavaScript malware family targeting Windows, distributed through malvertising that impersonates cryptocurrency and trading platforms — TradingView, Solana, Luno, Bybit. Related activity has been tracked by Bitdefender since September 2025 and by Confiant as SourTrade since July 2026, under cluster names including WEEVILPROXY and MeadowLocust.

Its browser-stealing module extracts cookies, passwords and OAuth tokens from the user-data directories of Chromium browsers — Chrome, Edge, Brave, Opera, Vivaldi, Cốc Cốc and others — and reconstructs the browser session to reach the victim's Google account.

That last capability is being reported as bypassing Google authentication. It is worth being precise, because the wording decides what people go and do on Monday.

What was actually defeated

Nothing in Google's authentication.

A session cookie is what a service issues after you have authenticated, so you need not log in every time. Stealing it and replaying it does not break the login — it skips the login, because the login already happened. No password was cracked, no multi-factor prompt was defeated, no passkey was forged: those 3 mechanisms were not involved at any point. The malware took a token the browser was already holding.

This is also not specific to Google. The same theft works against every service in that profile, for the same reason. Google is in the headline because it is recognisable.

Why the distinction changes the response

If you believe Google authentication was bypassed, you look for an authentication fix: stronger MFA, a different provider, a configuration change. None of those help. The failure is that unauthorised code ran on the endpoint with access to the browser profile — and JSCeal reads at least 6 Chromium browsers, so switching browser is no mitigation. Every session in that profile is the attacker's until it is invalidated.

What does help:

  • Endpoint control, because the whole chain starts with a malicious installer being run.
  • Short session lifetimes and reauthentication for sensitive actions, which shrink the window a stolen cookie is worth anything.
  • Device-bound session credentials, which cryptographically tie a session to the machine that created it so that a replayed cookie from elsewhere fails. This is the only control in the list that addresses the actual technique.
  • Sign out everywhere after a suspected infection. Rotating the password without invalidating sessions leaves the attacker exactly where they were.

The same confusion turned up in the passkey coverage last week: the cryptography holds and the account still falls, because the attack was never aimed at the cryptography.

How it arrives

Malvertising on Facebook and Google points at counterfeit trading sites. The victim downloads what looks like an installer for TradingView or a similar platform.

What runs is a PowerShell stage that pulls 2 ZIP archives: one containing a Node.js runtime, the other the payload. Bringing your own Node runtime is a deliberate choice — the interpreter is legitimate and signed, and the malicious part is script that a trusted binary executes. Nothing on disk looks like malware because, strictly, nothing on disk is malware.

The payload itself is compiled V8 bytecode rather than JavaScript source, which removes the easiest static analysis path. In the related SourTrade activity, what gets delivered is described as assembly instructions for building the malware in memory rather than a finished binary — no complete artifact to scan at any point.

Scale

The campaign has run since late 2024 in its SourTrade form, targeting 12 countries in 25 languages, concentrated in Asia Pacific and Latin America.

No infection count has been published, no indicators of compromise are included in the reporting, and Google has not commented.

What to do

  • Treat any machine that ran an unexpected installer as fully compromised, and invalidate its sessions everywhere rather than only changing passwords.
  • Enable device-bound session credentials wherever your provider offers them. It is the one control aimed at this technique rather than around it.
  • Shorten session lifetimes for administrative and financial accounts, and require reauthentication for high-value actions.
  • Assume search and social advertising is a delivery channel. The lure here is a paid ad for software the victim went looking for.
  • Do not tell your users that MFA failed. It did not, and telling them otherwise teaches the wrong lesson about what protects them.

What is not established

  • Attribution. No actor is named.
  • Victim count. None published.
  • Indicators of compromise. None were included in the reporting.
  • Whether Google has shipped detections or responded at all.
  • How effective stolen cookies are against Google's anomalous-login detection, which is the question that decides how much of this actually works in practice.