Mitigating Browser-Based Payload Assembly: The SourTrade/Bun Vector
Has anyone dug into the Confiant report on the 'SourTrade' malvertising campaign? The mechanism is wild—they're not serving the executable directly. Instead, they're compromising ad networks to deliver script fragments that force the victim's browser to compile the final Windows executable locally using the legitimate Bun runtime.
This poses a significant detection challenge. They're impersonating TradingView, Solana, and Luno to hit retail traders. Since Bun is a legitimate JavaScript runtime, standard static analysis might miss the payload if we're just looking for known malicious hashes. The assembly happens client-side, meaning the malicious file never touches the disk or network in its final form until it's built locally.
I'm trying to build a detection rule for this behavior. Since the browser shouldn't normally be spawning bun.exe, a parent-child process rule seems like the best immediate defense. I've drafted this Sigma rule, but I'm worried about false positives from developers actually testing web apps:
title: Potential Browser-Spawned Bun Runtime Payload Assembly
status: experimental
description: Detects bun.exe spawned by web browsers, indicative of malvertising payload assembly.
logsource:
category: process_creation
product: windows
detection:
selection:
ParentImage|endswith:
- '\chrome.exe'
- '\msedge.exe'
- '\firefox.exe'
Image|endswith: '\bun.exe'
condition: selection
level: high
Has anyone else observed this in the wild? Are there specific IOCs or network patterns (aside from the ad networks) we should be blocking at the perimeter?
That Sigma rule is a solid starting point, but you might want to add a filter for command line arguments. In the SourTrade campaign, Bun is usually invoked with specific flags to bundle the script silently. We've seen arguments like bun build --compile in similar cases.
Also, check your DNS logs. The initial malvertising phase often calls out to specific domains before fetching the Bun scripts. Blocking known ad-tech domains used for retargeting can reduce the attack surface significantly.
The real issue here is the prevalence of Bun in dev environments. If you have a lot of engineers running local tests, this rule might flood your SOC.
I'd suggest correlating this with network events. If bun.exe spawns from a browser AND immediately attempts an outbound connection to a non-corporate IP or to a known bad ASN (check for hosting providers rather than consumer broadband), that’s your smoking gun.
We don't allow Bun in our production environment, but blocking the execution is tricky if it's downloaded as a portable executable. We've had success using AppLocker to restrict execution to Program Files. Since these attacks usually drop the runtime in AppData or Temp, a simple block policy on unsigned binaries from user directories stops the chain.
Great discussion. While AppLocker is effective, you can also catch the post-compilation behavior. In these attacks, the resulting executable often spawns unexpected children like cmd.exe or powershell.exe. A simple process creation filter helps distinguish malicious usage from standard development builds:
ParentImage|endswith: '\bun.exe'
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
Legitimate builds typically don't drop to a shell immediately.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access