SourTrade Makes Browsers Assemble a Different Malware File for Each Victim
A ServiceWorker and SharedWorker combine a clean Bun runtime, delivered PE sections, and locally generated bytes before a same-origin download.

Confiant documented a SourTrade delivery chain that makes a victim’s browser assemble a Windows executable from separate inputs. The landing page combines a clean Bun runtime, actor-supplied executable sections, and locally generated bytes, then presents the result as a same-origin download. Each session can produce a different file hash.
The researchers say SourTrade has run malvertising since late 2024, impersonating TradingView, Solana, and Luno across 12 countries and 25 languages. Its target is the retail trader or cryptocurrency user who follows an ad to a replica site and chooses to download software. The page also fingerprints visitors so analysts and automated scanners can receive a blank page while selected visitors see the lure.
The download begins as assembly instructions
SourTrade does not send one finished executable from one URL. Before the visitor clicks download, the landing page’s React code registers sw.js as a ServiceWorker and creates a SharedWorker from JavaScript embedded in the page.
The ServiceWorker keeps an in-memory map of download streams. It accepts open, abort, and keep-alive messages and can answer a same-origin fetch with a streamed attachment. The SharedWorker performs the file construction. It requests /config from the landing page with victim fingerprinting data attached.
Confiant found that /config returns a byte-copy recipe rather than a conventional file. Its response includes a template, a URL for a standalone Bun runtime, and random seed and size values specific to the session. Those elements determine which bytes the browser retrieves, generates, and writes into the output.
A clean runtime becomes the carrier
The SharedWorker fetches the clean Bun runtime from the supplied standaloneUrl. It also decodes Base64 blobs delivered in /config. Those blobs provide the Windows PE header and section table, plus a .bun section containing malicious JavaScriptCore bytecode for app.js.
A local AES-CTR operation creates a pseudorandom byte stream from the server-provided seed and size. The template then copies selected ranges from the Bun runtime, the delivered blobs, and the generated stream in a defined order. Confiant says rotating the seed and size changes the completed executable’s hash between sessions.

Figure details
The SourTrade landing page registers a ServiceWorker and starts an embedded SharedWorker. The SharedWorker requests a session-specific config response containing a template, a standalone Bun runtime URL, random seed and size values, and Base64 executable sections. It fetches the clean Bun runtime, generates an AES-CTR byte stream locally, and follows the template to combine those sources with the PE header, section table, and malicious .bun section. The completed stream returns to the ServiceWorker, which serves it through a same-origin attachment URL. The user must still download and execute the file for the assembled bytecode to run.
When launched, the Bun interpreter executes the bytecode stored in the .bun section. Confiant did not identify the payload family in the samples covered by its July report. The report establishes the delivery mechanism and published infrastructure and file indicators. It does not establish how many people executed the assembled file or what happened on each endpoint afterward.
The final download preserves an incomplete origin story
After assembly, the page gives the completed stream to the ServiceWorker and opens a hidden iframe at a derived same-origin URL. The ServiceWorker answers that request with the streamed executable as an attachment. Browser and network records can therefore show a download from the landing-page domain even though another domain supplied the Bun runtime and /config supplied actor-controlled sections.
The file still receives Mark of the Web. Microsoft explains that Windows stores the Internet-zone origin in the Zone.Identifier alternate data stream for browser downloads. In this chain, Confiant found that the recorded source is the same-origin landing-page URL. That artifact is useful, but it does not identify every component used to build the file.
The distinction matters during triage. A clean Bun download in proxy history is one input, not the final output. One hash from an affected endpoint may not match another session. A blank response from a known landing page may reflect the campaign’s cloaking checks rather than an inactive domain.
Defenders should preserve the browser-to-file chain
For an endpoint that reached a suspected SourTrade page, preserve browser history, ServiceWorker registrations and storage, cached page scripts, the /config response when available, DNS and proxy records, the downloaded executable, and its Zone.Identifier stream before cleanup. Correlate the landing-page visit with requests to the runtime host and the creation and execution time of the resulting file. Confiant’s published domains and hashes can seed the search, but session-specific output means a missed hash is not an incident-closing result.
Block software downloads from sponsored results and lookalike domains. For TradingView users, enforce the vendor’s official-download guidance: its desktop and mobile applications come from TradingView’s site or official app stores. Verify the requested publisher and download origin through application control or software-distribution records before allowing execution.
If the assembled executable ran, isolate the endpoint and scope subsequent process, persistence, credential, and network activity using retained endpoint telemetry. Confiant did not identify the payload in the samples covered by this report, so the published delivery indicators cannot define the full post-execution search.
Close a non-execution event only when browser and endpoint records show the lure was reached but no assembled executable was saved or run. Close an execution event only after the built file and its process tree are accounted for, follow-on activity is absent or remediated, and the affected endpoint has been restored to a trusted state. Missing browser storage, proxy history, or endpoint process telemetry leaves the chain unresolved.