SourTrade: Malvertising leveraging Bun Runtime for Client-Side Payload Assembly
Hey everyone,
Just caught the Confiant report on the "SourTrade" operation active since late 2024. It looks like malvertising actors are getting smarter about evading static analysis. Instead of serving a pre-compiled EXE from a fixed URL—which is easy for signature-based heuristics to catch—they are delivering the payload in fragments and forcing the victim's browser to assemble the final malware locally using the legitimate Bun JavaScript runtime.
The campaign is specifically targeting retail traders, impersonating brands like TradingView, Solana, and Luno. By using Bun to build the executable on the fly, they effectively bypass traditional network gateways that might block known malicious binaries.
The reliance on Bun is a distinct TTP here. If you have EDR coverage, you should be hunting for unexpected process chains where the browser spawns bun.exe or creates suspicious child processes immediately after.
Here is a basic KQL query to start hunting for this behavior:
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in ~("chrome.exe", "msedge.exe", "firefox.exe")
| where FileName == "bun.exe"
| project DeviceName, FileName, InitiatingProcessFileName, ProcessCommandLine
Has anyone else seen Bun being abused in the wild like this? For those without strict software restriction policies, how are you handling the risk of legitimate runtimes being weaponized in userland?
We actually blocked Bun via AppLocker on our non-dev fleet last quarter after seeing it used in some crypto-stealers. It's a prime example of why allowing arbitrary runtimes in the user path is a massive risk. If a user doesn't need it for their job, the binary shouldn't be allowed to execute.
The fragmentation aspect is tricky. Since the pieces likely resemble standard web assets (JS/JSON) until they hit the Bun runtime, network inspection might struggle to flag the malicious intent without deep SSL inspection. We're looking at writing a Sigma rule to flag any child processes spawned by bun.exe that aren't signed by a trusted dev certificate.
From a pentester's perspective, this is a clever 'living-off-the-land' variation. It shifts the burden of 'compilation' to the victim. If the attackers are obfuscating the JavaScript payload before the browser builds it, even behavioral EDR might have a high false-positive rate unless they specifically profile Bun's activity patterns.
Solid points. If you can't block Bun outright, focus on hunting for the specific process lineage. Browser-spawned Bun instances followed by suspicious child processes are a huge red flag.
You can try a KQL hunt like this:
DeviceProcessEvents
| where FileName == "bun.exe"
| where InitiatingProcessFileName in ("chrome.exe", "msedge.exe")
| project Timestamp, DeviceName, FileName, ProcessCommandLine
Catching the transition from browser context to runtime execution is usually the best window for detection.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access