SURIQ
Most malware detection still rests on one assumption: at some point the malicious file travels across the network, where a proxy, a sandbox, or an endpoint agent can catch it and match it against something known. A malvertising operation that the ad-security firm Confiant named SourTrade breaks that assumption on purpose. It ships no finished executable at all. The victim's own browser assembles the Windows binary in memory, from parts that look harmless on their own, and every visitor ends up with a slightly different file. There is nothing on the wire to scan.
Confiant published its analysis on July 23, 2026, and traced the operation back to late 2024. It runs through fake TradingView, Solana, and Luno pages served in 25 languages across 12 countries, aimed at retail traders and cryptocurrency holders. The Hacker News counted 96 malicious domains in the published indicators. This is the same family of trick behind ransomware that runs inside a browser tab: the browser is the execution surface precisely because that is where on-host and network tools have the least visibility.
How the browser builds the malware for the attacker
A malicious ad drops the target onto a cloaked landing page, tuned to screen out scanners, researchers, and automated crawlers so that only a genuine victim ever reaches the payload. Nothing waits for the user to click download. As the page loads it quietly installs a page-scoped worker (the script is served from /sw.js) and starts a second, shared background worker from code that already shipped inside the page. That shared worker asks the server for a /config reply, which is not the program at all but the blueprint for it: a template plus the raw material the browser needs to build the file on its own.
With the blueprint in hand, the browser fetches and unpacks a clean, legitimate copy of the Bun runtime hosted on a different domain (purelogicbox[.]org in Confiant's sample). Encoded data from the config fills in the rest of a Windows Portable Executable: the file header, the section table, and a .bun section carrying the hostile bytecode. The shared worker then spins up a long pseudorandom stream with AES in counter mode and treats the template as a cut-and-paste map, stitching byte ranges from the runtime, that random stream, and the attacker's code into one finished binary. To the user it looks like an ordinary download from the site they were on, mark-of-the-web tag and all.
Run it, and you have a stealer on the machine. Confiant flagged similarities to a family Check Point calls JSCEAL and WithSecure calls WeevilProxy, without committing to a firm link. That family grabs stored credentials, logs keystrokes, plants itself as a local proxy to sit in the middle of the machine's network traffic, empties cryptocurrency wallets, and opens a remote channel back to the operator. It sits in the same category as the session-stealing malware we covered in ACR Stealer, where the way in is a convincing lure rather than an exploit.
This did not arrive fully formed. Confiant and BleepingComputer both trace an April 2026 version that used the StreamSaver library to stitch the download together in the browser; the ServiceWorker method is the same idea, refined and made harder to inspect. Read the two versions side by side and the direction is obvious. The assembly step keeps moving further inside the browser, away from anything a network defender can put eyes on. That trajectory, not this one campaign, is the thing to plan detections around.
Why your hash blocklist is now documentation, not defense
Confiant published three SHA-256 hashes with its report. Collect them, but do not expect them to block the next victim. Because the values that seed each build shift from one session to the next, the hash of the assembled file comes out different for every visitor even though the working code underneath stays the same. A hash that only ever existed on one person's disk is not something you can push to a blocklist and catch anyone else with.
That inverts the usual value of an indicator dump. Here the durable indicators are the domains and the delivery chain; the file hashes are close to disposable. Feed the 96 domains into your DNS and web filtering, treat freshly registered look-alike domains for trading and wallet brands as suspect, and file the hashes as forensic record rather than a preventive control. The same lesson runs through shared ClickFix delivery infrastructure: the lure and the plumbing are the stable thing to detect, not the final artifact.
Where the detection signal actually lives now
If the file is polymorphic and the network sees only benign-looking parts, detection has to move to where the assembly finishes, which is the endpoint and the browser. Two signals survive this technique.
First, the artifact. The final binary is a Bun-compiled executable. Bun is a real developer runtime, but a Bun-compiled program landing on a finance clerk's workstation is an anomaly on most corporate Windows fleets, and process telemetry can flag it whatever its hash happens to be. Because most of the finished file is a genuine, well-known runtime with a small malicious bytecode section riding inside it, static "is this file known-bad" checks and simple reputation scoring are working against the grain by design.
Second, the act of building it. A browser tab that registers a ServiceWorker and then writes an executable to disk through a worker-driven blob is a behavior, and behavior does not rotate with the seed. Endpoint tooling that watches what a process does, rather than what a file is, is what catches this. That is exactly why Confiant tells defenders to judge the sequence as a whole, the ad that referred the user, the cloaked page, the /config call, the runtime pulled from a second host, and the worker-driven download, rather than betting the verdict on any one of those pieces. Managed detection that maps that sequence of endpoint behavior to attacker technique, rather than matching files, is built for this shape of threat.
What to do about it this week
Three moves, in order of payoff:
-
Block at the door. Push Confiant's 96 domains into DNS and web filtering now, and flag newly registered look-alike domains for trading and crypto brands. The domains are the stable indicator, so this is the highest-value control.
-
Watch the endpoint for the assembly, not the file. Alert on browsers spawning or writing Bun-compiled executables, on unexpected ServiceWorker-driven downloads, and on the stealer's post-run behavior: a local proxy appearing, plus access to credential stores and wallet files.
-
Cut off the lure. Most victims arrive through a search ad or sponsored result, not the vendor's real site. A policy of installing trading and crypto software only from official vendor domains, with a signature-and-publisher check before running any such installer, removes the entry point outright.
SourTrade is not a vulnerability you can patch, because it exploits nothing. It abuses features every modern browser ships on purpose, plus a legitimate compiler that any developer can install. That makes it a preview of where commodity malware delivery is going: less reliance on a bad file crossing the network, more on the victim's own machine doing the assembly. This is the same shift we flagged in fake proof-of-concept lures, where the delivery, not the exploit, is the whole attack. Defenders who still treat "we caught the file" as "we caught the attack" will keep missing it.