Dando continuidade à nossa análise de documentos maliciosos, iremos abordar agora a etapa que é conhecida como análise estática. Porém, antes de adentrarmos nesta fase, precisamos entender qual formato é utilizado pelos documentos.

No nosso caso estamos nos referindo à documentos utilizados pela suíte de escritório Microsoft Office, que seguem o Compound Document Format (formato mencionado no post anterior), além de possuírem suporte à arquitetura de documentos conhecida como Object Linking and Embedding (OLE).

O principal ponto desta sopa de letrinhas é: os documentos Office possuem a capacidade, através do OLE, de linkar outros documentos ou objetos dentro de si. Uma planilha dentro de um documento Word é um exemplo disso. E é nesta estrutura que é inserido o código malicioso, que podem ser simples executáveis embutidos e/ou mesmo shellcodes.

figura1

Estes códigos abusam de falhas conhecidas em versões antigas do Microsoft Office (que só passou a adotar um novo padrão em 2007) para serem executados. Uma vez em execução utilizam várias outras técnicas para conseguir criar ou ler arquivos, capturar entradas de usuário, modificarem outros documentos ou mesmo, em casos mais raros, adentrarem no kernel space (de onde podem executar com mais privilégios).

Agora a questão que não quer calar é: como descubro de forma preemptiva que um documento é malicioso? Infelizmente a resposta não é simples e depende de fatores que não necessariamente estão sob nosso controle, como vimos no 1a..parte deste post. Discuti-los aqui iria consumir bastante tempo (e tornar a leitura entediante para alguns). Mas há algo que podemos fazer uma vez que temos um arquivo suspeito: uma análise estática do mesmo.

A análise deste tipo de documento têm recebido menos atenção do que merece, talvez porquê não seja tão trivial e não se encaixe na simples análise baseada em hash. Além disso, documentos PDF são distribuídos com maior frequência e facilidade. Nesta análise precisaremos realizar os seguintes passos:

  1. Verificar a estrutura do arquivo e procurar por trechos maliciosos.

  2. Identificar que tipo de ameaça está inserida no arquivo.

  3. Extrair as instruções maliciosas (ou parte delas).

  4. Procurar por símbolos suspeitos.

  5. Verificar se utilizam técnicas de exploração.

  6. Reconstruir o executável e analisá-lo.

Para cumprir a etapa 1 temos algumas opções:

a) Usar uma sandbox (método utilizado na primeira parte e que iremos ignorar);

b) Analisar a estrutura do arquivo e procurar em seus campos por dados não-esperados;

c) Analisar automaticamente o arquivo e pontuá-lo de acordo com os dados inseridos.

As opções b) e c) são na realidade complementares, porém, para efeito de aprendizado serão postas separadamente.

Começarei apresentado o OfficeVis, ferramenta desenvolvida pela Microsoft para seus desenvolvedores e que irá nos ajudar na atividade “b”. Ela é capaz de, ao carregar os arquivos, separar seus campos de acordo com o padrão CDF, mostrar os dados associados e averiguar se há incongruências.

Além disso, existe o recurso de procurar por exploits conhecidos, baseando-se nos CVEs. Uma vez analisado, ele consegue identificar os bytes maliciosos inseridos dentro do documento. Como exemplo, irei utilizar o arquivo que foi enviado para as clouds na primeira parte do post. Abaixo segue a imagem do resultado encontrado pela ferramenta:

figura2

De imediato nós somos apresentados a este conjunto de bytes que, segundo a ferramenta, compõe um forte candidato a um exploit relatado pelo CVE-2006-6456.

Mais uma vez dispomos de resultados que nos dão fortes indícios mas não nos dão certeza. A ferramenta relatou mais alguns conjuntos de bytes maliciosos mas também não nos deu certeza.

Por este motivo, irei apresentar agora outra ferramenta: MalOfficeScanner. Desenvolvida e apresentada por Frank Boldewin na Hack.Lu 2009, apresenta algumas features muito interessantes: scan de códigos malicioso (scan); decodificação de códigos através de força bruta (brute); debug de códigos encontrados com disassembly dos mesmos e detecção de strings e arquivos PE embutidos (debug); obtenção de OLEs, offsets, e macros VB (info); descompressão de arquivos de Office 2007 para identificação e categorização das ameaças (inflate).

Nos concentraremos aqui em duas opções: scan e debug. Primeiramente o scan:

Logo de início temos diversas assinaturas de prólogo de função encontrados em determinados offset:

figura4

O que é o prólogo de uma função? Grosseiramente falando, o prólogo é uma convenção de programação que determina que algumas instruções devem ser chamadas com o intuito de preparar a stack para ser utilizada pela função que está iniciando. Essa preparação pode (e deve) guardar o “contexto” da função passada, caso seja necessário retornar a ela. Mais a frente irem mostrar alguns exemplos.

O ponto chave aqui é: deveríamos ter funções neste documento?
Analisando a próxima evidência encontramos algo muito interessante:

figura5

A ferramenta conseguiu detectar diversas assinaturas de uma técnica que chamamos simplesmente de JMP/CALL/POP. Esta é uma das mais conhecidas e utilizadas técnicas de shellcoding para obter o endereço efetivo de onde aquele pedaço de código está executando. Encorajo buscar uma definição mais “extensa” desta técnica; vale a pena.

Desta vez, temos a confirmação de que uma técnica que nos permite descobrir um endereço de memória (e posteriormente manipulá-lo) está sendo utilizada exaustivamente.

Dando continuidade, somos informados de que existe dentro do documento assinaturas de seções que identificam a existência de possíveis executáveis MZ/PE; formatos para executáveis de MS-DOS e Windows, respectivamente:

figura6

É interessante salientar que neste exato instante a ferramenta está extraindo estes “executáveis” a partir de um endereço relativo e criando um binário à parte. Ao final ela realiza um somatório de todos os indícios encontrados, dando peso diferente a cada um deles, e mostra um índice:

figura3

Este índice é muito alto! O próprio Frank mostrou em sua apresentação arquivos com índice de 36 pontos. Este arquivo é, de acordo com a ferramenta, muito malicioso.

Agora vamos ao debug, que irá analisar o binário, apresentá-lo em formato hexadecimal e tentar extrair daí alguma informação valiosa:

figura8

De imediato somos apresentados a uma cadeia de caracteres (string) que identifica uma função “antiga”, e que segundo a Microsoft existe apenas para efeito de retrocompatibilidade com versões antigas do Windows, cujo propósito é executar binários: Winexec. Muito conveniente, não?

Em seguida temos uma chamada à função CreateFile, que cria arquivos ou acessa dispositivos de entrada/saída (I/O, por exemplo os discos rígidos):

figura9

A função seguinte (CloseHandle) é relativa a tratamentos de objetos:

figura10

Outra função interessante: WriteFile, que similarmente ao CreateFile, escreve em arquivos ou dispositivos de I/O.

figura12

ReadFile: lê arquivos ou dispositivos de I/O.

figura11

SetFilePointer: ajusta o apontamento para arquivos.

figura13

VirtualAlloc: reserva páginas no endereço virtual como um recurso para o processo em execução.

figura14

E agora, como prometido, o binário após ter sido revertido pela ferramenta e com seus devidos mnemônicos identificados e indicando a presença de prólogos! A seguir o código assembly que caracteriza o prólogo de uma função:

figura15

Sem nos estendermos muito no código acima, gostaria de chamar atenção para as 6 primeiras linhas, que representam o instante que os endereços base são salvos e uma nova pilha é criada (stack frame). O momento que o prólogo acontece é irrelevante para este momento da análise e varia muito com o que conhecemos como convenção de chamada (calling convention). Para efeito de curiosidade, recomendo verificar a diferença dessa chamada entre Windows, Linux e MacOS.

E finalmente o dado bruto que, após “mapeado” pelo MalOfficeScan, apresenta a string “this program must be run under Win32”, indicando que um executável deve ser executado no sistema operacional Windows que suporte binários programados para a arquitetura de 32 bits (o que engloba um espectro amplo de máquinas):

figura16

Acho que conseguimos bastante indícios de que o documento não é confiável!
Neste post, caminhamos pelas etapas 1 a 5. De certa forma, realizamos também a etapa 6, porém de forma automatizada. Para o próximo post iremos mais fundo no binário em busca de mais indícios e outras técnicas utilizadas por quem escreveu este artefato.

Até lá,

Referências Bibliográficas:

Análise de documentos e malware sandbox?

Object Linking and Embedding

Create, change or delete an OLE object

Methods for Understanding Targeted Attacks with Office

Malicious Office Files Analysis – pyOLEScanner and Cryptoanalytical Approach

Announcing Offvis

New advances in Ms Office malware analysis