Source the maldumping that the executable weapon in the browser and prevents signature detection

The maldumping operation nicknamed Source represents an interesting and worrying technical variant: instead of serving a complete malicious executable from a fixed URL, it forces the victim's browser to build the final binary on the client's side combining a legitimate runtime (Bun) with attacker-controlled fragments and pseudo-random data. According to the public analysis, the campaign has been active since the end of 2024 and has used convincing suplantations (TradingView, Solana, Luno) to attract retail traders and users of cryptomonedas in multiple countries and languages.

The novelty from a technical point of view is not a browser failure operation, but a standard APIs web orchestration: the landing page records a ServicWorker, creates a embedded SharedWorker and requests an endpoint / config a template and session values. From there, the browser download a "clean" Bun and the executable fragments (PE header, section tables and a .bun section with bytecode) on Base64; the worker generates a byte flow with AES-CTR and reassemble the executable following the template, finally passing the file to the ServiceWorker to be served as a download with a Content-Disposition. The practical result is that there is no "finished malware" passing with a stable hash, which complicates detections based on static signatures.

There are some technical countermeasures and limitations that should be stressed. First, the technique does not remove the Mark of the Web, so Windows will continue to register the home page as a source of the download; this keeps a forensic trail, although it can hide the domain that provided the runtime. Second, the campaign does not need a browser vulnerability: its success depends on the victim downloading or running the binary delivered from the malicious page, and relying on an installer obtained through a supplanted ad.

The implications for defenders and users are clear: The problem is full chain. Blocking or monitoring only the final file - when it does not exist fully on the network - is insufficient. The response and detection equipment must instruct and correlate signals of all the flow: notice reference, fingerprinting behavior on the landing page, ServicWorker / Shareworker registration, requests to / config, fiches to secondary domains that deliver runtimes (e.g. domains that host Bun binary in the incidents examined) and the emergence of large Base64 blobs or streaming patterns of downloads.

In practical terms for users and managers, priority recommendations do not vary from other download-oriented maldumping campaigns: install trading software or wallets only from the supplier's official websites, distrust of ads that promise quick downloads or shortcuts, and prefer digital signatures and official channels. For organizations, it is appropriate to apply download isolation policies (e.g. audited or executed downloads in contenedorized environments or sandboxes), white list policies for installers and EDR / NDLP controls that record executions initiated by "unusual" processes or by files downloaded from external pages.

From the advanced technical layer, there are concrete measures that the defenses can implement: to implement logs to detect records of ServiceWorker / Shareworker and responses to / config, to block the hosting of unauthorized runtimes on the outgoing network, and to create rules that correlate navigation from ads to downloads served via Streams with Content-Disposition headers. It is also useful to generate detection rules that search for massive Base64 fragments in configuration responses or the use of names of streaming library-characteristic messages (such as StreamSaver architecture) that the campaign has used in its previous iterations. These signals are not infallible, but they allow to trace the complete chain that is left on the network even though the final binary varies per session.

There is no browser "patch" for this pattern: effective technical defense combines navigation policies, user education and complete telemetry. The adoption of navigation isolation (browser isolation), group policy download restrictions in corporate environments and the automatic analysis of the artifacts registered by MotW and the ServicWorkers are practical levers. To understand the technical limits of the Web Mark, please see Microsoft documentation on MotW: https: / / learn.microsoft.com / en-us / windows / win32 / windust / mark-of-the-web.

For those who investigate or build detections, it is relevant to know the runtime involved: Bun is a JavaScript / TypeScript environment with ability to compile and pack applications, and its legitimate use explains why attackers use it as a basis for assembling executables in the browser; more technical information about Bun is available on their official website: https: / / bun.sh. Also, the streaming download architecture that used the campaign in previous phases is based on known patterns (StreamSaver), whose public implementation can help identify variations: https: / / github.com / jimmywarting / StreamSaver.js.

Finally, for response equipment: to preserve and correlate artifacts is essential. If network catches and browser records are available, search for requests to / config, the secondary domains that served runtimes, the possible Base64 blobs and the message chain between the page, the SharedWorker and the ServicWorker will allow you to rebuild the sample even if each session produces a different hash. The operational reality is that this technique complicates static indicators, but leaves multiple dynamic and infrastructure tracks that, well instrumented, allow detection and mitigation.