>samit_hota
Back to security news
SN-2026-191HighOpen

Malvertising Campaign Assembles Malware in Browser Memory via JavaScript

Samit Hota·
CVE ID
N/A
Affected Products / Orgs
Web browsers, Solana users, Luno users, TradingView users
#news#malware#javascript

In a newly identified malvertising campaign targeting users of cryptocurrency and trading platforms, malicious websites are using JavaScript to assemble malware payloads directly in browser memory. By spoofing popular financial services like Solana, Luno, and TradingView, attackers lure visitors via malicious ads and execute obfuscated scripts that reconstruct binary files on the fly. This technique—often categorized as HTML smuggling—bypasses network-level file inspection filters because the executable payload is generated client-side from benign-looking data fragments rather than downloaded as an outright binary file over the network.

Mechanics of In-Memory JavaScript Payload Assembly

HTML smuggling relies on standard web technologies, such as HTML5 download attributes and JavaScript Blob objects, to construct binary files inside the victim’s local browser context. When a user visits one of the spoofed landing pages, an embedded script decodes base64-encoded strings or retrieves array buffers hosted across distributed web nodes. The script joins these fragments into a byte array, creates a Blob URL, and automatically triggers a file download or execution prompt through the browser. Because the network traffic consists only of ordinary HTTP/HTTPS GET requests returning plain text, JSON, or JavaScript source code, traditional Secure Web Gateways (SWG) and perimeter intrusion detection systems fail to detect an executable payload in transit.

Once the payload is assembled in browser memory, the script prompts the user to run a fake installer or updates, or in some browser configurations, leverages helper applications to execute the dropped binary.

Defensive Strategies and Prevention

Mitigating client-side payload assembly requires endpoint-focused defenses and strict browser security controls:

  • EDR Process Hierarchy Rules: Configure Endpoint Detection and Response (EDR) agents to detect and alert on web browser processes (chrome.exe, msedge.exe, firefox.exe) spawning execution interpreters such as cmd.exe, powershell.exe, or unverified binaries directly from AppData\Local\Temp or browser download directories.
  • Content Security Policy (CSP): Website administrators should implement strict CSP rules disabling unsafe-eval and limiting script execution to trusted, cryptographic nonce-verified domains.
  • Malvertising Ad-Blocking: Enforce DNS-level filtering or centralized browser ad-blocking extensions across enterprise endpoints to block traffic to known ad-tech redirectors and newly registered malicious domains.

Found something similar in your stack?

Let's find out before it becomes an incident.

Book an advisory call