SourTrade builds malware in the browser to beat hashes

Nearly every endpoint control your business pays for assumes a malicious file crossed the wire at some point. SourTrade is a malvertising operation built specifically to violate that assumption: no finished binary ever travels the network. The victim's browser assembles the executable in memory from parts, using a fresh random seed each session, so every victim gets a file with a hash nobody has ever seen.

What actually happened

Confiant published research on the SourTrade campaign on July 23, and BleepingComputer covered it July 25. The campaign has run since late 2024, impersonating TradingView, Solana, and Luno to target retail traders and crypto investors across 12 countries in 25 languages.

The delivery chain is the interesting part. The landing page registers a ServiceWorker, spins up a SharedWorker, and fetches a config containing a template and a secondary runtime URL. It pulls down a clean, legitimate Bun runtime from separate attacker infrastructure — a real signed-looking binary base, not malware. Then it combines base64-encoded PE headers, section tables, and malicious JavaScriptCore bytecode with locally generated AES-CTR bytes, assembles the result according to the template recipe, and hands it to the ServiceWorker, which serves it back through a hidden iframe with a Content-Disposition: attachment header. The browser saves a file it built itself.

Two details make it durable. The seed and size parameters are randomized per session, so every victim's file has a unique hash — file fingerprinting, still the most widely deployed detection technique in the industry, fails by construction. And Mark of the Web records the landing page as the source, not the separate domains that supplied the components, so the provenance trail points at the wrong place. The landing pages also fingerprint visitors and show researchers and bots an empty page.

Why this matters for your business

You are probably not the target. Your bookkeeper searching for a trading platform on a work laptop might be, and that's the same thing.

The real lesson is about what your detection actually rests on. If your security posture is "we have endpoint protection," it's worth knowing which layers of it are hash-based signature matching, because that layer contributes roughly nothing against this technique. What still works: application allowlisting, blocking execution from user-writable paths like Downloads and %TEMP%, behavioral detection that flags an unknown binary making outbound connections, and — the cheapest control on the list — DNS filtering that never lets the landing page load.

The pattern generalizes past this campaign. Attackers have moved decisively toward assembling payloads on the endpoint rather than delivering them, and legitimate runtimes like Bun, Node, and Python are increasingly the carrier. Detection that asks "have I seen this file before" is answering a question attackers stopped asking. Detection that asks "should this process be doing this" still holds.

Concretely: confirm your EDR does behavioral analysis and not just signatures, turn on execution blocking for user-writable directories, and put DNS filtering in front of every managed device. That last one costs a few dollars per seat and stops this chain before step one.

Sources: Confiant, BleepingComputer.