RATKing: nova campanha com Trojans de acesso remoto
No final de maio, descobrimos uma campanha para distribuir malware Trojan de acesso remoto (RAT), programas que permitem que invasores controlem remotamente um sistema infectado.
O grupo que examinamos se destacou pelo fato de não ter selecionado nenhuma família específica de RAT para infecção. Vários Trojans foram detectados em ataques dentro da campanha (todos amplamente disponíveis). Com essa característica, o grupo nos lembrou o rei rato – animal mítico que consiste em roedores com caudas entrelaçadas.
O original foi retirado da monografia de K. N. Rossikov “Ratos e roedores semelhantes a camundongos, os mais importantes economicamente” (1908)
Em homenagem a esta criatura, nomeamos o grupo que estamos considerando RATKing. Nesta postagem, entraremos em detalhes sobre como os invasores realizaram o ataque, quais ferramentas eles usaram e também compartilharemos nossa opinião sobre a atribuição para esta campanha.
Progresso do ataque
Todos os ataques nesta campanha ocorreram de acordo com o seguinte algoritmo:
O usuário recebeu um e-mail de phishing com um link para o Google Drive.
Usando o link, a vítima baixou um script VBS malicioso que especificava uma biblioteca DLL para carregar a carga final no registro do Windows e iniciou o PowerShell para executá-la.
A biblioteca DLL injetou a carga final – na verdade, um dos RATs usados pelos invasores – no processo do sistema e registrou um script VBS na execução automática para obter uma posição segura na máquina infectada.
A carga final foi executada em um processo do sistema e deu ao invasor a capacidade de controlar o computador infectado.
Esquematicamente pode ser representado assim:
A seguir, focaremos nas três primeiras etapas, pois estamos interessados no mecanismo de entrega do malware. Não descreveremos em detalhes o mecanismo de operação do malware em si. Eles estão amplamente disponíveis - sejam vendidos em fóruns especializados ou mesmo distribuídos como projetos de código aberto - e, portanto, não são exclusivos do grupo RATKing.
Análise das etapas do ataque
Etapa 1. E-mail de phishing
O ataque começou com a vítima recebendo uma carta maliciosa (os invasores usaram diferentes modelos de texto; a captura de tela abaixo mostra um exemplo). A mensagem continha um link para um repositório legítimo drive.google.com, o que supostamente levou a uma página de download de documentos PDF.
Exemplo de e-mail de phishing
No entanto, na verdade, não foi um documento PDF carregado, mas um script VBS.
Quando você clicou no link do e-mail na captura de tela acima, um arquivo chamado Cargo Flight Details.vbs. Nesse caso, os invasores nem sequer tentaram disfarçar o arquivo como um documento legítimo.
Ao mesmo tempo, como parte desta campanha, descobrimos um script chamado Cargo Trip Detail.pdf.vbs. Já poderia passar por um PDF legítimo porque o Windows oculta as extensões de arquivo por padrão. É verdade que, neste caso, a suspeita ainda poderia ser levantada pelo seu ícone, que correspondia ao script VBS.
Nesse estágio, a vítima poderia reconhecer o engano: basta olhar mais de perto os arquivos baixados por um segundo. No entanto, nessas campanhas de phishing, os invasores geralmente contam com um usuário desatento ou apressado.
Estágio 2. Operação de script VBS
O script VBS, que o usuário poderia abrir inadvertidamente, registrou uma biblioteca DLL no registro do Windows. O script foi ofuscado: as linhas nele foram escritas como bytes separados por um caractere arbitrário.
Exemplo de um script ofuscado
O algoritmo de desofuscação é bastante simples: cada terceiro caractere foi excluído da string ofuscada, após o que o resultado foi decodificado da base16 na string original. Por exemplo, do valor 57Q53s63t72s69J70r74e2El53v68m65j6CH6Ct (destacado na imagem acima) a linha resultante foi WScript.Shell.
Para desofuscar strings, usamos a função Python:
def decode_str(data_enc):
return binascii.unhexlify(''.join([data_enc[i:i+2] for i in range(0, len(data_enc), 3)]))
Abaixo, nas linhas 9 a 10, destacamos o valor cuja desofuscação resultou em um arquivo DLL. Foi ele quem foi lançado na próxima etapa usando o PowerShell.
String com DLL ofuscada
Cada função no script VBS foi executada à medida que as strings eram desofuscadas.
Após executar o script, a função foi chamada wscript.sleep — foi usado para realizar execução diferida.
Em seguida, o script funcionou com o registro do Windows. Ele usou a tecnologia WMI para isso. Com sua ajuda, uma chave exclusiva foi criada e o corpo do arquivo executável foi gravado em seu parâmetro. O registro foi acessado via WMI usando o seguinte comando:
No terceiro estágio, a DLL maliciosa carregou a carga final, injetou-a no processo do sistema e garantiu que o script VBS fosse iniciado automaticamente quando o usuário efetuasse login.
Execute via PowerShell
A DLL foi executada usando o seguinte comando no PowerShell:
recebeu dados de valor de registro com nome rnd_value_name — esses dados eram um arquivo DLL escrito na plataforma .Net;
carregou o módulo .Net resultante na memória do processo powershell.exe usando a função [System.Threading.Thread]::GetDomain().Load()(descrição detalhada da função Load() disponível no site da Microsoft);
desempenhou a função GUyyvmzVhebFCw]::EhwwK() - a execução da biblioteca DLL começou com ele - com parâmetros vbsScriptPath, xorKey, vbsScriptName. Parâmetro xorKey armazenou a chave para descriptografar a carga final e os parâmetros vbsScriptPath и vbsScriptName foram transferidos para registrar um script VBS na execução automática.
Descrição da biblioteca DLL
Na forma descompilada, o bootloader ficou assim:
Carregador em formato descompilado (a função com a qual a execução da biblioteca DLL começou está sublinhada em vermelho)
O bootloader é protegido pelo protetor .Net Reactor. O utilitário de4dot faz um excelente trabalho ao remover esse protetor.
Este carregador:
injetou a carga útil no processo do sistema (neste exemplo, svchost.exe);
Adicionei um script VBS para execução automática.
Injeção de carga útil
Vejamos a função que o script do PowerShell chamou.
Função chamada pelo script do PowerShell
Esta função executou as seguintes ações:
descriptografou dois conjuntos de dados (array и array2 na captura de tela). Eles foram originalmente compactados usando gzip e criptografados com o algoritmo XOR com a chave xorKey;
dados copiados para áreas de memória alocadas. Dados de array - para a área de memória apontada intPtr (payload pointer na captura de tela); dados de array2 - para a área de memória apontada intPtr2 (shellcode pointer na captura de tela);
chamada de função CallWindowProcA(описание Esta função está disponível no site da Microsoft) com os seguintes parâmetros (os nomes dos parâmetros estão listados abaixo, na captura de tela eles estão na mesma ordem, mas com valores funcionais):
lpPrevWndFunc - ponteiro para dados de array2;
hWnd — ponteiro para uma string contendo o caminho para o arquivo executável svchost.exe;
Msg - ponteiro para dados de array;
wParam, lParam — parâmetros de mensagem (neste caso, esses parâmetros não foram utilizados e tinham valores 0);
criou um arquivo %AppData%MicrosoftWindowsStart MenuProgramsStartup<name>.urlOnde <name> - estes são os primeiros 4 caracteres do parâmetro vbsScriptName (na captura de tela, o fragmento de código com esta ação começa com o comando File.Copy). Dessa forma, o malware adicionava um arquivo URL à lista de arquivos de execução automática quando o usuário fazia login e, assim, se conectava ao computador infectado. O arquivo URL continha um link para o script:
Para entender como a injeção foi realizada, descriptografamos as matrizes de dados array и array2. Para fazer isso usamos a seguinte função Python:
def decrypt(data, key):
return gzip.decompress(
bytearray([data[i] ^ key[i % len(key)] for i in range(len(data))])[4:])
Como resultado, descobrimos que:
array era um arquivo PE - esta é a carga final;
array2 era o shellcode necessário para realizar a injeção.
Shellcode de uma matriz array2 passado como um valor de função lpPrevWndFunc em uma função CallWindowProcA. lpPrevWndFunc — função de retorno de chamada, seu protótipo é assim:
Então, quando você executa a função CallWindowProcA com parâmetros hWnd, Msg, wParam, lParam shellcode do array é executado array2 com argumentos hWnd и Msg. hWnd é um ponteiro para uma string contendo o caminho para o arquivo executável svchost.exeE Msg — ponteiro para a carga final.
O shellcode recebeu endereços de função de kernel32.dll и ntdll32.dll com base nos valores de hash de seus nomes e injetou a carga final na memória do processo svchost.exeusando a técnica Process Hollowing (você pode ler mais sobre isso neste статье). Ao injetar o shellcode:
criou um processo svchost.exe em estado suspenso usando a função CreateProcessW;
em seguida, ocultou a exibição da seção no espaço de endereço do processo svchost.exe usando a função NtUnmapViewOfSection. Assim, o programa liberou a memória do processo original svchost.exepara então alocar memória para a carga neste endereço;
memória alocada para a carga útil no espaço de endereço do processo svchost.exe usando a função VirtualAllocEx;
Início do processo de injeção
escreveu o conteúdo da carga útil no espaço de endereço do processo svchost.exe usando a função WriteProcessMemory (como na imagem abaixo);
retomou o processo svchost.exe usando a função ResumeThread.
Concluindo o processo de injeção
Malware para download
Como resultado das ações descritas, um dos vários malwares da classe RAT foi instalado no sistema infectado. A tabela abaixo lista o malware usado no ataque, que podemos atribuir com segurança a um grupo de invasores, uma vez que as amostras acessaram o mesmo servidor de comando e controle.
Exemplos de malware distribuído com o mesmo servidor de controle
Duas coisas são dignas de nota aqui.
Em primeiro lugar, o próprio facto de os atacantes terem utilizado várias famílias de RAT diferentes ao mesmo tempo. Esse comportamento não é típico de grupos cibernéticos bem conhecidos, que geralmente usam aproximadamente o mesmo conjunto de ferramentas que lhes são familiares.
Em segundo lugar, o RATKing usou malware que é vendido em fóruns especializados por um preço baixo ou é até mesmo um projeto de código aberto.
Uma lista mais completa de malwares usados na campanha – com uma ressalva importante – é fornecida no final do artigo.
Sobre o grupo
Não podemos atribuir a campanha maliciosa descrita a nenhum invasor conhecido. Por enquanto, acreditamos que estes ataques foram realizados por um grupo fundamentalmente novo. Como escrevemos no início, chamamos isso de RATKing.
Para criar o script VBS, o grupo provavelmente utilizou uma ferramenta semelhante ao utilitário Criptografia VBS do desenvolvedor NYAN-x-CAT. Isto é indicado pela semelhança do script que este programa cria com o script dos invasores. Especificamente, ambos:
executar execução atrasada usando a função Sleep;
usar WMI;
registre o corpo do arquivo executável como um parâmetro de chave de registro;
execute este arquivo usando o PowerShell em seu próprio espaço de endereço.
Para maior clareza, compare o comando do PowerShell para executar um arquivo do registro, que é usado por um script criado usando VBS-Crypter:
Observe que os invasores usaram outro utilitário do NYAN-x-CAT como uma das cargas - LimãoRAT.
Os endereços dos servidores C&C indicam outra característica distintiva do RATKing: o grupo prefere serviços DNS dinâmicos (veja a lista de C&Cs na tabela IoC).
COI
A tabela abaixo fornece uma lista completa de scripts VBS que provavelmente podem ser atribuídos à campanha descrita. Todos esses scripts são semelhantes e executam aproximadamente a mesma sequência de ações. Todos eles injetam malware da classe RAT em um processo confiável do Windows. Todos eles possuem endereços C&C registrados por meio de serviços de DNS dinâmico.
No entanto, não podemos afirmar que todos esses scripts foram distribuídos pelos mesmos invasores, com exceção de amostras com os mesmos endereços C&C (por exemplo, kimjoy007.dyndns.org).