Malvertising has always relied on getting a finished malicious file past the browser and onto a victim’s disk. A malvertising cluster tracked by ad-security firm Confiant, which it calls SourTrade, skips that step entirely: the browser itself builds the Windows executable, piece by piece, in memory, only at the moment a victim clicks download.
How SourTrade Builds Malware Inside the Browser
According to Confiant’s research, SourTrade has run since late 2024, using malicious display ads to funnel retail traders and cryptocurrency investors in 12 countries, including Australia and the UK, toward landing pages that impersonate TradingView, Solana, and Luno. The three brands cover the full lifecycle of a trader’s activity: market analysis, asset investment, and cashing out, which Confiant says is a deliberate targeting strategy rather than a coincidence of impersonation choices.
From Landing Page to ServiceWorker
The mechanics start ordinarily enough. A victim lands on a cloned trading or exchange site and clicks what looks like a software download. From there, Confiant found the page registers a ServiceWorker and spins up a SharedWorker, both legitimate browser features meant for offline apps and cross-tab communication. Instead of fetching a malicious file, the SharedWorker requests a small configuration payload: a random seed, a size value, and a template of byte-copy instructions.
The In-Memory Assembly Pipeline
Using that template, the browser fetches a clean, unmodified Bun JavaScript runtime from a separate domain, generates a pseudorandom byte stream from the session seed, and follows the server’s instructions to combine PE headers, section tables, the legitimate Bun interpreter, and a malicious bytecode payload into a single Windows executable, assembled entirely client-side. The ServiceWorker then serves that assembled file back through a hidden iframe as a same-origin download, so the file’s Mark of the Web metadata points to the trusted-looking landing page domain rather than to whichever server actually holds the malicious pieces.
Why Hash-Based Detection Misses It
The payoff for the operators, per Confiant, is that no two victims receive an identical file. Changing the random seed changes the resulting hash every time, even though the underlying malicious bytecode stays the same, which defeats detection tools that rely on matching known-bad file signatures. Confiant also documented cloaking logic on the landing pages that shows blank content to traffic it suspects belongs to researchers or automated scanners, while serving the full assembled-malware flow only to likely victims. Network logs, in Confiant’s account, show what looks like a legitimate same-origin download; the malicious activity is only visible if the full execution chain, including ServiceWorker and SharedWorker behavior, is examined.
This kind of client-side packaging is part of a broader pattern of malware operators moving evasion logic further from the payload and into delivery infrastructure. CyberTech has previously covered how commodity infostealer operations have added steganography and blockchain-based dead drops to their delivery chains for similar reasons: static, file-based detection increasingly catches only the operators who have not bothered to add a layer of per-victim variance.
An Operation That Keeps Adapting Its Cover Story
Confiant’s timeline shows SourTrade is not a one-off stunt but an infrastructure the operators have iterated on for more than a year. Earlier versions of the campaign, active through April 2026, used a different trick to hide the malware’s true origin: they hosted a copy of the open-source StreamSaver.js library on GitHub and used it to manipulate the downloaded file’s Mark of the Web attribute, again making a malicious file look like it came from a trusted domain. The move to a custom ServiceWorker and in-memory assembly pipeline is, by Confiant’s account, the next iteration of the same goal: keep the file’s apparent origin, and now its very construction, out of any single request a security tool could flag on its own.
Confiant’s writeup also notes the operators are running their advertising spend across multiple platforms in parallel, with Google Ads configuration, Meta pixel calls, and X pixel loading all present on the same landing infrastructure. That is standard ad-tech instrumentation for measuring campaign performance, but it also means SourTrade is not confined to a single ad network’s abuse-detection blind spot; a takedown on one platform does not stop the campaign on the others. Confiant’s report includes three malware file hashes and more than 100 associated domains for defenders who want to check their own telemetry, though given the hash-per-victim design, the domain list is the more durable of the two indicator sets.
What It Means for the Security Leader
SourTrade’s current targets are retail traders rather than enterprises, but the technique does not respect that boundary. Any employee using a personal or work browser to check a crypto wallet, a trading app, or a similar consumer finance tool on a corporate endpoint is a potential entry point, and the underlying method, building an executable from legitimate browser primitives at download time, is reusable against any brand an attacker chooses to clone.
For SOC teams, the practical problem is that SourTrade’s file never exists anywhere to be scanned before the moment a user runs it. That pushes the useful detection point away from file hashes and toward behavior: unusual ServiceWorker registrations, SharedWorker activity paired with a downloaded executable, and same-origin downloads whose Mark of the Web origin does not match any domain the organization’s web filtering has approved.
What Defenders Should Do
Security teams should treat this as a case for browser telemetry, not just endpoint telemetry. Enterprise browser management tools that can flag ServiceWorker registration on untrusted domains, combined with EDR rules that inspect newly created executables regardless of how they arrived on disk, are better matched to this technique than signature updates. Ad-blocking and DNS-layer filtering on known malvertising infrastructure remain useful first lines of defense, and user awareness training should be updated to note that “the download looked like it came from the site I was on” is no longer a reliable signal of legitimacy.
Source: Confiant
