SourTrade Builds a Different Malware for Every Victim, In the Browser, Before It Ever Touches Disk
- Patrick Duggan
- 16 minutes ago
- 4 min read
Confiant published research this week on SourTrade, a malvertising operation that has been running since late 2024 against crypto users across Asia-Pacific, Latin America, Africa, Australia, and Great Britain. The lure is ordinary — paid ads pointing at convincing clones of trading and exchange platforms.
The delivery is not ordinary at all.
The technique
The fake trading page does not hand you an executable. It registers a ServiceWorker — the browser component designed to intercept and control network requests, the thing that makes web apps work offline. Then it spins up a SharedWorker and starts feeding it parts.
Not a payload. Parts. A template. A clean, unmodified Bun runtime. An encrypted data blob. Session-specific values generated for you and only you.
Your browser assembles those into a Windows executable in memory. A different one for every victim, every session.
By the time anything hits disk, it is a file that has never existed before and will never exist again. The hash matches nothing, because there is nothing for it to match.
What this actually breaks
The security industry has spent thirty years building on one assumption: malware is a thing. A file with an identity. You find it once, you fingerprint it, you share the fingerprint, and every defender who consumes that fingerprint is now protected against that thing.
Everything downstream inherits that assumption. VirusTotal. Every hash blocklist including ours. The hashes.csv in our own STIX feed. YARA rules written against static byte patterns. EDR file reputation lookups. Threat intel sharing between organizations, which is overwhelmingly the exchange of identifiers for known things.
Per-victim assembly does not evade that model. It exits it. There is no shared identifier to share because no two victims receive the same artifact.
We should be honest that this class is not brand new — polymorphic packers and server-side generation have been around forever. What is new is the venue. The build is happening inside the browser, in memory, using standard web platform APIs that every legitimate progressive web app uses for entirely good reasons. The ServiceWorker doing this is doing exactly what ServiceWorkers were designed to do.
And it means the compilation step happens on the victim's machine, inside the browser sandbox, where most endpoint tooling has poor visibility and where blocking the underlying capability would break a meaningful chunk of the modern web.
Our honest position on our own feed
We publish a malware hash feed. It has real value — most malware still is a thing with an identity, and a defender who blocks known-bad hashes stops a great deal of real attack traffic for free.
But we should say the limit out loud rather than let a customer discover it during an incident: against SourTrade, our hashes.csv is worth nothing. Not degraded. Zero. There is no hash to publish.
That is not a flaw we can patch. It is a property of the technique. The honest response is to be clear about which of our feeds still bite here. Our IP and domain lists do — the ads, the clone sites, and the infrastructure feeding the assembly still live at addresses that can be blocked. Our package deny-list does. The hash list does not.
Any vendor telling you their file reputation engine handles this is selling you something. Ask them what hash they are matching.
What actually detects this
Behavior at the moment of execution. The assembled binary still has to run, and when it runs it does recognizable things — reads browser credential stores, touches wallet directories, beacons out. That is where the detection has to live now, and it is a considerably harder engineering problem than hash matching, which is why hash matching survived so long.
The Bun runtime as a signal. A clean, legitimate, signed Bun binary appearing on a finance user's laptop, dropped by a browser session, is not malware by any static measure. It is also not something that has any business being there. The same logic applies to Node, Deno, and Python runtimes arriving through a browser rather than through your software deployment. That is a hunt worth writing.
ServiceWorker registrations on non-app domains. A trading site clone registering a ServiceWorker and opening a SharedWorker to receive binary chunks is anomalous browser telemetry. Very few organizations collect browser telemetry at that granularity. The ones that do can see this happening live.
Block the road, not the car. The ads are the constant. Malvertising has to buy placement, and the domains it points at are finite and enumerable. Blocking known malvertising and clone-site infrastructure is unglamorous, and against a technique that defeats hash detection entirely, it is the control that still works.
The uncomfortable part
If per-victim in-browser assembly gets packaged into a kit and sold — and it will, because everything gets packaged and sold — then a meaningful fraction of the threat intelligence industry's core product degrades at once. Not to zero. Hashes will keep working against the long tail of unsophisticated malware for years. But the premium tier, the stuff aimed at people with money, moves out of reach of the mechanism.
We are 95 percent confident this technique is commoditized inside eighteen months. The five percent is the possibility that browser vendors tighten ServiceWorker and SharedWorker capabilities enough to make the assembly impractical. That would be the right fix and it would break real applications, which is why we are not counting on it.
Credit for the research to Confiant, who pulled the assembly chain apart and named it.
Our IP, domain, URL, and malicious-package blocklists remain free at analytics.dugganusa.com. We will tell you which ones stop a given technique and which ones do not.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.