DEV Community

Etairos.ai
Etairos.ai

Posted on • Originally published at threat-intelligence.redeyesecurity.com

SourTrade Malvertising Makes the Victim's Browser Assemble the Malware

TL;DR

  • what: Confiant detailed SourTrade, a malvertising campaign whose landing pages make the victim's browser build the final Windows executable in pieces from a clean Bun runtime plus attacker-supplied PE structures and bytecode.
  • impact: Every victim can receive a differently-hashed binary because the seed and size rotate per /config response, blunting simple hash-based detection while the malicious payload code stays intact.
  • fix: There is no patch; install trading and wallet software only from the vendor's own site, and inspect the full chain (ad referral, cloaked landing page, /config, secondary-domain runtime fetch, ServiceWorker download) rather than any single artifact.
  • who: Retail traders and cryptocurrency investors on Windows, targeted via ads impersonating TradingView, Solana, and Luno across 12 countries and 25 languages.

Confiant has detailed a malvertising operation it calls SourTrade that flips a basic assumption of malware delivery: no finished binary ever travels the network. Instead, the victim's browser assembles the final Windows executable itself, stitching a legitimate Bun runtime together with attacker-supplied Portable Executable structures and bytecode. The campaign has run since late 2024, impersonates TradingView, Solana, and Luno, and targets retail traders and crypto investors across 12 countries in 25 languages. Confiant published the analysis on July 23, 2026, along with three SHA-256 hashes and a list of malicious domains that The Hacker News counts at 96.

How the browser builds the payload

The landing page starts preparing delivery before any download click. It registers a page-scoped ServiceWorker at /sw.js, then builds a SharedWorker from JavaScript already embedded in the page, so the worker source never appears as its own fetch. The SharedWorker requests /config, which returns a template, a secondary runtime URL, and session-specific random values. The browser pulls and decompresses a clean Bun runtime from that second domain (purelogicbox[.]org in the published sample). Bun runs on Apple's JavaScriptCore engine and legitimately compiles apps and bytecode into standalone Windows executables, which is exactly the capability being abused here.

Base64 blobs in the /config response supply the PE header, the section table, and a .bun section carrying malicious JavaScriptCore bytecode for app.js. The worker generates a large pseudorandom byte stream with AES in counter mode (AES-CTR), then follows the template as a byte-copy recipe, combining selected ranges from the Bun runtime, the generated stream, and the attacker-controlled executable material. Once assembled, the page hands the executable to the ServiceWorker as a readable stream; a hidden iframe navigates to a same-origin URL, and the worker returns the bytes with a Content-Disposition attachment header.

Why per-session builds matter

Rotating the seed and size in each /config response changes the file hash while keeping the executable payload code intact. Each victim can therefore receive a different assembled file. "No finished malware ever exists on the network," wrote Michael Steele of Confiant's threat intelligence team. That claim holds for a complete binary, but the PE structures and the bytecode still arrive as Base64 inside /config, so the malicious material does cross the wire. The practical effect is narrower than it first appears: Confiant's own implications section frames it as unique per-session builds limiting the value of simple hash-based detections, not as full evasion.

⚠️ Mark of the Web is not removed — The chain relies on no browser vulnerability and does not strip MotW. Because the ServiceWorker serves the file same-origin, the MotW record names the landing page as the download source rather than the secondary domain that supplied the Bun runtime. MotW itself remains present on the file.

Cloaking and evolution

SourTrade's landing pages fingerprint visitors. Suspected researchers and bots get an empty page, while selected targets see a convincing copy of the impersonated trading or wallet service. The technique evolved from activity Confiant tracked through April 30, 2026, when pages loaded StreamSaver.js, an open-source streamed-download library, from its author's GitHub Pages address, which left the recorded download path pointing at that GitHub URL. Current pages keep the streaming architecture, including the streamsaver: message names, but no longer fetch the library from GitHub.

What the payload is, and what is unproven

Bitdefender documented the related TradingView malvertising cluster in September 2025, naming the final payload as the stealer that Check Point tracks as JSCEAL and WithSecure as WeevilProxy. Confiant identifies shared campaign and executable characteristics but does not demonstrate that its three published samples carry that payload. Confiant also states Bitdefender found a modified Bun executable in this cluster; The Hacker News found no mention of Bun in the linked September 2025 post, which instead names its loader detection Variant.DenoSnoop.Marte.1. Confiant named no actor and stopped its analysis at the moment the file lands on disk.

Attribution not yet established — Credential theft, keylogging, traffic interception, wallet theft, and remote-access capabilities documented in the earlier campaign cannot yet be assigned to the current SourTrade files. Confiant documents delivery, not execution, and does not establish whether the download starts automatically or requires a click.

Defensive takeaways

  • Install trading and wallet software only from the vendor's own site, never from an ad.
  • There is no patch to apply; this is a delivery and detection-evasion technique, not an exploited CVE.
  • Do not treat any single network or file artifact as decisive. Examine the whole chain: ad referral, cloaked landing page, /config request, secondary-domain runtime fetch, and ServiceWorker download.
  • Hash-based detection is weakened per session, but attacker-controlled PE material and bytecode still cross the network as Base64 in /config and remain viable inspection points.
  • Block the 96 published domains and hunt for the three published SHA-256 hashes, treating them as a floor rather than a complete set given per-session hash rotation.
  • Watch for browser behavior that registers a ServiceWorker plus SharedWorker and fetches a Bun runtime from a second domain before a same-origin attachment download fires.

Originally published on RedEye Threat Intelligence.

Top comments (0)