Análise estática vs dinâmica de malware Android

Todo APK suspeito levanta uma pergunta operacional antes de qualquer pergunta técnica: basta ler o arquivo ou é preciso executar a amostra?

A análise estática examina o pacote sem executá-lo. A análise dinâmica instala a amostra em um dispositivo instrumentado e registra o que ela faz. As duas costumam ser apresentadas como abordagens concorrentes, ou como uma escada de maturidade em que a dinâmica seria o degrau "avançado". Nenhuma das duas leituras ajuda. Elas respondem perguntas diferentes, falham de formas diferentes, e a passagem de uma para a outra deve se apoiar em uma lacuna concreta da evidência, não no hábito.

Cada método estabelece fatos diferentes e para em um ponto diferente, e uma regra prática decide quando a execução acrescenta informação que o arquivo sozinho não consegue dar. É a pergunta que um analista de banco ou de fintech se faz quando um cliente encaminha um APK recebido por SMS ou WhatsApp, e também a que um time de AppSec se faz antes de assinar um relatório.

Dois métodos, duas perguntas diferentes

A análise estática responde o que o aplicativo é capaz de fazer. Ela lê o manifesto, o certificado de assinatura, o bytecode compilado, as bibliotecas nativas e os recursos embutidos, e informa capacidades: as permissões solicitadas, os componentes expostos, o código presente e a infraestrutura referenciada.

A análise dinâmica responde o que o aplicativo realmente fez, neste dispositivo, nesta execução. Ela observa conexões de rede, gravações em disco, acesso a SMS, strings decifradas e atividade na tela enquanto acontecem.

A diferença importa porque as duas afirmações não têm o mesmo peso. Um achado estático como "o aplicativo pode ler SMS" vale para toda cópia daquele APK. Um achado dinâmico como "o aplicativo leu SMS e enviou um código de uso único para este domínio" vale para uma execução, em um conjunto específico de condições. É uma prova mais forte de intenção e uma prova mais fraca de completude.

O que a análise estática estabelece

Uma passada estática bem construída cobre a maior parte do que uma decisão de triagem exige, sem expor nenhum dispositivo nem nenhuma rede à amostra.

Identidade. O certificado de assinatura, sua validade e seu esquema de assinatura, comparados com a versão distribuída pelo Google Play. Um app bancário cujo certificado não coincide com o do Play é um forte indício de reempacotamento, e esse achado não depende de nada do que o código faz.

Capacidades declaradas. Permissões e componentes do manifesto. BIND_ACCESSIBILITY_SERVICE junto com SYSTEM_ALERT_WINDOW e QUERY_ALL_PACKAGES é o conjunto de capacidades típico de um trojan bancário com sobreposição de tela, descrito em detalhe em como funciona um trojan bancário Android.

Ocultação. Criptografia de strings, carregamento reflexivo de classes, empacotadores e stubs nativos de desempacotamento. A ocultação não revela comportamento, mas é um sinal por si só, ainda que não conclusivo: protetores comerciais usados por muitos apps legítimos também criptografam código, então o achado é avaliado junto com a assinatura, as permissões e a procedência.

Cadeia de suprimentos. SDKs de terceiros identificados por assinatura. O Droidwatch detecta 87 SDKs dessa forma e consulta o OSV.dev ao vivo em busca de vulnerabilidades conhecidas; hoje o OSV tem dados de 12 desses 87, porque os SDKs de publicidade e atribuição são em sua maioria de código fechado.

Infraestrutura. URLs, endereços IP e domínios embutidos e, quando a configuração pode ser decifrada sem execução, os servidores de comando e controle que ela contém.

Mapeamento para frameworks. Achados mapeados para técnicas do MITRE ATT&CK Mobile e para categorias do OWASP MASVS, para que o resultado seja compreensível para quem nunca vai abrir a amostra: a área de fraude, a auditoria ou o comitê de risco.

No Droidwatch isso é um pipeline de 28 etapas que cobre mais de 25 análises independentes. Um APK de 50 MB termina em dois a cinco minutos; acima de 100 MB, a média é de oito a dez. A narrativa que resume o relatório é produzida por um motor de regras, não por um modelo de linguagem: uma fase da cadeia de ataque só aparece nela quando há achados que a sustentam.

Onde a análise estática para

A análise estática estabelece capacidades, e há amostras construídas para que o que está em disco revele muito pouco.

• Carregamento dinâmico de código. Um dropper distribui um APK mínimo e baixa ou decifra a carga real em tempo de execução via DexClassLoader ou equivalente. O arquivo analisado é o mecanismo de entrega, não o malware.
• Comportamento comandado pelo servidor. Muitos trojans bancários baixam depois da instalação a lista de aplicativos-alvo e os modelos de sobreposição. O APK contém a maquinaria; os alvos chegam depois.
• Configuração criptografada. Se a chave é derivada em execução ou obtida remotamente, o endereço do C2 pode não ser recuperável a partir do arquivo. Um bom relatório diz que a extração falhou, em vez de sugerir que não existe infraestrutura.
• Reflexão e código nativo. Chamadas montadas a partir de strings em tempo de execução, ou lógica transferida para uma biblioteca nativa, escondem quais caminhos de código são reais.

Nada disso invalida um veredito estático. Uma amostra com ofuscação pesada, carregamento de código em execução e REQUEST_INSTALL_PACKAGES pode ser classificada como dropper sem ser executada. O que a análise estática não consegue fornecer nesses casos é o segundo estágio em si.

O que a análise dinâmica acrescenta

Executar a amostra sob instrumentação cobre justamente essas lacunas. O Frida, kit de instrumentação dinâmica de código aberto sobre o qual a análise dinâmica do Droidwatch é construída, se anexa ao processo em execução e intercepta métodos Java e funções nativas. Em geral, uma instrumentação desse tipo permite observar:

• as URLs que o aplicativo realmente contata, incluindo as montadas em tempo de execução;
• o acesso a SMS e notificações no momento em que acontece, não apenas a permissão para isso;
• chaves criptográficas e strings decifradas enquanto são construídas na memória;
• as telas que o aplicativo desenha, capturadas como imagens;
• o tráfego de rede da sessão.

No Droidwatch, o que chega ao relatório a partir de uma execução dinâmica é a saída do Frida, o logcat, as capturas de tela e a captura de rede.

Para um dropper, a execução costuma ser o único caminho prático até o segundo estágio. Para um trojan bancário com alvos definidos pelo servidor, a execução pode revelar quais instituições a campanha atual mira, desde que a infraestrutura de C2 ainda esteja respondendo.

Onde a análise dinâmica para

A análise dinâmica produz uma prova de comportamento mais sólida, e tem seus próprios pontos cegos.

• Cobertura. Uma execução só observa o código que roda durante aquela sessão. Uma função que depende de um comando específico, de uma data ou de um app bancário instalado pode nunca ser ativada.
• Evasão. O malware Android verifica com frequência se está em um emulador, com root, com depurador ou com instrumentação, e algumas famílias verificam também o idioma, o país do chip ou o tempo decorrido antes de agir. Uma amostra que detecta o ambiente de análise pode se comportar como um app inofensivo durante toda a execução.
• Dependência de infraestrutura ativa. Se o servidor de C2 estiver fora do ar, uma amostra que depende dele pode não fazer nada observável. Um resultado dinâmico vazio é, portanto, uma prova de inocuidade mais fraca do que um resultado estático vazio.
• Interação. As sobreposições costumam disparar só quando um app-alvo é aberto. Sem esse gatilho, o comportamento mais importante não acontece.
• Risco. A amostra está viva. Ela alcança tudo o que o dispositivo alcança e pode tentar persistir.

Comparativo

Análise dinâmica no próprio emulador

A análise dinâmica do Droidwatch é executada no dispositivo ou emulador do próprio cliente, conectado pelo agente do Droidwatch. Nenhuma amostra é executada na infraestrutura do Droidwatch; o sandbox hospedado não está em produção. O APK é enviado para a análise estática como de costume; a execução acontece só no emulador do analista, e o que volta ao Droidwatch dessa execução é o resultado: a saída do Frida, o logcat, as capturas de tela e a captura de rede, que entram no relatório já existente.

O guia de configuração descreve o procedimento completo. Em resumo:

1. Instalar o adb e as ferramentas de linha de comando do Frida na máquina de análise.
2. Criar um emulador com uma imagem sem Google Play. O frida-server precisa de root, e as imagens com Play são assinadas para produção e não permitem; uma imagem google_apis permite. Um celular comum não serve pelo mesmo motivo.
3. Enviar ao emulador uma versão do frida-server que coincida exatamente com a do cliente Frida local e com a arquitetura (ABI) do emulador.
4. Criar uma chave de API com o escopo read + analyze. Tanto as chaves de API quanto a análise dinâmica exigem o plano Pro ou superior.
5. Iniciar o agente, enviar o APK como de costume e escolher My device na aba Dynamic.

Como a execução acontece na máquina do cliente e não sob observação do Droidwatch, a seção dinâmica do relatório recebe o rótulo analyst-supplied, ao lado do nome do analista e da data.

As regras de segurança do guia valem para toda execução: nunca executar uma amostra em um celular pessoal, isolar a rede que o emulador alcança e restaurar o emulador a partir de um snapshot ao final, porque desinstalar o app não remove a persistência que a amostra possa ter criado.

A análise de iOS no Droidwatch é somente estática, em sete módulos. Não existe instrumentação em tempo de execução para iOS em nenhum plano.

Uma regra prática de decisão

Primeiro a estática, sempre. Ela é rápida, é segura e, para a maioria das decisões de triagem, suficiente. O fluxo de triagem do SOC mostra como chegar a uma classificação só com evidência estática.

A dinâmica se justifica quando resta uma pergunta concreta que a execução pode responder:

• o relatório estático mostra carregamento dinâmico de código e o segundo estágio é necessário para a detecção;
• a configuração do C2 não pôde ser extraída de forma estática e a infraestrutura é necessária para o bloqueio;
• a decisão depende de a capacidade ser usada, não apenas de estar presente;
• as instituições-alvo importam para a resposta e são entregues pelo servidor.

Quando nenhum desses casos se aplica, executar a amostra acrescenta risco sem acrescentar evidência. Quando algum se aplica, o relatório estático diz qual pergunta ficou em aberto, e a execução dinâmica mira exatamente essa pergunta. O guia do relatório do Droidwatch mostra onde cada um desses sinais aparece.

Perguntas frequentes

A análise dinâmica é mais precisa que a estática? Nenhuma é mais precisa em geral. A estática é completa em relação ao que o arquivo contém; a dinâmica é precisa em relação ao que uma execução fez. Amostras evasivas enganam a dinâmica; amostras empacotadas limitam a estática. Combinar as duas produz a evidência mais sólida.

O malware consegue perceber que está sendo analisado em execução? Sim. Verificações de emulador, root, depurador e frameworks de instrumentação são comuns no malware Android. Uma execução dinâmica sem ocorrências não prova que a amostra é inofensiva.

Por que a configuração exige um emulador com root? O frida-server roda com privilégios elevados dentro do dispositivo para poder se anexar a outros processos. As imagens de emulador que incluem Google Play não permitem root, por isso o guia pede uma imagem Google APIs.

Onde a amostra é executada durante a análise dinâmica do Droidwatch? No emulador do próprio analista. O APK é enviado ao Droidwatch como em qualquer análise estática; da execução, só os achados e os artefatos chegam ao relatório. Nenhuma amostra é executada na infraestrutura do Droidwatch.

Existe análise dinâmica para iOS? Não. O Droidwatch analisa arquivos .ipa de forma estática, em sete módulos, em todos os planos. Não há análise em tempo de execução para iOS.