AndroWasm: an Empirical Study on Android Malware Obfuscation through WebAssembly

Título: AndroWasm: Um Estudo Empírico sobre Obfuscação de Malware Android através de WebAssembly

1. Problema e Motivação

O ecossistema Android enfrenta uma ameaça crescente de malware sofisticado que utiliza técnicas avançadas para contornar mecanismos de detecção automática e dificultar a análise manual. Os adversários recorrem tradicionalmente a obfuscação, anti-reempacotamento, esteganografia e evasão de ferramentas baseadas em IA. No entanto, muitas dessas técnicas são bem conhecidas e facilmente identificáveis.

O WebAssembly (Wasm) surge como uma nova fronteira de risco. Originalmente projetado para executar código de alto desempenho em navegadores (jogos, renderização 3D), o Wasm é um formato binário portátil, seguro e rápido. Embora o Android tenha começado a suportar a execução de módulos Wasm (através de WebViews, JavaScript Engines e bibliotecas nativas), a maioria das ferramentas de segurança industriais (como VirusTotal e MobSF) não inspeciona adequadamente o código Wasm embutido. Isso cria um "ponto cego" onde payloads maliciosos podem ser escondidos dentro de binários Wasm, escapando da análise estática tradicional que foca no bytecode DEX (Java/Kotlin) e em strings legíveis.

2. Metodologia

Os autores investigaram a viabilidade de execução de Wasm em aplicativos Android e desenvolveram um modelo de ameaça para demonstrar como ele pode ser usado para obfuscação. A metodologia dividiu-se em três etapas principais:

• Análise de Metodologias de Execução: O estudo identificou três formas principais de integrar e executar Wasm em um APK:

  1. WebViews: O módulo Wasm é carregado em uma página HTML dentro de um componente WebView (usando o motor V8/Chromium). A comunicação ocorre via pontes JavaScript-Java.
  2. Motores JavaScript Standalone: O APK embute um motor JS (como o androidx.JavaScriptEngine) que compila e executa o Wasm sem a necessidade de uma interface HTML.
  3. Bibliotecas Nativas (WasmEdge): O aplicativo carrega uma biblioteca nativa (C/C++) que contém um runtime Wasm (como o WasmEdge), permitindo a execução direta via JNI (Java Native Interface), sem a camada intermediária do JavaScript.

• Desenvolvimento de Provas de Conceito (PoC): Foram criados dois exemplos de malware modificados para usar Wasm:

  1. Ransomware: A lógica de criptografia (AES) foi totalmente movida para o módulo Wasm. O código Java/Kotlin apenas inicializa o ambiente e chama a função Wasm.
  2. Spyware: O payload (URL de exfiltração e lógica de envio) foi escondido no Wasm. O módulo Wasm importa funções do Android (via WASI/Host functions) para realizar a comunicação de rede, mantendo o código malicioso oculto no binário.

• Avaliação de Detecção: Os aplicativos originais e as versões modificadas com Wasm foram submetidos a ferramentas de análise estática e dinâmica, incluindo VirusTotal (VT) e MobSF, e comparados com amostras obfusadas usando técnicas tradicionais (Renomeação de Classes, Reflexão, Criptografia de Strings) via ferramenta Obfuscapk.

3. Contribuições Principais

• Mapeamento de Execução: Um estudo abrangente sobre como o Android pode embutir e gerenciar a execução de módulos Wasm, detalhando as três arquiteturas de integração (WebView, JS Engine, Native).
• Modelo de Ameaça Novos: Demonstração de que o Wasm pode ser usado não apenas para desempenho, mas como uma camada de obfuscação eficaz para esconder lógica maliciosa completa ou indicadores de comprometimento (IoCs).
• Evidência Empírica de Falha de Detecção: Prova de que ferramentas industriais de ponta falham em detectar malware quando a lógica central é movida para o Wasm, superando técnicas de obfuscação convencionais.

4. Resultados

Os resultados experimentais foram alarmantes para a segurança atual:

• Ransomware:
  • Versão Original: Detectada por 27 dos 66 motores de antivírus no VirusTotal.
  • Versão com Wasm: Detectada por apenas 7 motores.
  • Análise: As ferramentas de segurança falharam porque a lógica de criptografia não estava mais no bytecode DEX (analisável), mas sim no binário Wasm, que não é analisado por padrões. O MobSF também ignorou a lógica maliciosa.
• Spyware:
  • Versão Original: Detectada por 1 motor (classificada apenas como PUA - Potentially Unwanted Application).
  • Versão com Wasm: Detectada por 1 motor (mesmo resultado, mas por motivos diferentes).
  • Diferença Crítica: Na versão original, o URL malicioso (IoC) era visível no código. Na versão com Wasm, o URL estava escondido dentro do módulo Wasm e não foi detectado. Embora o MobSF tenha identificado o comportamento geral (leitura de arquivo, conexão de rede), ele não conseguiu ver o IoC específico (URL) que estava oculto.
• Comparação com Obfuscação Tradicional: Amostras obfusadas com técnicas clássicas (via Obfuscapk) foram detectadas por uma média de 14 motores, enquanto a abordagem baseada em Wasm mostrou-se significativamente mais sutil e eficaz na evasão.

5. Significância e Implicações

• Vulnerabilidade das Ferramentas Atuais: O estudo expõe uma lacuna crítica nas ferramentas de segurança móveis. Elas não tratam módulos Wasm como artefatos de segurança de primeira classe, assumindo erroneamente que toda a lógica maliciosa reside no código nativo ou DEX.
• Novo Vetor de Evasão: O Wasm oferece uma camada de abstração que quebra as pipelines de análise estática baseadas em padrões de código Java/Kotlin.
• Guia de Defesa: Os autores propõem diretrizes para detecção, incluindo:
  • Busca por arquivos .wasm ou bibliotecas nativas (ex: libwasmedge.so).
  • Análise de bytearrays no código Java/Kotlin que contenham a assinatura binária do Wasm (00 61 73 6D).
  • Inspecionar chamadas de API específicas que interagem com runtimes Wasm.
  • Uso de análise dinâmica (ex: hooking com Frida) para interceptar a execução do Wasm em tempo de execução.

Conclusão

O artigo "AndroWasm" alerta que a adoção crescente do WebAssembly no Android, embora benéfica para o desempenho de aplicativos legítimos, introduz um vetor de ataque poderoso para malware. Os adversários podem usar o Wasm para esconder payloads e IoCs, tornando-se invisíveis para a maioria das soluções de segurança atuais. A comunidade de segurança precisa urgentemente desenvolver ferramentas capazes de descompilar, analisar e monitorar o comportamento de módulos WebAssembly dentro do ecossistema Android.