A sophisticated malvertising campaign tracked as SourTrade has been weaponizing the victim’s own browser to assemble a malicious Windows executable piece by piece, leveraging a legitimate JavaScript runtime to avoid serving a complete binary across the network. Operating since late 2024, the campaign has targeted retail traders and cryptocurrency investors across 12 countries with ads impersonating services like TradingView, Solana, and Luno.<\/p>\n
According to a detailed analysis published July 23, 2026, by Confiant’s threat intelligence team, the delivery mechanism marks a significant evolution in how malvertising chains can evade traditional detection. Instead of a user downloading a single malicious file from a fixed URL \u2014 which would be easily hash-matched and blocked \u2014 the SourTrade chain has the browser construct the final executable itself from components fetched from multiple sources, ensuring no complete malware binary ever exists in transit.<\/p>\n
The attack begins with an advertisement that, when clicked, directs the user to a landing page impersonating a legitimate service like TradingView or Solana. These pages are equipped with sophisticated fingerprinting: suspected researchers, bots, or automated scanners receive an empty or benign page, while selected human targets are presented with a highly convincing copy of the impersonated service. The first and most immediate defense for potential victims is straightforward software discipline: install trading and wallet software exclusively from the vendor’s own official website, never from an advertisement.<\/p>\n
Confiant’s analysis makes clear the documented chain does not rely on exploiting a browser vulnerability. It also does not remove the Mark of the Web (MotW) flag from the resulting download. The analysis focuses on the delivery of the file within the browser environment, not its execution, and does not definitively establish whether the final download is automatic or requires a user click.<\/p>\n
The landing page begins preparing the assembly infrastructure long before any download button is pressed. It registers a page-scoped ServiceWorker at This SharedWorker then issues a request to a The browser, guided by the instructions from the SharedWorker, retrieves a clean, legitimate copy of the Bun runtime from a second domain \u2014 This is the core of the evasion strategy. The bulk of the binary is a legitimate, signed, and well-known piece of software. No single download looks malicious.<\/p>\n Alongside the runtime, the The worker then performs a crucial obfuscation step. It generates a large, pseudorandom byte stream using AES encryption in counter mode (AES-CTR). It then uses the template from the The result is a unique binary for each victim session. Rotating the seed and size value in each Once assembled into a complete blob in the browser’s memory, the page passes the executable as a readable stream to the ServiceWorker. A hidden iframe then navigates to a same-origin URL controlled by the worker, which responds with the generated bytes and a Confiant’s analysis reveals this is an evolution of a technique observed as recently as April 30, 2026. In those earlier versions, the landing pages loaded an open-source library called StreamSaver.js directly from its author’s GitHub<\/a> Pages address. This meant the recorded initial download path pointed to the library’s GitHub URL, which was an easily traceable artifact. The current iteration keeps the streaming architecture and even retains the The SourTrade campaign is not an isolated incident. It appears to be a more advanced iteration of a malvertising cluster targeting TradingView users that was documented by Bitdefender in September 2025. In that earlier campaign, the final payload was identified as a stealer known as JSCEAL (tracked by Check Point) and WeevilProxy (tracked by WithSecure). These earlier campaigns were linked to credential theft, keylogging, traffic interception, cryptocurrency wallet theft, and remote access capabilities.<\/p>\n However, a critical nuance exists. Confiant identifies shared campaign and executable characteristics between the current SourTrade samples and the earlier TradingView ads, but the report does not demonstrate that the three published samples from the current campaign actually carry the JSCEAL payload. Confiant’s report also references Bitdefender finding a modified Bun executable in that earlier cluster, but The Hacker<\/a> News found no mention of Bun in the specific September 2025 post Confiant links to, which names its loader detection “Variant.DenoSnoop.Marte.1.” The specific capabilities of credential theft, keylogging, and wallet theft associated with the earlier campaign therefore cannot yet be definitively assigned to the files being delivered by the SourTrade chain.<\/p>\n For cybersecurity teams and individuals, the SourTrade campaign underscores a critical point: there is no software patch to apply. The evasion technique is narrower in practical impact than its technical sophistication might suggest. As Confiant’s own implications section notes, the primary value of the per-session builds is to limit the utility of simple, hash-based file detection. The attacker-controlled PE material and the malicious JavaScriptCore bytecode still cross the network, albeit in an encoded form within the \/sw.js<\/code>codecodecodecode. More cunningly, it builds a SharedWorker from JavaScript code already embedded within the page’s own source. This means the worker’s code never appears as a separate network fetch that a security tool could flag, completely blending into the initial page load.<\/p>\n\/config<\/code>codecodecodecode endpoint on the same domain. The response contains a template for the final executable, a URL for a secondary runtime file, and session-specific random values. This is the key to the entire operation.<\/p>\nHow the Browser Assembles the Executable: Bun Runtime as a Base<\/h2>\n
purelogicbox[.]org<\/code>codecodecodecode in the sample analyzed by Confiant<\/a>. Bun is an open-source, legitimate JavaScript runtime built on Apple’s JavaScriptCore engine. It supports compiling applications and bytecode into standalone executables, a feature the attackers have hijacked for malicious purposes.<\/p>\n\/config<\/code>codecodecodecode response includes Base64-encoded blobs that provide the critical components the Bun runtime does not contain: the Portable Executable (PE) header, the PE section table, and a .bun<\/code>codecodecodecode section containing malicious JavaScriptCore bytecode for a file named app.js<\/code>codecodecodecode. This bytecode is the actual payload.<\/p>\n\/config<\/code>codecodecodecode response as a byte-copy recipe. This recipe directs the worker to combine selected ranges from the clean Bun runtime, the generated pseudorandom stream, and the attacker-controlled PE material and malicious bytecode.<\/p>\n\/config<\/code>codecodecodecode response changes the file’s hash while retaining all the malicious executable payload code. As Michael Steele of Confiant noted, “No finished malware ever exists on the network.” While the PE structures and malicious bytecode do cross the network as Base64 in the \/config<\/code>codecodecodecode response, they are combined with a large, per-session random block and a large, legitimate runtime binary to create a new, unique file every time.<\/p>\nFinal Delivery and Mark of the Web<\/h3>\n
Content-Disposition: attachment<\/code>codecodecodecode header. This triggers the browser’s standard download process. Because the file is served from the same origin (the landing page), the MotW record on the downloaded file identifies the landing page itself as the source, not the purelogicbox[.]org<\/code>codecodecodecode domain that supplied the base runtime. The MotW flag itself remains intact on the file.<\/p>\nstreamsaver:<\/code>codecodecodecode message names internally, but it no longer fetches the library from an external source, making the network trail cleaner for the attackers.<\/p>\nHistorical Context and Payload Attribution<\/h2>\n
What This Means for Defenders: Practical Implications<\/h2>\n
\/config<\/code>codecodecodecode request.<\/p>\n