Triagem de um APK suspeito: o fluxo do SOC

Um cliente encaminha o APK que recebeu depois de uma ligação de alguém que dizia falar pelo departamento de fraudes do banco. Um canal de inteligência publica um nome de pacote que imita o aplicativo de banco móvel da instituição. Um funcionário instala um arquivo entregue por uma campanha de smishing com o pretexto de atualização obrigatória.

Nos três casos o SOC enfrenta a mesma pergunta, e ela não é se a amostra é malware. É se a organização deve agir, e com base em qual evidência.

Este documento estabelece um fluxo de triagem estática: uma classificação defensável mais um conjunto de indicadores adequados para detecção, produzidos sem dispositivo, sem emulador e sem ambiente de laboratório.

O escopo da triagem

A triagem responde a quatro perguntas, em sequência:

1. O aplicativo é o que afirma ser?
2. Quais capacidades o manifesto solicita?
3. O código está ocultando sua função?
4. Com qual infraestrutura ele se comunica?

A triagem não estabelece a cadeia de ataque completa nem a atividade do operador após o comprometimento. Esses são objetivos de engenharia reversa, e confundir os dois planos é a principal causa de acúmulo nas filas de triagem móvel.

Um limite prático: quando uma classificação não foi alcançada em cerca de dez minutos de trabalho do analista, a amostra pertence a uma fila de engenharia reversa, não a uma de triagem. A triagem é o processo que determina qual das duas.

Manuseio da amostra

Todo APK desconhecido é tratado como malware vivo durante o processo.

• A análise ocorre em ambiente isolado. Amostras de triagem nunca são instaladas em um dispositivo que contenha credenciais ou conectado à rede de produção.
• O SHA-256 é registrado antes de qualquer outra etapa. É o único identificador estável que a amostra conserva; nome de pacote, rótulo e ícone são todos controlados pelo atacante.
• O binário não é redistribuído. Compartilham-se hashes e indicadores, não a amostra. Acordos de troca de amostras são uma questão jurídica, não técnica.
• A procedência é registrada. O mesmo APK recuperado do aparelho de um cliente e obtido de um feed público representam incidentes diferentes.

Etapa 1 — Verificação de identidade

A análise começa pelos componentes que um atacante é obrigado a expor para que o pacote sequer seja instalado.

Nome de pacote. Compara-se com o pacote do aplicativo legítimo na Google Play. Aplicativos bancários reempacotados raramente reutilizam o nome exato: usam uma variação próxima, um domínio invertido em outra ordem ou uma cadeia aleatória. Um nome de pacote ausente da Play cujo rótulo corresponde a uma instituição financeira conhecida já é motivo suficiente de escalonamento.

Certificado de assinatura. É o sinal de identidade mais sólido disponível em um APK. Examinam-se quatro propriedades:

• Esquema de assinatura. Assinatura apenas v1 em um aplicativo moderno é anômala. v2 e v3 são a norma.
• Sujeito do certificado. Um certificado de depuração (CN=Android Debug) em um aplicativo que se apresenta como produto bancário é desqualificante.
• Janela de validade. Um certificado emitido dias antes do aparecimento da amostra indica uma identidade descartável de campanha. Um autoassinado de trinta anos indica geralmente ferramentas padrão, padrão presente tanto em malware quanto em aplicativos legítimos mal mantidos.
• Reutilização. Um certificado compartilhado entre aplicativos aparentemente sem relação estabelece vínculo de campanha, e costuma ser o pivô mais produtivo obtido de uma única amostra.

Verificação contra a Play. Quando o pacote existe na Play mas o certificado não coincide com o distribuído por ela, a amostra é um aplicativo reempacotado. Isso é um incidente de fraude, não um achado de malware, e cabe imediatamente à área de proteção de marca.

No Droidwatch essas saídas são resolvidas antes de o restante da análise terminar.

Etapa 2 — Análise do manifesto

As permissões constituem uma declaração de capacidade pretendida. Para fins de triagem, o que um aplicativo é capaz de fazer costuma ser suficiente.

Permissões que exigem leitura atenta:

Uma única permissão perigosa é uma pergunta. BIND_ACCESSIBILITY_SERVICE junto de SYSTEM_ALERT_WINDOW e QUERY_ALL_PACKAGES é o conjunto de capacidades estabelecido de um trojan bancário Android.

Os componentes são lidos junto das permissões:

• Componentes exportados. Um Service ou BroadcastReceiver exportado sem permissão que o proteja é superfície de ataque, inclusive em aplicativos legítimos.
• Receptores de RECEIVE_BOOT_COMPLETED. Persistência após reinicialização.
• android:debuggable="true" em build de release. Ou construção descuidada de malware, ou um defeito significativo em um aplicativo legítimo.
• android:allowBackup="true" combinado com armazenamento local sensível.
• Tráfego em texto claro. cleartextTrafficPermitted="true" ou um networkSecurityConfig permissivo indicam tráfego inspecionável, e constituem falha de MASVS-NETWORK.

Etapa 3 — Ocultação de código

O objetivo nesta fase não é ler o código, mas estabelecer se ele foi construído para resistir à leitura.

• Ofuscação. Renomear identificadores por si só é irrelevante: a maioria das builds de release passa por R8 ou ProGuard. Criptografia de strings, carregamento reflexivo de classes e achatamento de fluxo de controle não são esperados em um aplicativo bancário.
• Carregamento dinâmico de código. DexClassLoader, PathClassLoader sobre um arquivo obtido em tempo de execução, ou uma carga descriptografada a partir de assets. É o padrão dropper: o APK enviado é o mecanismo de entrega, não o malware.
• Bibliotecas nativas. Um objeto compartilhado em um aplicativo sem necessidade plausível de código nativo merece anotação. Packers frequentemente escondem a carga atrás de um stub nativo de desempacotamento.
• Blobs em assets. Arquivos grandes, criptografados ou de alta entropia em assets/ que o manifesto não justifica.

Uma amostra com ofuscação intensa, carregamento de código em tempo de execução e REQUEST_INSTALL_PACKAGES pode ser classificada sem a leitura de um único método.

Etapa 4 — Extração de infraestrutura

Extraem-se todos os endpoints embutidos: URLs, endereços IP isolados, domínios presentes nas tabelas de strings e, quando a configuração é criptografada, a configuração descriptografada.

As saídas relevantes são:

• Endpoints de C2 e o padrão de protocolo ao redor deles.
• Idade e registro do domínio. Um domínio registrado na semana anterior servindo um aplicativo que imita uma instituição de longa trajetória constitui por si só um achado conclusivo.
• Tokens de bots do Telegram, URLs de caixa postal e identificadores de chat embutidos. Campanhas de baixa sofisticação recorrem a eles de forma sistemática, e pivotam com facilidade.
• Reutilização de infraestrutura. Um único endereço IP servindo várias famílias de APK sem relação aparente indica uma campanha, não uma coincidência.

Esses indicadores são o componente da triagem que chega à pilha de detecção. Uma classificação protege um cliente; um domínio C2 incluído em uma blocklist de DNS protege todos os usuários por trás dela. O Droidwatch os emite como bundle STIX 2.1, de modo que a passagem de amostra para regra de detecção não exige transcrição manual.

Etapa 5 — Mapeamento para frameworks

O mapeamento é o que torna um achado móvel legível para responsáveis que nunca examinam a amostra.

Técnicas recorrentes nesta classe de amostra:

Para as áreas de segurança de aplicações, os mesmos achados mapeiam para categorias do OWASP MASVS: MASVS-NETWORK para transmissão em texto claro e falhas de pinning, MASVS-STORAGE para dados locais expostos, MASVS-CODE para carregamento dinâmico, MASVS-RESILIENCE para deficiências de antiadulteração. O MASTG fornece o procedimento de teste correspondente quando um resultado precisa ser demonstrado.

O Droidwatch produz ambos os mapeamentos em cada execução, ao lado de um sinal de classificador medido em F1 macro 0,9873 sobre um holdout de 1.661 amostras, treinado com 6.642 amostras do CICMalDroid 2020. O classificador contribui para o veredito; os achados acima são o que um relatório defende.

Etapa 6 — Classificação e escalonamento

O Droidwatch pontua o risco de 0 a 100, onde a pontuação mais alta indica risco maior. Quatro saídas, cada uma com um responsável definido:

O artefato importa mais do que o rótulo. Um relatório que afirma «malicioso» é uma asserção. Um relatório que contém o hash, a análise do certificado, o conjunto de permissões, os domínios C2, o mapeamento ATT&CK e o raciocínio por trás da pontuação é evidência, e evidência é o que resiste a uma revisão semanas depois. O Droidwatch exporta isso em PDF, DOCX, JSON, CSV ou STIX 2.1.

Limitações da triagem estática

• A análise estática estabelece capacidade, não comportamento. Um aplicativo capaz de interceptar SMS pode nunca fazê-lo, ou fazê-lo apenas mediante instrução do seu C2. Quando uma decisão depende do comportamento em execução, é necessária análise dinâmica.
• Configuração criptografada pode não ceder. Alguns packers exigem execução. Quando a extração de configuração falha, o relatório declara isso em vez de sugerir ausência de achados.
• A análise dinâmica do Droidwatch é somente Android e executa contra o dispositivo ou emulador do próprio cliente, conectado pelo agente do Droidwatch. Nenhuma amostra executa na infraestrutura do Droidwatch. É o desenho pretendido para organizações que não podem enviar amostras de seus clientes a um sandbox de terceiros, e exige configuração do lado do cliente. Está disponível a partir do plano Pro.
• A análise de iOS é somente estática. Sobre um .ipa executam-se sete módulos: análise do binário Mach-O, Info.plist, entitlements, configuração de App Transport Security, class-dump, frameworks vinculados e manifestos de privacidade declarada. Não existe instrumentação em execução para iOS em nenhum plano.

Executando o fluxo na plataforma

As seis etapas acima descrevem o processo analítico. A mecânica é um único envio:

1. Envie o .apk (ou .xapk, .aab, .dex, .ipa) para o analisador. Um APK de 50 MB conclui em dois a cinco minutos; pacotes acima de 100 MB levam em média de oito a dez.
2. Revise o relatório: veredito e pontuação, achados ordenados por severidade, certificado e comparação com a Play, mapeamento ATT&CK Mobile, cobertura MASVS, indicadores extraídos.
3. Exporte no formato que o destinatário exigir — STIX 2.1 para o SIEM, PDF ou DOCX para o registro do incidente.

Em volume, o fluxo roda pela API: POST /api/upload devolve um upload_id; POST /api/analyze devolve um job_id e um run_id; consulta-se GET /api/jobs/{job_id} até que o status seja done ou failed; o relatório é obtido em GET /api/runs/{run_id}/artifact/report.json. A autenticação aceita um cabeçalho X-API-Key ou um bearer token. Quando o arquivo já foi analisado antes, a resposta traz cached: true com o job_id nulo e não há o que consultar. O guia rápido documenta a sequência completa.

Perguntas frequentes

Quanto deve durar a triagem de um APK? Cerca de dez minutos de trabalho do analista até uma classificação. Amostras que ultrapassam esse limite de forma sistemática pertencem a uma fila de engenharia reversa.

O VirusTotal basta para este fluxo? O VirusTotal responde se um hash já foi observado e como os motores participantes o classificaram, e é a primeira consulta adequada. Não fornece o conjunto de permissões, as anomalias do certificado, o mapeamento ATT&CK nem o raciocínio necessário para produzir um relatório de incidente. As duas ferramentas ocupam posições diferentes do fluxo. Há uma comparação detalhada disponível.

Por que não operar o MobSF diretamente? O MobSF é um motor de análise sólido e boa parte da disciplina de segurança móvel foi construída sobre ele. O custo é operacional, não analítico: orquestração de contêineres, escalonamento de workers, manutenção de dependências, e a ausência de multi-tenant, controle de acesso por papéis e trilha de auditoria em ambientes multicliente. A comparação completa documenta o trade-off.

Qual é o resultado quando uma amostra se revela benigna? Um relatório assinado que estabelece essa conclusão, produzido em dez minutos. Resultados negativos são uma saída necessária de qualquer processo de triagem.

Os indicadores das amostras analisadas na plataforma são publicados no threat feed público sob licença CC BY 4.0. As práticas de manuseio e divulgação estão documentadas na página de confiança.