The Attack: Malware Assembly Inside the Browser
The SourTrade malvertising campaign, documented by Confiant in July 2026, represents a new level of effort in evading signature-based detection. Instead of serving a complete malicious executable from a fixed URL, the attack has the victim’s browser build the payload itself.
The landing page registers a ServiceWorker and a SharedWorker, then requests a configuration file containing PE headers, section tables, and malicious JavaScriptCore bytecode as Base64 blobs. The browser fetches a clean Bun runtime from a separate domain, generates a pseudorandom byte stream using AES-CTR, and follows a byte-copy recipe to assemble a working Windows executable. Each victim receives a different hash because the configuration rotates the seed and padding on every request.
The assembled file is passed to the ServiceWorker as a readable stream, and an iframe navigation triggers the download with a Content-Disposition header. The executable lands on disk with Mark of the Web intact, but the MotW points to the landing page, not the domain that supplied the Bun runtime.
Confiant’s analysis stops at the moment the file reaches disk. The article notes there is no software patch to apply and recommends defenders examine the entire attack chain rather than relying on hash-based artifact detection.
Why Hash-Based Detection Fails Here
The whole point of this technique is to make every downloaded file unique. Traditional endpoint security that depends on recognizing known-bad file hashes is worthless — the hash changes with every victim. Signature-based detection that looks for specific byte patterns inside the executable is harder to evade but still requires the vendor to obtain a sample, analyze it, create a signature, and push an update before your system is protected.
During that window — hours, days, or longer if the campaign is targeted — you’re unprotected. And by the time the signature arrives, the attacker has probably rotated to a new Bun version or a different runtime entirely.
The article correctly identifies that the attacker-controlled PE material and bytecode still cross the network, so network-layer inspection could theoretically catch it. But that requires deep packet inspection, TLS interception, and behavioral analysis of JavaScript execution inside the browser — a lot of infrastructure and a lot of places where the detection can fail or be evaded.
How FileSure Blocks It
FileSure Defend operates at the Windows kernel file system layer and controls which programs can perform which file operations. One of the default rules in the product blocks browser processes from writing executable files to local drives.
The rule is simple:
- File name filter:
*.exe;*.dll;*.bat;*.cmd;*.ps1 - Program name filter:
\chrome.exe;\firefox.exe;\msedge.exe;\iexplore.exe - Operations: Write, Create
- Drive type: Hard drives, Workstations
- Result: Browser processes cannot write executable files. The write operation is intercepted at the kernel level and blocked before it completes.
When the SourTrade ServiceWorker attempts to write the assembled executable to disk, the kernel filter driver intercepts the write request, checks the rule, sees that the requesting process is a browser and the target file has an .exe extension, and denies the operation. The attack fails before the payload ever lands on disk.
It doesn’t matter that the executable was assembled from pieces. It doesn’t matter that the hash is unique. It doesn’t matter that no signature exists yet. The browser tried to write an .exe file, and that operation is not permitted.
No execution, no encryption, no data theft — because the malware never made it past the file system gate.
The Upstream Intervention Principle
The best place to stop an attack is as early in the chain as possible. SourTrade goes to great lengths to evade detection during delivery, but it still has to write a Windows executable to disk before that executable can run. That write operation is the choke point.
Blocking the write is more durable than trying to recognize the payload. It works on this campaign, and it works on the next one that uses a different runtime or a different assembly technique. As long as the attack involves a browser writing an executable file to a Windows system, the same rule applies.
FileSure doesn’t try to outsmart the attacker’s evasion techniques. It just enforces a simple constraint: normal people don’t need their browser to write executable files to disk. If that operation happens, it’s almost certainly malicious — so block it.
Start a free trial at bystorm.com and see how kernel-level file operation control stops threats that signature-based tools miss.
Source: Malvertising Sends Malware in Pieces, Then Makes the Browser Build the Executable
Category: Threat Intelligence
Tags: malvertising, sourtrade, browser security, kernel filter driver, file system security, zero-day defense, executable write blocking
