Deconstructing SourTrade: Client-Side Malware Assembly via the Bun Runtime

The evolution of modern threat landscapes has forced a shift in how malicious payloads are delivered, moving away from static, monolithic binaries toward dynamic, on-demand construction. If you look at endpoint and network security tools over the past decade, they have largely been built on a foundational assumption: that malware must traverse a network or reside on a disk in a recognizable, signature-matchable state long enough to be inspected.

The SourTrade campaign, active since late 2024 and targeting retail traders and crypto investors across 12 countries, systematically breaks this assumption. Rather than downloading an executable, victims’ browsers are co-opted into acting as local compilation factories. By leveraging advanced visitor cloaking, native browser workers, and the high-performance Bun runtime, SourTrade bypasses traditional signature-based detection entirely. Understanding how this client-side assembly pipeline operates is essential for modern security engineers and threat intelligence analysts working to outpace weaponized development ecosystems.

Anatomy of the Delivery: Evasion and Visitor Cloaking

Before a single byte of malicious code is synthesized, SourTrade executes a rigorous reconnaissance and cloaking phase designed to filter out automated scanners, security researchers, and sandboxes. Malvertising distribution networks often rely on programmatic ad exchanges, making them ripe for filtering if not handled with care.

When a user clicks a malicious ad, the landing page initiates advanced browser fingerprinting. It checks for headless browser indicators, known security vendor IP ranges, behavioral anomalies, and environmental inconsistencies.

[Victim Browser] ---> (Landing Page Fingerprinting) 
                         |
       +-----------------+-----------------+
       |                                   |
[Bot / Researcher]                 [Legitimate Target]
       |                                   |
[Serves Empty Page]               [Renders Platform Clone:
                                   TradingView, Solana, Luno]

If the visitor fails the fingerprinting checks—indicating a potential analysis environment—the server simply renders a completely benign, empty page. This starves the analyst of artifacts. However, if the visitor matches the demographic profile of a retail trader or crypto investor, the infrastructure serves a pixel-perfect clone of high-value platforms such as TradingView, Solana, or Luno.

To maximize its reach across its target geographic spread, the campaign supports multi-language delivery across 25 distinct languages. The social engineering wrapper is localized down to the regional dialect and UI expectations of the victim, ensuring that the prompt to download a “performance update” or “desktop client” feels entirely authentic.

The Architecture of Client-Side Assembly

The defining characteristic of SourTrade is the complete absence of a finished malware binary on the network. If you pull PCAPs or inspect HTTP streams during the initial phases of the attack, you will not find a malicious .exe file passing over the wire. Instead, the components are shipped in fragmented, decoupled pieces that look innocuous in isolation.

The orchestration of this delivery relies heavily on modern browser APIs—specifically SharedWorkers and ServiceWorkers.

1. Reconnaissance & Request: Once the target is hooked on the cloned platform page, a background SharedWorker quietly initializes. This worker requests a configuration file containing Base64-encoded Portable Executable (PE) structures and encrypted bytecode configurations.
2. Sourcing the Runtime: Simultaneously, the script fetches a legitimate, clean, uncompromised Bun runtime binary from an external, trusted domain. Because the Bun runtime itself is signed and legitimate, standard network filters see only a standard developer tool being downloaded.
3. Local Synthesis: The browser’s ServiceWorker intercepts network requests and acts as an assembly plant. It takes the clean Bun runtime, the fetched PE headers, and the encrypted bytecode configurations, stitching them together directly within the browser’s memory space.

This modular architecture means that threat intel teams relying solely on static file hashes or classic indicators of compromise (IoCs) are left chasing ghosts. There is no static hash for the final binary because the binary does not exist until it is minted locally on the victim’s machine.

Weaponizing the Stack: Bun, JavaScriptCore, and AES-CTR

The choice of the Bun runtime and its underlying JavaScriptCore bytecode engine by the SourTrade operators represents a broader trend in modern threats: the weaponization of high-performance developer tooling. Bun’s speed and lightweight architecture make it an ideal vehicle for rapid execution, but its inclusion in a delivery chain introduces fascinating cryptographic mechanics.

To assemble the final executable without triggering memory corruption anomalies or crashing the browser context, the payload uses an AES-CTR (Advanced Encryption Standard in Counter mode) pseudorandom byte stream recipe.

The AES-CTR recipe acts as the blueprint, dictating how the byte streams from the PE headers, the .bun JavaScriptCore bytecode section, and the runtime binary are interleaved and aligned. Because the cryptographic key or IV can be randomized per session, this results in polymorphic file generation. Every single victim session yields a mathematically unique binary hash, rendering traditional file-hash blacklists obsolete.

Furthermore, when the final assembled executable is streamed back to the browser and offered as a download via a hidden iframe, it inherits Mark of the Web (MotW) attributes linked to the initial landing page. Depending on how the browser handles the attachment stream, this can sometimes influence Windows Defender SmartScreen prompts, though the social engineering context often convinces the user to bypass warnings manually.

For a deeper dive into the specific mechanics of this runtime manipulation, you can review our technical analysis on the anatomy of the SourTrade Bun runtime malware.

Defensive Strategies and Mitigation

Defending against client-side assembly pipelines requires a fundamental pivot in mindset. If your detection engineering strategy relies on catching a known malicious file hash at the network perimeter or the endpoint, campaigns like SourTrade will bypass your controls every time. Security teams must adapt by implementing behavioral and contextual telemetry across the entire kill chain.

1. Advanced Endpoint Behavioral Monitoring

Because the malware is assembled in-memory and executed via a legitimate interpreter, focus on process lineage and behavioral anomalies rather than static binaries:

• Monitor for child processes spawned by runtime environments (like bun.exe) executing suspicious system commands, network connections, or memory injection techniques (e.g., process hollowing).
• Alert on anomalous file creation events where a standard developer utility suddenly writes a disparate PE payload to disk from an unexpected browser cache directory.

2. Browser Worker and Network Visibility

Client-side assembly heavily abuses native web worker architectures. Security teams should:

• Audit enterprise browser policies to restrict unnecessary SharedWorker and ServiceWorker activity, particularly on endpoints where users should not be running development runtimes.
• Implement deep packet inspection and endpoint browser telemetry that monitors for hidden iframe data-stream generation, especially when paired with data blobs or unusual Base64 decoding routines inside worker threads.

3. Egress Filtering and Runtime Governance

Since threat actors rely on fetching clean components from trusted external domains to maintain legitimacy, strict egress filtering and application control are critical:

• Restrict execution of unauthorized runtimes like Bun, Node.js, or Deno on non-developer endpoints via application whitelisting solutions.
• Inspect HTTP/HTTPS traffic for anomalous data-streaming patterns originating from web worker contexts that mimic file construction pipelines.

Future Outlook: The Next Wave of Living-Off-The-Browser Attacks

The SourTrade campaign is unlikely to remain an isolated incident; rather, it serves as a proof-of-concept for a maturing class of “Living-Off-The-Browser” (LotB) attacks. As endpoint detection engineering grows increasingly sophisticated at catching traditional script-based droppers and macro-enabled documents, threat actors are pushing execution down into the browser engine itself.

We can expect future campaigns to further weaponize legitimate software runtimes, cloud IDE environments, and native browser features like WebAssembly (Wasm) and advanced worker threads to obfuscate delivery paths. When the browser becomes the compiler and the assembly plant, perimeter-only security models collapse.

Mitigating this wave requires moving away from siloed defenses toward whole-chain anomaly detection—correlating network edge telemetry, browser worker behavior, and endpoint execution context in real-time. Only by observing how these pieces stitch together can security teams break the assembly line before the payload ever reaches execution.