WebAssembly Is Abused by eCriminals to Hide Malware

October 25, 2021

CrowdStrike research finds that 75% of the WebAssembly modules are malicious
WebAssembly is an open standard that allows browsers to execute compiled programs
Cryptocurrency miners boost efficiency by abusing WebAssembly to achieve near-native execution performance
eCriminals turn to WebAssembly to hide web-based malware

CrowdStrike researchers analyzed 12,291 unique WebAssembly (Wasm) samples from May 2018 to June 2021 and found that 75% of Wasm modules are malicious. WebAssembly is an open standard that allows browsers to execute resource-intensive compiled programs, such as games or image manipulation apps, directly in the browser with greater ease and performance.

Analysis revealed that malicious Wasm modules are used for two threat-related activities: mining cryptocurrency and hiding malicious scripts. Some cryptocurrency miners abuse Wasm to achieve near-native execution performance on the targeted machine, potentially enabling more efficient abuse of CPU computing power. Threat actors also use Wasm for obfuscation purposes. How? By tampering with specific WebAssembly sections to embed malicious JavaScript or JScript code and trick browsers into executing it.

Since eCrime activities dominate the threat landscape, according to the recently published CrowdStrike Falcon® OverWatch 2021 Threat Hunting Report, abusing Wasm modules for building more efficient cryptocurrency miners falls in line with threat actors’ financial motivation.

What Is WebAssembly?

WebAssembly started as asm.js, a subset of JavaScript enabling developers to write C and other CPU-intensive applications for web browsers. Users would need only browsers to perform a wide range of activities. W3C saw the potential in this use case and started working on the next masterpiece of an open standard, which became WebAssembly.

One of the defining characteristics of WebAssembly is that it was built for speed and performance, especially when compared to JavaScript. It enables browsers to execute CPU-intensive tasks faster and more efficiently without freezing up, something JavaScript could never achieve.

WebAssembly has a binary format made to run in the browser’s Virtual Machine (VM) and a text format that is its assembly representation.

Previous attempts to achieve this failed — one of the most popular and worst examples is Adobe’s Flash platform. It’s highly likely that WebAssembly also has many vulnerabilities, but being relatively new, it’s difficult to compare the two technologies head-to-head.

A WebAssembly Format Primer

WebAssembly is structured in modules that can be distributed, instantiated and executed individually. What follows is the basic high-level structure of a module.

Preamble

Each module has the following preamble:

magic = 0x00 0x61 0x73 0x6D (4-byte magic number, the string '\0asm')
version = 0x01 0x00 0x00 0x00 (The current version of the binary format)

Encoding

Apart from the preamble, integer types in the Wasm format, either Signed and Unsigned, use the Leb128 encoding, which shows the hard work put into by W3C to make sure the format is as compact as possible. There are other primitive types encoded differently, but we only need to mention integers for the purpose of this blog post. To see the rest of the encodings, please see the specification.

Sections

The preamble is followed by a sequence of sections, and each section has the following structure:

id: u8 (A one byte section id)
size: u32 (Size of the contents, in bytes)
contents: [size] (The actual content whose structure depends on the section id)

Every section is optional, but an omitted section is equivalent to having a section present with empty contents.

The following section ids are recognized:

Id	Section
0	custom section
1	type section
2	import section
3	function section
4	table section
5	memory section
6	global section
7	export section
8	start section
9	element section
10	code section
11	data section
12	data count section

The above is a high-level overview of the Wasm format. Each section is then parsed for contents to know what, where and how something should be loaded and executed.

WebAssembly’s Popular Hat Trick

Like any well-established programming language, WebAssembly speaks a lot of “dialects.” One of those dialects is hashing and the ability to use cryptographic functions.

We can look at WebAssembly as a “frequent flier.” Although it uses the cheap, economy-class web browser, it is actually traveling first class because it can reach anyone, anytime, as long as there’s an internet connection. Wasm even has a membership to all of the major “airlines”: Firefox, Chrome, Safari and even Edge.

Combining the two capabilities — compatibility with major browsers and an internet connection as a minimum necessary requirement — provides the perfect mix for “clandestine” cryptocurrency mining operations.

However, Wasm takes cryptomining to an entirely new level, especially when backed publicly by open source repositories on GitHub, such as CryptoNight and Monero.

A previous study analyzed how cryptocurrency mining is achieved in the wild using WebAssembly and revealed that eCrime operators have been abusing Wasm since at least 2019 for financial gain. The study also looked into the distribution of execution time spent by WebAssembly miners compared to other usages, as seen below.

Figure 1. CPU time spent by WebAssembly miners vs. other uses of WebAssembly (Source: Technische Universität Braunschweig)

CrowdStrike’s Findings

Since WebAssembly has been gaining in popularity for the past two years, as more websites embed resource-intensive apps such as games or image and audio manipulation apps, CrowdStrike researchers started diving deeper into how eCrime adversaries might be abusing Wasm and for what purposes, apart from financial motivation. They collected and analyzed 12,291 unique WebAssembly samples from May 2018 to June 2021.

Crypto Mining Efficacy
Some of the analyzed Wasm samples were identified as cryptocurrency miners. For example, two samples:

09c72015592622dd874c544dec7ed8ea21b4ff2ea30716dc670645d71ac42b5a and e1aa80619c71857310574e4de6ba583a1dc7ed51f3dafca3cfca0d4c49af6f81

contain artifacts of the Cryptonight mining algorithm, while further research showed that they are genuine mining modules.

A Clever Hide-and-Seek Trick

Of the 12,291 unique files collected and analyzed, 9,308 were malicious — more than 75% of the entire corpus.

The majority of the malicious files use a relatively efficient trick to hide malicious scripts, embedding JavaScript or JScript code in the Data section of the WebAssembly module. This behavior could indicate a new trend that WebAssembly malware could be heading toward. Wasm acts as an enclosing capsule for the already-known JavaScript and JScript malware present in the wild.

Below, we have the disassembled WebAssembly (“text version,” it’s called) of two malicious samples:

0033aae4043665c6210eb7d143733238da67060655969b18e449f7be4fd6f743 and 006cd8d1d784f26ad8ee209a0a995d73d4f9c9b15185a499f180ae196c7091b3

that use this tactic.

Each file starts with the keyword module, and after that, each line starts with a keyword corresponding to the WebAssembly sections mentioned above.

What is interesting is the data section located at code line 9 on both samples. The first sample contains an html document inside the section, which embeds a malicious JScript. The second sample also contains a malicious JavaScript inside its data section.

Hash: 0033aae4043665c6210eb7d143733238da67060655969b18e449f7be4fd6f743

At run time, the sample above drops the respective script or document, which is then executed by the browser. This method abuses the intended functionality of browsers that execute them and is a practical and efficient tactic for threat actors to hide malicious scripts within Wasm.

This method can be seen as a new type of obfuscation or even packing on top of the already-existing obfuscated malware state, adding another evasion tactic to the pool of techniques that adversaries can use.

Hash: 006cd8d1d784f26ad8ee209a0a995d73d4f9c9b15185a499f180ae196c7091b3

Final Thoughts

Malicious WebAssembly modules are not new, but their increase in popularity suggests that adversaries can abuse Wasm versatility and efficiency to hide additional malicious scripts for financial and obfuscation purposes. Previous research discovered 150 unique WebAssembly modules by crawling the top 1 million sites, and now we’ve found that of over 12,000 unique WebAssembly samples gathered, more than 75% contained an embedded malicious behavior.

The increased adoption of WebAssembly over the past couple of years suggests we can expect adversaries and eCrime groups to continue abusing this browser’s built-in standard for their illicit gains.

Bibliography

Addition Resources

Learn more about the CrowdStrike Falcon® platform by visiting the product webpage.
Test CrowdStrike® next-gen AV for yourself. Start your free trial of Falcon Prevent™ today.