Anatomy of SourTrade: How Modern Malvertising Uses the Bun Runtime to Assemble Malware Client-Side

The evolution of web-based malware delivery has reached a fascinating and dangerous inflection point. For decades, the standard playbook for threat actors involved hosting a binary on a remote server, tricking a user into downloading it, and hoping it slipped past perimeter defences. If the file hash was discovered, security tools would block it globally within minutes.

Enter SourTrade, a sophisticated malvertising campaign active since late 2024. Targeting retail traders and cryptocurrency investors across 12 countries and 25 languages, SourTrade uses impersonations of trusted platforms like TradingView, Solana, and Luno. But what makes this campaign a watershed moment for threat intelligence is its core architectural shift: no complete binary ever exists on the network.

Instead of downloading a pre-compiled executable, the victim’s browser does the heavy lifting. Through a clever orchestration of modern web APIs and a legitimate JavaScript runtime, the browser acts as a local forge, stitching together a unique piece of malware entirely on the client side.

Here is a breakdown of how the SourTrade campaign works under the hood, why legacy security controls crumble against it, and how security engineers can adapt to this new paradigm of client-side assembly.

The SourTrade Architecture: Workers and Runtimes

To understand how SourTrade pulls off this trick, we have to look at the initial execution chain. When a user clicks a malicious advertisement or navigates to a typo-squaded landing page, the site initiates a complex background orchestration process. Rather than relying on simple, easily inspectable inline JavaScript, the campaign leverages browser ServiceWorkers and SharedWorkers.

Worker Architecture: By utilizing background workers, the attackers maintain execution persistence independent of the primary DOM tab lifecycle. Even if the user navigates away from the landing page view, the worker thread continues to orchestrate the attack chain in the background.

The anatomy of this phase relies on a few key components:

• Configuration Payloads: The worker requests an encrypted or obfuscated configuration file containing template structures, randomized parameters, and secondary URLs.
• The Legitimate Runtime: Rather than pulling down a custom, heavily flagged binary loader, the worker fetches a clean, unmodified copy of the Bun runtime from a secondary domain.

By sourcing a legitimate, signed application runtime, the attackers immediately establish an aura of operational trust. From a network monitoring perspective, downloading a legitimate utility like Bun often fails to trigger perimeter alerts, setting the stage for the core assembly phase.

Client-Side Assembly: Stitching the PE Executable

Once the worker has acquired the configuration parameters and the clean Bun runtime, the real engineering marvel—and security nightmare—begins. The browser dynamically constructs a unique Windows Portable Executable (PE) on the fly.

This client-side assembly relies heavily on the HTML5 Streams API and cryptographic primitives running entirely within the JavaScript environment.

+-------------------------------------------------------------+
|                     Browser Environment                     |
|                                                             |
|  +------------------+       +----------------------------+  |
|  | ServiceWorker /  | ----> | Fetch Clean Bun Runtime    |  |
|  | SharedWorker     |       +----------------------------+  |
|  +------------------+                     |                 |
|           |                               v                 |
|           |                 +----------------------------+  |
|           +---------------> | Fetch Config & Params      |  |
|                             +----------------------------+  |
|                                           |                 |
|                                           v                 |
|                             +----------------------------+  |
|                             | Stream Assembly (AES-CTR)  |  |
|                             | - PE Header                |  |
|                             | - Section Table            |  |
|                             | - Custom .bun JS Bytecode  |  |
|                             | - Randomized Padding       |  |
|                             +----------------------------+  |
|                                           |                 |
|                                           v                 |
|                             +----------------------------+  |
|                             | Deliver as Streamed Blob   |  |
|                             +----------------------------+  |
+-------------------------------------------------------------+

The Anatomy of the Generated PE

The script uses a pseudorandom byte stream generator—often powered by AES-CTR implementations in JavaScript—to stitch the PE structure together block by block:

1. The PE Header and Section Table: The basic structural skeleton of a Windows executable is written into a memory buffer.
2. The Custom .bun Section: Instead of embedding raw malicious shellcode directly into a standard .text or .data section, the assembly process embeds a custom section housing JavaScriptCore bytecode designed to be executed natively by the Bun runtime.
3. Randomized Padding and Seeds: To ensure that static file hashes are entirely useless, the configuration injects randomized sizing padding and unique seeds into the file structure during generation.

Finally, the browser packages this constructed byte array into a Blob and triggers a download. Because the file was synthesized locally within the browser’s memory space, no signature scanner ever had the opportunity to analyze the completed payload prior to execution.

Evasion Mechanics and the Mark of the Web (MotW)

The brilliance of the SourTrade approach lies in how it systematically neutralizes legacy security controls.

Defeating Hash-Based Detection

Because the configuration parameters and padding sizes are randomized per request, every single victim receives a cryptographically distinct Windows executable. Traditional endpoint detection and response (EDR) systems that rely on static indicators of compromise (IoCs) like SHA-256 hashes are rendered completely blind. There is no shared signature to blacklist.

The Mark of the Web (MotW) Paradox

One might assume that browser-downloaded files would immediately trigger Windows Mark of the Web (MotW) protections, warning the user before running an unverified executable. SourTrade navigates this by delivering the final payload via a readable stream and invoking a controlled Content-Disposition attachment header.

Interestingly, the browser attributes the MotW to the primary landing page (the impersonated TradingView or Solana site) rather than the external domain that served the clean Bun runtime. This maintains the illusion of legitimacy while still delivering an artifact that the user must manually execute—a hurdle easily cleared through social engineering tactics tailored to anxious crypto traders and retail investors.

Defensive Strategies and Mitigation

Defending against campaigns like SourTrade requires an architectural pivot. Traditional perimeter defenses focused on static file blocking and signature matching will continue to miss threats that are assembled at the endpoint. Security teams must adopt a multi-layered approach centered on behavioral visibility.

1. Shift from Static File Checks to Behavioral Monitoring

Because the payload hash changes per victim, detection engineering must focus on what the process does, not what it looks like on disk.

• Monitor for unexpected child-process spawns originating from browser processes.
• Track anomalous executions of runtime environments (such as Bun or embedded Node.js components) in enterprise environments where developers are not expected to use them, particularly on endpoints belonging to finance, retail, or executive staff.

2. Inspect Worker Activity and Script Orchestration

Security operations centers (SOCs) should enhance browser telemetry and endpoint visibility to flag suspicious client-side script behaviors:

• Inspect for heavy use of the HTML5 Streams API combined with large binary blob generation originating from ad networks or untrusted domains.
• Audit the instantiation of persistent ServiceWorkers and SharedWorkers originating from newly registered or unverified domains.

3. Enforce Application Control Policies

Implement strict application whitelisting (such as Microsoft Defender Application Control or equivalent enterprise tools) to prevent unauthorized binaries and scripting runtimes from executing outside of approved developer directories. If an unauthorized runtime like Bun attempts to execute from an AppData or temporary download directory, it should be blocked automatically regardless of its cryptographic signature.

Future Outlook: The Rise of Living-off-the-Browser Runtimes

SourTrade represents a worrying precursor to where web-based threats are heading. As perimeter defenses grow more adept at spotting traditional malware payloads, threat actors are shifting their operational overhead away from infrastructure-heavy binary hosting and onto the victim’s own hardware.

We can anticipate an increase in threat campaigns leveraging legitimate application runtimes—whether that is Bun, modular Node.js components, or other language ecosystems with native compilation or interpretation features—to dynamically generate payloads in the browser.

For security engineers and threat hunters, the message is clear: the battlefield has moved from the network boundary to the browser execution context. Protecting modern organizations requires moving past static file analysis and embracing real-time behavioral monitoring that can catch malware in the exact moment of its birth.