AndroWasm: an Empirical Study on Android Malware Obfuscation through WebAssembly

TL;DR

This work investigates WebAssembly as a novel obfuscation layer for Android malware, examining how Wasm modules can be embedded and executed inside APKs to hide malicious payloads from traditional detectors. It systematically analyzes three execution modalities—WebView-based, standalone JavaScript engines, and native WasmEdge runtimes—and validates the approach with PoC ransomware and spyware cases that conceal critical IoCs from VirusTotal and MobSF. The study demonstrates tangible evasion of static detectors and argues that Wasm introduces a challenging, low-signature attack surface for current mobile security tooling, while offering practical defense guidelines. Overall, the paper highlights Wasm-based obfuscation as a feasible threat in Android ecosystems and calls for automated, scalable analysis pipelines and enhanced runtime-aware defenses to mitigate such concealment strategies.

Abstract

In recent years, stealthy Android malware has increasingly adopted sophisticated techniques to bypass automatic detection mechanisms and harden manual analysis. Adversaries typically rely on obfuscation, anti-repacking, steganography, poisoning, and evasion techniques to AI-based tools, and in-memory execution to conceal malicious functionality. In this paper, we investigate WebAssembly (Wasm) as a novel technique for hiding malicious payloads and evading traditional static analysis and signature-matching mechanisms. While Wasm is typically employed to render specific gaming activities and interact with the native components in web browsers, we provide an in-depth analysis on the mechanisms Android may employ to include Wasm modules in its execution pipeline. Additionally, we provide Proofs-of-Concept to demonstrate a threat model in which an attacker embeds and executes malicious routines, effectively bypassing IoC detection by industrial state-of-the-art tools, like VirusTotal and MobSF.

Figures (8)

• Figure 1: Wasm execution methodologies we studies. After compilation, it can be executed inside Android HTML WebViews and JS engines embedded there, inside a standalone JavaScript engine that spawns a Wasm runtime, and inside a standalone WasmEdge runtime and Java Native Interfaces to enable communication between native and Android.
• Figure 2: Android WebView with execution.
• Figure 3: Example of JS Sandbox with runtime instantiation and module execution. The name of the exported function to execute within JS Code is an argument to the function runWasmInJSEngine that can be called inside the Kotlin source code.
• Figure 4: Example of WasmEdge runtime instantiated to execute function taken from the official WasmEdge repository. fib is a function exported by the Wasm module.
• Figure 5: Ransomware example. Native library included in the ransomware sample with binary exporting the run function that init and encrypts data. run C++ implementation can be found in \ref{['app:ransomware:use_case']}.