Ads gone wild: a malvertising scheme nicknamed SourTrade tricks browsers into assembling a full Windows executable from bits and pieces the page hands over — no single malicious binary hosted outright. The campaign impersonated trading sites and crypto services to lure retail traders across multiple countries and languages, and it’s been active since late 2024 according to the security firm that uncovered it.

The browser as assembler — how the trick works

Think of the landing page as a tiny factory. It fingerprints visitors (to hide from researchers), then, for chosen targets, it quietly wires up a delivery pipeline. The rough steps are:

  • Register a page-scoped /sw.js ServiceWorker and spin up a SharedWorker from inline JavaScript so the worker source never shows up as a separate fetch.
  • The SharedWorker requests /config, which returns a template, a secondary runtime URL, and session-specific random values. The browser pulls and inflates a legitimate runtime from that other domain — in samples, that was a clean Bun build.
  • Base64 blobs in the configuration carry PE header pieces, the section table, and a .bun section with malicious bytecode for an app.js-style payload. The page uses that to guide assembly.
  • The worker generates a large pseudo-random byte stream using AES in counter mode (AES-CTR), then follows the template as a byte-copy recipe: copying ranges from the runtime, from the generated stream, and from attacker-supplied chunks to produce a finished PE file.
  • The assembled binary is handed to the ServiceWorker as a readable stream. A hidden iframe navigates to a same-origin URL and the worker serves the bytes back with a Content-Disposition attachment header. The resulting Mark of the Web (MotW) marks the landing page as the download origin.

This pipeline is sneaky for two reasons: it never places a complete malicious executable on the network (each victim can receive a slightly different build) and it leans on a legitimate runtime to provide most of the binary material. In short, no big malicious file sits waiting to be hashed and blocked.

Why this matters (and what to do about it)

Yes, it’s clever, but it isn’t magic. The attackers didn’t exploit a browser zero-day here, and MotW is still present — the trick mainly undermines simple hash-based detections by producing per-session variations of the same payload.

  • Install apps only from vendor websites or trusted app stores — not from ads or ad-driven landing pages.
  • Look beyond single artifacts. Investigate the full chain: ad referral, cloaked landing page behavior, the /config request, the secondary-domain runtime fetch, and the ServiceWorker-served download. Any one piece alone can lie.
  • Monitor for unusual worker registration and same-origin iframe downloads with attachment headers — those are the assembly-and-serve signs to watch for.
  • Use behavioral detection and content inspection in addition to static hashes. Per-session builds reduce hash utility but cannot fully hide attacker-controlled bytecode and PE structures transported in the config data.

The researchers published indicators such as a few hashes and a list of suspicious domains. If you run threat hunting or incident response, chase the chain, not just a single file hash. And if you trade or manage crypto, be extra picky: download trading or wallet tools only from the official vendor pages.

Short version: the ad is the Trojan horse, the browser briefly becomes the blacksmith, and the final executable is forged inside the victim’s session. It’s bizarrely inventive — and a good reminder that defenders need to think about the whole delivery story, not just the final binary.