DESMANTELANDO BLACKENERGY, PARTE 2 – “A MARCA”

Eu não vou fazer um discurso sobre o que é uma estrutura BlackEnergy, já que muito foi escrito sobre isso e sem a minha participação, no entanto, quero me referir às informações deste revisão em particular:

Pessoal, conheçam o Flashplayer!

Durante a investigação do ataque à nossa infraestrutura, detectamos várias amostras de malware, entre elas Flashplayerapp.exe (https://www.virustotal.com/ru/file/c787166ad731131c811d1a63080ac871ec11f10bcd77b9a1e665f1c9bbaa9a54/analysis/)Brevemente, o flashplayerapp extrai main_light.dll em seu próprio espaço de memória e transfere o controle para ele. Esta biblioteca é uma versão leve do BlackEnergy utilizada para comunicação C&C para baixar a carga principal com funcionalidade dependendo dos objetivos perseguidos pelo atacante. Ele cria um arquivo: C:UsersuserAppdataAdobecache.datEnquanto criptografado, este arquivo contém várias informações, incluindo a versão do build (como 2015lstb), endereço do comando e controle a partir do qual pode-se recuperar várias cargas (como hxxps://188.40.8.72/l7vogLG/BVZ99/rt170v/solocVI/eegL7p.php) etc. Enquanto eu examinava esta amostra, mudei o foco do C&C, pois uma parte específica do código chamou minha atenção, sendo um sinal óbvio do uso de uma técnica chamada permutação de código. Deixe-me traduzir uma citação desta fonte http://hacks.clan.su/publ/11-1-0-481:

Assim, é assim que o fragmento de código parecia (as instruções adicionadas pelo motor de permutação estão destacadas em vermelho e não afetam a funcionalidade de forma alguma, apenas tornam o código mais difícil de entender):Ao remover as strings desnecessárias, obtemos um mecanismo que processa todos os nomes de funções em kernel32.dlltransformando-os (os nomes) em alguma forma de hash que depois os compara com algum valor:Vamos recriar este mecanismo usando C como exemplo. Como resultado, recebemos uma utilidade que pode produzir para nós um ‘dicionário’ que contém nomes de todas as funções na biblioteca kernel32.dll e valores de hash desses nomes. Vamos tentar buscar os valores de hash que obtivemos durante a análise reversa do código em nosso novo ‘dicionário’. Primeiro, buscamos pelo valor do registrador EAX (0x5147F60F) e depois comparamos com o valor de referência:Nossa teoria está funcionando: nossa amostra processou o nome da primeira função, criou o hash e agora está comparando-o com o valor de referência contido no buffer (0xC8AC8026). Procuramos esse valor e eis que… encontramos a função LoadLibraryA!Para pular outro exemplo de parede de texto, mencionarei apenas que nossa ‘amostra’ usa a mesma abordagem para procurar outra função chamada GetProcAdress.Usando essas duas funções, nossa ‘amostra’ pode carregar outras bibliotecas e extrair os endereços das funções que necessita.

Os traços deixados pelo Motor

A técnica de tornar a análise de código estática difícil via chamada de função baseada em algum valor de hash em vez de seu nome não é nova. No entanto, ela me levou ao seguinte pensamento: independentemente de como o código malicioso é processado, sabemos o algoritmo de hashing dos nomes das funções e, assim, podemos procurar com confiança por essas duas funções (LoadLibraryA e GetProcAdress) no código. Portanto, comecei a procurá-los na internet para saber se alguém já havia usado o mesmo motor do nosso exemplo antes e, para minha surpresa, encontrei algo:0xC8AC8026) para ver se alguém usou o mesmo motor do nosso exemplo antes e para minha surpresa, encontrei algo:Este hash é mencionado pela primeira vez durante 2006 (o artigo só pode ser encontrado no archive.org): https://web.archive.org/web/20060614030412/http://osix.net/modules/article/?id=789

Mais tarde, em 2008, um possível autor do algoritmo faz uma aparição no fórum:https://exelab.ru/f/index.php?action=vthread&forum=6&topic=11845

Depois disso, em 2009, um artigo de análise sobre shellcode MS08-067 é publicado em blogs.technet.com:  http://blogs.technet.com/b/srd/archive/2009/06/05/shellcode-analysis-via-msec-debugger-extensions.aspx

Então, em 2013, a revista ‘XAKEP’ (uma das maiores mídias russas em TI e Segurança da Informação) publica um artigo https://xakep.ru/2011/06/23/55780/ onde mencionam exatamente o mesmo algoritmo que cria o mesmo hash (!):Espere um segundo, a situação que temos aqui é que o mesmo algoritmo que gera os mesmos valores de hash está em uso há mais de 10 anos e ainda assim ninguém notou isso? Caso contrário, para o flashplayerapp.exe (https://www.virustotal.com/ru/file/c787166ad731131c811d1a63080ac871ec11f10bcd77b9a1e665f1c9bbaa9a54/analysis/) sendo o mesmo como aparece agora, seria impossível passar despercebido pelas soluções antivírus enquanto já vivemos no ano de 2016:Há uma clara ‘marca’ deixada por este motor de permutação concreto que foi usado em nossa amostra analisada e que parece uma assinatura válida para mim. Além disso, é bastante fácil de rastrear diretamente no texto claro:Bem, temos nossas suposições e a teoria está alinhada, então vamos seguir para a prática e tentar transformar nossas conclusões em uma assinatura/regra Yara:

rule API_Hash

{meta: description = “Hash of LoadLibrary that is {26 80 ac c8} e GetProcAddres {ee ea c0 1f}”

strings:

$a = {26 80 ac c8}

$b = {ee ea c0 1f}

condição: $a e $b

}

A única coisa que resta a fazer agora é testá-la em várias amostras diferentes (por exemplo, de um laboratório antivírus) para descobrir exatamente quanto código malicioso foi compactado por este motor de verdade?
Neste ponto, só posso declarar que foi possível realizar o experimento em uma quantidade muito pequena de amostras em uma das empresas de antivírus, mas os resultados valem a pena! Entre as amostras capturadas, temos:Win32/Spy.Bebloh (trojan bancário) — http://www.virusradar.com/en/Win32_Spy.Bebloh/detailWin32/PSW.Fareit (Trojan para roubar senhas) — http://www.virusradar.com/en/Win32_PSW.Fareit/detailWin32/Rustock (Backdoor) — http://www.virusradar.com/en/Win32_Rustock/detailWin32/TrojanDownloader.Carberp (Dropper que instala Trojan bancário Carberp) — http://www.virusradar.com/en/Win32_TrojanDownloader.Carberp/detailWin32/Kelihos (Remetente de spam) — http://www.virusradar.com/en/Win32_Kelihos/detailEsta lista contém apenas famílias bem conhecidas. Esses dois valores de hash também aparecem em outras famílias de malware, incluindo Ransomware/encriptores de arquivos (Win32/Filecoder.HydraCrypt), um minerador de Bitcoin (CoinMiner.LC), um WinLocker (LockScreen.AQT) e outros.

Até agora, também posso adicionar que esta regra Yara de aparência bastante simples não levou a um único falso positivo até a data, mas os testes foram conduzidos apenas em algumas dezenas de computadores. Portanto, realmente expresso minhas esperanças de que após a publicação desta pesquisa, Você (!) e aqueles que leram até aqui compartilharão seus feedbacks, que serão grandes o suficiente para provar ou desaprovar a precisão desta regra! Claro, usar apenas oito bytes para uma assinatura é excepcionalmente pequeno e a regra provavelmente captará alguns arquivos ‘legítimos’. No entanto, esta regra Yara leve pode viver em uma sandbox como parte de uma lógica de análise mais complexa.

Conclusões

O objetivo deste artigo não é a engenharia reversa do malware BlackEnergy, mas sim destacar o fato de que ferramentas usadas durante a montagem de um ou outro código de malware deixam suas marcas e podem levar ao surgimento de indicadores úteis que podem ser usados para a defesa. E esses indicadores podem permanecer despercebidos por bastante tempo…

Traduzido do original por Andrii Bezverkhyi | CEO SOC Prime