Michael Elford

Michael is a cybersecurity professional that is passionate about 
malware analysis and reverse engineering.

Uma análise mais aprofundada do arquivo executável resultou na confirmação de que o arquivo é malicioso.

Nesta postagem do blog, pretendo compartilhar as descobertas da investigação, com o objetivo de conscientizar o público sobre as técnicas que podem ser usadas para analisar efetivamente o malware em geral e analisar especificamente o ASyncRAT.

Análise ASyncRAT

Note: All malware analysis should be carried out in a sandboxed environment.

Esta é a lista de ferramentas que foram usadas para esta análise:

• FlareVM
• PEStudio
• dnSpy
• Cyberchef
• Lixeiro

Iniciando a análise do Stage One do malware, o primeiro passo foi verificar o executável no PEStudio, que confirmou que se tratava de um arquivo .NET . Além disso, interpretamos a entropia razoavelmente alta como indicativa de empacotamento de malware, em que o malware adiciona complexidade para não ser detectado pelas soluções de segurança.

Nosso próximo passo foi examinar as cadeias de caracteres do malware e anotar qualquer coisa estranha que possamos querer examinar um pouco mais a fundo mais tarde.

Examinando as strings, identificamos imediatamente algumas strings que parecem ofuscadas . Como uma observação para nós mesmos, destacamos que talvez seja necessário implantar um ' localizar e substituir ' mais tarde.

Indo além

Depois de determinar que o arquivo foi escrito em .NET e anotar as strings ofuscadas, recorremos ao dnSpy , um depurador .NET.

Uma das primeiras coisas que notamos foi uma discrepância de nomes. O nome do executável no host e o nome do executável mostrado no dnSpy são completamente diferentes. A razão pela qual o executável com um nome completamente diferente é interessante é porque muitos agentes de ameaças que usam malware os renomeiam para que não chamem tanta atenção e possam ser ocultos no host e executados silenciosamente em segundo plano para que mesmo que o usuário perceba que algo estranho está acontecendo com seu sistema, ele pulará o arquivo pensando que é normal e não acionará nenhum alarme com o usuário e seu AV.

Analisando o código, há uma função de substituição para uma string que observamos anteriormente. Agora que temos certeza sobre o que está substituindo o padrão de ofuscação, podemos verificar quais são essas strings, o que pode nos dar uma pista sobre o que está acontecendo.

Puxando o Fio

Para analisar as strings ofuscadas, usamos o CyberChef . No CyberChef, usamos o recurso `Find/Replace` para realizar a função de substituição encontrada no código. Isso nos permitiu ver o texto claro do que foi ofuscado, o que resultou em uma compreensão mais clara do que estava acontecendo no código.

O resultado final do exercício acima nos deu a versão desofuscada de strings que continham “Load” e “Invoke”. Isso mostrava que algo seria carregado e executado (“invocado”) pelo código contido no executável.

Se, a qualquer momento, você não tiver certeza de quais ações esses métodos executam, a melhor coisa a fazer é pesquisar no Google e encontrar alguns documentos. Pode ser demorado no início, mas é uma parte importante da análise de malware.

Nesta fase da análise, acumulamos descobertas suficientes para começar a esboçar a trajetória do fluxo de execução do malware. Identificamos que o malware estava carregando e executando algo e que o malware estava compactado e continha dados executáveis ​​que veríamos no próximo estágio de análise.

Caça ao Escondido

A ferramenta Garbage Man é usada para análise de heap — uma técnica que permite aos analistas intervir e observar como o malware .NET está se revelando.

A análise do malware no Garbage Man auxiliou na extração de dados ocultos que compunham o segundo executável dentro do primeiro executável.

Para analisar melhor o malware, executamos o malware original encontrado no host no Garbage Man. Para começar, adicionamos um atraso de 300 ms com 10 instantâneos tirados em intervalos de 100 ms.

Adicionamos o atraso para dar tempo para o processo iniciar a execução e adicionamos instantâneos e intervalos extras para que possamos comparar a diferença entre os intervalos, se necessário.

Depois que o Garbage Man executou o arquivo, tínhamos as seguintes opções:

• Pesquise a pilha manualmente e observe as strings e os valores contidos no executável
• Use a função de pesquisa para examinar todos os instantâneos. Procurando especificamente por bytes que começam com o valor de MZ - que é o cabeçalho PE para executáveis ​​e arquivos dll e, em seguida, ordene-os por tamanho em ordem decrescente. A função de pesquisa nos fornece uma lista de resultados e podemos salvar os binários com cabeçalhos MZ e salvá-los para análise posterior.

Estágio Dois

Investigando nosso stage2.exe, descobrimos que a verificação de suas strings destacou algumas APIs Win32 notáveis ​​que o malware utiliza . Algumas APIs que saltaram foram conectadas com processos de manipulação [ T1055 ], especificamente neste caso, esvaziamento de processo [ T1055.012 ] — uma técnica adversária para criar um processo legítimo pausado e, em seguida, trocar sua memória por conteúdo malicioso.

Como nosso estágio dois estava no mundo .NET novamente, usamos o dnSpy para ir um pouco mais fundo. Ao abrir o executável, encontramos muitas informações que tínhamos que passar. Como no primeiro estágio, a convenção de nomenclatura do segundo estágio também era suspeita.

Examinando a saída do dnSpy, descobrimos uma seção completamente diferente das outras partes do código devido ao fato de ser ofuscada e aparentemente executar uma função na memória - ambas técnicas usadas para evitar a detecção [ T1140 ] .

Usamos o Garbage Man mais uma vez para observar sorrateiramente como o malware se desvendou. No entanto, se você deseja uma técnica alternativa para desofuscar esta parte do código, pode usar de4dot , que também pode colocá-lo em um formato mais fácil de ler.

Em seguida, em Garbage Man, o objetivo era recuperar o terceiro estágio oculto. Nossa técnica anterior poderia ser implantada aqui novamente, executando o binário e procurando os cabeçalhos MZ.

Encontramos um executável e o salvamos como “stage3.exe”. Em seguida, empacotamos e enviamos para o PEstudio (também há informações sobre procexp.sys contidas aqui, mas não vamos nos concentrar nisso neste momento).

Estágio três

Ao verificar o executável do terceiro estágio no PEstudio, observamos novamente que era um arquivo .NET e que continha strings e APIs que sugeriam que ele estava tentando fazer uma conexão de rede com uma fonte externa — como a API Send . Essa foi uma grande dica de que se tratava de um Trojan de acesso remoto; Sinto cheiro de RATO [ TA0011 ]!

Depois de dar uma olhada rápida nas strings do estágio três através do PEstudio, voltamos para o velho e confiável dnSpy. Percorrendo o estágio três, identificamos que a criptografia AES foi usada para codificar a porta e o IP/domínio que compunham o comando e controle do adversário (C2). Com certeza estávamos lidando com um RAT e queríamos reunir os IoCs associados a essa criptografia.

Definimos um ponto de interrupção no dnSpy onde a descriptografia AES foi executada e, em seguida, executamos o depurador para encontrar a string descriptografada. O uso de uma técnica 'stop-start' com pontos de interrupção em um depurador permite que um analista de malware interrompa o malware em momentos oportunos enquanto ele se decodifica ou descriptografa. Isso nos permite entender o que o malware está fazendo enquanto o faz.

Quando chegamos ao nosso ponto de interrupção, ele interrompeu a execução do malware. Agora, permitimos cuidadosamente que o malware progredisse uma etapa por vez usando o botão de etapa. Fizemos isso até que o malware começou sua fase de descriptografia e recebemos as portas usadas por este RAT.

Quando passamos pelas diferentes seções, pudemos ver que para este RAT ele estava usando as portas “6606, 7707, 8808” e, eventualmente, desvendamos o RAT até que ele nos entregasse o servidor adversário ao qual reportava: “109.206.241 [.]84”.

Defendendo-se contra RATs

Nossas correções variam, mas a primeira etapa é recomendar o bloqueio desse IPv4 público no nível do firewall da organização para que o RAT não possa mais sinalizar.

O conselho para se defender contra RATs é realmente um conselho para malware em geral:

• O principal conselho é treinar a equipe para verificar o que está baixando. Seja de um anexo de e-mail ou de um site que promete acelerar o funcionamento do computador se eles executarem algo, o treinamento de conscientização de segurança é a melhor e primeira camada de defesa que recomendamos que você priorize.
• Aproveite a telemetria de rede para tentar monitorar atividades inesperadas. Quer se trate de VPN, firewall ou fluxo de rede mais focado em segurança, ficar de olho no tráfego de entrada e saída ajudará a detectar comportamentos anômalos. Além disso, cultivar uma lista de negação bem mantida para endereços maliciosos novos e emergentes só pode ser uma coisa boa.
• Boas ferramentas de segurança são inimigas perfeitas de nossos adversários. Implante o que funciona para sua organização, apenas implante algo . Uma máquina sem qualquer solução de segurança é uma máquina que apresenta um risco inadministrável e inaceitável para o seu negócio.

Big thanks to Matthew Brennan and Chad Hudson for help and guidance. 
Hopefully this writeup has helped show examples of some good tools and 
techniques that can be used to help decrypt and understand what is going on 
with other .NET executables in the future.