Este artigo busca concluir um experimento com um honeypot, detalhando a análise de malware realizada com o auxílio de IA. A premissa do projeto é verificar se a combinação de uma máquina virtual (VM) isolada, ferramentas clássicas de análise de malware e um agente LLM pode gerar não apenas um relatório esteticamente agradável, mas também informações úteis para a defesa contra ameaças.
Os requisitos mínimos definidos para o projeto incluem:
- Execução segura de um sample em uma VM Windows.
- Captura de memória, disco e tráfego de rede do host.
- Análise estática utilizando Ghidra.
- Geração de um parecer técnico que permita a tomada de decisões e a criação de regras de detecção.
Embora um leitor atento possa notar semelhanças com soluções como ANY.RUN, CAPE ou VirusTotal, a intenção aqui não é a análise de malware em larga escala, mas sim uma análise aprofundada de um sample específico, fornecendo respostas rápidas para o pesquisador. Com base nisso, o engenheiro reverso pode decidir se vale a pena investigar mais a fundo o binário.
O Que Foi Testado
A hipótese era que, ao conceder ao Codex (um modelo de linguagem grande) acesso controlado a ferramentas de análise, ele seria capaz de realizar uma pesquisa preliminar semelhante a um engenheiro reverso: identificar pontos vulneráveis no binário, correlacionar dados dinâmicos e estáticos, e formular conclusões e relatórios. O resultado foi positivo, mas com ressalvas importantes.
É crucial lembrar que a IA ainda não substitui especialistas em segurança. O controle humano é essencial, especialmente em cibersegurança. As decisões que permaneceram sob responsabilidade do autor incluíram:
- Como isolar a máquina virtual.
- Qual snapshot considerar como referência.
- Quando permitir a execução da análise dinâmica.
O agente de IA foi encarregado do trabalho mais rotineiro e repetitivo: preparação de scripts, verificação de ambiente, execução do pipeline de transferência do sample da quarentena para a VM, processamento de artefatos, análise de dump de memória, importação no Ghidra e geração de relatórios.
Arquitetura do Sistema
A arquitetura é dividida em duas zonas: o host e a VM Windows convidada.
- Host Linux: Utiliza libvirt/QEMU para gerenciamento da VM, captura de pcap, dump de memória, gerenciamento de discos e resultados, Volatility 3 para análise de memória, Ghidra + Ghidra MCP para análise estática e o Codex para orquestração e análise.
- VM Windows 11: Contém um agente para execução do sample, Sysmon para monitoramento de eventos, logs e o próprio sample em execução.
A regra principal é capturar o máximo de dados do lado do host. O sistema convidado não é confiável, pois é considerado potencialmente comprometido após a execução do malware.
Componentes da VM Convidada
A VM Windows possui um conjunto mínimo de componentes para execução e registro de eventos:
- Agente preparado para executar o sample.
- Scripts PowerShell para execução.
- Configuração do Sysmon.
- Diretório para recebimento do sample.
- Mecanismo para gravação de artefatos básicos.
Não há canais de rede, drag-and-drop ou pastas compartilhadas para evitar vetores de ataque durante a configuração da sandbox.
Componentes do Host
O host gerencia a lógica principal de orquestração:
- Criação de disco a partir de um snapshot de referência.
- Conexão de um dispositivo de armazenamento removível virtual à VM.
- Inicialização da VM via libvirt.
- Captura de PCAP.
- Captura de dump de memória.
- Análise com Volatility.
- Análise com Ghidra.
- Geração de relatórios.
A captura de dump e PCAP, bem como a análise com Volatility 3, são realizadas no host, pois o convidado é considerado comprometido.
Por Que QEMU/libvirt?
QEMU/libvirt foi escolhido por oferecer controle de baixo nível sobre o ciclo de vida da VM e gerenciamento via terminal, incluindo snapshots, montagem de discos, conexão de mídias, captura de dump e PCAP sem a necessidade de intervenção do convidado.
Primeira Lição de Engenharia: Permissões de Acesso
A principal dificuldade encontrada não foi a análise do malware ou a IA, mas sim as permissões de acesso. O QEMU roda como um usuário específico (ex: libvirt-qemu), enquanto o Codex roda como um usuário comum. Discos e dumps de memória eram criados em locais diferentes e por sujeitos distintos, gerando conflitos. A solução foi configurar ACLs (Access Control Lists) para garantir que o snapshot base fosse acessível para leitura pelo QEMU, o diretório /runs fosse acessível por ambos os usuários, e novos arquivos herdassem as ACLs corretas.
Segunda Lição: BitLocker e Extração Offline
O autor optou por não desativar a criptografia BitLocker do Windows para simular um cenário mais realista. No entanto, isso complica a extração de dados do disco. Se o sistema de arquivos convidado for criptografado, o dump de disco pode ser inútil sem chaves adicionais ou exportação da VM. Artefatos do convidado são exportados para um disco separado e não criptografado, o que representa um ponto de atenção em termos de segurança.
Exemplo de Execução: Um Stealer de Steam
O experimento utilizou um sample de Windows PE stealer (bac12c7b2bc08d4d552e4692bc1566d7d54efc67c3a1131628c491c23626d773) baixado do malwarebazaar. O sample foi escolhido por resolver para uma conta Steam real, o que o autor achou peculiar.
O cenário de execução foi:
- Preparação de um diretório com permissões adequadas.
- Criação de uma VM temporária a partir de um snapshot.
- Importação paralela do sample no Ghidra para análise estática.
- Conexão do sample (.exe) como um dispositivo de mídia.
- Início da VM.
- O agente inicia o sample.exe.
- O host captura o tráfego de rede (PCAP).
- Após um timeout, um dump de memória é capturado.
- A VM é parada.
- Volatility é executado para extrair artefatos suspeitos.
- Artefatos são importados no Ghidra para análise adicional, se necessário.
- Dados dinâmicos e estáticos são correlacionados.
O sample foi executado como sample.exe, com um agente PowerShell como pai. A execução foi interrompida por timeout após 180 segundos.
Análise Dinâmica: O Que a Memória Revelou
O Volatility identificou um artefato com permissões PAGE_EXECUTE_READWRITE e cabeçalho MZ dentro do processo sample.exe. Isso geralmente indica um módulo PE que não existe como arquivo normal no disco, podendo ser uma carga útil descompactada, um loader reflexivo ou algo mapeado diretamente na memória.
Um PE x64 foi extraído dessa região, com 4 seções, image base em 0x1a0000000 e entry point próximo a 0x1a00e3dec. O Import Directory estava vazio. Este foi um caso de referência para a análise estática, pois forneceu um segundo sample.
Rastro de Rede: Útil, Mas Incompleto
O tráfego de rede continha requisições DNS para telegram.me, steamcommunity.com e alguns domínios de background da Microsoft. No entanto, não foram encontradas sessões TCP/HTTP/TLS, devido ao isolamento da rede da sandbox.
Análise Estática: Código Fonte vs. PE Descompactado
Inicialmente, o PE original foi carregado no Ghidra, que o reconheceu como um binário Go. A análise foi ruidosa devido a funções de runtime, nomes ofuscados e IOCs não evidentes.
Em seguida, o PE extraído da memória foi carregado. O loader PE padrão do Ghidra falhou devido a marcações de debug/runtime corrompidas. A solução foi importá-lo como um arquivo bruto (BinaryLoader), especificando o base e a arquitetura. Com isso, o Ghidra conseguiu analisar o código, revelando cerca de 857 funções e um conjunto valioso de strings.
O Que o Módulo Descompactado Revelou
O PE descompactado continha strings como:
https://telegram.me/...https://steamcommunity.com/profiles/...winhttp.dll- User-Agent do Windows/Edge
- Caminho local como
C:\WINDOWS\TEMP\... - Um identificador/chave hexadecimal.
Através do Ghidra MCP, foram obtidos xrefs e a descompilação de funções chave. As principais descobertas incluíram:
- Funções com lógica de XOR/rotate/hash para decodificação/ofuscação.
- Função de inicialização para strings do Telegram/Steam/User-Agent.
- Resolução dinâmica de API WinHTTP por hash.
- Inicialização de sessão WinHTTP.
- Candidato a rotina de rede.
- Função de montagem de buffer/pacote.
As strings do Telegram/Steam, juntamente com as requisições DNS observadas, confirmaram sua relevância.
Conclusão Após a Execução
A cadeia de trabalho validada foi:
Execução na VM -> Dump de memória -> Volatility malfind -> Extração de PE do VAD -> Importação bruta no Ghidra -> Descompilação MCP -> Correlação com IOCs -> Relatório final.
A principal conclusão sobre o sample é que ele é malicioso, descompacta um módulo PE na memória, utiliza configuração em tempo de execução, resolve dinamicamente a API WinHTTP e contém IOCs do Telegram/Steam que se correlacionam com as requisições DNS capturadas.
Da Análise às Regras: YARA e Sigma
Após a verificação manual no Ghidra, foi adicionada uma etapa de geração de regras de detecção. O objetivo não é substituir o analista, mas sim transformar descobertas em modelos de regras reproduzíveis.
Para cada execução, são gerados:
iocs.json: Conjunto de IOCs legível por máquina.iocs.md: Resumo legível por humanos.- Regra YARA para o PE descompactado.
- Regra Sigma para indicadores DNS.
- Regra Sigma para artefato de arquivo.
A regra YARA para este sample específico é construída com base em uma combinação de fatores: cabeçalho MZ + URL do Telegram + URL do Steam + User-Agent + winhttp.dll + identificador hexadecimal. Essa abordagem reduz o risco de falsos positivos, pois o Telegram e o Steam, por si só, não são IOCs maliciosos, mas em conjunto com outros elementos, formam uma assinatura útil para este cluster de malware.
As regras Sigma, focadas em DNS, são menos úteis isoladamente, pois requisições para telegram.me ou steamcommunity.com podem ser comportamento normal do usuário. No entanto, em um contexto de laboratório, essas regras são valiosas para verificar se o comportamento se repete em execuções futuras.
TLDR ou Minhas Conclusões
A análise manual de malware geralmente esbarra na desconexão entre conhecimento e ferramentas. O Volatility mostra uma coisa, Ghidra outra, PCAP um terceiro aspecto e o sistema de arquivos um quarto. Manter tudo isso em mente, em anotações, pode ser tedioso. Um agente LLM é ideal para o trabalho rotineiro, eliminando a necessidade de:
- Executar manualmente o malware.
- Examinar o binário inteiro no Ghidra.
- Procurar artefatos suspeitos no Volatility.
- Analisar pacotes PCAP.
As ações e decisões do assistente de IA forneceram material que permite ao analista decidir se vale a pena investigar mais a fundo ou se o sample é simples e não requer atenção adicional. A IA ainda não substitui completamente o pesquisador na tomada de decisões, mas libera tempo para tarefas mais complexas e interessantes.
O MVP (Minimum Viable Product) confirmou a hipótese. Um sample PE real foi executado em uma VM Windows isolada, a memória foi capturada, o módulo descompactado foi extraído, carregado no Ghidra, e a descompilação resultante foi correlacionada com os rastros de rede. Tudo isso consumindo apenas 20% do limite de tempo do Codex Pro, indicando que a economia de esforço é possível, mas limitada em ferramentas de fluxo contínuo.
O resultado final é um algoritmo reproduzível:
Sandbox controlada pelo host + Triagem inicial pela memória + Ghidra MCP + Correlação assistida por LLM = Fluxo de trabalho de análise de malware explicável.
P.S. O autor agradece aos leitores e se oferece para fornecer comentários adicionais para quem desejar implementar um sistema semelhante.
