AndroWasm: an Empirical Study on Android Malware Obfuscation through WebAssembly

1. El Problema

El ecosistema de Android es el objetivo más común de malware debido a su predominio global. Aunque existen técnicas de detección avanzadas (análisis estático, dinámico y basado en IA), los atacantes han evolucionado hacia métodos de ofuscación sofisticados para eludir estas defensas.

• Limitaciones actuales: Las técnicas tradicionales de ofuscación (cambio de nombres de variables, encriptación de cadenas, reflexión) son bien conocidas y detectadas por herramientas industriales como VirusTotal (VT) y MobSF.
• La brecha de seguridad: WebAssembly (Wasm) es un formato binario emergente, seguro y portátil, diseñado para ejecutarse a velocidad casi nativa. Aunque se usa comúnmente en navegadores web, su adopción en Android (a través de WebViews, motores JS y bibliotecas nativas) ha creado un "punto ciego".
• La amenaza: Los atacantes pueden utilizar Wasm para ocultar la lógica maliciosa dentro de un binario que las herramientas de análisis estático tradicionales no inspeccionan, ya que estas herramientas suelen centrarse en el código DEX (Java/Kotlin) y no en los módulos Wasm embebidos.

2. Metodología

Los autores investigaron la viabilidad de ejecutar Wasm en Android y diseñaron un modelo de amenaza para demostrar cómo se puede utilizar para ocultar malware.

A. Metodologías de Ejecución de Wasm en Android

El estudio identificó y analizó tres formas principales de integrar y ejecutar módulos Wasm dentro de una aplicación Android (APK):

1. WebViews: La APK carga una página HTML local o remota que contiene el código JavaScript necesario para instanciar y ejecutar el módulo Wasm. Es compatible pero introduce sobrecarga por el entorno del navegador.
2. Motores JavaScript (JS Engine): Se incrusta un motor JS (como V8 o androidx.JavaScriptEngine) directamente en la APK sin necesidad de una interfaz HTML. El código Java/Kotlin pasa los datos al motor JS, que compila y ejecuta el Wasm.
3. Bibliotecas Nativas (WasmEdge): Se utiliza un motor Wasm nativo (como WasmEdge) compilado como una biblioteca nativa (.so) y vinculado a la aplicación mediante JNI (Java Native Interface). Este método ofrece el menor overhead y el mayor control sobre el entorno de ejecución, ejecutando el Wasm directamente en el sistema nativo sin pasar por una capa intermedia de JS.

B. Desarrollo de Pruebas de Concepto (PoC)

Para validar la amenaza, los autores desarrollaron dos casos de estudio utilizando malware de código abierto modificado:

• Ransomware: Se reescribió la lógica de cifrado (AES) en C++ y se compiló a Wasm. El módulo Wasm se ejecuta para cifrar archivos, sin que la lógica de cifrado aparezca en el bytecode DEX de la aplicación.
• Spyware: Se ocultó la URL de exfiltración de datos dentro del módulo Wasm. El módulo Wasm llama a una función importada desde Kotlin (Java) para realizar la solicitud HTTP, manteniendo la lógica de la URL oculta en el binario Wasm.

3. Contribuciones Clave

1. Análisis de Viabilidad: Primer estudio exhaustivo sobre cómo Android puede embeber y gestionar la ejecución de módulos Wasm a través de sus tres vectores principales (WebView, JS Engine, Nativo).
2. Modelo de Amenaza: Demostración de que Wasm puede utilizarse como una capa de ofuscación superior a las técnicas tradicionales, ocultando tanto la lógica maliciosa como los Indicadores de Compromiso (IoC) como cadenas de texto y llamadas a APIs específicas.
3. Evaluación de Herramientas Industriales: Pruebas empíricas que demuestran la incapacidad de herramientas de estado del arte (VirusTotal y MobSF) para detectar malware cuando la lógica maliciosa se mueve a un módulo Wasm.

4. Resultados

Los experimentos arrojaron resultados alarmantes sobre la eficacia de la evasión:

• Ransomware:

  • Versión Original: Detectada por 27 de 66 motores antivirus en VirusTotal.
  • Versión con Wasm: Detectada por solo 7 de 66 motores.
  • Análisis: Las herramientas de análisis estático fallaron porque la lógica de cifrado ya no residía en el archivo DEX, sino en el binario Wasm, el cual no fue analizado o clasificado como malicioso.
  • Comparación: Las técnicas de ofuscación tradicionales (renombrado de clases, encriptación de cadenas) lograron una detección promedio de 14 motores, siendo Wasm significativamente más efectivo para eludir la detección.

• Spyware:

  • Versión Original: Detectada por 1 motor (clasificada como PUA).
  • Versión con Wasm: Detectada por 1 motor (clasificada como PUA).
  • Diferencia Crítica: En la versión original, VirusTotal detectó la URL maliciosa (IoC). En la versión con Wasm, la URL estaba oculta dentro del binario Wasm y no fue detectada.
  • Limitación: MobSF pudo detectar el comportamiento general (lectura de archivos, conexión de red) porque las definiciones de las APIs de Android seguían visibles en el código fuente, pero falló en identificar el IoC específico (la URL) oculto en Wasm.

5. Significado y Recomendaciones

• Impacto en Seguridad: Este estudio revela una vulnerabilidad crítica en los pipelines de análisis de seguridad actuales. Los atacantes pueden aprovechar Wasm para crear malware "invisible" para los escáneres estáticos convencionales, ya que estos no desensamblan ni interpretan el código Wasm.
• Guías de Detección Defensiva: Los autores proponen un nuevo flujo de trabajo para la detección estática y dinámica:
  1. Buscar archivos .wasm o bibliotecas nativas asociadas (ej. wasmedge).
  2. Analizar arrays de bytes en el código Java/Kotlin buscando la firma de Wasm (00 61 73 6D).
  3. Utilizar herramientas como wabt (wasm2wat, wasm-objdump) para descompilar y analizar el código Wasm en busca de patrones maliciosos.
  4. Emplear análisis dinámico (ej. con Frida) para interceptar la ejecución del runtime de Wasm y examinar la memoria en tiempo real.

Conclusión:
El artículo "AndroWasm" advierte que WebAssembly, aunque es una tecnología legítima para el rendimiento, se ha convertido en una herramienta poderosa para la ofuscación de malware en Android. La comunidad de seguridad debe adaptar sus herramientas para incluir el análisis de binarios Wasm como un componente estándar en la detección de amenazas móviles, ya que ignorar este formato deja una brecha significativa en la defensa contra malware avanzado.