Esse artigo apresentará as etapas iniciais de uma análise de malware, abordará algumas técnicas simples das análises estática e dinâmica (ou comportamental). Geralmente essas tarefas podem ser automatizadas e existem muitas sandboxes que fazem isso. Porém nem sempre é recomendável o uso de sandboxes de terceiros, principalmente se estivermos lindando com informações que não podem se tornar públicas.
Então vamos começar!
ANÁLISE ESTÁTICA
Na análise estática fazemos a dissecação de um artefato malicioso sem executá-lo, apenas observando seu código com ajuda de disassemblers, debuggers, descompiladores, etc. É o onde entra a engenharia reversa do binário.
Identificação do artefato
Recebi esse arquivo através de um e-mail phishing utilizando o nome de uma instituição pública:
Nome: Anexo2011.pif
MD5: dc150c6df434feeceb88dc176e27b6fe
O primeiro passo é fazer a identificação do arquivo para encontrar possíveis packers ou cryptors que dificultam bastante a engenharia reversa do malware.
Alguns programas recomendados para essa tarefa são os já conhecidos PEiD, ExeinfoPE e RDG Packer Detector.
Ao submeter o arquivo ao ExeinfoPE foi apresentada a seguinte tela:
Como vemos na imagem, o arquivo é do tipo executável de 32 bits e foi compactado com o “PEcompact ver.2.78a – 3.00” e na dica lammer diz para buscarmos o unpacker “RL!dePacker”.
Ainda conforme sublinhei na imagem, ele nos diz que teremos problemas se foi adicionada na proteção a injeção de um DLL.
Então vamos tentar o RL!dePacker. Fiz o download do unpacker e submeti o arquivo a ele:
Pelas mensagens do RL!dePacker parece que conseguiu fazer a descompactação corretamente. Ao submeter o arquivo ao RDG apresentou as seguintes telas:
Realmente o PEcompact foi eliminado, mas como havia alertado o ExeinfoPE foi identificada outra proteção, o uso da biblioteca de compressão aPLib. E também mais uma outra contra o uso de debuggers, a função IsDebuggerPresent da API kernel32.dll do Windows.
Não são notícias muito boas para a análise estática mas vamos continuar.
Disassembler
Abri o arquivo descompactado no IDA Pro 5.0 freeware, que é um poderoso disassembler e também possui funções de debugger. No início da análise ele já apresentou telas informando que o arquivo poderia estar compactado e que teve problemas para refazer a IAT.
A IAT (Import Address Table) é uma tabela onde o executável armazena os ponteiros ou endereços das funções externas que ele utiliza, isto é, que ele importa da API do Windows.
Por exemplo, se um malware importa a função IsDebuggerPresent isso quer dizer que lá na IAT dele existe a localização (endereço) exata dessa funçao na DLL que está em C:\windows\system32\kernel32.dll.
Os packers geralmente também “embaralham” essa tabela de endereços justamente porque sem ela a engenharia reversa do malware se torna muito mais difícil, não teríamos nenhuma referência de nomes de funções.
Continuando com a análise no IDA ao buscar pelos Imports do malware, mesmo a tabela de Imports estando corrompida, foi possível visualizar o uso da DLL WSOCK32:
O uso dessa DLL já nos diz que o malware possui funções de comunicação com a Internet (o que já era de se esperar).
No código disassembly também localizei o uso da função IsDebuggerPresent:
Código simples, um “IF” que se identificar a presença do debugger (retorno diferente de zero) para a execução.
Por o malware estar com todas essas proteções não consegui localizar mais nada de relevante, nesses casos, na minha opinião, o melhor caminho é partir para a análise dinâmica.
ANÁLISE DINÂMICA
A análise dinâmica consiste em executar o malware em um ambiente controlado, comumente dentro de um máquina virtual, e através de ferramentas de monitoramento capturar as interações que ele realiza com o sistema operacional e ambiente de rede.
Monitoramento do tráfego de rede
Já sabemos que o malware realiza comunicação com a Internet então nada mais lógico do que monitorar (“snifar”) o tráfego de rede. Para essa tarefa o uso do já consagrado Wireshark é certo.
Em uma máquina virtual Windows XP SP2 32 bits deixei a placa de rede ativa e o Wireshark rodando e executei o malware.
As comunicações de rede geradas foram essas:
Download do arquivo: http://www.zhenqingzs.com/images/clean.jpg
Download do arquivo: http://www.eremnakliyat.com.tr/images/logo32.jpg
Acesso à página PHP: http://aruana.com.br/images/fearless.php
Então foram baixados dois arquivos supostamente JPG e tentativa de acesso a uma página PHP que não existia no site.
Pelo que conheço dos malwares os dois JPGs não devem ser imagens e a página PHP possivelmente deve ser um controle do autor do malware para saber quantos foram infectados. Ele se conecta a essa página e então automaticamente deve ser registrado o endereço IP ou coisa do tipo em um arquivo de controle.
Para descobrirmos o verdadeiro tipo de um arquivo o interessante é usar o comando “file” que vem nativamente no Linux, também é possível instalá-lo no Windows, foi o que eu fiz.
Nos dois arquivos baixados pelo malware o resultado foi arquivo de dados e o terceiro que era um JPG verdadeiro vemos que a saída é bem diferente.
Então os dois “JPGs” não são imagens e nem executáveis, são arquivos genéricos de dados que devem ser utilizados pelo malware para algum propósisto ainda desconhecido. Ao abrir esses arquivos em um editor hexadecimal não foi identificada nenhuma informação útil, apenas sequências de caracteres aleatórios.
Monitoramento de processos e sistema de arquivos
Outra forma importante de descobrir o comportamento de um malware é observando quais processos são criados por ele, o que eles fazem, quais acessos realizam no sistema de arquivos, alterações do registro, etc. Uma excelente ferramenta para essa tarefa é o Process Monitor.
Antes de executar o malware na máquina virtual também deixei rodando o Process Monitor, das várias linhas de log que ele gerou algumas que mais me chamaram atenção foram essas:
Aqui vemos que o processo do malware criou um arquivo com o sugestivo nome de “delme167D.bat” e salvou em:
C:\Documents and Settings\Administrador\Configurações locais\Temp\delme167D.bat
Depois o processo chamou o cmd.exe para executar o arquivo BAT e em seguida se encerrou:
Com o nome de “delme” ele deve apagar alguma coisa, eis seu conteúdo:
Então o arquivo “delme” tenta excluir o arquivo do malware após ele ter sido executado e depois tenta se auto-excluir.
Monitoramento de alterações no Registro do Windows
Para esse função o uso do RegShot é indicado. Antes de executar o malware tira-se uma “foto” do registro do Windows, depois da execução tira-se outra “foto” e por fim compara as duas para descobrir o que foi alterado.
Ao realizar esse procedimento com o malware o RegShot apresentou várias modificações, mas as significativas foram essas:
Foi adicionada a seguinte DLL na chave de registro:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs: "gter.dll"
As DLLs que estiverem na chave AppInit_DLLs são carregadas dentro de processos do usuário na inicialização do Windows. Isso quer dizer que a DLL será injetada em um processo legítimo do sistema operacional, com isso quando for exibida a lista de processos pelo Gerenciador de Tarefas não aparecerá nenhum processo estranho.
Essa é um ótima técnica de ocultação do malware, não é trivial identificar um malware rodando desse jeito, bem diferente do que achar um processo chamado “fotos.exe” sendo executado.
O programa Autoruns da Microsoft exibe tudo que é inicializado com o Windows, ao utilizá-lo para identificar essa DLL ele apresentou corretamente a chave e o local onde estava salva:
C:\windows\system32\gter.dll
Conclusões
Com base nas informações encontradas, observando no tráfego de rede o tamanho dos downloads e o tamanho dos arquivos gerados, muito provavelmente no primeiro download o malware gerou o arquivo “delme167D.bat” e no segundo o “gter.dll” e após fazer isso ele tentou apagar o malware original e o arquivo “delme”, restando apenas a dll que será injetada em um processo e executada na próxima inicialização do sistema.
Basicamente isso é tudo o que o malware faz, características comuns em malwares do tipo trojan (down)loader, abrem caminho para outras pragas. O nome atribuído para ele pela Kaspersky confirma isso “Trojan-Downloader.Win32.Banload.bkqk”.
Vimos que mesmo com todas as proteções no executável através da análise dinâmica conseguimos descobrir praticamente tudo de importante que o malware faz, isso não quer dizer que esse tipo de análise é melhor, ela é complementar. Lógico que esse artefato era bem simples, para os mais complexos a análise se torna mais trabalhosa.
O que a “gter.dll” faz ficará para o próximo artigo. Analisar uma DLL é um pouco mais complicado do que um executável, o caminho que estou utilizando é o uso de ferramentas de “memory forensics”.
Até a próxima!
Ronaldo P. Lima
