Análise de malware com IA precisa de pacotes de evidências

Zane St. John comprou um projetor Android barato, percebeu tráfego DNS suspeito e usou Claude Code como assistente de engenharia reversa para inspecionar os apps pré-instalados do dispositivo.¹

O ponto interessante não é um agente de IA ter ajudado na análise de malware. Essa afirmação vai deixar de chamar atenção rapidamente. O que importa é o formato do artefato: comportamento de rede observado, nomes de pacotes, caminhos de código decompilado, saída de comandos, anotações e indicadores que um humano consiga inspecionar. A análise de malware com agentes só se torna confiável quando a saída se parece menos com uma resposta e mais com um dossiê de caso.

Análise de malware com IA precisa de pacotes de evidências. Agentes podem acelerar desempacotamento, decompilação, busca, resumo e geração de hipóteses. Analistas ainda precisam de hashes, versões de ferramentas, comandos, indicadores extraídos, caminhos de origem, rótulos de incerteza e trilhas entre afirmações e evidências antes de confiar na conclusão.

Resumo rápido

A Microsoft Research descreve o Project Ire como um agente autônomo de classificação de malware que faz engenharia reversa de software e produz uma cadeia de evidências antes que um validador decida se há suporte suficiente para um veredito de malware.² A investigação de Zane sobre o projetor Android mostra o mesmo padrão em menor escala: um agente pode ajudar um analista individual a navegar por APKs, logs, strings e caminhos de código suspeitos.¹

A lição segura para produto é específica. Trate um analista de malware com IA como uma bancada de trabalho, não como uma autoridade. Essa bancada pode extrair, organizar e conectar evidências. Ela não deve contatar infraestrutura ativa, escrever clientes de exploração, executar cargas desconhecidas em uma estação de trabalho comum nem substituir o julgamento humano sobre impacto. A saída útil é um pacote de evidências que um revisor consiga reproduzir.

Principais aprendizados

Para equipes de segurança: - Peça pacotes de evidências aos agentes, não vereditos. - Mantenha identidade da amostra, logs de comandos, versões de ferramentas, indicadores extraídos e suporte das afirmações no mesmo lugar. - Exija aprovação humana antes de qualquer execução dinâmica, contato de rede ou análise com credenciais.

Para criadores de agentes: - Defina fluxos de análise de malware como análise estática somente leitura por padrão. - Separe extração, hipótese, verificação e relatório em etapas distintas. - Preserve artefatos brutos e locais de origem para que um humano consiga auditar a cadeia.

Para equipes de produto: - Não venda “análise autônoma de malware” como mágica. - Mostre o que o agente inspecionou, o que ele inferiu, o que não verificou e o que um humano ainda precisa decidir. - Construa pacotes de revisão antes de criar painéis dramáticos.

O que o caso do projetor Android prova

A investigação de St. John começou com comportamento observado: solicitações DNS saindo do projetor antes do uso normal.¹ Isso importa porque a suspeita veio do dispositivo, não do modelo. O agente entrou depois que o analista já tinha uma pergunta que valia investigar.

O fluxo então passou por superfícies comuns de engenharia reversa:

O artigo cita ferramentas comuns de engenharia reversa Android, como adb e jadx.¹ Essas ferramentas não tornam uma conclusão verdadeira. Elas tornam o artefato inspecionável. O jadx se descreve como um decompilador de linha de comando e GUI que converte arquivos Android Dex e APK em código-fonte Java e pode decodificar recursos Android.³ O Apktool se descreve como uma ferramenta de engenharia reversa de arquivos APK Android, incluindo manifesto, recursos, smali e fluxos de reconstrução.⁴

A vantagem do agente fica no meio do processo. Ele pode buscar pacotes desconhecidos, resumir código, sugerir áreas prováveis para inspeção e manter uma lista de tarefas. O analista ainda precisa verificar cada afirmação contra o artefato original.

IA transforma engenharia reversa em gestão de caso

A análise tradicional de malware já produz um dossiê. Ele pode incluir hashes, origem da amostra, strings, domínios, endereços IP, mutexes, chaves de registro, caminhos de arquivo, capturas de tela, notas de disassembly, saída de ambiente isolado e um veredito final.

Agentes mudam a velocidade e o volume desse trabalho. Eles podem ler mais arquivos, escrever mais notas e produzir mais hipóteses do que um analista digitaria manualmente. Sem um contrato de saída mais forte, essa velocidade cria um problema de confiança. Um resumo confiante pode esconder uma inferência ruim, um desvio ignorado ou um nome de API alucinado.

O Project Ire da Microsoft aponta para um formato melhor. A Microsoft afirma que o sistema analisa e classifica software de forma autônoma e constrói uma cadeia de evidências para suas descobertas.² O desenho inclui ferramentas de engenharia reversa e um validador que verifica se as evidências sustentam o veredito.² Essa ideia de validador importa mais do que a marca. Análise de malware precisa de um juiz separado para as evidências, não apenas de um narrador fluente da conclusão.

Use a mesma divisão em fluxos menores:

O agente pode fazer muita coisa. A barreira decide o que merece crédito.

Android tem superfícies estáticas úteis

A análise de malware em Android tem uma vantagem prática: APKs expõem várias superfícies estáticas antes que alguém execute o app.

A documentação de segurança do Android lista categorias de risco como comunicações em texto claro, carregamento dinâmico de código, broadcast receivers inseguros, segredos codificados diretamente e erros relacionados a permissões.⁵ O MITRE ATT&CK for Mobile inclui técnicas como Broadcast Receivers e Download New Code em tempo de execução, o que dá aos analistas um vocabulário para mapear comportamento observado a práticas de atacantes.⁶

Isso torna valioso um pacote de evidências que começa pela análise estática:

A tabela evita um erro importante: ela não pede que o modelo decida primeiro se é “malware ou não”. Ela pede que o sistema preserve as evidências que tornariam um veredito revisável depois.

O pacote de evidências

Um pacote útil de análise de malware com IA deve seguir um formato previsível:

O mapa de afirmações é o centro do pacote:

Essa última linha protege o analista. Vereditos de malware têm consequências. Um falso positivo pode prejudicar um fornecedor ou confundir uma resposta a incidente. Um falso negativo pode deixar um usuário exposto. O modelo não deve ganhar um atalho ao redor das evidências.

O que o agente deve recusar

Trabalho com malware precisa de limites de recusa mesmo quando o objetivo é defensivo.

Um agente deve recusar ou exigir autorização humana explícita antes de:

• contatar infraestrutura ativa de comando e controle;
• escrever um cliente para uma possível backdoor ou atualizador;
• baixar cargas de segundo estágio de infraestrutura controlada por atacantes;
• executar uma amostra desconhecida fora de um laboratório isolado;
• usar credenciais reais de usuários, contas pessoais ou redes de produção durante a análise;
• publicar indicadores ativos que possam identificar uma vítima antes de uma divulgação responsável;
• transformar uma investigação defensiva em instruções de exploração.

A documentação de shell local da OpenAI alerta que permitir que agentes executem comandos arbitrários de shell pode ser perigoso e recomenda ambientes isolados ou listas rígidas de permissão e bloqueio antes de encaminhar comandos para um shell.⁷ O guia de melhores práticas de Claude Code da Anthropic enfatiza critérios de verificação e gestão de contexto para trabalho com agentes.⁸ A análise de malware precisa dos dois: limites de comando antes da ação e limites de evidência antes da crença.

O limite de recusa deve aparecer na própria tarefa:

Analise este APK estaticamente.
Não o execute.
Não contate infraestrutura remota.
Não escreva código de exploração nem código cliente.
Retorne apenas evidências com caminhos de arquivo, comandos e rótulos de confiança.
Marque toda afirmação sem suporte como não verificada.

Esse tipo de instrução não torna o fluxo seguro por si só. Ele dá a ganchos, ambientes isolados e revisores algo concreto para aplicar.

O humano ainda é dono do veredito

Um agente de IA pode economizar horas em uma análise de malware. Ele pode sair de uma pilha de APKs para uma lista curta de pacotes suspeitos. Pode resumir classes, desempacotar filtros de intent, identificar strings de configuração e produzir um rascunho de relatório. Esses ganhos importam.

O agente não deve ser dono do veredito.

O analista é responsável por:

• autorizar a análise da amostra;
• decidir executar algo dinamicamente;
• interpretar intenção e impacto;
• comunicar-se com fornecedores, usuários ou plataformas afetados;
• tomar decisões de remediação e divulgação;
• definir a linguagem final do relatório.

Essa divisão mantém o agente útil. O modelo faz o trabalho cansativo de conexão. O humano mantém a responsabilidade ética, legal e contextual.

Como criar o fluxo de trabalho

Comece com um pequeno ciclo de análise estática:

1. Calcule o hash da amostra e registre de onde ela veio.
2. Extraia manifesto, recursos, strings e código decompilado para uma pasta de trabalho somente leitura.
3. Peça ao agente para criar uma lista de achados com locais de origem.
4. Peça uma segunda passada para contestar cada achado e marcar afirmações sem suporte.
5. Monte o pacote de evidências.
6. Decida se o pacote justifica uma análise dinâmica em laboratório.

O prompt do agente deve exigir saída estruturada:

Para cada achado, inclua:
- afirmação
- caminho do artefato
- comando que produziu o artefato
- trecho da fonte ou símbolo
- confiança
- o que refutaria a afirmação
- se a análise dinâmica é necessária

Essa saída parece menos empolgante do que “o projetor tem malware”. Ela é muito mais útil.

A barreira de evidências se aplica diretamente. Uma afirmação sem evidência não deve entrar na resposta final. Pacotes de revisão são a nova resposta final também se aplica: a entrega não é o resumo em prosa, mas o pacote que permite que outra pessoa verifique o trabalho.

FAQ

Agentes de IA conseguem fazer análise de malware?

Sim, dentro de limites. Agentes podem ajudar com análise estática, resumo, navegação por decompilação, extração de indicadores e rascunho de relatórios. Eles não devem virar a autoridade final para vereditos de malware sem evidências reproduzíveis e revisão humana.

É seguro usar Claude Code ou Codex em malware?

Somente dentro de um fluxo defensivo controlado. Não execute amostras desconhecidas em uma estação de trabalho comum, não contate infraestrutura ativa e não entregue ao agente credenciais nem acesso irrestrito a shell ou rede. A análise estática em uma pasta de trabalho isolada é o ponto de partida mais seguro.

O que um pacote de evidências de análise de malware deve incluir?

No mínimo: hashes, origem da amostra, versões de ferramentas, comandos, fatos do manifesto, indicadores extraídos, locais de código, um mapa entre afirmações e evidências, rótulos de confiança e uma lista do trabalho não verificado.

Um veredito de IA conta como evidência?

Não. A declaração do modelo é uma interpretação. Evidências vêm de artefatos: hashes, logs, comandos, caminhos de código, manifestos, comportamento de rede observado e etapas de análise reproduzíveis.

Agentes devem mapear achados para MITRE ATT&CK?

Sim, quando a evidência sustenta o mapeamento. Um rótulo de técnica sem suporte em artefatos vira decoração. Use ATT&CK Mobile como vocabulário, não como substituto de prova.⁶

Fechamento

IA não remove o analista da análise de malware. Ela muda o que o analista deve exigir.

A saída fraca é um veredito confiante. A saída forte é um pacote reproduzível: identidade da amostra, comandos, artefatos, indicadores, suporte das afirmações, incerteza e próxima ação.

Agentes podem tornar a engenharia reversa mais rápida. Pacotes de evidências a tornam confiável.

Referências