Hoje falaremos sobre uma nova abordagem para enviar malware ao grupo Buhtrap.

Módulo do carregador de inicialização
Em 19 de dezembro, tomamos conhecimento de uma correspondência mal-intencionada contendo um arquivo executável (
md5: faf833a1456e1bb85117d95c23892368 ). O arquivo recebeu vários nomes: “Reconciliação para December.exe”, “Docs wednesday.exe”, “Documents 19.12.exe”, “Fechando documentos wednesday.exe”.
De interessante - o arquivo está escrito em .Net, o que não é típico para este grupo criminoso. Para descompilar .Net, você pode
usar qualquer software:
Refletor ,
dotPeek ,
dnSpy ,
ILSpy . No artigo, falaremos sobre os recursos da implementação deste arquivo e como o analisamos.
Inspeção inicial do carregador de inicialização
Para análise, usamos o
dnSpy , e todas as outras capturas de tela serão dele.
Por hábito, abra o executável no
IDA Pro e consulte a seção de importação. Exemplos:

A presença de algumas funções sugere a presença de uma carga útil compactada (
LoadCursorW ,
LoadIconW - obteve o objeto dos recursos,
VirtualProtect - alterou os atributos da página e, em seguida, você pode executar o código) e uma simples anti-depuração (
IsDebuggerPresent ). Mas tudo acabou sendo ainda mais simples. A execução nem chegou a IsDebuggerPresent, e LoadCursorW e LoadIconW funcionaram inutilmente porque tentaram acessar recursos inexistentes (LoadCursorW de "
fiza " e LoadIconW de "
saxikulatebutohutejijobodugore "):


Mas voltando ao descompilador
dnSpy . No arquivo executável, vemos uma quantidade significativa de código não gerenciado:

Para entender o código não gerenciado no arquivo sob investigação, usaremos o IDA Pro. A maneira mais fácil é exibir o corpo do código não gerenciado em formato hexadecimal. Para fazer isso, vá para o deslocamento do arquivo de deslocamento. Usando a função
_main () como exemplo:


Em seguida, no
IDA Pro, procuraremos por sequência hexadecimal:

Na saída, obtemos a função não gerenciada _main (), com a qual você pode trabalhar convenientemente com a ajuda do descompilador idov:


Obtendo carga útil
De volta ao dnSpy. Atenção é chamada para a variável
payloadData .


Encontramos essa sequência no IDA Pro, obtemos links para ela e descobrimos que a chamada ocorre apenas na função
_main () :

O código descompilado usando esse buffer se parece com o seguinte:

As seguintes funções são responsáveis pela conversão desse buffer:

Aqui, a variável
holdrand é
inicializada em
0xEA48CB16 e a função
foo () é chamada em um loop para cada byte de
payloadData (
parâmetro sbyte c ). Deve-se observar que a função t () é de um código não seguro: se você olhar para o código, pode garantir que ela sempre retorne
0x343FD .
Nós nos armamos com o IDA Pro e, observando o buffer descompactado resultante, percebemos que ele contém algum código no início:

No deslocamento
0x15A0 desde o início do buffer, um arquivo executável está localizado:

Salve-o para análise posterior.
Bem, no próprio código executável, uma coisa bastante trivial é implementada. Primeiro, a seguinte estrutura é formada (
aqui mz_base é o endereço de deslocamento no buffer com o PE descompactado e os campos restantes são os endereços das funções e identificadores de biblioteca necessários ):

E, usando as funções obtidas, o processo do mesmo arquivo executável é criado (
md5: faf833a1456e1bb85117d95c23892368 ) e o executável descompactado é mapeado para os endereços virtuais do novo processo. Após alterar o endereço da instrução executável (pacote
GetThreadContext e
SetThreadContext ), o encadeamento do novo processo é iniciado e o próprio processo pai é eliminado.
Bem, agora nos voltamos para a análise do arquivo executável resultante (carga útil).
Desembalagem da carga útil
A carga útil (
despejo md5: d8f40c7060c44fab57df87ab709f058f ) também é gravada no .Net Framework.
Para se proteger contra análises estáticas e dinâmicas, os desenvolvedores de
malware usaram o mais recente protetor
ConfuserEx popular:
O ConfuserEx é um protetor de código aberto bem estabelecido.
Desembalagem primária
O ponto de entrada dos arquivos protegidos por este protetor é o seguinte:

Após a descriptografia, a matriz de bytes é carregada na memória na forma de um módulo chamado
koi . Em seguida, o método principal deste módulo é determinado e chamado. Na plataforma .Net, um método ou construtor em um módulo pode ser obtido do token de metadados chamando a função
Module.ResolveMethod () . Para transferir o controle para o método obtido, a função
MethodBase.Invoke () é usada.

O código executável no módulo
koi é o seguinte:

Para remover a banda de rodagem, usamos os seguintes utilitários:
O ConfuserEx-Unpacker descriptografou as linhas e o código dentro dos métodos, e
de4dot tornou os nomes dos métodos legíveis.
O resultado é um código adequado para análise estática:

Obviamente, tivemos a sorte de obter código legível. Os criadores de vírus podem modificar o código-fonte do passo
ConfuserEx para complicar ainda mais a análise.
Ainda existem dois problemas que precisaram ser resolvidos para uma análise confortável do arquivo.
1º problema
Após remover a banda de rodagem, o decompilador não pôde analisar alguns dos métodos. Por exemplo:

Se você alternar para o código IL, notará chamadas em ponteiros nulos:

Para corrigir erros de descompilação, substitua as instruções incorretas pelas instruções nop. (O utilitário
dnSpy permite modificar o código descompilado e o código IL.)
Após a substituição, o código descompilado parece correto:

Alterando o código IL em todos os métodos problemáticos, obtivemos um arquivo totalmente descompilado.
Segundo problema
É improvável que o arquivo resultante seja iniciado e isso exclui a possibilidade de análise dinâmica. Para resolver esse problema, você deve especificar o token do método de entrada na estrutura do arquivo executável.
Você pode encontrá-lo de duas maneiras:
- procure em depuração com qual parâmetro a função foi chamada
Module.ResolveMethod () antes de descompactar o arquivo:

- no arquivo descompactado, encontre o método com o rótulo [STAThread] :

Nesse caso, o token de metadados para o método de entrada é
0x6000106 . Nós o
alteramos usando o utilitário
CFF Explorer :

Após salvar as alterações, o arquivo descompactado é iniciado e depurado corretamente.
Análise do carregador de inicialização
Imediatamente após o início do trabalho, o carregador de inicialização verifica se está sendo executado em um ambiente virtual.
A execução no
VMWare ou
QEMU é determinada pesquisando as substrings "vmware" e "qemu" no seguinte valor do registro:
- [HKLM \ System \ CurrentControlSet \ Services \ Disk \ Enum \ 0].
Se uma máquina virtual for detectada, o carregador de inicialização exibirá a mensagem da janela correspondente:

Curiosamente, a saída desta mensagem não afeta a operação do processo.
Depois disso, o malware tenta carregar as bibliotecas da lista a seguir na memória:
SbieDll.dll, dbghelp.dll, api_log.dll, dir_watch.dll, pstorec.dll, vmcheck.dll, wpespy.dll, snxhk.dll, guard32.dll .
Além disso, usando as chamadas para as funções
Debugger.IsLogging () e
Debugger.get_IsAttached () , o carregador verifica se está sendo executado no depurador.
Se pelo menos uma das bibliotecas for carregada com sucesso ou o carregador detectar que está sendo executado no depurador, ele será
excluído automaticamente usando o comando “
cmd / C ping 8.8.8.8 -n 1 -w 3000> Nul & Del ”. Curiosamente, o gerenciador de inicialização pode excluir
automaticamente mesmo em um sistema real carregando a biblioteca
dbghelp.dl l.
Em seguida, o malware verifica se é iniciado a partir do diretório que contém a substring "Mozilla".
Se o processo não for iniciado no diretório que contém a substring "Mozilla"
- O malware cria uma lista de diretórios localizados na área de trabalho e contém as seguintes substrings (todas as linhas dentro do gerenciador de inicialização são criptografadas usando o algoritmo AES-256-ECB, as chaves de criptografia são geradas usando senhas codificadas):

- Gera uma lista de URLs do histórico do navegador que contêm as seguintes substrings:

- Gera uma lista de arquivos localizados nos diretórios "% UserProfile% \\ Desktop", "% AppData%", "C: \\ Arquivos de Programas (x86)", "C: \\ Arquivos de Programas (x86) (x86)" e tem os seguintes nomes:

- Conta o número de listas não vazias de indicadores relacionados às operações bancárias (na versão atual do gerenciador de inicialização, essa funcionalidade não afeta nada).
- Cria uma tarefa para executar esse arquivo sempre que um usuário efetua login usando o comando "schtasks / create / f / sc ONLOGON / RL HIGHEST / tn LimeRAT-Admin / tr".
- Se a tarefa não pôde ser criada, cria o atalho "% AppData% \\ Microsoft \\ Windows \\ Menu Iniciar \\ Programas \\ Inicialização \\ MozillaUpdate.lnk", indicando "% Appdata% \\ Mozilla \\ xaudiodg.exe" , que garante que o arquivo xaudiodg.exe seja iniciado sempre que o sistema for reiniciado.
- Ele se copia no caminho "% AppData% \\ Mozilla \\ xaudiodg.exe".
- Exclui o arquivo <self_path>: Zone.Identifier, executa xaudiodg.exe e exclui automaticamente.
Se o processo for iniciado a partir do diretório que contém a substring "Mozilla"
- O malware também procura os indicadores acima de operações bancárias no sistema infectado.
- Coleta outras informações do sistema para enviar ao servidor de gerenciamento.
- Em um thread separado, envia informações ao C&C e aguarda uma resposta do servidor.
- Em outro segmento, ele envia uma sequência criptografada "PING?" Para o servidor em um loop sem fim.
Interação com o servidor de gerenciamento
O endereço IP do servidor na amostra de malware testada é 213.252.244 [.] 200. A conexão é inicializada por uma porta selecionada aleatoriamente da lista:
• 8989,
• 5656,
2323.
Imediatamente após a conexão ser inicializada, o carregador de inicialização envia informações sobre o sistema infectado ao C&C:
• ID do usuário,
Nome de usuário
• versão do sistema operacional,
• sua própria versão (loader v0.2.1),
• listas de indicadores de operações bancárias encontradas no sistema infectado.
Um exemplo de linha enviada pelo carregador ao servidor de gerenciamento:
«INFO<NYANxCAT>9D3A4B22D21C<NYANxCAT>IEUser<NYANxCAT> Windows 7 Enterprise SP 1 <NYANxCAT>loader v0.2.1<NYANxCAT><NYANxCAT><NYANxCAT>1c, »
Essa linha será enviada se houver uma pasta "1c" na área de trabalho do usuário infectado e não houver outros indicadores.
A função para processar a resposta do servidor é a seguinte:

A resposta descriptografada do servidor é a seguinte:
Como pode ser visto na captura de tela, o COMMAND pode assumir um dos seguintes valores:
- FECHAR - finaliza a conexão e fecha o processo atual;
- DW - decodifica o conteúdo base64 do DATA2 a partir do base64, grava-o no arquivo <temp_file_name> com a extensão do DATA1 e inicia o arquivo para execução;
- UPDATE - decodifica o conteúdo base64 de DATA1, grava-o em um arquivo com o nome <temp_file_name> e a extensão .exe, inicia um novo arquivo executável e se limpa;
- RD- - envia a string "RD-" em resposta;
- RD + - envia uma captura de tela ao servidor de gerenciamento;
- DEL - exclui automaticamente.
Durante a investigação do carregador de inicialização, conseguimos obter o comando DW no servidor atacante. Como resultado, o software Punto Switcher foi instalado com a DLL maliciosa winmm.dll (md5: 9d25553bb09e2785262b2f7ba7923605), que é um módulo de spyware Buhtrap.
O fluxo TCP é o seguinte:


Para criptografar os dados transmitidos entre o cliente e o servidor de gerenciamento, é utilizado o algoritmo
AES-128-ECB . A chave de criptografia é inicializada com uma senha codificada.
Após a descriptografia, o tráfego é o seguinte:


A partir do base64, o instalador do NSIS é decodificado com o seguinte conteúdo:

Curiosamente, o servidor respondeu, embora a lista de indicadores bancários estivesse vazia.
DLL maliciosa
A biblioteca
winmm.dll é executada usando a técnica de seqüestro de dll. O módulo malicioso envia informações sobre o sistema infectado e uma lista de leitores de cartão inteligente ativos para a C&C. Além disso, possui um componente keylogger e pode receber outros módulos maliciosos do servidor de gerenciamento, executá-los a partir do disco ou na memória do processo atual. Os servidores C e C da amostra em estudo estão localizados nos seguintes endereços:
- hxxp: // my1cprovider [.] xyz: 6060 / klog [.] php
- hxxp: // tinderminderorli1999 [.] xyz: 7764 / klog [.] php
Conclusão
O processo de infecção pode ser representado como o seguinte esquema:

Apesar da boa proteção contra a análise, é claro que no momento o gerenciador de inicialização não funciona corretamente e é mais provável no processo de desenvolvimento:
- pode excluir-se mesmo em um sistema real;
- verifica a conexão do sistema infectado com as operações bancárias antes de se copiar para "% AppData% \\ Mozilla \\ xaudiodg.exe" e antes de interagir com a C&C, mas não usa essas informações de forma alguma.
Finalmente, lembre-se da mensagem estranha da janela. Curiosamente, isso é uma falha nos desenvolvedores - ou é feito especificamente para incentivar os usuários a deixar o ambiente virtual e iniciar em uma máquina real? Bem-vindo nos comentários.
COI
MD5:faf833a1456e1bb85117d95c23892368
9d25553bb09e2785262b2f7ba7923605URLs:hxxp: // my1cprovider [.] xyz: 6060 / klog [.] php
hxxp: // tinderminderorli1999 [.] xyz: 7764 / klog [.] php
IPs:
213.252.244 [.] 200