The Dark Side of WebAssembly: Cryptomining, Keyloggers, and Browser Exploitation

Executive Summary

WebAssembly (WASM) is an open binary instruction format — announced in 2015 and broadly supported by browsers from 2017 onward — designed to let code written in C, C++, Rust, and other compiled languages execute at near-native speed inside web browsers. While the technology was created to complement JavaScript (not replace it), and has already been adopted for demanding use cases such as video games, CAD platforms, physics simulations, and blockchain smart contracts, its capacity to run compiled binary code directly in the browser opens a meaningful attack surface that security practitioners cannot ignore.

Threat actors have already weaponized WASM in documented campaigns: in-browser cryptomining operations (Coinhive and Cryptonight), tech-support-scam fraud pages, keyloggers that bypass JavaScript-based detection, and browser-exploitation shellcode loaders are all real-world abuse patterns. This post surveys the dark side of WebAssembly — examining how its binary format, performance characteristics, and evasion properties give concrete advantages to attackers — and concludes with actionable hardening recommendations for security engineers.

What Is WebAssembly?

WebAssembly is an open standard for a compact, portable binary instruction format designed to execute in modern web browsers at near-native speed. Officially announced in 2015, it achieved mainstream browser support in 2017 when Chrome, Firefox, Safari, and Edge all shipped compatible runtimes. Rather than replacing JavaScript, WASM was designed to complement it: the JavaScript engine in the browser is responsible for loading and executing WASM modules, so the two technologies are tightly coupled at the runtime level.

The standard supports a wide range of legitimate use cases. Browser-based game engines, web-hosted CAD and engineering tools, physics simulations, and blockchain smart contracts are among the most prominent deployment contexts. Projects such as WasmBoy (a browser-running Game Boy emulator) and the web port of AutoCAD illustrate just how capable the platform has become. Developers who previously had to ship native binaries can now deliver near-equivalent performance entirely through the browser — without any plug-in installation.

Why WASM Is Attractive to Attackers

As with any powerful new programming primitive, it is only a matter of time before adversaries identify ways to weaponize it. WebAssembly is no exception. Its design properties translate directly into offensive advantages:

• Opaque binary format: Unlike JavaScript, which is delivered as human-readable source text, WASM arrives as a compact binary module. This significantly complicates static analysis by browser-embedded security controls, proxy-based scanners, and external detection tools that rely on pattern matching against readable code.
• Near-native execution speed: Operations that are computationally intensive — cryptocurrency mining, brute-force credential attacks, side-channel timing probes — run substantially faster when compiled to WASM than when implemented in equivalent JavaScript.
• Evasion of JavaScript-oriented signatures: Many browser security extensions and endpoint products base their detection logic on JavaScript heuristics. A malicious operation compiled into a WASM module and loaded dynamically can bypass those signatures entirely, even when the underlying behavior is identical to a known JavaScript payload.

Proof of Concept: Tech-Support Scam via WASM

To illustrate concretely how WebAssembly can be used offensively, consider a proof-of-concept compilation of a tech-support scam payload to WASM. In this attack category, the adversary impersonates a technology company’s support team, confronts the victim with an alarming browser lockout or fake infection notice, and uses intimidation and social engineering to extract payment for fictitious services — or persuades the victim to install a backdoor under the guise of “remote remediation.”

Compiling the attack logic to WASM — rather than leaving it in plain JavaScript — provides meaningful obfuscation: antivirus engines and browser security extensions are significantly less likely to recognize malicious intent hidden inside a binary module. The sophistication already achieved by real-world campaigns was documented by security researcher Sergio de los Santos on Twitter.

Tech Support Scam Case Study

When a victim reaches a page hosting a WASM-based tech-support scam, the compiled module takes over the browser: it triggers audio alerts, displays fake infection counters, and surfaces a support phone number. If the victim calls, the fraudster either demands payment or requests remote access to install a backdoor. The WASM wrapper ensures that static analysis of the page’s JavaScript gives few clues about the actual payload, buying the campaign additional operational time before detection and takedown.

Cryptomining: The First Large-Scale Wave

The best-documented weaponization of WebAssembly in the wild involves in-browser cryptocurrency mining. Two campaigns in particular became widely known:

• Coinhive: A JavaScript/WASM cryptomining library that was embedded in thousands of compromised or cooperating websites. Visitors’ browsers silently mined Monero on behalf of the attacker — consuming CPU resources without consent — while the page remained fully functional. At its peak, Coinhive was the most widely deployed web-based mining payload in existence.
• Cryptonight: A closely related campaign leveraging the same WASM-powered technique to achieve cryptocurrency mining throughput approaching that of dedicated mining software, exploiting the performance advantage WASM holds over equivalent JavaScript.

Both attacks exploited the absence of adequate browser controls for dynamic WASM execution. A user visiting an infected page without browser hardening in place would unknowingly contribute CPU cycles to the attacker’s mining operation for the entire duration of their visit.

Additional Attack Vectors

Beyond cryptomining and social-engineering fraud, researchers and threat analysts have identified several other ways that WebAssembly enables or amplifies offensive techniques:

Malicious URL Redirection

Campaigns have deployed WASM-based redirect logic on compromised sites that silently forwards visitors to malicious destinations: tech-support scam landing pages, additional cryptomining operations, phishing portals, or malware-delivery endpoints. Because the redirection is implemented in a binary WASM module rather than readable JavaScript, inspection of the page’s HTML and script content may reveal nothing obviously malicious to an analyst or automated scanner.

Keyloggers

WebAssembly can be used to implement keystroke-capture logic that evades both browser-native controls and external monitoring tools. A keylogger compiled to WASM and loaded by a compromised page can silently harvest passwords, credit card numbers, and other sensitive input entered by visitors — while remaining invisible to the JavaScript-based detection heuristics that would typically flag such behavior. Research has demonstrated that WASM-generated code can successfully evade standard browser and endpoint controls that rely on JavaScript pattern matching.

Browser Exploitation

Browser exploitation almost always involves JavaScript at some layer of the attack chain. WASM can play a significant role by acting as an obfuscation wrapper around exploit code: shellcode, heap-spray primitives, or JIT-spray gadgets can be embedded in a binary module that resists static analysis and interacts with the browser’s memory management in ways that differ materially from equivalent JavaScript. As browser vendors harden their JavaScript engines against exploitation, WASM provides adversaries with a parallel attack surface that is considerably less mature from a defensive standpoint.

Key Takeaways

• WebAssembly is a legitimate and powerful open standard; its binary format is not inherently malicious, but it gives attackers a built-in obfuscation layer that defeats JavaScript-focused detection controls.
• In-browser cryptomining (Coinhive, Cryptonight) was the first major documented wave of WASM weaponization and demonstrated the real-world scalability of the threat model.
• Tech-support scam pages, keyloggers, malicious URL redirectors, and browser-exploit loaders are all confirmed WASM-based attack categories.
• The binary format, near-native performance, and evasion properties of WASM collectively reduce the effectiveness of signature-based and heuristic JavaScript security controls.
• Users without browser hardening are exposed when visiting any compromised website, regardless of that site’s prior reputation.
• The attack surface will grow as WASM adoption expands — both legitimate first-party WASM on mainstream sites and attacker-controlled WASM embedded in compromised pages.
• Existing defensive tooling (NoScript, AMSIext) provides meaningful protection today, but uptake remains low among general end users.

Defensive Recommendations

• Enforce execution whitelisting via Content Security Policy: Use a CSP header that restricts which origins may serve WASM modules. A policy such as script-src 'self' blocks WASM loaded from third-party CDNs or compromised dependencies before they execute.
• Deploy NoScript or equivalent: Browser extensions that enforce per-site JavaScript and WASM execution policies prevent unauthorized module loads. This is especially valuable on high-risk browsing endpoints and analyst workstations.
• Integrate AMSI on Windows endpoints via AMSIext: Deploy a browser-AMSI bridge to route in-browser script and WASM execution through the Windows Antimalware Scan Interface for real-time behavioral scanning, catching payloads that bypass static JavaScript signatures.
• Alert on anomalous CPU usage in browser processes: Sustained high CPU consumption in browser processes is a reliable indicator of in-browser cryptomining. Endpoint monitoring rules targeting this pattern provide a low-false-positive detection layer.
• Scan .wasm traffic at the proxy layer: Configure web proxies or WAF rules to log or block delivery of .wasm files from uncategorized or unexpected origins. Legitimate enterprise web applications rarely load WASM from unknown third-party hosts.
• Enforce rapid browser patching: WASM-related CVEs appear regularly in browser security advisories. Establish a patch SLA of 48–72 hours for critical browser updates across your fleet.
• Verify WASM supply-chain integrity via SRI: If your own applications load WASM modules from CDNs, enforce Subresource Integrity (SRI) hashes so that a compromised CDN cannot substitute a malicious binary without triggering a browser-level block.

Conclusion

WebAssembly has earned its place in the modern web platform: it unlocks performance-critical applications previously impossible to deliver in the browser, and its adoption is accelerating across the industry. The same properties that make it attractive to developers — compact binary format, near-native speed, broad browser support, and seamless JavaScript interop — also make it a valuable primitive for attackers. Cryptomining, keylogging, social-engineering fraud, and browser exploitation are all documented abuse patterns, and the threat surface will expand as WASM continues to mature. The practical defense is not to abandon the technology but to harden the environments where it executes: updated browsers, execution-policy enforcement, AMSI integration, and CPU anomaly monitoring are the controls security teams should have in place today.

Original text: “El lado oscuro de WebAssembly” by Carlos Ávila at Telefónica Tech Blog.