2212.08427

## WebAssembly Diversification for Malware Evasion Javier Cabrera-Arteaga a , < , Martin Monperrus a , Tim Toady, a and Benoit Baudry a a KTH Royal Institute of Technology, Stockholm, Sweden ## ARTICLE INFO Keywords : WebAssembly, cryptojacking, software diversification, malware evasion. ## 1. Introduction ## ABSTRACT WebAssembly has become a crucial part of the modern web, offering a faster alternative to JavaScript in browsers. While boosting rich applications in browser, this technology is also very efficient to develop cryptojacking malware. This has triggered the development of several methods to detect cryptojacking malware. However, these defenses have not considered the possibility of attackers using evasion techniques. This paper explores how automatic binary diversification can support the evasion of WebAssembly cryptojacking detectors. We experiment with a dataset of 33 WebAssembly cryptojacking binaries and evaluate our evasion technique against two malware detectors: VirusTotal, a general-purpose detector, and MINOS, a WebAssembly-specific detector. Our results demonstrate that our technique can automatically generate variants of WebAssembly cryptojacking that evade the detectors in 90% of cases for VirusTotal and 100% for MINOS. Our results emphasize the importance of meta-antiviruses and diverse detection techniques and provide new insights into which WebAssembly code transformations are best suited for malware evasion. We also show that the variants introduce limited performance overhead, making binary diversification an effective technique for evasion. WebAssembly is a binary format that has become an essential component of the web. It first appeared in 2017 as a fast and safe complement for JavaScript [20]. The language provides low-level constructs enabling efficient execution, much closer to native code than JavaScript. Since its inception, the adoption of WebAssembly has grown exponentially, even outside the web [11]. Its early adoption by malicious actors is further evidence of WebAssembly's success. 5, 26, 48]. Yet, it is known that black-hats can use evasion techniques to bypass detection. Only the previous work of Bhansali et al. [4] investigates the possibility of WebAssembly cryptojacking to evade detection techniques. This is a crucial motivation for our work, one of the first to study WebAssembly malware evasion. The primary black-hat usage of WebAssembly is cryptojacking [46]. Such WebAssembly code mines cryptocurrencies on users' browsers for the benefit of malicious actors and without the consent of the users [41]. The main reason for this phenomenon is that the core foundation of cryptojacking is: the faster, the better. In this context, WebAssembly, a binary instruction format designed to be portable and fast, is a feasible technology for implementing and distributing cryptojacking over the web. A Kaspersky report about the state of cryptojacking in the first three quarters of 2022 confirms the steady growth in the usage of cryptominers [24]. The report shows that Monero [36] is the most used cryptocurrency for cryptomining in the browser. Attackers might hide WebAssembly cryptominers [50] in multiple locations inside web applications. Our work is different from Bhansali et al.'s [4] in the following aspects. First, we extend the evaluation of MINOS by using VirusTotal and, we empirically demonstrate that this latter is a valid cryptojacking malware meta-detector for WebAssembly to be used as baseline (see section 5). Second, we conduct an evaluation of the correctness and efficiency of the Wasm variants, which provides insights into the trade-offs and limitations of bytecode-level transformations for malware evasion in WebAssembly. Our approach, performs bytecode transformations at the WebAssembly level, instead of source code based transformations like the Bhansali's technique. We focus on software diversification techniques in the spirit of Cohen [15], as this technique has the ability to generate many variants, while the impact on the binary size and performance can be controlled through the selection of specific diversification transformations [35]. Antivirus and browsers provide support for detecting cryptojacking. For example, the Firefox browser supports the detection of cryptomining by using deny lists [38]. The academic community also provides related work on detecting or preventing WebAssembly cryptojacking [52, 42, 25, < Corresponding authors <details> <summary>Image 1 Details</summary>  ### Visual Description Icon/Small Image (20x18) </details> 0000-0003-3505-3383 (M. Monperrus); 0000-0002-0209-2805 (T. Toady,); 0000-0002-4015-4640 (B. Baudry) javierca@kth.se (J. Cabrera-Arteaga); monperrus@kth.se (M. Monperrus); toady@eecs.kth.se (T. Toady,); baudry@kth.se (B. Baudry) ORCID(s): 0000-0001-9399-8647 (J. Cabrera-Arteaga); In this paper, we design, implement and evaluate a fullfledged evasion pipeline for WebAssembly. Concretely, we use wasm-mutate as a diversifier [10], which implements 135 possible bytecode transformations, grouped into three categories: peephole operator, module structure, and control flow. We demonstrate the effectiveness of our evasion technique against two cryptojacking detectors: VirusTotal, a general detection tool that comprises 60 antiviruses and, MINOS [42], a WebAssembly-specific detector. Weevaluate our proposed evasion technique on 33 cryptojacking malware that we curated from the 8643 binaries of the wasmbench dataset [22], to our knowledge, the most exhaustive collection of real-world WebAssembly binaries. We experiment with the 33 binaries marked as potentially dangerous by at least one antivirus vendor of VirusTotal. We empirically demonstrate that evasion is possible for all of these 33 real-world WebAssembly cryptojacking malware while using a WebAssembly-specific detector. Remarkably, we find 30 cryptominers for which our technique successfully generates variants that evade VirusTotal. Our set of malware includes 6 cryptojacking programs that are fully reproducible in a controlled environment. With them, we assess that our evasion method does not affect malware correctness and generates fully functional malware variants with minimal overhead. Our work provides evidence that the malware detection community has opportunities to strengthen the automatic detection of cryptojacking WebAssembly malware. The results of this work are actionable, as we provide quantitative evidence on specific malware transformations on which detection methods can focus. To sum up, the contributions of this work are: - A full-fledged cryptojacking malware evasion pipeline for WebAssembly, based on a state-of-the-art binary diversification. We provide the repository of the tool at https: //github : com/ASSERT-KTH/wasm\_evasion . - A systematic evaluation of our cryptojacking evasion pipeline, including effectiveness, performance, and correctness. - Actionable evidence on which transformations are better for evading WebAssembly cryptojacking detectors, calling for future work from the academic and the industrial community alike. - A reproducible comparison of VirusTotal with MINOS, a WebAssembly-specific detector, showing the relevance of VirusTotal as a valid and practical cryptojacking meta-detector. This paper is structured as follows. In section 2, we introduce WebAssembly for cryptomining and the state-of-theart on malware detection and evasion techniques and its limitations for WebAssembly cryptojacking. In section 3, we instantiate and explain malware evasion for WebAssembly cryptojacking in a real scenario. We follow with the technical description of our malware evasion algorithms in section 4. We formulate our research questions in section 5, answering them in section 6. We discuss our research in section 7, in order to help future research projects on similar topics. We finalize with our conclusions section 8. ## 2. Background & Related Work In this section, we introduce WebAssembly. Besides, we illustrate its usage for cryptojacking. Then, we discuss how WebAssembly cryptojacking can be detected, and the most common techniques used to evade such detection. ## 2.1. WebAssembly WebAssembly programs are compiled ahead-of-time from source languages such as C/C++, Rust, and Go, utilizing compilation pipelines like LLVM. This allows Wasm to benefit from ahead-of-time compiling optimizations, improving its performance. A Wasm binary is comprised of sections, which are consecutive sequences of bytes in the binary file. In contrast to the absolute order of sections in Windows Portable Programs, sections in Wasm binaries have a relative order between them. Thus, Wasm can be considered a more flexible binary format. WebAssembly (Wasm) is a binary instruction set meant initially for the web. It was adopted as a standard language for the web by the W3C in 2017, building upon the work of Haas et al. [20]. One of Wasm's primary advantages is that it defines its own Instruction Set Architecture (ISA), which is both straightforward and platform-independent. As a result, a Wasm binary can execute on virtually any platform, including web browsers and server-side environments. Since its introduction, all major web browsers have implemented support for WebAssembly, reporting to be only 10% slower than machine code during runtime. ``` eval a more flexible binary format. ``` WebAssembly programs operate on a virtual stack that allows for only four data types: i32, i64, f32, and f64. These same data types are used to annotate the numeric operations in the WebAssembly code. Additionally, a WebAssembly program might include several custom sections. For example, binary producers such as compilers use it to store meta- data. A WebAssembly code also declares memories and globals, which are used to store, manipulate and share data during program execution, e.g. to share data with the host engine of the WebAssembly binary. In Listing 1, we provide an example of a C program that contains a function declaration, a loop, a loop conditional, and a memory access. When the C code is compiled to WebAssembly, it produces the code shown in Listing 2. The stack operations are folded with parentheses. The module in the example contains the components described previously. WebAssembly is designed with isolation as a primary consideration. For instance, a WebAssembly binary cannot access the memory of other binaries or interact directly with a browser's built-in API, such as the DOM or the network. Instead, communication with these features is constrained to functions imported from the host engine, ensuring a secure and safe Wasm environment. Moreover, control flow in WebAssembly is managed through explicit labels and welldefined blocks, which means that jumps in the program can only occur inside blocks, unlike regular assembly code. ## 2.2. Malware in WebAssembly Web cryptojacking is often carried out by including a malicious JavaScript+WebAssembly payload, which then execute on the victim's browser without their knowledge [50]. For example, websites that offer illegal download or adult sites, often include cryptojacking in their webpages to generate passive income. Since cryptojacking is difficult to detect and remove, it can remain on a victim's computer for an extended period, continuing to consume resources and to generate income for the attacker. This lucrative form of malware does need vulnerabilities or stealing credentials. The use cases of WebAssembly in browsers focuses on computation-intensive activities such as gaming or image processing. Also, malign actors have taken advantage of WebAssembly to carry out their activities, and cryptojacking is the most common usage observed so far [41, 40]. The reason for this is that cryptojacking involves executing vast amounts of hash functions, which requires significant computing resources. In comparison to JavaScript, WebAssembly is significantly faster at handling these intense hashing operations in the browser [20]. ## 2.3. Malware Detection Malware detection determines if a binary is malicious or not. This process can be based on static, dynamic, or hybrid analysis [3]. In this section, we highlight works in the area of malware detection. Static-based approaches analyze the source code or the binary to find malign patterns without executing them. The literature reports a range of techniques, from simple checksum checking to advanced machine learning methods, that have subsequently been adopted by commercial antiviruses [8, 30]. In the context of WebAssembly, MineSweeper is a detection method based on static analysis [27] of WebAssembly. Its detection strategy depends on the knowledge of the internals of CryptoNight, one popular library for cryptomining. In the same context, MINOS is a state-of-art static detection tool that converts WebAssembly binaries to vectors for malware detection [42]. Dynamic analysis for malware detection is based on the execution of the malware code to identify potentially dangerous behaviors [18]. Usually, this is done by monitoring some functions, such as API calls. For example, BLADE [34] is a Windows kernel extension that aims to eliminate drive-by malware installations. It wraps the filesystem for browser downloads for which user consent has been involved. It thwarts the ability of browser-based exploits to download and execute malicious content surreptitiously. SEISMIC and MineThrotle also perform dynamic analyses [52, 5] on WebAssembly binaries to profile instructions that are specific to cryptominers. For example, cryptominers overly execute XOR instructions. SEISMIC and MineThrotle use machine learning approaches to classify the binary as benign or malign based on collecting runtime profiles. On the same topic, MinerRay [48] detects cryptojacking in WebAssembly binaries by analyzing their control flow graph at runtime, searching for structures that are characteristic of encryption algorithms commonly used for cryptojacking. CoinSpy is another malware detector based on dynamic analysis [25]. It uses a convolutional neural network to analyse the computation, network, and memory information caused by cryptojackers running in client browsers. MINOS is a practical approach for detecting malicious WebAssembly binaries. It works by converting the Wasm binary's bytestream into a 100x100 grayscale image, which is then fed into a Convolutional Neural Network (CNN). The CNN has learned patterns in the image to classify it as either benign or malicious. This approach is similar to imagebased methods used in other areas [32], e.g., for detecting Windows malware [23, 28]. We believe MINOS is the optimal static approach to detect WebAssembly malware due to its simplicity and practicality, such as being easily implemented as a browser extension. Hybrid approaches use a mix of static and dynamic detection techniques. The main reason to use hybrid approaches is the impracticability of executing the whole program. Thus, only pieces of code that can be quickly executed are dynamically analyzed. For example, AppAudit embodies a novel dynamic analysis for Android applications that can simulate the execution of some parts of the program [55]. For WebAssembly, Outguard [26] trains a Support Vector Machine model with a combination of cryptomining function names obtained statically and dynamic information such as the number of web workers used in the web application that is analyzed. It is possible to combine several independent detectors into a meta-antivirus. Each detector embeds some heuristics that are good at detecting specific types of malware [37]. Hence, their combination can effectively detect a broader range of malware, e.g., using relationship analysis. VirusTotal [51, 19] is a consolidated meta-antivirus. VirusTotal operates with 60 antivirus vendors to provide malware scanning. Through its API, a program can be labeled by 60 an- tiviruses. This aggregation is used to determine if an asset under analysis is malicious, e.g., by voting. Previous works used VirusTotal to assess detection efficiency, [44] because it is a proxy to evaluate state-of-art techniques in combination with commercial antiviruses. In this work, we follow the same methodology, using VirusTotal to assess our technique's ability to evade cryptojacking detectors. While concerns have been raised about the use of VirusTotal for some malware and file type families [7], it can be considered for WebAssembly cryptojacking detection. We empirically highlight later in this paper that VirusTotal is slightly better than the WebAssembly-specific detector MINOS regarding the detection of cryptojacking malware. ## 2.4. Malware Evasion In the context of WebAssembly, malware evasion is nearly unexplored. Only Romano et al. [47] recently proposed wobfuscator, a code obfuscation technique that transforms JavaScript code into a new JavaScript file and a set of WebAssembly binaries. Their technique mostly focuses on JavaScript evasion and not WebAssembly evasion. Malware evasion techniques aim at avoiding malware detection [1] Potential attackers use a wide range of techniques to achieve evasion, such as genetic programming [13]. With time, the techniques to avoid detection have grown in complexity and sophistication [2]. For example, Chua et al. [14] proposed a framework to automatically obfuscate Android applications' source code using method overloading, opaque predicates, try-catch, and switch statement obfuscation, creating several versions of the same malware. Also, machine learning approaches have been used to create evading malware [16], based on a corpus of pre-existing malware [6]. While most approaches try to break static malware detectors, more sophisticated techniques avoid dynamic detection, usually involving throttling techniques or dynamic anti-analysis checks [33, 43]. Wang proposes the concept of Accrued Malicious Magnitude (AMM) to identify which malware features should be manipulated to maximize the likelihood of evading detection [53]. Bhansali et al. [4] propose a technique where WebAssembly binaries are transformed while maintaining the functionality with seven different source code obfuscation techniques. They evaluate the effectiveness of the techniques against MINOS [42]. They show these transformations can generate malware variants that evade the MINOS classifier. ## 3. WebAssembly cryptojacking malware evasion in practice Figure 1 illustrates our attack scenario: a practical WebAssembly cryptojacking attack consists of three components: a WebAssembly binary, a JavaScript wrapper, and a backend cryptominer pool. The WebAssembly binary is responsible for executing the hash calculations, which consume significant computational resources. The JavaScript wrapper facilitates the communication between the WebAssembly binary and the cryptominer pool. Overall, a successful cryptojacking attack on a victim's browser consists Figure 1: WebAssembly evasion in practice. The user visits a webpage containing cryptojacking malware that uses network resources to operate. A malware detector blocks identified malicious WebAssembly binaries. The attacker, using a malware oracle, creates a WebAssembly cryptojacking malware variant that evades detection. Finally, the attacker delivers the modified binary, initiating the cryptojacking process and compromising the browser. <details> <summary>Image 2 Details</summary>  ### Visual Description \n ## Diagram: Web Attack Flow ### Overview This diagram illustrates the flow of a web-based attack involving JavaScript (JS) and WebAssembly (WA), targeting a user browser and ultimately connecting to a remote mining pool or server controlled by an attacker. The diagram depicts the interaction between the user browser, malware detection systems, and the attacker's infrastructure, highlighting evasion techniques. ### Components/Axes The diagram consists of the following components, numbered 1 through 6: 1. **User Browser:** Represented by a browser window icon with a globe inside. Labeled "user browser". 2. **Attacker/Remote Server:** Represented by a silhouette of a person wearing a hoodie, labeled "Remote mining pool or server". 3. **Malware Detector:** Represented by a red circle with a diagonal line through it (indicating detection/blocking), labeled "Malware detector". 4. **Malware Evasion Technique:** Represented by a dashed rectangle, labeled "Malware evasion technique". 5. **WebAssembly (WA) - Evasive Code:** Represented by a purple square, labeled "WA". 6. **WebAssembly (WA) - Executed Code:** Represented by a purple circle, labeled "WA". Arrows indicate the flow of data and control between these components. The text "JS" is positioned between the user browser and the attacker/remote server. ### Detailed Analysis or Content Details The diagram shows the following flow: * **Step 1-2:** JavaScript (JS) is delivered from the "Remote mining pool or server" (2) to the "user browser" (1). * **Step 2-3:** The JS attempts to deliver WebAssembly (WA) code to the "Malware detector" (3). * **Step 3-4:** The "Malware evasion technique" (4) is employed to bypass the "Malware detector" (3). * **Step 4-5:** The bypassed WA code (5) is then delivered to the "user browser" (6). * **Step 1-6:** The "user browser" (1) receives the WA code (6). * **Step 2-3:** The "Remote mining pool or server" (2) also receives the WA code (3). The diagram highlights that the malware utilizes a "Malware evasion technique" to avoid detection by the "Malware detector". The use of WebAssembly (WA) is central to this evasion strategy. ### Key Observations The diagram emphasizes the use of JavaScript as the initial delivery mechanism for the malicious WebAssembly code. The "Malware evasion technique" is a critical component, suggesting that the attacker is actively attempting to bypass security measures. The diagram does not provide specific details about the evasion technique itself, but it indicates its importance in the attack chain. The use of WebAssembly is notable, as it can be used to obfuscate malicious code and make it more difficult to detect. ### Interpretation This diagram illustrates a common attack vector where JavaScript is used to deliver malicious code (WebAssembly) to a user's browser. The attacker aims to bypass malware detection systems using an "evasion technique," ultimately gaining control of the user's browser resources for purposes such as cryptocurrency mining (as suggested by the "Remote mining pool or server" label). The diagram suggests a sophisticated attack, as it involves the use of WebAssembly, which requires a degree of technical expertise to implement. The diagram is a high-level overview and does not provide details about the specific vulnerabilities exploited or the nature of the evasion technique. It serves as a conceptual illustration of the attack flow, highlighting the key components and their interactions. The diagram is a simplified representation of a complex process, and real-world attacks may involve additional steps and complexities. </details> in the following sequence of steps. First, the victim visits a web page infected with the cryptojacking code. The web page establishes a channel to the cryptominer pool, which then assigns a hashing job to the infected browser. The WebAssembly cryptominer calculates thousands of hashes inside the browser, in parallel using multiple browser workers [39]. Once the malware server receives acceptable hashes, it is rewarded with cryptocurrencies for the mining. Then, the server assigns a new job, and the mining process starts over. i) The user visits a webpage that contains a cryptojacking malware, which utilizes network resources to execute, (1) and (2) in Figure 1. Cryptojacking malware can be injected through malicious browser extensions, malvertising, compromised websites, or deceptive links [50]. ii) A malware detector blocks WebAssembly binaries that are identified as malicious (3). The malware detector system can be implemented locally or remotely. For instance, a proxy can intercept and send network resources to an external detector through the detector's API. iii) The attacker, based on a malware oracle, crafts a WebAssembly cryptojacking malware variant that evade the detection (4). iv) The attacker delivers the modified binary instead of the original one (5), which initiates the cryptojacking process and compromises the browser (6). Some detection techniques discussed in subsection 2.3 can be deployed in the browser directly to prevent cryptojacking. The primary objective of our work is to demonstrate the possibility of using code diversification to bypass cryptojacking defenses. Concretely, the following workflow can happen to successfully evade placed defenses: The idea is that attackers rapidly diversify their WebAssembly code to stay ahead of the defense system and maintain successful cryptojacking operations. Crucially, attackers must ensure that the diversified binaries they use for cryptojacking meet specific performance requirements, which is an aspect we will study in section 4. Figure 2: Our original workflow of binary diversification for malware evasion in WebAssembly. The workflow begins with a WebAssembly malware binary sent to a software diversifier. The diversifier creates binary variants, which are analyzed by a malware oracle that labels them as malware or benignware. The oracle's results guide the development of a new binary based on the previous one. This process continues until the malware oracle labels the mutated binary as benign or a timeout occurs. <details> <summary>Image 3 Details</summary>  ### Visual Description \n ## Diagram: Evasion Algorithm Workflow ### Overview The image depicts a diagram illustrating an evasion algorithm workflow, likely for malware. The process begins with a "Malware Wasm" input and cycles through diversification, malware oracle evaluation, and mutation selection to ultimately attempt to evade detection and be labeled as benign. ### Components/Axes The diagram consists of the following components: * **Malware Wasm (Input):** A purple rectangular block labeled "WA Malware Wasm". * **Diversifier:** A rectangular block labeled "Diversifier". * **Malware Oracle:** A rectangular block labeled "Malware Oracle". * **Mutation Selection & Fitness Function:** A rectangular block labeled "Mutation Selection & Fitness Function". * **Labeled as benign (Output):** A green checkmark within a circle, labeled "labeled as benign". * **Timeout:** A red circle with a slash through it, and a circular arrow, labeled "Timeout". * **Arrows:** Solid and dashed arrows indicating the flow of data and control. * **"WA" blocks:** Multiple grey rectangular blocks labeled "WA", representing diversified malware samples. The diagram is contained within a larger grey rectangular border. Numbered circles (1-4) are placed along the flow to indicate the sequence of operations. ### Detailed Analysis or Content Details 1. **Step 1:** The "Malware Wasm" (WA) input enters the "Diversifier". A solid arrow indicates the flow. 2. **Step 2:** The "Diversifier" outputs multiple instances of "WA" (diversified malware samples) to the "Malware Oracle". A solid arrow indicates the flow. 3. **Step 3:** A dashed arrow connects the "Mutation Selection & Fitness Function" back to the "Diversifier", indicating a feedback loop for mutation selection. 4. **Step 4:** The "Malware Oracle" outputs a labeling to either "labeled as benign" (green checkmark) or "Timeout" (red circle with slash and circular arrow). A solid arrow indicates the flow to the benign label. The "Mutation Selection & Fitness Function" also has a solid arrow labeled "Labeling" connecting it to the "Malware Oracle". A separate arrow labeled "Evasion algorithm" connects the "Mutation Selection & Fitness Function" to the "Timeout" component. ### Key Observations The diagram highlights a closed-loop system where malware is diversified, evaluated by an oracle, and then mutated based on the evaluation results. The goal is to evade detection and be labeled as benign. The "Timeout" component suggests a limit on the number of iterations or the time allowed for the evasion process. The dashed arrow from the "Mutation Selection & Fitness Function" to the "Diversifier" indicates a feedback mechanism for refining the diversification process. ### Interpretation This diagram illustrates a common approach to adversarial machine learning, specifically in the context of malware evasion. The "Malware Oracle" represents a detection system (e.g., an antivirus engine or a machine learning classifier). The "Diversifier" generates variations of the malware, and the "Mutation Selection & Fitness Function" guides the evolution of the malware to maximize its chances of evading detection. The feedback loop ensures that the malware adapts to the detection system over time. The "Timeout" component is a practical consideration, preventing the algorithm from running indefinitely if it fails to find an evading variant. The entire process is an example of an evasion algorithm attempting to find inputs (malware variants) that are misclassified by the "Malware Oracle". The diagram suggests a dynamic and iterative process, where the malware is continuously refined to bypass security measures. </details> ## 4. Diversification for Malware Evasion in WebAssembly In Figure 2 we illustrate our generic architecture for the malware evasion component. The workflow starts by passing a WebAssembly malware binary to a software diversifier (1). The diversifier generates binary variants, which are passed to a malware oracle (2). The oracle returns labeling feedback for the binary variant: malware or benignware. The oracle result is the input for a fitness function that steers the construction of a new binary on top of the previously diversified one. This process is repeated until the malware oracle marks the mutated binary as benign or a timeout is reached (4). For the sake of open science and for fostering research on this important topic, our implementation is made publicly available on GitHub: https: //github : com/ASSERT-KTH/wasm\_evasion . In this section, we explain a technique for potential attackers to craft a WebAssembly binary that evades detection (steps 4, 5 and 6 in Figure 1). ## 4.1. Diversifier wasm-mutate defines 135 possible transformations on an input WebAssembly binary, grouped into three categories. The peephole operator is the first category. It is responsible for rewriting instruction sequences in function bodies. It selects a random instruction within the binary functions Conceptually, our approach is parametrized by a semantic preserving diversifier [15]. For our prototype implementation, we select one diversifier that supports wasm-to-wasm diversification and performs almost non-costly transformations: wasm-mutate [10]. This tool takes a WebAssembly module as input and returns a set of variants of that module. wasm-mutate follows the notion of program equivalence modulo input [29], i.e., the variants should provide the same output for the same program inputs. It represents the search space for new variants as an e-graph [54], and it exploits the property that any traversal through the e-graph represents a semantically equivalent variant of the input program. wasm-mutate can generate thousands of semantically equivalent variants from a single binary in a few minutes. and applies one or more of the 125 rewrite rules. Finally, it re-encodes the WebAssembly module with the new, rewritten expression to produce a binary variant. The second category of transformations in wasm-mutate implements module structure transformations. It operates at the level of the WebAssembly binary structure. It includes the following eight transformations: add a new type definition, add/modify custom sections, add a new function, add a new export, add a new import, add a new global, remove a type and remove a function. The third transformation category is on the control flow graph of a function code level. wasm-mutate performs two possible transformations: unroll a loop or swap the branches of a conditional block. The decision of using wasm-mutate as a diversifier is based on three key factors. First, while diversification approaches for WebAssembly from LLVM sources exist [12, 11], compiler-based diversification may include compiler fingerprints in the built binaries, which is bad for stealthy evasion. Second, while optimization-based approaches could be used to diversify WebAssembly binaries from source code [45], optimizations are usually all applied at once, providing a smaller diversification space, hence fewer opportunities for evasion. Finally, wasm-mutate is a tool that implements many useful semantically equivalent transformations, making it well-suited as a diversifier with minimal engineering effort. Therefore, using wasm-mutate as a diversifier provides a practical approach for evasion in WebAssembly. We believe that attackers would take the same path and reach the same conclusion. Listing 3: Wasm-mutate transformation applied over Listing 2. <details> <summary>Image 4 Details</summary>  ### Visual Description \n ## Code Snippet: LLVM Intermediate Representation (IR) ### Overview The image displays a snippet of code in LLVM Intermediate Representation (IR). It appears to be a section defining a module and a function within that module, including a loop and conditional statement. The code is syntax-highlighted, with different colors indicating different elements of the IR. ### Components/Axes The code snippet consists of the following elements: * `(module)`: Indicates the start of a module definition. * `@custom "producer" "llvm.."`: A custom metadata annotation. * `(func (:5) (type 1))`: Defines a function with an argument list (:5) and return type (type 1). * `(loop :: label = @1)`: Defines a loop with a label @1. * `(if :: label = @2)`: Defines a conditional statement with a label @2. * `(i32.eqz)`: Integer comparison for zero. * `(i32.ge_s)`: Integer greater than or equal to (signed). * `(i32.load (local.get 0))`: Loads a 32-bit integer from local variable 0. * `(i32.const 100)`: Defines a 32-bit integer constant with the value 100. ### Detailed Analysis or Content Details The code snippet can be transcribed as follows: ``` (module - (@custom "producer" "llvm..") (func (:5) (type 1) (loop :: label = @1 (if :: label = @2 (i32.eqz (i32.ge_s (i32.load (local.get 0)) (i32.const 100) ) ) ) ) ) ) ``` The code defines a function that contains a loop. Inside the loop, there's a conditional statement (`if`). The condition checks if the result of `i32.ge_s` is zero. `i32.ge_s` compares a value loaded from local variable 0 with the constant 100, checking if the loaded value is greater than or equal to 100. The `i32.eqz` instruction then checks if the result of the comparison is zero (meaning the loaded value was less than 100). ### Key Observations The code snippet demonstrates a basic control flow structure (loop and conditional) within LLVM IR. The use of `i32` indicates that the code operates on 32-bit integers. The `@custom` annotation suggests that this code might be generated by a specific tool or compiler. ### Interpretation This code snippet likely represents a part of a larger program being compiled or analyzed using LLVM. The conditional statement suggests a comparison operation, potentially used for loop termination or branching logic. The `local.get 0` indicates that the function has at least one local variable. The overall structure suggests a simple iterative process where a value is loaded, compared to a constant, and potentially used to control the loop's execution. The `producer` metadata could indicate the source of this IR code, such as a specific compiler pass or optimization stage. The `llvm..` part of the metadata is likely a namespace or identifier specific to the LLVM toolchain. </details> ``` (then (i32.store (i32.add (i32.mul (i32.load (local.get 0)) (i32.load (local.get 0)) ) (i32.const 1024) ) (i32.load (local.get 0))) (i32.store (local.get 0) (i32.add (i32.load (local.get 0)) (i32.const 1))) (br 1 (;@1;)))) ) ``` For the sake of illustration, in Listing 3, we present a variant of the WebAssembly code shown in Listing 2. We generate this variant using the wasm-mutate diversifier, with two transformations. The changes made to the original code are highlighted in orange and green. The first transformation, highlighted in orange, involves removing the custom section that indicates the producer of the original binary. The second transformation, highlighted in green, replaces the shift-left operation in the original binary with two consecutive multiplications of the same value. ## 4.2. Malware Oracle In our experiments, we use VirusTotal [51] as our malware oracle. VirusTotal operates with 60 antivirus vendors to provide malware scanning. Users submit binaries, and they receive labels from different vendors. The resulting 60 labels can then be used to determine if a queried asset is malicious, e.g., by voting. VirusTotal can be used as both a binary and a numerical oracle [57]. We use VirusTotal as a binary oracle by returning malware if at least one vendor classifies the binary as malware. We also use VirusTotal as a numerical oracle, using the number (between 0 and 60) of oracles labeling a binary as malware. To determine whether a given sample is malicious or not, we rely on a malware oracle. The simplest form of malware oracle is a binary classifier that outputs a label of {malware, benignware}. In addition to binary classifiers, we also consider numerical oracles that provide a value representing the likelihood that a sample is malicious. research [7], classification labels assigned to samples by vendors in VirusTotal can change over time due to new antivirus releases. In our work, we operate under the assumptions outlined in section 3 and consider a scenario where an attacker develops and executes an evasion technique in under an hour. This timeframe is significantly shorter than the time it takes for classification labels to change in VirusTotal, which typically takes several days. ## 4.3. Transformation Selection & Fitness Function First, we use a binary malware oracle. In this context, we always apply the transformation. This is the baseline evasion algorithm , which is discussed in more detail later. The third step of our workflow consists of two actions towards synthesizing a malware variant: select a wasm-mutate transformation to apply; and determine if the transformation is applied. This latter decision depends on: 1) the result of the malware oracle at the previous iteration and 2) an estimation of the ability of the new transformation to generate an evading binary. For this estimation, we implement two variations of our evasion algorithm. The second variation of the evasion algorithm includes a fitness function that uses a numerical oracle to estimate if the transformation should be applied. The fitness function uses the information from VirusTotal and is the total number of vendors (between 0 and 60) that label a binary as malware: $$F F ( m ) = \Sigma _ { i = 0 } ^ { i = 6 0 } \left \{ \begin{array} { l } { 1 i f v _ { i } ( m ) r e t u n s \, m a l w a r e } \\ { 0 i . o . c } \end{array}$$ This fitness function is used in our second proposed algorithm and is discussed in details below. ## 4.3.1. Baseline Evasion With this algorithm, a transformation is randomly selected at each iteration, and always applied. Hence, the baseline algorithm can require many iterations and oracle queries to turn the original malware into a misclassified binary. Second, some transformations might suppress the effect of previous ones. Third, the baseline algorithm considers each vendor equally good at detecting a malware, which is naive as the vendors display considerable diversity regarding detection strength. An algorithm that would target evasion on the strongest vendor first would increase the overall performance of the evasion process. Finally, we might generate a binary that entirely evades the oracle but is unpractical in terms of size or its execution performance. The baseline evasion algorithm is described in algorithm 1. It uses VirusTotal as a binary oracle (true if at least one VirusTotal detects malware, false otherwise). In this algorithm, step 1 is in line 3, steps 2 and 4 are in lines 4 to 6, and step 3 is in line 7. Each iteration of this algorithm, 'stacks' a transformation on top of the previous ones (line 7) until the binary is marked as benign (line 5) or the maximum number of iterations is reached (line 2). ## 4.3.2. MCMCEvasion The algorithm for the MCMC evasion is given in algorithm 2. The halting condition is met when a mutated binary is marked as benign, or a maximum number of iterations is reached. The algorithm implements the MCMC in lines 6 To overcome the limitations of the baseline algorithm, we devise the MCMCevasion algorithm , which we now discuss. It is a Markov Chain Monte Carlo (MCMC) sampling [21] of the transformations to apply [49]. MCMC is used to sample from the space of transformation sequences to maximize the likelihood of oracle evasion in two ways. ``` input : binary W , diversifier D, Malware Oracle MO output: Benign binary M' 1 M' <- W while Not max iterations do 2 | return M';; 3 else 4 | M <- M';; 5 end 7 end 8 return "Not evaded";Algorithm 1: Baseline evasion algorithm. ``` to 15. The Markov decision function in line 12 is used to determine whether it is worth applying the transformation at this step or whether it should be skipped. This decision function is based on the current transformation's fitness and the fitness value saved at the previous step (line 14). The core idea is to favor a binary variant that evades the largest number of vendors (lines 4 and 13). Therefore, the number of oracle calls should decrease as the algorithm searches for transformations that converge toward total evasion. On the other hand, if a new transformation step decreases the fitness value, it is likely to be ignored. The classical MCMC acceptance criteria in line 12 is meant to prevent the algorithm from being stuck in local minima. The MCMC evasion algorithm addresses the three limitations of the baseline mentioned in the previous section. First, the fitness function selects transformations, thus reducing the total number of transformations that are actually performed. Second, MCMC aims at increasing fitness, which reduces the risk of suppressing a valuable transformation performed in the previous step. Third, by favoring solutions that maximize the number of evaded vendors, MCMC biases the search towards evading the strongest vendors. In line 12, the fraction calculated in the exponentiation is controlled by the parameter. By setting a low parameter, we can turn the MCMC evasion algorithm into a greedy algorithm. In this case, the algorithm selects a new transformation only if the fitness value is higher than in the previous iteration. On the contrary, if the parameter is significant, the algorithm searches for local maxima. In our experiments (section 5), we explain how we select the values of . ## 5. Experimental Methodology In this section, we enunciate the research questions around which we assess the ability of our technique to evade malware detectors. We also describe our dataset of malware, as well as the metrics we define to answer our research questions. ## 5.1. Research Questions - RQ1. To what extent can cryptojacking malware detection be bypassed by WebAssembly diversification? With this research question, we evaluate the ``` input : binary W , diversifier D, fitness function FF output: Benign binary M' 1 M <- W 2 previous_fitness = FF(W) 3 while Not max iterations do 4 M' <- D(M) 5 current_fitness = FF(M') 6 if current_fitness == 0 then 7 // Zero means that none vendor marks 8 // the binary as malware 9 return M''; 10 else 11 p <- random() 12 if p < min(1, exp(sigma previous_fitness)) then 13 return M'; 14 | M <- M'; 15 end 16 end 17 return "Not evaded"; 18 return "Algorithm 2: MCMC evasion algorithm. ``` feasibility of binary transformations on malware and how they affect the detection of cryptojacking. - RQ2. To what extent can the attacker minimize the number of calls to the cryptojacking detection oracle? In real-world scenarios, the number of calls to the oracle is limited. With this question, we analyze the ability of our technique at limiting the number of oracles calls made during the evasion process. - RQ3. To what extent do the evasion techniques impact cryptojacking malware functionality? The evasion algorithms might generate variants that evade the detectors but modify their core malicious functionality. This research question evaluates the correctness of the created variants, as well as their efficiency. - RQ4. What are the most effective transformations for WebAssembly cryptojacking malware evasion? This research question provides empirical evidence on which types of transformations are better for WebAssembly cryptojacking evasion. - RQ5. To what extent can Wasm diversification evade cryptojacking detection with MINOS? In this research question, we evaluate the feasibility of our technique for evading a state-of-the-art detector, MINOS, which is tailored to the analysis of WebAssembly. ## 5.2. Dataset Selection To answer our research questions, we curate a dataset of WebAssembly malware. For this, we filter the wasmbench dataset of Hilbig et al. [22] to collect suspicious mal- ware according to VirusTotal. The wasmbench dataset contains 8643 binaries collected from GitHub repositories and web pages in 2021. To our knowledge, this dataset is the newest and most exhaustive collection of real-world WebAssembly binaries. On August 2022, we passed the 8643 binaries of wasmbench to VirusTotal [51], and we 33 binaries were marked as potentially dangerous by at least one antivirus vendor of VirusTotal. All malware were marked as cryptojacking programs and we use these WebAssembly binaries to answer our research questions for cryptojakcing malware evasion. The programs include between 30 and 70 functions, for a total number of instructions ranging from 30531 to 55839. The size of the programs ranges from 62 to 103 kilobytes. These binaries are detected as malicious by at least 1 antivirus, and at most 31. We have observed that 6 out of 33 binaries can be executed end-to-end. In Table 1 we describe the 33 binaries detected as malware by VirusTotal. The table contains the following properties as columns: the identifier of the WebAssembly binary which is the sha256 hash of its bytestream, its size in bytes, the number of instructions, the number of functions defined inside the binary and the number of VirusTotal vendors that detect the binary. The last column contains the origin of the binary according to the wasmbench dataset. 1 To validate that the detected binaries are cryptojacking, we manually analyze each of the 33 binaries identified as malign. First, we observe that the binaries in the dataset originate from two primary sources: project SEISMIC and project MinerRay. SEISMIC [52] is a research project about instrumentation and monitoring at runtime to detect cryptojacking binaries. MinerRay is also a research project to detect crypto mining processes in web browsers [48]. Both projects have collected the binaries as real cryptojacking from the web and the dataset is a union of them. Third, our manual analysis of the binaries reveals 6 main sources for these differences. 1) Versions: the binaries do not depend on the same version of cryptonight, 2) Function reordering: The order in which the functions are declared inside the binary changes 3) Innocuous expressions: Second, we observee that all binaries share code from cryptonight [56], which is a library for cryptomining hashing. This observation is consistent with the findings of Romano et al. [48]. We find 5 binaries that are multivariant packages [11] of cryptopnight. A multivariant package is a binary containing more than one hashing function. Concretely, the binaries 0d996462 , d2141ff2 , 046dc081 , a32a6f4b and fbdd1efa contain between 2 and 3 versions of hashing functions cryptonight\_hash . 1 Binaries that could be found in a live webpage at the moment of this writing are marked with http:// . 3 All Wasm binaries of the MinerRay project could be found at https://github : com/miner-ray/miner-ray : github : io/tree/master/Data/ SampleWasmFiles 2 Yara project https://github : com/davbo/yara-rs/tree/master/sampleminers 4 All Wasm binaries of the SEISMIC project could be found at https: //github : com/wenhao1006/SEISMIC 5 Deepminer project https://github : com/deepwn/deepMiner Table 1: The 33 real-world WebAssembly cryptojacking used in our experiments. The table contains: the 256 hash of the WebAssembly cryptojacking, its size in bytes, the number of instructions, the number of functions defined inside the binary and the number of VirusTotal vendors that detect the binary at the time of writing. The last column contains the origin of the binary. | Hash | S | #I. | #F. | #D | Origin | |----------|--------|-------|-------|------|-------------------| | 9d30e7f0 | 68796 | 30768 | 61 | 30 | http archive | | 8ebf4e44 | 68803 | 30768 | 61 | 26 | Web crawling | | 47d29959 | 68796 | 30768 | 61 | 31 | Yara 2 | | aafff587 | 97551 | 47033 | 72 | 6 | SEISMIC 3 | | dc11d82d | 67496 | 30246 | 49 | 20 | MinerRay 4 | | 0d996462 | 70972 | 30531 | 30 | 19 | SEISMIC, MinerRay | | fbdd1efa | 94270 | 45905 | 40 | 18 | SEISMIC | | a32a6f4b | 94461 | 45940 | 40 | 18 | SEISMIC | | d2141ff2 | 70111 | 31783 | 30 | 9 | MinerRay, SEISMIC | | 046dc081 | 74099 | 31783 | 29 | 6 | MinerRay, SEISMIC | | 24aae13a | 62458 | 28339 | 37 | 4 | SEISMIC | | 000415b2 | 62466 | 28339 | 37 | 3 | SEISMIC | | 643116ff | 73010 | 31866 | | 6 | MinerRay | | 006b2fb6 | 87502 | 39544 | 90 | 4 | DeepMiner 5 | | 15b86a25 | 100755 | 45881 | 79 | 4 | MinerRay | | 4cbdbbb1 | 104666 | 47916 | 62 | 3 | SEISMIC | | 119c53eb | 137320 | 67069 | 79 | 2 | SEISMIC | | f0b24409 | 77572 | 34918 | 59 | 2 | MinerRay | | c1be4071 | 77572 | 34918 | 59 | 2 | MinerRay | | a74a7cb8 | 77572 | 34918 | 59 | 2 | MinerRay | | a27b45ef | 77572 | 34918 | 59 | 2 | MinerRay | | 6b8c7899 | 77572 | 34918 | 59 | 2 | MinerRay | | 68ca7c0e | 77572 | 34918 | 59 | 2 | MinerRay | | 65debcbe | 77572 | 34918 | 59 | 2 | MinerRay | | 5bc53343 | 77572 | 34918 | 59 | 2 | MinerRay | | 59955b4c | 77572 | 34918 | 59 | 2 | MinerRay | | 942be4f7 | 103520 | 46208 | 79 | 4 | MinerRay | | fb15929f | 77054 | 33562 | 112 | 4 | MinerRay | | 7c36f462 | 121931 | 55839 | 79 | 4 | MinerRay | | 89a3645c | 75003 | 34134 | 58 | 2 | MinerRay | | dceaf65b | 77575 | 34901 | 58 | 2 | MinerRay | | 089dd312 | 79883 | 34989 | 58 | 2 | MinerRay | | e09c32c5 | 71955 | 32416 | 46 | 1 | MinerRay | Expressions have been injected into the program code, but their execution does not affect the semantic of the original program 4) Function renaming: The name of the functions exported to JavaScript have been changed 5) Data layout changes: The data needed by the cryptominers has different location in the WebAssembly linear memory. 6) Partial cryptonight: Some binaries exclude cryptonight functions, i.e., the cryptonight\_create , cryptonight\_destroy , cryptonight\_hash functions. It is interesting to note that changes in function order, function names, or data layout leads to different programs that have the same number of instructions and functions, as is the case for 9 of our malign binaries. ## 5.3. Methodology RQ1: Evasion effectiveness. Toanswer RQ1, we execute the baseline evasion algorithm discussed in subsection 4.3. Wefirst pass a suspicious binary to wasm-mutate. The diversified version is passed to VirusTotal as a binary oracle. If at least one vendor still detects the diversified binary, we pass it to wasm-mutate again to stack a new random transformation. We repeat this process until VirusTotal does not label the binary as malware or reach a limit of 1000 transformations. The process is performed 10 times with 10 different random seeds for each binary. Based on our dataset of WebAssembly binaries, we follow the following procedures to answer our research questions. RQ2: Oracle minimization. Malicious actors have a limited budget to perform evasion before they get caught. The number of oracle calls is a proxy for such a budget, i.e., the lesser the number of oracle calls, the lesser effort spent. To answer RQ2, we aim at minimizing the number of oracle calls while keeping the same evasion effectiveness. In particular, we assess the capability of the MCMC evasion algorithm to minimize the number of calls to the malware oracle (Metric 1). For this, we execute the MCMC evasion algorithm (algorithm 2) one time for each malware binary of our dataset. We use VirusTotal as an oracle and stop when we reach a limit of 1000 transformations. Since MCMC has a configuration parameter , we repeat the process with three values: 0 : 01 , 0 : 3 , and 1 : 1 . The -value weights exploration and exploitation of transformations during the evasion process. For example, the first value is low, favoring exploration at the most, meaning that the MCMC algorithm will take any new transformation, whether it increases the fitness function value or not. On the contrary, the largest value 1 : 1 favors the exploitation and, meaning that during evasion, MCMCwill only accept transformations with higher values from the oracle, i.e., more evaded detectors. We manually select the third value 0 : 3 as the balance between exploration and exploitation. Our end-to-end pipelines provide data on the number of generated hashes in the webpage component as an HTML element. Besides, the number of successful or incorrect jobs are logged by the miner pool. This information can be used RQ3: Malware functionality. A diversified binary that fully evades the detection, might not be practical due to behavioral or performance issues. RQ3 complements our first two research questions with a correctness and an efficiency evaluation. For every cryptojacking that can be executed, we reproduce all cryptominer components (described in subsection 2.2) and replace the WebAssembly binaries with variants that fully evade VirusTotal. For each executable cryptojacking program, we generate 10 variants with the baseline evasion algorithm as well as 10 variants with the MCMC algorithm, with value 0 : 3 to balance the MCMC explorationexploitation. Then, we replace the original cryptojacking by each of the 20 variants in order to determine that the behavior of the original cryptojacking program is preserved in the variants [17]. to measure both the correctness and efficiency of the generated WebAssembly variants. To collect data on the number of hashes per second, the webpage is accessed with Puppetter, while the miner pool logs are saved to measure the number of successful and failed jobs with their respective log time. By analyzing these two types of data, the overall correctness and effectiveness of a diversified WebAssembly binary can be determined. To check for efficiency, we measure the frequency of hashes produced by the variants binaries. For each WebAssembly cryptojacking and its generated variants, we execute and measure the hashes produced per second, during 1000 seconds. For each malware variant, we check if the hash production frequency is still in the same order of magnitude as the original. Tocheck correctness, we verify that the hashes generated by the variants are valid. We determine whether the hashes reach the third component of a cryptojacking (see subsection 2.2), i.e., how many successful and failed jobs are reported by the miner pool. If a miner pool correctly accepts the hashes, then the cryptojacking variant generated by our evasion algorithms is considered correct. RQ4: Individual Transformation Effectiveness. As discussed in subsection 4.1, our diversifier comprises 135 possible transformation operators. In this research question, we want to study which transformations perform better in evading the VirusTotal malware detection oracle. This investigation will help future researchers and detectors engineers to improve their detection methods and tackle subversive transformations. RQ5: Effectiveness against MINOS This research question assesses the effectiveness of our evasion technique with respect to the state-of-the-art WebAssembly malware detector, MINOS [42]. This detector takes a Wasm binary as input and creates a 100x100 grayscale image from its pure byte stream. Using a Convolutional Neural Network, the generated image is classified as benign or malware. Weuse a value of = 1 : 1 to tune the MCMC evasion algorithm. With this parameter, the MCMC evasion algorithm only keeps transformations that significantly contribute to improving the fitness of the variant. In other words, a transformation is applied if at least one more detector of VirusTotal is evaded. Then, we count the number of applied transformations, aggregated by its type. By measuring this, we obtain the most used one (resp. the least used), and, therefore, understand where malware researchers should focus for counter-evasion. We replicate MINOS. However, the model of MINOS is not publicly available, so we train our own model for this experiment. We use our own dataset to train the model with 33 malign programs and 33 benign programs. The 33 malign programs for training MINOS are the same listed in Table 1, the 33 benign programs are collected from the original MINOS reproduction steps. Our reproduction of MINOS achieves the same results as the original paper, based on one-off validation. Our reproduction of MINOS is publicly available at https://github : com/ASSERT-KTH/ralph . Weuse MINOS as an oracle and follow the same method proposed in RQ1, passing each one of the binaries in Table 1 to our diversifier and then to MINOS. For each binary, we do the process 10 times with 10 different seeds, generating a total of 330 variants with no more than 1000 stacked mutations. ## 5.4. Metrics In this section, we define the notions of total and partial evasion used in this work to measure the impact of the evasion algorithms proposed in subsection 4.3. Besides, we also define the number of oracle calls and number of stacked transformations metrics. In addition, we define the metrics for correct hashes generated by the malware variants and the hashes generation speed. Definition 1. Total evasion: Given a malware WebAssembly binary, an evasion algorithm generates a variant that totally evades detection if all detectors that originally identify the binary as malware identify the variant as benign. Definition 2. Partial evasion: Given a malware WebAssembly binary, an evasion algorithm generates a variant that partially evades detection if at least one detector that originally identifies the binary as malware identifies the variant as benign. Metric 1. Number of oracle calls: The number of calls made to the malware oracle during the evasion process. Metric 2. Number of stacked transformations: The total number of transformations applied on the initial malware binary during the evasion process. Notice that Metric 1 is the number of times that lines 4 and 5 in algorithm 1 and algorithm 2 are executed, respectively. The same could be applied to Metric 2, in lines 7 and 13 of algorithm 1 and algorithm 2, respectively. The main purpose of a WebAssmbly cryptominer is to calculate hashes. By measuring the number of calculated hashes per time unit, we can measure how performant the cryptojacking is. Therefore, the impact of the evasion process over the performance of the created binary can be measured, calculating the number of hashes per time unit: Metric 3. Crypto hashes per second (h/s): Given a WebAssembly cryptojacking, the crypto hashes per second metric is the number of successfully generated hashes in one second. Metric 4. Correct crypto hashes: Given a WebAssembly cryptojacking, the number of correct crypto hashes is the number of hashes that the WebAssembly cryptojacking generates and that the miner pool accepts as valid. ## 6. Experimental Results In section, we answer our four research questions regarding the feasibility of WebAssembly diversification for malware evasion. ## 6.1. RQ1. Evasion Effectiveness Table 2 shows the data to answer RQ1. The table contains as columns: the hash of the program, calculated as the sha256 hash, as its identifier, the number of initial VirusTotal detectors flagging the malware, the number of evaded antivirus vendors (cf. Definition 2) and the mean number of iterations needed to generate a variant that fully evades the detection (cf. Definition 1). The rows of the table are ordered with respect to the number of detectors for the original binary. We run our baseline evasion algorithm with a limit of 1000 iterations per binary. At each iteration, we query VirusTotal to check if the new binary evades the detection. This process is repeated with 10 random seeds per binary, resulting in a maximum of 10,000 queries per original binary. In total, we generate 98714 variants for the original 33 suspicious binaries. We observe that the baseline evasion algorithm successfully generates variants that totally evade detection for 30 out of 33 binaries. The mean value of iterations needed to generate a variant that evades all detectors ranges from 120 to 635 stacked transformations. For the 30 binaries that completely evade detection, we observe that the mean number of iterations to evade is correlated to the number of initial detectors. For example, the a32a6f4b binary, initially flagged by 18 detectors, requires around 635 iterations, while the 309c32c5 , with only one initial flag, needs 120 iterations. The mean number of iterations needed is always less than 1000 stacked transformations. There are 3 binaries for which the baseline algorithm does not completely evade the detection. In these three cases, the algorithm misses 5 out 31, 6 out of 30 and 5 out 26 detectors. The explanation is the maximum number of iterations (1000) we use for our experiments. However, having more iterations seems not a realistic scenario. For example, if some transformations increment the binary size during the transformation, a considerably large binary might be impractical for bandwidth reasons. Figure 3 shows the evasion process with four different seeds for the binary 046dc081 . Each point in the x-axis represents 50 iterations, and the y-axis represents the number of VirusTotal detectors flagging the binary. Three out of 4 seeds manage to totally evade VirusTotal in less than 250 iterations. We have observed that there are better evasion techniques than pure random transformations. For example, the seed represented by the green line partially evades the oracle but shows no tendency to evade detection before 300 iterations. Besides, some transformations help some classifiers to detect the mutated binary. These phenomena are empirically exemplified in Figure 3 in which the curves is not always monotonously decreasing, like the blue-colored curve. In this case, it goes from 3 VirusTotal detectors to 5 during the 50-100 iterations. On the other hand, there is a balance between generating variants and avoiding detection by defense mechanisms. For example, VirusTotal detects when it is being stressed with too many requests and too many queries can be detected and Table 2: Baseline evasion algorithm for VirusTotal. The table contains as columns: the hash of the program, the number of initial VirusTotal detectors, the maximum number of evaded antivirus vendors and the mean number of iterations needed to generate a variant that fully evades detection. The rows of the table are sorted by the number of initial detectors, from left to right and top to bottom. | Hash | #D | Max. #evaded | Mean #trans. | |----------|------|----------------|----------------| | 47d29959 | 31 | 26 (83.8%) | N/A | | 9d30e7f0 | 30 | 24 (80.0%) | N/A | | 8ebf4e44 | 26 | 21 (80.7%) | N/A | | dc11d82d | 20 | 20 (100.0%) | 355 | | 0d996462 | 19 | 19 (100.0%) | 401 | | a32a6f4b | 18 | 18 (100.0%) | 635 | | fbdd1efa | 18 | 18 (100.0%) | 310 | | d2141ff2 | 9 | 9 (100.0%) | 461 | | aafff587 | 6 | 6 (100.0%) | 484 | | 046dc081 | 6 | 6 (100.0%) | 404 | | 643116ff | 6 | 6 (100.0%) | 144 | | 15b86a25 | 4 | 4 (100.0%) | 253 | | 006b2fb6 | 4 | 4 (100.0%) | 282 | | 942be4f7 | 4 | 4 (100.0%) | 200 | | 7c36f462 | 4 | 4 (100.0%) | 236 | | fb15929f | 4 | 4 (100.0%) | 297 | | 24aae13a | 4 | 4 (100.0%) | 252 | | 000415b2 | 3 | 3 (100.0%) | 302 | | 4cbdbbb1 | 3 | 3 (100.0%) | 295 | | 65debcbe | 2 | 2 (100.0%) | 131 | | 59955b4c | 2 | 2 (100.0%) | 130 | | 89a3645c | 2 | 2 (100.0%) | 431 | | a74a7cb8 | 2 | 2 (100.0%) | 124 | | 119c53eb | 2 | 2 (100.0%) | 104 | | 089dd312 | 2 | 2 (100.0%) | 153 | | c1be4071 | 2 | 2 (100.0%) | 130 | | dceaf65b | 2 | 2 (100.0%) | 140 | | 6b8c7899 | 2 | 2 (100.0%) | 143 | | a27b45ef | 2 | 2 (100.0%) | 145 | | 68ca7c0e | 2 | 2 (100.0%) | 137 | | f0b24409 | 2 | 2 (100.0%) | 127 | | 5bc53343 | 2 | 2 (100.0%) | 118 | | e09c32c5 | 1 | 1 (100.0%) | 120 | blocked, effectively ruining evasion. In our attack scenario, where VirusTotal is used as an external detector (see section 3), we must be mindful of this limit. In contrast, when defense mechanisms such as MINOS are placed locally, we believe that the number of queries is not necessarily limited. Wasm-mutate performs mutations based on the input binary. In the experiments for RQ1, the input binaries for the baseline algorithm comes from the application of a previous mutation. Yet, we have observed that some transformations can be applied in any order. This means that different sequences of transformations can produce the same binary variant. This often happens when two mutation targets inside the binary are different, such as two disjoint pieces of code. Therefore, a potential parallelization for the baseline algorithm is possible as soon as transformation sequences do Figure 3: The figure shows the evasion process with four seeds for binary 046dc081 . Each point in the x-axis represents 50 iterations, and the y-axis represents the number of VirusTotal detectors. <details> <summary>Image 5 Details</summary>  ### Visual Description \n ## Line Chart: Detector Count vs. Iteration Number ### Overview The image presents a line chart illustrating the number of detectors remaining over iteration number for different random seeds. The chart appears to track a reduction in detector count as the iteration number increases, with varying rates of decline depending on the seed used. ### Components/Axes * **X-axis:** Iteration number, ranging from approximately 0 to 250. * **Y-axis:** Number of detectors, ranging from 0 to 7. * **Legend:** Located in the top-right corner, identifying the lines by seed number: * seed 1 (Blue, dashed line with circle markers) * seed 2 (Orange, dashed line with square markers) * seed 3 (Green, dashed line with plus markers) * seed 5 (Red, dashed line with x markers) * **Title:** "046dc081" located in the top-center of the chart. ### Detailed Analysis Let's analyze each line individually, noting trends and approximate data points: * **seed 1 (Blue):** Starts at approximately 6 detectors at iteration 0. Decreases steadily to around 3 detectors at iteration 50. Increases sharply to approximately 5.2 detectors at iteration 100, then declines rapidly to 0 detectors by iteration 200. * **seed 2 (Orange):** Begins at approximately 6 detectors at iteration 0. Decreases rapidly to approximately 1 detector at iteration 100. Fluctuates between 1 and 2 detectors from iteration 100 to 250, ending at approximately 1.5 detectors at iteration 250. * **seed 3 (Green):** Starts at approximately 6 detectors at iteration 0. Decreases steadily to approximately 3 detectors at iteration 50. Continues to decline to approximately 1 detector at iteration 150. Increases slightly to approximately 1.8 detectors at iteration 250. * **seed 5 (Red):** Starts at approximately 6 detectors at iteration 0. Decreases steadily to approximately 3 detectors at iteration 50. Continues to decline to approximately 1 detector at iteration 150. Decreases to approximately 0.2 detectors at iteration 250. ### Key Observations * All seeds show a general trend of decreasing detector count with increasing iteration number. * Seed 1 exhibits the most dramatic decline, reaching zero detectors relatively quickly. * Seed 2 shows the slowest decline and remains above 1 detector for a significant portion of the iterations. * Seeds 3 and 5 follow a similar trajectory, with seed 5 ultimately reaching the lowest detector count. * There is significant variability in the rate of detector reduction depending on the initial seed. ### Interpretation The chart likely represents a process where detectors are being eliminated or deactivated over time, potentially due to some form of filtering or selection mechanism. The different seeds suggest that the initial conditions or random variations within the process lead to different outcomes in terms of detector survival. The rapid decline observed for seed 1 could indicate a more aggressive filtering process or a higher sensitivity to certain conditions. The persistence of detectors for seed 2 suggests a more robust or resilient configuration. The fact that all lines eventually trend towards zero detectors suggests that the process is ultimately converging on a state with fewer or no detectors remaining. The title "046dc081" could be a unique identifier for this specific experiment or simulation run. The data suggests that the initial random seed has a significant impact on the dynamics of detector elimination. </details> not interfere with others. Answer to RQ1 : The baseline evasion algorithm with wasm-mutate clearly decrease the detection rate by VirusTotal antivirus vendors for cryptojacking malware. We achieve total evasion of WebAssembly cryptojacking malware in 30/33 (90%) of our malware dataset. Overall, our experiments prove that wasm-mutate is a powerful tool to perform malware evasion. By carefully selecting the order and type of transformations applied, it is possible to generate program variants that are both performant and effective at evading detection. This same idea is explored in the next section. ## 6.2. RQ2. Oracle Minimization In Table 3 we can observe the impact of the MCMC evasion algorithm on our reference dataset. The first two columns of the table are the original program's hash and the number of initial VirusTotal detectors flagging the malware. The remaining columns are divided into two categories, maximum detectors evaded (Definition 2) and the number of oracle calls if total (Definition 1). Each one of the two categories contains the result for both evasion algorithms, first the baseline algorithm(BL) followed by the three -values analyzed in the MCMC evasion algorithm. Notice that, for the baseline algorithm, the number of oracle calls is the same value as the number of transformations needed to evade by construction. We highlight in bold text the values for which the baseline or the MCMC evasion algorithms are better than each other, the lower, the better. With RQ2, we analyze the effect of the MCMC evasion algorithm in minimizing the number of calls to the malware oracle (Metric 1). To answer RQ2, we execute the MCMC evasion algorithm discussed in algorithm 2. We observe that the MCMC evasion algorithm successfully generates variants that totally evade the detection for 30 out of 33 binaries, it thus as good as the baseline algorithm. The improvement happens in the number of oracle calls. The oracle calls needed for the MCMC evasion algorithm are 92% of the needed on average for the baseline Table 3: MCMC evasion algorithm for VirusTotal. The first two columns of the table are: the identifier of the original program and the number of initial detectors. The remaining columns are divided into two categories, maximum detectors evaded if partial evasion and number of oracle calls if total evasion. Each one of the two categories contains the result of the evasion algorithms, first the baseline algorithm (BL) followed by the three -values analysed in the MCMC evasion algorithm. We highlight in bold text the values for which the baseline or the MCMC evasion algorithms are better from each other. Overall, the MCMC evasion algorithm needs less oracle calls than the baseline algorithm. | Hash | #D | Max. evaded | Max. evaded | Max. evaded | Max. evaded | #Oracle calls | #Oracle calls | #Oracle calls | #Oracle calls | |----------|------|---------------|----------------|----------------|----------------|-----------------|-----------------|-----------------|-----------------| | | | BL | MCMC | MCMC | MCMC | BL | MCMC | MCMC | MCMC | | | | | =0.1 | =0.3 | =1.1 | | =0.01 | =0.3 | =1.1 | | 47d29959 | 31 | 26 | 19 | 12 | 10 | | | | | | 9d30e7f0 | 30 | 24 | 17 | 9 | 10 | | | | | | 8ebf4e44 | 26 | 21 | 13 | 5 | 4 | | | | | | dc11d82d | 20 | 20 | 20 | 14 | 15 | 355 | 446 | | | | 0d996462 | 19 | 19 | 19 | 14 | 4 | 401 | 697 | | | | a32a6f4b | 18 | 18 | 18 | 6 | 1 | 635 | 625 | | | | fbdd1efa | 18 | 18 | 18 | 3 | 3 | 310 | 726 | | | | d2141ff2 | 9 | 9 | 9 | 9 | 5 | 461 | 781 | 783 | | | aafff587 | 6 | 6 | 2 | 6 | 6 | 484 | | 331 | 413 | | 046dc081 | 6 | 6 | 6 | 6 | 5 | 404 | 397 | 159 | | | 643116ff | 6 | 6 | 6 | 6 | 1 | 144 | 436 | 631 | | | 15b86a25 | 4 | 4 | 4 | 4 | 4 | 253 | 208 | 214 | 131 | | 006b2fb6 | 4 | 4 | 4 | 4 | 0 | 282 | 380 | 709 | | | 942be4f7 | 4 | 4 | 4 | 4 | 4 | 200 | 200 | 200 | 219 | | 7c36f462 | 4 | 4 | 4 | 2 | 0 | 236 | 221 | | | | fb15929f | 4 | 4 | 2 | 4 | 2 | 297 | | 475 | | | 24aae13a | 4 | 4 | 4 | 4 | 0 | 252 | 401 | 446 | | | 000415b2 | 3 | 3 | 3 | 3 | 2 | 302 | 376 | 34 | | | 4cbdbbb1 | 3 | 3 | 3 | 3 | 3 | 295 | 204 | 72 | 685 | | 65debcbe | 2 | 2 | 2 | 2 | 2 | 131 | 33 | 33 | 33 | | 59955b4c | 2 | 2 | 2 | 2 | 2 | 130 | 33 | 33 | 33 | | 89a3645c | 2 | 2 | 2 | 2 | 2 | 431 | 319 | 197 | 107 | | a74a7cb8 | 2 | 2 | 2 | 2 | 2 | 124 | 33 | 33 | 33 | | 119c53eb | 2 | 2 | 2 | 2 | 2 | 104 | 45 | 480 | 18 | | 089dd312 | 2 | 2 | 2 | 2 | 2 | 153 | 166 | 167 | 123 | | c1be4071 | 2 | 2 | 2 | 2 | 2 | 130 | 33 | 33 | 33 | | dceaf65b | 2 | 2 | 2 | 2 | 2 | 140 | 166 | 166 | 132 | | 6b8c7899 | 2 | 2 | 2 | 2 | 2 | 143 | 33 | 33 | 33 | | a27b45ef | 2 | 2 | 2 | 2 | 2 | 145 | 33 | 33 | 33 | | 68ca7c0e | 2 | 2 | 2 | 2 | 2 | 137 | 33 | 167 | 595 | | f0b24409 | 2 | 2 | 2 | 2 | 2 | 127 | 11 | 33 | 11 | | 5bc53343 | 2 | 2 | 2 | 2 | 2 | 118 | 33 | 33 | 33 | | e09c32c5 | 1 | 1 | 1 | 1 | 0 | 120 | 488 | 921 | | evasion algorithm. The impact of the MCMC evasion algorithm is illustrated in Figure 4. Each point in the x-axis represents 50 iterations, and the y-axis represents the number of VirusTotal detectors flagging binary 046dc081. 2 out of 3 -values manage to totally evade VirusTotal in less than 400 iterations. On the contrary, lower acceptance criteria = 1 : 1 (green line) partially evades the oracle, but does not fully For 21 of 30 binaries that evade detection entirely, we observe that the mean number of oracle calls needed is lower than those in the baseline evasion algorithm. For example, f0b24409 needs 11 oracle calls with the MCMC evasion algorithm to fully evade VirusTotal, while for the baseline evasion algorithm, it needs 127 oracles calls. For those 21 binaries, it needs only 40% of the calls the baseline evasion algorithm needs. evade within the maximum 1000 iterations limit of the experiment. According to our experiments, = 0 : 3 offer a good acceptance trade-off. However, the best value of actually depends on the binary to mutate. Therefore, we cannot conclude the best value of for the whole dataset. This is a consequence of the particularities of each one of the original binaries and its detectors. For example, we have observed that for the bottom part of Table 3 the highest value of works better overall. The main reason is the low number of original detectors. In those cases, the exploration space for transformations is smaller. Thus, for the MCMC evasion algorithm, the chances of a local minimum for the fitness function to be global are larger. Therefore, the MCMC evasion algorithm with low acceptance criteria can find the binary that fully evades in fewer iterations. On the contrary, if the number of initial detectors is more significant, the exploration space is too big to explore in 1000 max iterations. The reason is that the MCMC evasion algorithm applies one transformation per time. While we provide fine-grained analysis in our work, more than one transformation per iteration could be applied in the MCMC evasion algorithm to solve this. The value in the algorithm 2 provides the acceptance criteria for new transformations in the MCMC evasion algorithm. We run the MCMC evasion algorithm with three values to better understand the extent to which the transformation space is explored to find a binary that evades successfully. We have observed that for a large value of , meaning low acceptance, 16 binaries cannot be mutated to evade VirusTotal entirely. The main reason is that, in this case, the MCMC evasion algorithm discards transformations that increase the number of oracle calls. Therefore, the algorithm gets stuck in local minima and never finds a binary that entirely evades. On the contrary, a small value of accepts more new transformations even if more detectors flag the binary. In all 3 cases for which neither the baseline nor the MCMC evasion algorithms could find a binary that fully evades, the maximum evaded detectors are less for the MCMC evasion algorithm. The main reason is that the MCMCevasionalgorithm might prevent transformations for which the number of detectors increases. As previously discussed, it is stuck in local minima, which means that it does not explore transformation paths for which a higher number of detectors could lead to better long-term results and, eventually, full evasion. Answer to RQ2 : The MCMC evasion algorithm needs fewer oracle calls than the baseline algorithm. In 21 cases out of 33, it needs only 40% of oracle calls compared to the baseline, providing more stealthiness to the malicious organization directing the evasion. The acceptance criterion of the MCMC evasion algorithm needs to be carefully crafted depending on the original binary. Figure 4: The figure shows the MCMC evasion process for the binary 046dc081 . Each point in the x-axis represents 50 iterations, and the yaxis represents the number of VirusTotal detectors. The figure shows less chaotic progress for oracle evasion. <details> <summary>Image 6 Details</summary>  ### Visual Description \n ## Line Chart: Detector Count vs. Iteration Number ### Overview The image presents a line chart illustrating the number of detectors remaining over iteration number for three different sigma values in a Markov Chain Monte Carlo (MCMC) process. The chart aims to show how the number of detectors changes as the MCMC algorithm progresses, with different lines representing different levels of noise or uncertainty (sigma). ### Components/Axes * **X-axis:** Iteration number, ranging from 0 to 1000, with tick marks at 0, 200, 400, 600, 800, and 1000. * **Y-axis:** Number of detectors, ranging from 0 to 6, with tick marks at 0, 1, 2, 3, 4, 5, and 6. * **Legend:** Located in the top-right corner, identifying three lines: * `mcms sigma=0.01` (dashed blue line) * `mcms sigma=0.3` (dashed orange line) * `mcms sigma=1.1` (dashed green line) ### Detailed Analysis * **Line 1: `mcms sigma=0.01` (dashed blue)**: This line starts at approximately 6 detectors at iteration 0. It decreases rapidly to around 1 detector by iteration 200, then fluctuates between 0 and 1.5 detectors for the remainder of the iterations, ending at approximately 1 detector at iteration 1000. * **Line 2: `mcms sigma=0.3` (dashed orange)**: This line begins at approximately 4.5 detectors at iteration 0. It drops quickly to around 2 detectors by iteration 200, then remains relatively stable between 1.5 and 2.5 detectors for iterations 200-800, and then decreases to approximately 1 detector at iteration 1000. * **Line 3: `mcms sigma=1.1` (dashed green)**: This line starts at 6 detectors at iteration 0. It decreases to approximately 4 detectors by iteration 200, then plateaus around 2 detectors for iterations 200-800, and finally decreases to approximately 1 detector at iteration 1000. ### Key Observations * All three lines show a general decreasing trend in the number of detectors as the iteration number increases. * The line with the lowest sigma value (0.01) experiences the most rapid initial decrease in detector count. * The line with the highest sigma value (1.1) maintains a higher detector count for a longer period compared to the other two lines. * All lines converge to approximately 1 detector at iteration 1000. ### Interpretation The chart suggests that as the MCMC algorithm iterates, detectors are being eliminated or filtered out. The sigma value appears to influence the rate at which detectors are removed. A lower sigma value (less uncertainty) leads to a faster reduction in detector count, potentially indicating a more aggressive filtering process. Conversely, a higher sigma value (more uncertainty) allows more detectors to persist for a longer duration. The convergence of all lines to approximately 1 detector at the end suggests that the algorithm eventually settles on a single, or a small number of, detectors regardless of the initial sigma value. This could represent the algorithm converging to a stable solution or identifying the most reliable detectors. The initial rapid drop in detector count for all sigma values could be due to an initial pruning of poorly performing detectors. The fluctuations observed in the lines, particularly for the sigma=0.01 case, might indicate instability or noise in the algorithm's process. </details> ## 6.3. RQ3. Malware Functionality Weexecute the original binary and the variants generated by the baseline and MCMC evasion algorithms. The essence of a cryptojacking is to generate hashes at high-speed. Consequently, we assess the correctness of the variants concerning two properties: validity of the hashes and frequency of hash generation. With Metric 4, we determine the validity of the generated hashes by checking if the backend miner pool accepts them. The frequency is measured as the amount of hashes produced by the variant binaries in one second (Metric 3). To answer RQ3, we select the six binaries we can build and execute end-to-end, because we have access to the three components previously mentioned in subsection 2.2. For those six binaries, we are able to replace the original WebAssembly binary with variants generated by our evasion algorithms. Table 4 summarizes the key data for RQ3. Each row of the table corresponds to one binary that can be executed end-to-end, by reproducing the three components mentioned in subsection 2.2. The first two values of each row are the original binary's identifier and its original frequency of hash generation. Then, for our baseline algorithm, each row has the data for 10 variants generated during a successful oracle evasion. For each one of the variants, we include the correctness percentage and the hashes calculated per second. The last group of columns of the table contains the correctness percentage and the hashes calculated per second for the 10 variants generated with the MCMC algorithm. After each frequency of hashing measurement, we indicate the relative difference with the original frequency in parentheses. A difference larger or equal to 1.0 means that the variant is faster or as efficient as the original. On the contrary, the variant is slower if the difference is lower than 1.0. The table contains the information for 120 variants. We use the backend miner pools (see subsection 2.2) of the six cryptojacking to determine the validity of the hashes computed by all the programs. All correctness assessments for the 120 variants indicate that the miner pools do not detect any invalid hash when executing the WebAssembly cryptominer variants. This means that the variants synthesized by the baseline and the MCMC algorithms to evade the malware oracle can still systematically generate valid hashes. In summary, all this is evidence that focused optimization is a good primitive for evasion. On the contrary, 97 out of 120 variants underperform compared to the original binary. The worst case is the binary 0d996462 . Its slowest variant has 0.20 of the original generation frequency. The main reason is that wasm-mutate also introduces nonoptimal transformations regarding performance. We have observed that 23 of 120 variants are more efficient than the original cryptojacking. For example, for the fbdd1efa binary, all its variants are from 1.27 to 1.43 faster than the original hash generation frequency. This phenomenon occurs because wasm-mutate can perform transformations in the executable code, which work as optimizations. Our experiments have revealed two sources of faster WebAssembly variants: loop unrolling transformations and code replacements that lead to smaller binaries. We have also found that debloating transformations, which remove unneeded structures and dead code, results in more hashes being produced by the cryptominer in the first few seconds of mining, likely because of faster compilation. The variants generated by the baseline evasion algorithm tend to be slower than the MCMC evasion algorithm. The MCMCevasionalgorithm triggers fewer oracle calls and can generate variants faster than the ones generated by the evasion algorithm. This phenomenon is a direct consequence of the MCMC evasion algorithm implementation, which has a selective strategy when applying transformations on a binary (see algorithm 2). In summary, the MCMC evasion algorithm produces variants that fully evade the VirusTotal oracle with lower performance overhead during execution. The worst performant variant is only 1.93 times slower for the MCMC evasion algorithm. In Figure 5, we plot the distribution of the hashes per second for variants generated for the fbdd1efa cryptojacking. In the figure, we include the original binary (in blue), the ten variants generated by the baseline algorithm (in orange), and the ten variants generated by the MCMC evasion algorithm (in green). Each violin plot corresponds to the hashes per second. We observe a normal distribution around the exact number of hashes per second. In this case, we have observed that the MCMC evasion algorithm provides a hashper-second ratio better than the original. This phenomenon can be observed in the lines inside the violin plots, the green line is shifted to the right compared to the lines of the blue violin plot. Table 4: Malware correctness and efficiency. We execute each cryptojacking that can be reproduced, with the original malware, and with 10 baseline variants and 10 MCMC variants. The first left section indicates the identifier of the original binary and its original frequency of hash generation. The second section of the table shows correctness percentage and hashes per second for ten variants generated with our baseline algorithm. The third section of the table shows correctness percentage and hashes per second for ten variants generated with the MCMC algorithm. After each frequency of hashing measurement, we indicate the relative difference with the original frequency, in parentheses. A difference larger or equal to 1.0 indicates a variant that is faster or as efficient as the original; a difference lower than 1.0 is a variant slower than the original. | Hash | Original h/s | Baseline algorithm | Baseline algorithm | Baseline algorithm | Baseline algorithm | Baseline algorithm | Baseline algorithm | MCMCalgorithm | MCMCalgorithm | MCMCalgorithm | MCMCalgorithm | MCMCalgorithm | MCMCalgorithm | |----------|----------------|-----------------------|------------------------------------------|----------------------|--------------------------------|----------------------|-------------------------------|---------------------|-------------------------------------------|-----------------|-------------------------------|-----------------|----------------------------------| | 0d996462 | 116.0 | 100% 100% 100% 100% | 25 (0.22) 116 (1.00) 55 (0.47) 27 (0.23) | 100% 100% 100% | 24 (0.21) 110 (0.95) 27 (0.23) | 100% 100% 100% | 26 (0.22) 30 (0.26) 23 (0.20) | 100% 100% 100% 100% | 116 (1.00) 110 (0.95) 86 (0.74) 76 (0.66) | 100% 100% 100% | 70 (0.60) 76 (0.66) 60 (0.52) | 100% 100% 100% | 67 (0.58) 60 (0.52) 72 (0.62) | | a32a6f4b | 48.0 | 100% 100% 100% 100% | 25 (0.52) 26 (0.54) 26 (0.54) 23 (0.48) | 100% 100% 100% | 24 (0.50) 25 (0.52) 24 (0.50) | 100% 100% 100% | 24 (0.50) 26 (0.54) 25 (0.52) | 100% 100% 100% 100% | 26 (0.54) 46 (0.96) 44 (0.92) 45 (0.94) | 100% 100% 100% | 45 (0.94) 41 (0.85) 42 (0.88) | 100% 100% 100% | 41 (0.85) 45 (0.94) 45 (0.94) | | fbdd1efa | 37.0 | 100% 100% 100% 100% | 25 (0.68) 25 (0.68) 25 (0.68) 25 (0.68) | 100% 100% 100% | 25 (0.68) 26 (0.70) 25 (0.68) | 100% 100% 100% | 25 (0.68) 26 (0.70) 25 (0.68) | 100% 100% 100% 100% | 28 (0.76) 47 (1.27) 48 (1.30) 47 | 100% 100% 100% | 47 (1.27) 47 (1.27) 48 (1.30) | 100% 100% 100% | 48 (1.30) 53 (1.43) 49 (1.32) | | d2141ff2 | 113.0 | 100% 100% | 54 (0.48) 57 (0.50) | 100% 100% | 55 (0.49) 56 (0.50) | 100% 100% 100% | 55 (0.49) 56 (0.50) 53 (0.47) | 100% 100% 100% | (1.27) 107 (0.95) 109 (0.96) | 100% 100% | 107 (0.95) 106 (0.94) | 100% | 107 (0.95) 100 (0.88) | | 046dc081 | | 100% 100% | 57 (0.50) 55 (0.49) 58 (0.49) | 100% 100% | 53 (0.47) 60 (0.51) | 100% | 59 (0.50) 62 (0.53) | 100% 100% 100% | 101 (0.89) 107 (0.95) 118 (1.00) | 100% 100% 100% | 100 (0.88) 120 (1.02) | 100% 100% | 107 (0.95) | | | 118.0 | 100% 100% 100% 100% | 60 (0.51) 55 (0.47) 55 (0.47) 7 (0.88) | 100% 100% | 55 (0.47) 50 (0.42) | 100% 100% | 57 (0.48) 4 (0.50) | 100% 100% 100% | 120 (1.02) 119 (1.01) 120 (1.02) 6 (0.75) | 100% 100% | 116 (0.98) 120 (1.02) | 100% 100% 100% | 119 (1.01) 120 (1.02) 119 (1.01) | | 006b2fb6 | 8.0 | 100% 100% 9 100% 100% | (1.12) 4 (0.50) 6 (0.75) | 100% 100% 100% | 6 (0.75) 6 (0.75) 6 (0.75) | 100% 100% 100% | 4 (0.50) 4 (0.50) | 100% 100% 100% | 6 (0.75) 8 (1.00) 6 (0.75) | 100% 100% | 6 (0.75) 6 (0.75) 9 (1.12) | 100% 100% 100% | 6 (0.75) 6 (0.75) 6 (0.75) | Answer to RQ3 : Our algorithms synthesize WebAssembly cryptojacking variants that fully evade our malware oracle and that provide the same functionality as the original. The execution of evading malware systematically produces valid hashes, and the variations in performance are imperceptible. For 19% of the generated variants, we observe better performance, and in the worst case, the generated variant underperforms by five times the original binary. ## 6.4. RQ4. Individual Transformation Effectiveness In Figure 6 we plot the distribution of transformations applied by the MCMC evasion algorithm with = 1 : 1 when With RQ4, we investigate what individual transformations are the most appropriate to generate evading malware variants. Both attackers and defenders can leverage this information as follows. On the one hand, attackers know which transformation operators they can discard to speedup the search for evading malware and minimize calls to the oracle. On the other hand, defenders can focus on the most effective transformations to evade antiviruses. For example, one way to defend against evasion is to use transformation as a preprocessing stage prior to detection. This can help to ensure that detection is more robust to potential evasion vectors. it generates variants that fully evade the VirusTotal oracle. On the x-axis, we provide the name of the transformation, as wasm-mutate implements them. The y-axis is the absolute number of transformations found among the generated variants. The transformations are sorted in decreasing order of usage in the variants. We use two colors for transformations: transformations that affect the execution of the binary (in blue color) and transformations that do not (in orange color). For example, adding a new type definition does not affect the execution of the binary, while a peephole transformation does. Transformations remove function and remove type also affect malware detection. This novel observation indicates First, we concentrate on non-behavioral transformations in orange. The most effective transformation is to add a random function, which is present 117 times in the evading binaries. The next most present structural transformation is the modify custom section transformation. This highlights the sensitivity of malware detectors to the custom section. We note that custom section modification at the bytecode level provides advantages against source code obfuscation because we are sure that the compiler does not add metadata information that would help malware detectors. In other words, metadata information injected by compilers into WebAssembly binaries [22], could be removed from being part of possible detection. Figure 5: Distribution of the number of hashes per second for the variants generated for the original fbdd1efa cryptojacking. In the figure we include the original binary (in blue), ten variants generated by the baseline algorithm (in orange), and ten variants generated by the MCMC evasion algorithm (in green). ## fbddlefa <details> <summary>Image 7 Details</summary>  ### Visual Description \n ## Chart: Performance Comparison of Hashing Algorithms ### Overview The image presents a comparative performance analysis of three hashing algorithms: "Original h/s", "Baseline h/s", and "MCMC h/s". The performance metric is "Number of hashes per second". The data is visualized using a series of horizontal lines, each representing a single measurement or trial, with the length of the line indicating the range of values observed. The chart uses a violin-like representation for each data point, showing the distribution of values. ### Components/Axes * **Title:** ibdd1ela (appears at the top-center) * **Y-axis:** Categorical labels representing the hashing algorithms: "Original h/s", "Baseline h/s", and "MCMC h/s". These are arranged vertically from top to bottom. * **X-axis:** "Number of hashes per second", ranging from 0 to 60. * **Data Representation:** Horizontal lines (violin plots) representing the distribution of hash rates for each algorithm. * **Colors:** * Original h/s: Light Blue * Baseline h/s: Orange * MCMC h/s: Light Green ### Detailed Analysis The chart is divided into three horizontal sections, one for each hashing algorithm. Each section contains multiple horizontal lines representing individual measurements. **Original h/s:** * The data points are clustered around approximately 30 hashes per second. * The lines are relatively short, indicating a narrow range of values. * Approximate values (reading from left to right of the line): 28, 30, 31, 32, 33, 34, 35 hashes per second. **Baseline h/s:** * The data points are spread over a wider range, from approximately 20 to 40 hashes per second. * The lines are longer than those for "Original h/s", indicating greater variability. * Approximate values: 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40 hashes per second. **MCMC h/s:** * The data points are concentrated between approximately 40 and 60 hashes per second. * The lines are of varying lengths, suggesting some variability in the measurements. * Approximate values: 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60 hashes per second. ### Key Observations * "MCMC h/s" consistently achieves the highest hash rates, significantly outperforming both "Original h/s" and "Baseline h/s". * "Original h/s" exhibits the least variability in performance. * "Baseline h/s" shows the widest range of hash rates. * There is no overlap in the distributions of the three algorithms. ### Interpretation The chart demonstrates a clear performance advantage for the "MCMC h/s" algorithm in terms of hashing speed. The consistent high hash rates and relatively contained variability suggest that "MCMC h/s" is a more reliable and efficient hashing method compared to the "Original h/s" and "Baseline h/s" algorithms. The "Original h/s" algorithm, while slower, provides a more stable performance. The "Baseline h/s" algorithm is the most variable, indicating potential inconsistencies or dependencies on external factors. The lack of overlap between the distributions suggests that the differences in performance are statistically significant. The title "ibdd1ela" is likely a test identifier or a specific configuration under which these hashing algorithms were evaluated. The chart provides a quantitative comparison of the hashing algorithms, allowing for informed decision-making regarding their implementation in a specific application. </details> Figure 6: Distribution of applied transformation for the MCMC evasion algorithm with = 1 : 1 (low acceptance). The x-axis displays the names of the transformations. The y-axis indicates the number of transformations found in the generated variants. We can observe which transformations perform better in order to provide total evasion. <details> <summary>Image 8 Details</summary>  ### Visual Description \n ## Bar Chart: Refactoring Operation Counts ### Overview The image presents a bar chart comparing the counts of different refactoring operations. The x-axis lists the refactoring operation names, and the y-axis represents the number of times each operation was performed. Two distinct colors are used to represent the different refactoring operations. ### Components/Axes * **X-axis:** Refactoring Operation (Categorical) * Labels: "peephole mutation", "add function", "codemotion", "modify custom section", "add type", "remove type", "remove function" * **Y-axis:** Count (Numerical, ranging from 0 to 400, increments of 50) * **Bar Colors:** * Blue: Represents some refactoring operations. * Orange: Represents other refactoring operations. ### Detailed Analysis The chart displays the following counts for each refactoring operation: * **peephole mutation:** 378.00 (Blue bar, tallest in the chart) * **add function:** 117.00 (Orange bar) * **codemotion:** 108.00 (Blue bar) * **modify custom section:** 101.00 (Orange bar) * **add type:** 60.00 (Orange bar) * **remove type:** 22.00 (Orange bar) * **remove function:** 8.00 (Orange bar, shortest in the chart) The blue bars represent "peephole mutation" and "codemotion", while the orange bars represent "add function", "modify custom section", "add type", "remove type", and "remove function". ### Key Observations * "peephole mutation" is by far the most frequent refactoring operation, with a count significantly higher than all others. * "remove function" is the least frequent refactoring operation. * The counts generally decrease from left to right, with some fluctuations. * The orange bars generally have lower counts than the blue bars, except for "add function" which is higher than "codemotion". ### Interpretation The data suggests that "peephole mutation" is a dominant refactoring activity, potentially indicating a focus on code optimization or simplification. The relatively low counts for "remove function" and "remove type" might suggest that the codebase is generally stable in terms of function and type definitions. The difference in counts between the blue and orange bars could indicate different categories of refactoring, with "peephole mutation" and "codemotion" being more common than the others. The chart provides a quantitative overview of the types of refactoring operations being performed, which can be useful for understanding code evolution patterns and identifying areas for improvement in the refactoring process. The large difference in the "peephole mutation" count compared to the others suggests it may be an automated process or a very common optimization step. </details> that VirusTotal is looking for code common in malware yet dead code. For example, malware detectors probably check for code that does not affect the original functionality of the binary. Thus, if this information is removed, the detector misses the malware. In other terms, by removing code, the detection surface is reduced. The most significant transformation to generate evading malware consists of peephole transformations (the largest bar of the figure at the left-hand side of the figure). The peephole transformations operate at the bytecode instruction level. For example, in Listing 4 and Listing 5 we show a piece of the binary 089a3645c , and one peephole transformation applied, respectively. The transformation in the listings corresponds to a variant generated with the MCMC evasion algorithm. Only this transformation is required to fully evade for the 089a3645c binary. Ourresults show that malware detectors should prioritize the detection of peephole transformations in WebAssembly, to increase the likelihood of detecting cryptojacking. For example, the transformation of Listing 5 can be reversed with static analysis. ... Listing 5: Peephole mutations of Listing 4. Only with this mutation VirusTotal passed from 2 initial detectors to 0 in our experiments. Listing 4: Original piece of code for the 089a3645c WebAssembly binary. <details> <summary>Image 9 Details</summary>  ### Visual Description \n ## Code Snippets: WASM Instructions ### Overview The image presents two columns of code snippets, likely representing WebAssembly (WASM) instructions. The code appears to be low-level, focusing on memory access, constant definitions, and arithmetic operations. The snippets are not complete programs but rather fragments of a larger WASM module. ### Components/Axes There are no axes or legends in this image. The components are individual lines of WASM instructions. The snippets are separated by "..." indicating omitted code. ### Detailed Analysis or Content Details **Left Column:** * `local.get 0`: Retrieves the value from local variable index 0. * `i32.const 4`: Pushes the 32-bit integer constant 4 onto the stack. * `i32.add`: Pops two values from the stack, adds them, and pushes the result back onto the stack. **Right Column:** * `local.get 0`: Retrieves the value from local variable index 0. * `i64.const -461681990785514485`: Pushes the 64-bit integer constant -461681990785514485 onto the stack. * `drop`: Removes the top value from the stack. * `i32.const 0`: Pushes the 32-bit integer constant 0 onto the stack. * `i32.shr_u`: Pops a value from the stack, performs an unsigned right shift, and pushes the result back onto the stack. * `i32.const 4`: Pushes the 32-bit integer constant 4 onto the stack. * `i32.add`: Pops two values from the stack, adds them, and pushes the result back onto the stack. ### Key Observations The right column contains a large constant value and a `drop` instruction, suggesting a potential calculation or manipulation of a large number followed by discarding a result. The `i32.shr_u` instruction indicates an unsigned right bit shift operation. The left column performs a simple addition of a local variable and the constant 4. ### Interpretation These code snippets likely represent parts of a function within a WASM module. The left column might be a simple increment operation. The right column appears to be more complex, potentially involving a large constant, a bit shift, and an addition. The `drop` instruction suggests that a value is being calculated but not used in subsequent operations. Without the surrounding context, it's difficult to determine the exact purpose of these instructions. The use of both `i32` and `i64` constants suggests the module handles both 32-bit and 64-bit integer values. The code is likely related to memory manipulation or arithmetic calculations within a WASM application. </details> When we answer our four research questions, we generate WebAssembly cryptominer variants by adding one transformation at a time (See subsection 4.3). This method allows us to answer our research questions at a fine-grained level. For instance, the answer to RQ4 could only be possible if the transformations are analyzed one by one in the evasion process. Now, our method can be easily tuned to one-shot evasion: the algorithms could apply multiple transformations simultaneously to produce evading malware in one iteration. Consequently, the evasion process proposed in this work could be faster and more practical for a potential attacker. On the other hand, our algorithms stop as soon as one binary is diversified enough to provide total evasion. Since the overhead introduced by wasm-mutate is imperceptible, the transformation process can generate remarkably more binaries. Our approaches could escalate to infinite cryptojacking variants. Answer to RQ4 : Our experiments reveal that peephole transformations are the most effective for WebAssembly cryptojacking malware evasion. We also show that transformations on non-executable parts of WebAssembly binaries can contribute to evasion. These novel observations are crucial for cryptojacking malware detector vendors to prioritize their work on improving malware detection. ## 6.5. RQ5. Effectiveness against MINOS To evaluate the effectiveness of MINOS at detecting diversified malware, we reuse the protocol of RQ1. We repeat- Table 5: The table provides the identifier of the program as its sha256 hash value and the mean number of iterations required to totally evade MINOS. Each binary was mutated with the baseline algorithm 10 times. | Hash | Mean #trans. | Hash | Mean #trans. | |----------|----------------|----------|----------------| | 24aae13a | 980 | 000415b2 | 960.0 | | 59955b4c | 38 | 119c53eb | 1.0 | | fb15929f | 1 | 5bc53343 | 33.0 | | 47d29959 | 100 | dc11d82d | 115.0 | | a27b45ef | 33 | 006b2fb6 | 1.0 | | 942be4f7 | 29 | 7c36f462 | 85.0 | | 0d996462 | 24 | 15b86a25 | 1.0 | | 8ebf4e44 | 92 | a74a7cb8 | 38.0 | | fbdd1efa | 1 | 089dd312 | 68.0 | | 65debcbe | 38 | aafff587 | 1.0 | | 046dc081 | 33 | 6b8c7899 | 38.0 | | a32a6f4b | 1 | d2141ff2 | 81.0 | | 68ca7c0e | 38 | dceaf65b | 66.0 | | 9d30e7f0 | 419 | 4cbdbbb1 | 1.0 | | 643116ff | 47 | c1be4071 | 38.0 | | e09c32c5 | 15 | f0b24409 | 33.0 | | 89a3645c | 108 | | | edly stack random mutations to the original malware binary until MINOS is fully evaded or the maximum number of iterations is reached. We repeat this process 10 times for each binary. The results of our experiment are presented in Table 5. The table provides the identifier of the program and the mean number of iterations required to synthesize a variant that fully evades MINOS. Remarkably, this experiment shows that WebAssembly diversification requires fewer iterations to evade MINOS than VirusTotal, meaning that it is easier to evade MINOS. The minimum number of iterations needed overall for evading VirusTotal are 118 for the baseline algorithm Table 2 and 11 for the MCMC algorithm Table 3, while for MINOS, wasm-mutate totally evades detection for 8 out of 33 binaries in one single iteration. This shows that the MINOS model is fragile wrt binary diversification. According to those results, VirusTotal can be considered better than MINOS wrt to cryptojacking detection. Our technique completely evades MINOS in all cases. In 2 cases out of 33, wasm-mutate needs more than 900 iterations to evade MINOS. The main reason is the application of symmetric mutations. For example, in some cases, wasmmutate performs mutations that copy parts of the binary to another program location. Thus, when the binary is turned into a grayscale image, the embedding of the image is preserved, i.e., the code has changed, but the shape of the image has not. The contrary happens when non-symetric mutations are applied. For example, removing functions also removes embeddings of the grayscale image used by MINOS. To further enhance the detection capabilities of MINOS, we believe in binary canonicalization [9]. By creating a canonical representation of the malware variant before training and inference, one would help the classifier to better generalize. This is feasible as it is a preprocessing step in the pipeline. We believe this is an interesting direction for future work. Answer to RQ5 : Our approach fully evades detection by the WebAssembly antivirus MINOS. In our study, we achieve evasion for all cryptojacking binaries in our dataset. wasm-mutate needs fewer iterations to totally evade MINOS compared to VirusTotal, validating VirusTotal as a baseline. ## 7. Discussion Dataset size: The dataset is smaller than other similar works for malware evasion. However, the related work does not consider WebAssembly - e.g. Ling et al. [31] focus on Windows. For example, while Tekiner and colleagues consider cryptojacking [50], we entirely focus only on WebAssembly cryptojacking malware. In this context, to the best of our knowledge, wasmbench is the most complete dataset of WebAssembly binaries. We analyze this dataset through the lens of VirusTotal and systematically extract all the cryptojacking malware it includes. Despite novelty, we acknowledge that the limited size of our malware dataset poses a challenge in terms of the generalizability of our results. Some types of malware might be absent from our dataset. To address this issue, one solution for future work would consist in expanding the dataset by using the inherent diversity found within the popular Cryptonight library. One could utilize the release history of their GitHub repository to compile and mine distinct, yet semantically equivalent malware instances. This approach would entail the exploration of a broader range of variations of cryptojacking malware Yet, this is considered as a new research paper per se as the process of mining and compiling code from a repository's release history is both time-consuming and computationally demanding. This is due to the need to analyze, filter, and compare a vast number of code commits and releases, as well as to validate their semantic equivalence. This process is even more complex in the case of malware reproduction due to the complex architecture in which this type of software operates (cf. Figure 1.) In this section, we discuss the key challenges we faced, in order to help future research projects on similar topics. VirusTotal Observations: The final labelling of binaries for VirusTotal vendors is not definitive [57]. For example, a VirusTotal vendor could label a binary as benign and change it later to malign after several weeks. This phenomenon creates a time window in which slightly changed binaries (fewer iterations in our case) sometives evade the detection of numerous vendors. Also, we have observed that when our evasion algorithms manage to evade, some VirusTotal vendors result in timeout in several cases. This suggests that the evasion effectiveness is also due to performance constraints on the VirusTotal side. Lack of abstraction: AWebAssembly cryptojacking can only exist with its web complements. As we previously discussed, a browser cryptojacking needs to send the calculated hashes to a cryptocurrency service. This network communication is outside the WebAssembly accesses and needs to be delegated to a JavaScript code. We have observed that, the imports and the memory data of the WebAssembly binaries have a high variability in our dataset. The imported functions from JavaScript change from binary to binary. Their data segments also differ in content and length. This suggests that the whole JavaScript-WebAssembly polyglot package is the right direction for cryptojacking detection. Mitigation: As we noted in our response to RQ4 and RQ5, we believe that code canonicalization and is a promising mitigation technique if they are applied directly to WebAssembly. One way to do this would be to modify a diversifier such as wasm-mutate into a binary optimizer completely based on e-graph. This would provide canonicalization through a compact representation of WebAssembly code. In turn, malware variants with the same ancestor would be more seen as the 'same' program, from its canonical representation. ## 8. Conclusion Asfuture work, we will improve the evasion fitness functions by including malware program properties, w.r.t. both evasion and malware execution performance. Some argue that the future of malware detection lies in machine learning. In future work, we believe in using our diversification technique to provide data augmentation for better malware detection. We have demonstrated the potential for WebAssembly cryptojacking malware to be diversified and evade detection by leading malware detectors, such as VirusTotal and MINOS. Our generated variants are functional, performant, and do not trigger malware detection. Our evaluation of the technique against 60 state-of-the-art antiviruses through the meta-tool VirusTotal highlights the superiority of metaantiviruses over single tailored defenses, even when the latter are specifically designed for WebAssembly cryptojacking binaries such as MINOS. By studying effective code transformations for evading cryptojacking detection, our work provides valuable insights and guidance for researchers in the field to better mitigate evasion. ## References - [2] Aghakhani, H., Gritti, F., Mecca, F., Lindorfer, M., Ortolani, S., Balzarotti, D., Vigna, G., Kruegel, C., 2020. When malware is packin' heat; limits of machine learning classifiers based on static analysis features, in: Proc. of NDSS. - [1] Afianian, A., Niksefat, S., Sadeghiyan, B., Baptiste, D., 2019. Malware dynamic analysis evasion techniques: A survey. ACM Comput. Surv. 52. URL: https://doi : org/10 : 1145/3365001 , doi: 10 : 1145/3365001 . - [3] Aslan, O.A., Samet, R., 2020. A comprehensive review on malware detection approaches. IEEE Access 8, 6249-6271. doi: 10 : 1109/ ACCESS : 2019 : 2963724 . - [5] Bian, W., Meng, W., Zhang, M., 2020. Minethrottle: Defending against wasm in-browser cryptojacking, in: Proceedings of The Web Conference 2020, Association for Computing Machinery. URL: https://doi : org/10 : 1145/3366423 : 3380085 , doi: 10 : 1145/ 3366423 : 3380085 . - [4] Bhansali, S., Aris, A., Acar, A., Oz, H., Uluagac, A.S., 2022. A first look at code obfuscation for webassembly, in: Proc. of Conf. on Security and Privacy in Wireless and Mobile Networks. doi: 10 : 1145/ 3507657 : 3528560 . - [6] Bostani, H., Moonsamy, V., 2021. Evadedroid: A practical evasion attack on machine learning for black-box android malware detection. CoRR abs/2110.03301. URL: https://arxiv : org/abs/2110 : 03301 , arXiv:2110.03301 . - [8] Botacin, M., Domingues, F.D., Ceschin, F., Machnicki, R., Zanata Alves, M.A., de Geus, P.L., Grégio, A., 2022. Antiviruses under the microscope: A hands-on perspective. Computers & Security 112. URL: https://www : sciencedirect : com/science/article/pii/ S0167404821003242 , doi: https://doi : org/10 : 1016/j : cose : 2021 : 102500 . - [7] Botacin, M., Ceschin, F., de Geus, P., Grégio, A., 2020. We need to talk about antiviruses: challenges & pitfalls of av evaluations. Computers & Security 95. URL: https: //www : sciencedirect : com/science/article/pii/S0167404820301310 , doi: https://doi : org/10 : 1016/j : cose : 2020 : 101859 . - [9] Bruschi, D., Martignoni, L., Monga, M., 2007. Code normalization for self-mutating malware. IEEE Security & Privacy 5, 46-54. doi: 10 : 1109/MSP : 2007 : 31 . - [11] Cabrera Arteaga, J., Laperdrix, P., Monperrus, M., Baudry, B., 2022. Multi-variant execution at the edge, in: Proceedings of the 9th ACM Workshop on Moving Target Defense, Association for Computing Machinery. URL: https://doi : org/10 : 1145/3560828 : 3564007 , doi: 10 : 1145/3560828 : 3564007 . - [10] Bytecodealliance, 2021. wasm-mutate. URL: https://github : com/ bytecodealliance/wasm-tools/tree/main/crates/wasm-mutate . - [12] Cabrera-Arteaga, J., Malivitsis, O.F., Pérez, O.L.V., Baudry, B., Monperrus, M., 2021. Crow: Code diversification for webassembly, in: Proceedings of MadWEB. doi: 10 : 14722/madweb : 2021 : 23xxx . - [14] Chua, M., Balachandran, V., 2018. Effectiveness of android obfuscation on evading anti-malware, in: Proceedings of the Eighth ACM Conference on Data and Application Security and Privacy, Association for Computing Machinery. URL: https://doi : org/10 : 1145/ 3176258 : 3176942 , doi: 10 : 1145/3176258 : 3176942 . - [13] Castro, R.L., Schmitt, C., Dreo, G., 2019. Aimed: Evolving malware with genetic programming to evade detection, in: 2019 18th IEEE International Conference On Trust, Security And Privacy In Computing And Communications/13th IEEE International Conference On Big Data Science And Engineering (TrustCom/BigDataSE), IEEE. pp. 240-247. - [15] Cohen, F.B., 1993. Operating system protection through program evolution. Computers & Security 12, 565-584. - [17] Demetrio, L., Biggio, B., Lagorio, G., Roli, F., Armando, A., 2021. Functionality-preserving black-box optimization of adversarial windows malware. IEEE Transactions on Information Forensics and Security 16, 3469-3478. - [16] Dasgupta, P., Osman, Z., 2021. A Comparison of State-of-the-Art Techniques for Generating Adversarial Malware Binaries. arXiv eprints arXiv:2111.11487 . - [18] Egele, M., Scholte, T., Kirda, E., Kruegel, C., 2008. A survey on automated dynamic malware-analysis techniques and tools. ACM Comput. Surv. 44. URL: https://doi : org/10 : 1145/2089125 : 2089126 , doi: 10 : 1145/2089125 : 2089126 . - [20] Haas, A., Rossberg, A., Schuff, D.L., Titzer, B.L., Holman, M., Gohman, D., Wagner, L., Zakai, A., Bastien, J., 2017. Bringing the web up to speed with WebAssembly, in: Proceedings of the 38th ACM SIGPLAN Conference on Programming Language Design and Implementation. - [19] GoogleLLC, 2022. Virustotal enterprise. URL: https:// assets : virustotal : com/vt-360-outcomes : pdf . - [21] Hastings, W.K., 1970. Monte carlo sampling methods using markov chains and their applications. Biometrika 57. URL: http:// www : jstor : org/stable/2334940 . - [23] Kalash, M., Rochan, M., Mohammed, N., Bruce, N.D.B., Wang, Y., Iqbal, F., 2018. Malware classification with deep convolutional neural networks, in: 2018 9th IFIP International Conference on New Technologies, Mobility and Security (NTMS), pp. 1-5. doi: 10 : 1109/ - [22] Hilbig, A., Lehmann, D., Pradel, M., 2021. An empirical study of real-world webassembly binaries: Security, languages, use cases. Proceedings of the Web Conference 2021 . ## NTMS : 2018 : 8328749 . - [25] Kelton, C., Balasubramanian, A., Raghavendra, R., Srivatsa, M., 2020. Browser-based deep behavioral detection of web cryptomining with coinspy, in: Workshop on Measurements, Attacks, and Defenses for the Web (MADWeb) 2020, pp. 1-12. - [24] Kaspersky, 2022. The state of cryptojacking in the first three quarters of 2022. URL: https://securelist : com/cryptojacking-report-2022/ 107898/ . - [26] Kharraz, A., Ma, Z., Murley, P., Lever, C., Mason, J., Miller, A., Borisov, N., Antonakakis, M., Bailey, M., 2019. Outguard: Detecting in-browser covert cryptocurrency mining in the wild, in: The World Wide Web Conference, Association for Computing Machinery. URL: https://doi : org/10 : 1145/3308558 : 3313665 , doi: 10 : 1145/ 3308558 : 3313665 . - [28] Lachtar, N., Ibdah, D., Khan, H., Bacha, A., 2023. Ransomshield: A visualization approach to defending mobile systems against ransomware. ACM Trans. Priv. Secur. 26. URL: https://doi : org/ 10 : 1145/3579822 , doi: 10 : 1145/3579822 . - [27] Konoth, R.K., Vineti, E., Moonsamy, V., Lindorfer, M., Kruegel, C., Bos, H., Vigna, G., 2018. Minesweeper: An in-depth look into drive-by cryptocurrency mining and its defense. doi: 10 : 1145/ 3243734 : 3243858 . - [29] Le, V., Afshari, M., Su, Z., 2014. Compiler validation via equivalence modulo inputs, in: Proceedings of the 35th ACM SIGPLAN Conference on Programming Language Design and Implementation, Association for Computing Machinery. URL: https://doi : org/10 : 1145/ 2594291 : 2594334 , doi: 10 : 1145/2594291 : 2594334 . - [31] Ling, X., Wu, L., Zhang, J., Qu, Z., Deng, W., Chen, X., Qian, Y., Wu, C., Ji, S., Luo, T., et al., 2023. Adversarial attacks against windows pe malware detection: A survey of the state-of-the-art. Computers & Security , 103134. - [30] Li, D., Li, Q., Ye, Y.F., Xu, S., 2021. Arms race in adversarial malware detection: A survey. ACM Comput. Surv. 55. URL: https://doi : org/10 : 1145/3484491 , doi: 10 : 1145/3484491 . - [32] Liu, L., Wang, B., 2016. Malware classification using gray-scale images and ensemble learning, in: 2016 3rd International Conference on Systems and Informatics (ICSAI), pp. 1018-1022. doi: 10 : 1109/ ICSAI : 2016 : 7811100 . - [34] Lu, L., Yegneswaran, V., Porras, P., Lee, W., 2010. Blade: an attack-agnostic approach for preventing drive-by malware infections, in: Proceedings of the 17th ACM conference on Computer and communications security, pp. 440-450. - [33] Lu, G., Debray, S.K., 2013. Weaknesses in defenses against web-borne malware -(short paper), in: Rieck, K., Stewin, P., Seifert, J. (Eds.), Detection of Intrusions and Malware, and Vulnerability Assessment -10th International Conference, DIMVA. Proceedings. URL: https://doi : org/10 : 1007/978-3-642-39235-1\_8 , doi: 10 : 1007/978-3-642-39235-1\_8 . - [35] Lundquist, G.R., Mohan, V., Hamlen, K.W., 2016. Searching for software diversity: attaining artificial diversity through program synthesis, in: Proceedings of the 2016 New Security Paradigms Workshop, pp. 80-91. - [37] Moser, A., Kruegel, C., Kirda, E., 2007. Limits of static analysis for malware detection, in: Twenty-Third Annual Computer Security Applications Conference (ACSAC 2007), pp. 421-430. doi: 10 : 1109/ ACSAC : 2007 : 21 . - [36] Monero, 2022. Monero. URL: https://www : getmonero : org/ . - [38] Mozilla, 2019. Protections Against Fingerprinting and Cryptocurrency Mining Available in Firefox Nightly and Beta . URL: https://blog : mozilla : org/futurereleases/2019/04/09/protectionsagainst-fingerprinting-and-cryptocurrency-mining-available-infirefox-nightly-and-beta/ . - [40] Musch, M., Wressnegger, C., Johns, M., Rieck, K., 2019a. New Kid on the Web: A Study on the Prevalence of WebAssembly in the Wild. doi: 10 : 1007/978-3-030-22038-9\_2 . - [39] Mozilla, 2022. Using web workers. URL: https: //developer : mozilla : org/en-US/docs/Web/API/Web\_Workers\_API/ Using\_web\_workers . - [41] Musch, M., Wressnegger, C., Johns, M., Rieck, K., 2019b. Thieves in the browser: Web-based cryptojacking in the wild, in: Proceedings of the 14th International Conference on Availability, Reliability and Security, Association for Computing Machinery. URL: https: //doi : org/10 : 1145/3339252 : 3339261 , doi: 10 : 1145/3339252 : 3339261 . - [43] Payer, M., 2014. Embracing the new threat: Towards automatically self-diversifying malware, in: The Symposium on Security for Asia Network, pp. 1-5. - [42] Naseem, F., Aris, A., Babun, L., Uluagac, S., Tekiner, E., 2021. MINOS: A Lightweight Real-Time Cryptojacking Detection System. Ndss URL: https://www : ndss-symposium : org/wp-content/uploads/ ndss2021\_4C-4\_24444\_paper : pdf , doi: 10 : 14722/NDSS : 2021 : 24444 . - [44] Peng, P., Yang, L., Song, L., Wang, G., 2019. Opening the blackbox of virustotal: Analyzing online phishing scan engines, in: Proceedings of the Internet Measurement Conference, Association for Computing Machinery. URL: https://doi : org/10 : 1145/3355369 : 3355585 , doi: 10 : 1145/3355369 : 3355585 . - [46] Rokicki, T., Maurice, C., Botvinnik, M., Oren, Y., 2022. Port contention goes portable: Port contention side channels in web browsers, in: Proceedings of the 2022 ACM on Asia Conference on Computer and Communications Security, Association for Computing Machinery. URL: https://doi : org/10 : 1145/3488932 : 3517411 , doi: 10 : 1145/ 3488932 : 3517411 . - [45] Ren, X., Ho, M., Ming, J., Lei, Y., Li, L., 2021. Unleashing the hidden power of compiler optimization on binary code difference: An empirical study, in: Proceedings of the 42nd ACM SIGPLAN International Conference on Programming Language Design and Implementation, Association for Computing Machinery. URL: https: //doi : org/10 : 1145/3453483 : 3454035 , doi: 10 : 1145/3453483 : 3454035 . - [47] Romano, A., Lehmann, D., Pradel, M., Wang, W., 2022. Wobfuscator: Obfuscating javascript malware via opportunistic translation to webassembly, in: Proceedings of the 2022 IEEE Symposium on Security and Privacy (S&P 2022), pp. 1101-1116. - [49] Schkufza, E., Sharma, R., Aiken, A., 2012. Stochastic superoptimization. ACM SIGPLAN Notices 48. doi: 10 : 1145/2451116 : 2451150 . - [48] Romano, A., Zheng, Y., Wang, W., 2020. Minerray: Semanticsaware analysis for ever-evolving cryptojacking detection, in: 2020 35th IEEE/ACM International Conference on Automated Software Engineering (ASE), pp. 1129-1140. - [50] Tekiner, E., Acar, A., Uluagac, A.S., Kirda, E., Selcuk, A.A., 2021. In-browser cryptomining for good: An untold story, in: 2021 IEEE International Conference on Decentralized Applications and Infrastructures (DAPPS), pp. 20-29. doi: 10 : 1109/DAPPS52256 : 2021 : 00008 . - [52] Wang, W., Ferrell, B., Xu, X., Hamlen, K.W., Hao, S., 2018. Seismic: Secure in-lined script monitors for interrupting cryptojacks, in: Lopez, J., Zhou, J., Soriano, M. (Eds.), Computer Security, Springer International Publishing, Cham. pp. 122-142. - [51] VirusTotal, 2020. VirusTotal -Home. URL: https:// www : virustotal : com/gui/home/search . - [53] Wang, W., Sun, R., Dong, T., Li, S., Xue, M., Tyson, G., Zhu, H., 2021. Exposing weaknesses of malware detectors with explainabilityguided evasion attacks. arXiv preprint arXiv:2111.10085 . - [55] Xia, M., Gong, L., Lyu, Y., Qi, Z., Liu, X., 2015. Effective realtime android application auditing, in: Proceedings of the 2015 IEEE Symposium on Security and Privacy, IEEE Computer Society. - [54] Willsey, M., Nandi, C., Remy Wang, Y., Flatt, O., Tatlock, Z., Panchekha, P., 2020. egg: Fast and Extensible Equality Saturation. arXiv e-prints arXiv:2004.03082 . - [56] XMRIG, 2016. Xmrig. URL: https://github : com/xmrig/xmrig . - [57] Zhu, S., Shi, J., Yang, L., Qin, B., Zhang, Z., Song, L., Wang, G., 2020. Measuring and modeling the label dynamics of online AntiMalware engines, in: 29th USENIX Security Symposium (USENIX Security 20), USENIX Association. URL: https://www : usenix : org/ conference/usenixsecurity20/presentation/zhu .