Dissecando Malware – Parte 1
Autor: Ronaldo Lima | Publicado: 2012-05-03T16:28:00-03:00


Nesse artigo inicio a análise detalhada de um malware curioso, ao
invés de executar de uma só vez, ele faz execuções recursivas
para atingir seus objetivos. Em cada execução um novo bloco de
código é alcançado até chegar na função principal. Essa
estratégia pode ter sido utilizada para dificultar a análise ou
mesmo ser apenas um estilo de codificação.



O objetivo desse artigo é mostrar um pouco mais sobre as estruturas
internas dos malwares. O tópicos abordados nessa primeira parte
serão:



- O Phishing

- Os Imports

- Caminhos de execução

- 1ª Execução

- Uso de Mutex

- Mais validações

- Preparação para a 2ª Execução

- Algumas Considerações



Qualquer dúvida, sugestão, correção, será muito bem-vinda. E não deixe de acompanhar as novidades do blog no twitter: @crimescibernet.




Let's start!



O
Phishing



Tudo
começou com um e-mail se passando pela Receita Federal comunicando
que devido a um congestionamento nos sistemas, algumas declarações
haviam sido danificadas e era necessário verificar com o CPF se
houve problema ou não com a declaração. A velha fórmula de
engenharia social envolvendo assunto do momento mais a ameaça ao
usuário (medo).







O link
apontava para essa URL:



hxxp://receita-federal.mail333.su/Declaracao
2011.rar



Fiz o
donwload do RAR e descompactei, tratava-se do executável “Declaracao
2011.exe”. Estava compactado com o UPX e foi só utilizar o
“upx -d” para remover o packer. No Brasil ainda utilizam
bastante o UPX, será que só querem diminuir o tamanho do arquivo ou
acham que ele realmente é bom para ofuscação de código?



Submetendo
o arquivo descompactado ao Exeinfo PE e RDG Packer Detector a
linguagem de programação identificada foi Borland Delphi 2009-2010.
Fizeram um upgrade no Delphi, na maioria das vezes a versão é 6.0
ou 7.0. 








Os
Imports



Agora sim
vamos iniciar a análise do código, as ferramentas que irei utilizar
serão o IDA Pro para análise estática e o OllyDbg para debugging
de alguns trechos do código.



Ao
carregar o arquivo no IDA a primeira coisa que fiz foi abrir a aba
Imports, ou seja, as funções que o malware importa da API do
Windows. Eram muitos imports, mas alguns me chamaram atenção:



MessageBoxA

QueryPerformanceCounter

GetTickCount

WriteFile

IsDebuggerPresent

GetEnvironmentVariableA

GetEnvironmentVariableW

DeleteFileW

CreateMutexA

ShellExecuteA



Os
imports de um programa dizem muito sobre suas funcionalidades. A
partir dessa pequena lista podemos deduzir muitas coisas, o uso do
MessageBoxA no diz que o malware em algum momento apresenta
uma mensagem para o usuário.



Ao ver
QueryPerformanceCounter e GetTickCount logo imaginei
que eram utilizadas para anti-debugging. Geralmente elas são
utilizadas na técnica de Time Check, onde o malware tira um
timestamp, realiza algumas instruções, tira outro timestamp e
compara os dois. 




Se o
tempo decorrido for maior que o normal ele supõe que está rodando
dentro de um debugger, já que o debugger atrasa a execução do
código. E ainda também há o uso da função IsDebuggerPresent,
o nome já diz tudo. Estaríamos lidando com um malware com técnicas
anti-debugging? Veremos mais adiante.



WriteFile
e DeleteFile nos diz que o malware grava e apaga arquivo no
disco. GetEnvironmentVariable no mostra que o malware manipula
ou utiliza alguma variável de ambiente  do SO. 




CreateMutex
é a função que cria objetos que são compartilhados por processos,
isso para lidar com a concorrência, ou semáforo, entre os
processos. Veremos mais sobre ela adiante. ShellExecuteA
realiza operações em um arquivo, do tipo abrir, editar, imprimir,
etc.



O “A”
ou “W” que existe no final do nome das funções se referem a
“ASCII” ou “UNICODE” (Wide), respectivamente. Para descobrir
o que cada função faz, consulte o site da MSDN, pode-se buscar no
Google: “NomedaFuncao msdn”.



Apesar
dos muitos imports, algo me chamou atenção, não havia nenhum
import de API relacionada a funções de rede. Muito estranho para um
malware já que praticamente todos utilizam a Internet para se
comunicarem com um servidor C&amp;C, baixarem mais pragas, enviarem
dados, etc. Somente havia imports das DLLs: kernel32, advapi32,
oleaut32, shell32 e user32.







Porém,
ao buscar as strings do malware, encontrei referências a DLLs com
funções de rede: WS2_32.DLL, MSWSOCK.DLL, Wship6.dll e
FwpucInt.dll. Então, essas DLLs devem ser carregadas pelo malware em
tempo de execução através da função LoadLibrary. Veremos
também sobre isso adiante.











Ainda
falando sobre as strings, encontrei algumas criptografadas, no
decorrer da análise veremos o uso delas.



Já temos
algumas informações sobre as funcionalidades do malware, hora de
seguir em frente e encarar o (dis)assembly!



Caminhos
de execução



Esse
malware funciona de maneira peculiar, ele é recursivo. Na verdade,
após a primeira execução originada pelo usuário ele se
auto-executa mais duas vezes. Em cada execução ele passa por
algumas validações e é direcionado para um caminho diferente de
código, até atingir o objetivo final.



Vamos
seguir as funções principais do código para entender melhor com
isso funciona. Abaixo o trecho inicial do código. Use essa imagem
para acompanhar o que está sendo explicado, esse é o fluxo
principal do programa, o Main Code.







1ª
Execução



Assim que
o malware é executado pelo usuário, é chamada uma função que
denominei FilePathInfo. Essa função é complexa, dentro dela
há chamadas para umas outras 20 funções, nesses casos para não
nos perdermos devemos abstrair e tentar entender o propósito geral
da função, para isso o debugger ajuda muito.



Descobri
que basicamente essa função busca o caminho da variável de
ambiente TEMP através da GetEnvironmentVariableA, como
podemos ver no código abaixo.







A string
“TEMP” está criptografada mas logo abaixo há a função de
descriptografia, com o debugger foi fácil obter o retorno. Esse tipo
de criptografia de strings já é bem
conhecido do blog.



E depois
ela obtém o caminho do executável com o uso da GetCommandLineW.
Feito isso ela compara os dois caminhos e retorna:



0 se
forem diferentes

1 se
forem iguais



Após a
chamada da função FilePathInfo há o teste do retorno no
Main Code:



call
FilePathInfo

test al,
al

jnz short
Continue



Jump if
Not Zero (jnz), se forem iguais pule para o bloco de código que
denominei “Continue”. Em outras palavras, testou se o malware
está sendo executado dentro do diretório TEMP. Como não está, vai
executar o bloco de código logo abaixo, apontado pela seta vermelha.



Uso de
Mutex



A próxima
instrução é a chamada para a função TestMutex (nomeada
por mim). Aqui teremos os uso do mutex. Mutex é um objeto criado no
kernel do Windows, esse objeto pode-se entender como uma string. Essa
string é utilizada por um programa (processo) para sinalizar a outro
(programa) alguma coisa.



Sabemos
que cada processo em user-mode tem seu espaço de memória reservado
e isolado dos demais, justamente para evitar que um interfira no
outro. Criar o mutex no kernel permite que todos os processos tenham
acesso a ele. 




Essa
técnica é muito utilizada por malwares para garantir que somente
uma instância do processo esteja em execução, para evitar erros de
execução por exemplo. O processo antes de executar completamente
sempre verifica se o mutex já existe e se existir finaliza o
processo, sinal que já há outra instância do malware em execução.



Isso é
exatamente o que nosso artefato faz, dentro da função TestMutex
há o trecho de código abaixo.







Há o uso
de outra string criptografada que em texto simples significa
"SFIheg72". Esse será o nome do mutex. Depois há a
chamada à função CreateMutex da API do Windows. Se
consultarmos na MSDN o que essa função faz, diz o seguinte:



“Creates
or opens a named or unnamed mutex object.”



Então é
passado o nome do mutex para a função, se o mutex "SFIheg72"
não existir é criado um mutex com esse nome, caso contrário é
aberto o mutex já existente.



Como o
programa sabe se foi criado um novo ou se já existia? Buscando o
código de erro gerado pela função através da GetLastError.
Há uma tabela padrão no Windows com todos
os códigos de erros. Nessa tabela há:



 
 
 
 

  
Código

  
Constante

  
Descrição

 

  
0 (0x0)

  
ERROR_SUCCESS

  
A operação foi realizada com
   sucesso.

 

  
183 (0xB7)

  
ERROR_ALREADY_EXISTS

  
Não é possível criar o arquivo
   quando ele já existe.

 




No código
vemos que é feita uma comparação com o valor 0xB7, isso para
descobrir se o mutex já existe ou não. Baseado nessa comparação,
a função TestMutex irá retornar:



0 se o
mutex não existir (e criará o mutex)

1 se o
mutex existir (e retornará um handle para o mutex)



Note que
após a chamada da função no Main Code, é feita uma comparação
com o retorno no registrador AL. Jump if Zero (jz) “Continue”. E
se o valor não for zero, ou seja, o mutex já existe, o que quer
dizer que outra instância do malware já está sendo executada.
Nesse caso é chamada uma função que finaliza o processo com
ExitProcess.



Prosseguindo
com a execução, agora no bloco “Continue”, há novamente a
chamada para a função TestMutex. Dessa vez ela retornará 1
pois o mutex já existe, acabou de ser criado como vimos.



Mais
validações



Novamente
é chamada a função FilePathInfo e ela retornará 0, já que
o arquivo não está dentro do diretório TEMP. Não identifiquei a
necessidade de chamar a TestMutex e a FilePathInfo
nesse trecho de código.



Prosseguindo
no Main Code, é chamada a função que denominei GetToken.
Nessa função há uma série de chamadas a funções relacionadas
com o SID (Security Identifier) do processo em execução. Ficou meio
obscura a funcionalidade dela pra mim, mas de forma geral tem a ver
com as permissões de acesso do usuário que está executando o
processo, é feita algumas comparações relacionadas a isso.



Parece
que se o usuário não tiver privilégios suficientes o processo é
finalizado. Nos meus testes essa função sempre retornou 1, mas
vemos que se ela retornar 0 é chamado o código que prepara a
finalização do processo.



Abaixo a
continuação do Main Code para prosseguirmos com a análise.







Como a
GetToken retornou 1, a execução prosseguirá para a chamada
da FilePathInfo novamente. Como sabemos ela verifica se o
executável está dentro do TEMP e retorna 0 caso não esteja, que é
o valor retornado aqui.



O Jump
redirecionará para o bloco de código “ExecFile”. Esse por sua
vez chama a função rotulada por mim como ExecuteFile. 




Preparação
para a 2ª Execução



A função
ExecuteFile possui diferentes caminhos com diferentes
validações, vamos passar pelas instruções mais interessantes.



Pouco
depois de armazenar espaço na pilha para as variáveis locais, a
função chama a FilePathInfo para testar se o executável
está no TEMP. Não estando lá é feito um jump para o bloco de
código que denominei “NotInTEMP”. Abaixo seguem as instruções
desse bloco.







Pelo nome
que coloquei nas funções já dá pra ter uma ideia do que elas
fazem. A GetTEMPVar busca o caminho do diretório %TEMP%,
ReturnPath busca o caminho completo do executável,
ReturnFileName retorna somente o nome do arquivo,
RemoveExtension retira do nome do arquivo a extensão, o
“.exe” (poderia ser ponto qualquer coisa).



Depois é
utilizada uma string criptografada que equivale a “.exe”. Por
fim, é chamada a função MakeNewPath que faz a concatenação
de tudo:



%TEMP% +
FileName + “.exe”



E em
seguida a GetNewPath retorna esse caminho:



C:\DOCUME~1\ADMINI~1\CONFIG~1\Temp\Declaracao
2011.exe



Após
construir o caminho é hora de salvar o arquivo em disco, isto é,
fazer uma cópia do arquivo no diretório TEMP. A função que faz
isso está logo abaixo, chamada de WriteMZFile.







Após
salvar em disco há uma chamada para a função GetOSVersion,
ela é responsável por verificar a versão do Windows, não sei
dizer se essa verificação foi adicionada pelo programador ou pelo
próprio compilador, o código dela está a seguir.







A função
GetVersionExW da API do Windows tem a seguinte definição:



“Retrieves
information about the current operating system. If the function
succeeds, the return value is a nonzero value. If the function fails,
the return value is zero.”



Como
parâmetro a função recebe uma estrutura de dados chamada de
VersionInformation que receberá as informações do sistema
operacional caso tenha sucesso. Essa estrutura possui o campo
dwMajorVersion que é o versão numérica principal do SO. Na
MSDN
há uma tabela com os nomes e versões possíveis para esse
campo.



Basicamente,
a versão será:



6 –
para Windows 7, Server 2008 e Vista.

5 –
para Windows 2000, XP, Server 2003.



Vemos no
código que há uma comparação com o 6 que determinará o valor do
EAX (AL). Se a versão for 6 o AL (EAX) receberá 1, caso contrário
receberá 0 (xor eax, eax).



E o EAX
será o retorno da GetOSVersion,
que após a chamada da função é utilizado em um “test”. No meu
caso, como estou utilizando o Windows XP, a versão retornada foi a 5
e consequentemente o EAX recebeu 0.



No
“test al, al” fui redirecionado pelo “JZ” para o bloco de
código “loc_4BC2D3”.







Vemos
no código o uso de uma string criptografada que em texto simples
equivale a “open”. E depois é obtido o novo caminho do arquivo
através da GetNewPath.





Enfim
vamos chegar na segunda execução do malware. Isso é feito com a
função ShellExecuteA.
Essa função executa uma operação e um arquivo específico e
possui 6 parâmetros:



HINSTANCE
ShellExecute(

__in_opt  HWND hwnd,

__in_opt  LPCTSTR lpOperation,

__in
     LPCTSTR lpFile,

__in_opt  LPCTSTR lpParameters,

__in_opt  LPCTSTR lpDirectory,

__in
     INT nShowCmd

);



Os
mais interessantes para nós são o lpOperation
(qual operação vai ser executada no arquivo), lpFile
(o arquivo utilizado) e lpParameters
(parâmetros passado para o arquivo, como em linha de comando). Para
saber mais sobre a função consulte
a MSDN. 




No
código a seguir vemos a chamada da função com a passagem de
parâmetros através do 6 PUSHs.







Com
o OllyDbg  conseguimos ver a chamada da função, e como é possível
imaginar, com os parâmetros ela ficará assim:







Isso vai
abrir (executar) o arquivo recém-criado no TEMP. Trata-se do mesmo
arquivo, mesmo MD5. Lembro que todo esse código está dentro da
ExecuteFile. Após o retorno dessa função, o processo
original (Main Code) é finalizado.



Algumas
considerações



Vimos que
em determinados trechos do código há a verificação se o arquivo
está no TEMP ou não, por causa disso nessa segunda execução o
malware percorrerá caminhos diferentes, o que fará com que ele
execute outras funções.



Outro
ponto a ser observado, imaginemos que estamos analisando o malware
com o debugger, linha a linha. O que acontecerá quando chegar na
função ShellExecute e dermos um step over? O malware será
executado sem que possamos debugá-lo já que será criado um novo
processo. 




Por isso,
é importante entendermos seu funcionamento. Agora que sabemos o que
ele fez, se quisermos debugar essa segunda execução é só abrir o
executável a partir do TEMP.



Normalmente
não precisamos fazer uma análise detalhada assim, basta sabermos o
que o malware faz, mas quanto maior o conhecimento do baixo-nível
mais fácil será para obter o alto-nível.



Continua...