• Nenhum resultado encontrado

3. Análise de malware

3.4. Frameworks de análise dinâmica

A análise dinâmica de malware é um tópico com bastante relevo[29, 33, 133], pois permite a um analista perceber o comportamento de uma amostra de uma forma rápida, segura e eficaz.

Nas frameworks de análise dinâmica a amostra é executada e todo o seu comportamento é analisado, assim é possível determinar os propósitos da amostra e se é maliciosa. Esta secção irá abordar as técnicas de análise dinâmica normalmente utilizadas dando a

39 conhecer as suas capacidades, serão apresentadas duas plataformas de análise de

malware, devido à importância histórica foi abordada a CWSandbox agora apelidada de

GFISandbox que passou a ser um produto comercial, a outra plataforma denominada de Cuckoo tem sido alvo de atenção nos últimos tempos. Os criadores que estão por detrás do seu desenvolvimento são conhecidos no projeto honeynet e têm bastante reputação no campo de análise de malware, assim foi escolhida para o estudo nesta dissertação.

3.4.1. CWSandbox

A plataforma de análise CWSandbox permite a execução de malware num ambiente simulado e assim deduzir se o comportamento de uma amostra é ou não malicioso. Para isso injeta um DLL no binário para efetuar a monitorização das system calls invocadas, depois do processo de malware terminar gera um relatório que permitirá ao analista uma melhor compreensão sobre a amostra. A CWSandbox utiliza várias técnicas desde o hooking a captura do tráfego de rede para ter uma melhor perceção do comportamento do malware.

A sandbox é constituída por duas aplicações, o cswsandbox.exe e cwmonitor.dll, como se pode ver na Figura 13.

Figura 13 − Arquitectura CWSandbox adapdata de Provos[90].

O método de hooking que a sandbox utiliza passa por suspender o processo e injetar o

dll. Depois da fase de inicialização o processo é resumido e executado durante o tempo

40 (cwssanbox.exe) dos parâmetros utilizados nas calls, assim o DLL consegue comunicar quando o processo de malware cria novos processos, permitindo a instalação e injeção nesses processo do mesmo DLL que vai permitir a comunicação ao cwsandbox.exe[90]. O diagrama da Figura 13 − representa a relação entre os DLL e a sandbox, para o método de comunicação entre processos é utilizado IPC, onde cada função com um

hook envia uma notificação para informar a sandbox sobre a call e os parâmetros

passados. Em alguns casos é enviada uma resposta por parte da sandbox para o DLL. Devido à grande comunicação entre os processos e ao número desconhecido de processos que o malware irá criar é necessário ter um método de comunicação fiável e que não pudesse ser modificado por isso foi implementado um mecanismo de comunicação entre processos IPC na CWSandbox[90].

O DLL esconde a sua presença do malware através de técnicas de rootkit, fazendo com que todos os objetos que pertencem a sandbox sejam escondidos do malware, tal como os processos, módulos, ficheiros, entradas de registo etc.

O método de funcionamento da CWSandbox pode ser categorizado em 3 fases:

 Inicialização – A fase de inicialização, onde é injetado o DLL e existe troca de informação inicial;

 Execução – A fase de execução, esta fase dura tanto quanto o processo de

malware, é também nesta fase que é efetuada a maior parte da comunicação

entre os componentes;

 Relatório – Os dados colecionados são analisados e é gerado um relatório XML que contém os protocolos acedidos, passwords utilizadas e vetores de infeção utilizados. O relatório deve ajudar o analista a classificar a amostra de uma forma rápida e eficaz, análises posteriores podem ser efetuadas pelo analista caso se verifique necessário.

3.4.2. Cuckoo

A Cuckoo sandbox permite a execução de malware num ambiente virtualizado, tem como diferenciador o facto de ser opensource ser recente e os responsáveis pelo projeto estarem envolvidos em projetos de captura e análise de malware.

41 Relativamente as capacidade permite a monitorização dos processos e calls, suporta

dumps de memória do processo de malware, captura do tráfego de rede num formato

standard (PCAP), e outras funcionalidades que demonstram a extensibilidade, como por exemplo a captura de ecrãs durante a execução do malware.

A arquitetura da framework Cuckoo é baseada num software central de gestão que lida com a execução, análise das amostras, e os hóspedes de análise. A maneira como a Cuckoo sandbox efetua o hooking foi baseada na biblioteca detours da Microsoft mas eventualmente foi rescrita e agora é apelidada de cHook. A maneira como a amostra é analisada é feita com recurso à virtualização onde a amostra é lancada numa máquina virtual que é reposta ao estado inicial em poucos segundos depois da análise, o hospedeiro corre os componentes essenciais à análise e faz a gestão dos hóspedes onde a amostra é executada como se pode ver na Figura 14

Figura 14 − Arquitetura Cuckoo adaptada de Rodriguez[95].

Como se observa na Figura 14, a aplicação Cuckoo.py comunica com o agent.py que irá comunicar com a DLL injetada (cuckoomon.dll) que é o responsável pelo hook das várias funções do malware e também é da sua responsabilidade providenciar comunicação através de um named pipe8, assim a DLL consegue comunicar com o agente e enviar informação sobre os processos criados.

O Motor do Cuckoo responsável pelo hooking foi reescrito, antigamente utilizava a biblioteca detours da Microsoft o que se revelou limitante e facilmente detetável, visto

8

42 que o hook apenas utilizava uma instrução para a função de trampolim. Assim a deteção passava por procurar um opcode[31] como se pode ver na Figura 16 .

Figura 16 − Deteção do hook da biblioteca detours.

Devido a isso o motor foi escrito de raiz, com o nome de cHook este novo motor permite inline hooking para além que permite ao utilizador utilizar e desenvolver o código de trampolim desejado, sendo que atualmente o motor escolhe aleatoriamente a função de trampolim[31]. É possível ver na Figura 15 uma implementação de hooking utilizando a instrução JMP, à esquerda é o código original e na direita a utilização de um hook através da instrução JMP.

Figura 15 − Utilizacao JMP para hooking.

O novo motor de hooking da Cuckoo fornece mais flexibilidade, permitindo ao analista especificar o seu próprio código de trampolim e assim utilizar varias técnicas como se pode ver na Figura 16.

43 Na parte dos relatórios a framework providência bastante informação sendo bastante extensivos e modulares sendo possível escolher o formato de relatório e baseado na análise pretendida é dado um relatório específico, suporta output em JOSN, HTML, MAEC, MongoDB, HPFeeds.

O tipo de relatório pode ser um das seguintes 6 categorias que se ajusta ao nível de informação que se pretende[68]:

 EXE – É a análise por defeito a ser executada e serve para analisar executáveis do Windows;

 DLL – Para a análise de DLL existe a possibilidade de poder instruir a

framework qual a função a ser analisada também existe a opção para não injetar

o processo rundll32;

 PDF Utilizada para análise de pdf ;

 DOC/EXCEL Análise de ficheiros de documento;

 IE Para analisar o comportamento do Internet Explorer quando abre o ficheiro fornecido, este modo é útil para a investigação de exploits para o browser;  BIN Utilizado para analisar dados binários tais como shellcode.

Como podemos constatar as frameworks de análise dinâmica providenciam ao analista uma visão sobre o processo de infeção e seu comportamento podendo determinar através as suas ações se a amostra é maliciosa e assim tornar mais fácil a construção de assinaturas e outros métodos que permitam a desinfeção e prevenção de malware de uma forma eficaz e eficiente.

44

CAP 4

Documentos relacionados