Key Takeaways
- The SourTrade malvertising campaign builds a Windows executable inside the victim’s browser by stitching together a legitimate Bun runtime and attacker‑supplied code, rather than delivering a pre‑compiled malware file.
- Landing pages use cloaking: they show an empty page to researchers/bots while presenting a convincing clone of TradingView, Solana, or Luno to genuine targets.
- A page‑scoped ServiceWorker and an embedded SharedWorker coordinate the download; the SharedWorker fetches a configuration that supplies Base64‑encoded PE headers, a .bun section with malicious JavaScriptCore bytecode, and a secondary runtime URL.
- The final binary is assembled client‑side using a pseudorandom byte stream (AES‑CTR) and a template, producing unique per‑session files that evade simple hash‑based detection.
- Although the Mark of the Web (MotW) remains attached to the landing page, no complete malicious binary ever appears on the network; only components and instructions are transferred.
- Defenders must inspect the entire infection chain—ad referral, cloaked landing page, /config request, secondary‑domain runtime fetch, and ServiceWorker‑mediated download—rather than relying on isolated indicators.
Overview of the SourTrade Technique
Confiant’s July 23 2026 report details a malvertising operation named SourTrade that has been active since late 2024. The campaign impersonates popular crypto‑related services such as TradingView, Solana, and Luno to lure retail traders and investors across twelve countries, serving ads in twenty‑five languages. Instead of hosting a ready‑made malicious executable, the attackers force the victim’s browser to construct the final Windows PE file on the fly, using a clean Bun runtime as a foundation. This approach reduces the footprint of static malware on distribution networks and complicates traditional signature‑based defenses.
Landing Page Cloaking and Target Selection
The initial landing page performs browser fingerprinting to distinguish between casual visitors, security researchers, bots, and genuine trading‑interested users. Suspected analysts receive an empty or benign page, while selected targets are presented with a high‑fidelity clone of the impersonated service. This cloaking tactic ensures that automated analysis tools and sandboxes see little suspicious activity, allowing the malicious flow to proceed only for likely victims. Users are advised to download trading and wallet software directly from official vendor sites to avoid falling for such decoys.
ServiceWorker and SharedWorker Coordination
Upon loading, the landing page immediately registers a page‑scoped ServiceWorker at /sw.js. Simultaneously, it creates a SharedWorker from JavaScript already embedded in the page, meaning the worker’s source code never appears as a separate network request. The SharedWorker then issues a request to /config, which returns a JSON‑like template containing a secondary runtime URL, session‑specific random values, and Base64‑encoded blobs that represent the PE header, section table, and a .bun section holding malicious JavaScriptCore bytecode for app.js. This modular delivery keeps the malicious payload fragmented across multiple requests.
Retrieving the Clean Bun Runtime
Using the secondary domain supplied in /config (in the analyzed sample, purelogicbox[.]org), the browser fetches a legitimate Bun runtime. Bun is a JavaScript toolchain that runs on Apple’s JavaScriptCore engine and can compile applications and bytecode into standalone Windows executables. Because the runtime itself is benign and signed normally, it passes typical reputation checks, allowing the attackers to piggyback on a trusted component while injecting their own malicious bytecode later in the process.
Client‑Side Assembly of the Executable
The SharedWorker combines three elements to build the final PE file: the clean Bun runtime, a large pseudorandom byte stream generated via AES in counter mode (AES‑CTR), and the attacker‑controlled executable material supplied in the Base64 blobs. The configuration provides a byte‑copy template that dictates which ranges of each source to concatenate. By rotating the seed and size of the pseudorandom stream for each /config response, every victim receives a uniquely hashed binary while preserving the core malicious code. As Confiant’s researcher Michael Steele noted, “No finished malware ever exists on the network”; only the parts and instructions travel over the wire.
Delivery to the User’s Disk
Once assembled, the executable is exposed as a readable stream to the ServiceWorker. A hidden iframe then navigates to a same‑origin URL, prompting the worker to return the generated bytes with a Content‑Disposition: attachment header. This triggers a download that the browser marks as originating from the landing page, so the Mark of the Web (MotW) points back to the ad‑served page rather than the secondary domain that supplied the Bun runtime. The MotW remains present, but because the file is assembled client‑side, hash‑based blocklists are ineffective unless they catch the exact per‑session variant.
Evolution from Earlier Streamsaver‑Based Tactics
Earlier iterations of the campaign, observed through April 30 2026, relied on the open‑source StreamSaver.js library hosted on the author’s GitHub Pages. That left a clear download‑path artifact pointing to GitHub, making the infrastructure easier to trace. The current version retains StreamSaver’s streaming architecture and message names but no longer fetches the library from GitHub; instead, the streaming logic is embedded directly in the page, further obscuring the attack chain and reducing detectable external dependencies.
Connections to Known Payloads and Attribution Gaps
Bitdefender’s September 2025 analysis of a related TradingView malvertising cluster identified the final payload as the information stealer tracked by Check Point as JSCEAL and by WithSecure as WeevilProxy. Confiant notes shared characteristics between that cluster and SourTrade but does not confirm that the three published samples carry the same stealer. Additionally, Bitdefender reported finding a modified Bun executable in the earlier cluster, yet The Hacker News could not locate any mention of Bun in the linked September 2025 post, which described a loader detection named Variant.DenoSnoop.Marte.1. Consequently, capabilities such as credential theft, keylogging, traffic interception, wallet theft, and remote access attributed to the earlier activity cannot yet be definitively assigned to the current SourTrade files without further evidence.
Practical Implications for Defenders
Because each victim receives a uniquely constructed binary, relying solely on hash‑based detection offers limited value. However, the attack still leaves observable network artifacts: the ad referral, the cloaked landing page, the /config request, the fetch of the clean Bun runtime from a secondary domain, and the ServiceWorker‑mediated download that returns the assembled file with an attachment header. Security teams should monitor the full chain, looking for anomalies such as ServiceWorker registrations on unexpected origins, SharedWorker creation from inline scripts, requests to unusual domains for Bun runtimes, and downloads accompanied by Content‑Disposition: attachment that originate from ad‑served pages. Employing behavioral detection, network‑level inspection of the described request patterns, and user education about downloading software only from official sources will improve resilience against this evolving malvertising technique.