Conheça o malware AutoIT

Publicado em Serviços e Consultoria, Segurança, por Juniper em 18/12/2016


Neste post, Asher Langton, especialista em malware na equipe Sky ATP (Advanced Threat Prevention ou prevenção avançada de ameaças) da Juniper Networks, analisa um trecho do malware AutoIT. AutoIT é uma linguagem e um interpretador de scripting usado principalmente para a administração e automação de tarefas no Windows. Malware escrito em AutoIT não é especialmente comum, mas houve recentemente um clone do Locky escrito nesta linguagem. Vamos percorrer três diferentes camadas de análise de forma a encontrarmos o payload malicioso em cada uma das técnicas de ataques usadas.



Camada 1
Esta amostra veio como um arquivo WinRAR. Dentro dele, encontramos uma diversidade de tipos de arquivo.



A maior parte deles se parece com arquivos de imagens e documentos comuns que compartilhamos diariamente, mas todos eles, com exceção dos arquivos dqu.exe, são arquivos de texto simples. O arquivo executável é uma cópia do interpretador AutoIT, o que pode ser verificado buscando pelo seu hash no VirusTotal:
 

 
Na tela do WinRAR acima, podemos ver que depois que o arquivo é desempacotado há um comando de setup:


Setup=dqu.exe tid.ivb


Como o dqu.exe é o interpretador do AutoIT, pode parecer que o tid.ivb é o script de input. Mas, à primeira vista, parece que o arquivo tid.ivb está vazio!


Olhando mais a fundo, notamos que esta é apenas outra técnica utilizada para enganar a ferramenta de análise. O arquivo contém principalmente retornos de controle (ASCII 0x0d) e linhas de feed (ASCII 0x0a), com o conteúdo real escondido dentro de um bloco:
 


Após analisarmos o bloco de dados ofuscado, encontramos o script AutoIT:

 

 
Para facilitar a análise, criamos um script em Python, que nos permite renomear as funções e variáveis e assim ler e remover com mais facilidade algumas das strings (sequências de código) ofuscadas:

 


Ao percorrer este código, vemos que o script é executado sem um ícone de notificação, para evitar ser revelado. Ele também dorme por 20 segundos para evadir a detecção do antivírus e, em seguida, lê os dados de configuração de um arquivo PDF falso:



A função (renomeada) func_3 usa um nome de diretório ( 'sqv') extraído do arquivo PDF e verifica que


1. o script está sendo executado a partir do diretório AppDataRoamingsqv do usuário e
2. não existe uma janela aberta intitulada 'sqv'.


A última verificação falhará se o analista de malware estiver executando o script enquanto o subdiretório sqv estiver aberto no Windows Explorer. Se qualquer uma das condições falhar, o script encerrará todos os processos em execução e forçará uma reinicialização completa do sistema:



Depois de passado este estágio, o script continua a ler dados do kcj.pdf:



Neste ponto, o $var_4 contém uma longa cadeia hexadecimal tirada de kcj.pdf, e $ var_6 é uma string de 5 caracteres gerada aleatoriamente por func_1 (). Na sua forma original, este procedimento era quase incompreensível:



O código desobscurecido é mais fácil de entender:

 

 

As entradas para esta função são a longa cadeia hexadecimal mencionada acima ($ var_10) e a string "897" ($ var_11). Essas variáveis, juntamente com a sequência hexadecimal armazenada em $ var_12, são formatadas e usadas em uma chamada de sistema do Windows:

 

 

Esse uso do CallWindowProc é um truque bem conhecido para incorporar shellcode em scripts do Windows. A string $ var_12 representa código binário executável, que podemos desmontar no IDA Pro:

 

 

Este shellcode implementa a  RC4 stream cipher. Ele toma $ var_11 como entrada e transforma a string longa $ var_10. Aqui está o código equivalente em Python:



Usando este script, podemos extrair o conteúdo descriptografado e... é outro script AutoIT!

 

 

O novo script é gravado no disco, todos os arquivos no diretório são definidos como 'ocultos' e o script é executado.



Camada 2

O segundo script AutoIT usa técnicas de obscurecimento adicionais, mas novamente algumas mudanças de nome  e simplificações tornam o código mais legível.

 

 

A primeira coisa a notar é que este script tenta ler um número de variáveis de configuração do PDF falso. Esses valores, se presentes, são usados para modificar o comportamento do script. A maioria dessas opções não é usada nesta instância, mas uma olhada no código mostra algumas das funcionalidades disponíveis, incluindo a evasão do sandbox, a execução binária e a capacidade de publicar conteúdo na conta do Facebook da vítima se o site estiver aberto em um navegador:



Em nosso caso, o script lê outra sequência hexadecimal do arquivo PDF, a descriptografa com o mesmo truque CallWindowProc/shellcode, grava o arquivo no disco e, em seguida, executa-o. Em vez de outro script AutoIT, a carga útil desta vez é um arquivo executável portátil (PE) padrão do Windows.
 

 

Camada 3
Felizmente, este executável foi escrito em Visual Basic 5 e compilado para p-code, e existem ferramentas comerciais para ‘descompilar’ este tipo de executável. Algumas das funcionalidades são óbvias, como esta rotina que rouba senhas de contas, um aplicativo popular de mensagens instantâneas:



Além de uma série de outras funções de roubo de senhas, há também uma rotina chamada InjPE que executa um arquivo do Windows (PE), injetando-o em outro processo. Mas quais binários serão injetados? Podemos começar com a seção de recursos do nosso executável.


 

O primeiro componente do recurso DVCLAL é uma sequência ASCII. No Visual Basic descompilado, vemos que essa sequência de caracteres é extraída e cada caractere é deslocado para cima por 2:



Podemos decodificar a sequência com uma linha de Python:
 


O resultado é uma URL, provavelmente usada para filtrar os dados roubados do computador da vítima. Os outros dois componentes do recurso DVCLAL são arquivos do Windows PE – WebBrowserPassView  e MailPassView – utilitários que exploram um computador para buscar senhas “perdidas”. Nenhum deles é um malware, estritamente falando, mas ambos são comumente usados para propósitos maliciosos.
 

Visão geral
Descobrimos o que o payload procura no computador de destino: senhas. A Camada 1 é o script AutoIT entregue em um executável de extração automática. A Camada 2 é um script AutoIT criptografado e descriptografado no destino com o truque CallWindowProc/shellcode. A Camada 3 é o executável escrito em Visual Basic, que por sua vez contém mais dois executáveis usados como utilitários para varrer o computador da vítima antes de filtrar os dados para uma URL que encontramos escondida na seção de recursos. Dada a configurabilidade e as partes não utilizadas dos scripts AutoIT, parece que os autores do malware usaram algum tipo de conjunto de ferramentas para envolver e ofuscar seu malware. Isso, combinado com o uso de arquivos de dados/configuração separados, torna viável fornecer executáveis exclusivos a cada vítima.

 

Leia também
Utilizar ROP para detectar malware é perda de tempo
Conheça os malwares que fogem de detecção e análise
Juniper divulga o primeiro, de uma série de relatórios, sobre as ameaças do momento na rede.
 

 


Tags: Segurança, Criptografia, Python, Malware, Antivírus, Windows, Script AutoIT, Sandbox, Payload


Tags: seguranca, criptografia, python, malware, antivirus, windows, script-autoit, sandbox, payload


Posts Relacionados


Deixe seu comentário:

=