Analisando o Dark Crystal RAT, um backdoor C #

12 de maio de 2020 | por Jacob Thompson

equipe de Inteligência de Ameaça da FireEye Mandiant ajuda a proteger nossos clientes, rastreando os invasores cibernéticos e o malware que eles usam. A equipe do FLARE ajuda a aumentar nossa inteligência de ameaças através de amostras de malware de engenharia reversa. Recentemente, o FLARE trabalhou em uma nova variante C # do Dark Crystal RAT (DCRat) que a equipe de informações sobre ameaças passou para nós. Revisamos a inteligência de código aberto e o trabalho anterior, realizamos testes em sandbox e fizemos a engenharia reversa do Dark Crystal RAT para revisar seus recursos e protocolo de comunicação. Com a publicação desta publicação, nosso objetivo é ajudar os defensores a procurar indicadores de comprometimento e outros sinais reveladores do Dark Crystal RAT e ajudar outros pesquisadores de malware novos no malware .NET ou que encontrarem variantes futuras desse exemplo.

Descobrindo o Dark Crystal RAT

A equipe da Intel de ameaças forneceu ao FLARE uma amostra de EXE, que se acredita conter Dark Crystal RAT, e com o hash MD5 b478d340a787b85e086cc951d0696cb1. Usando o teste de sandbox, descobrimos que esse exemplo produzia dois executáveis ​​e, por sua vez, um desses dois executáveis ​​produzia mais três. A Figura 1 mostra os relacionamentos entre os executáveis ​​maliciosos descobertos por meio do teste de sandbox.


Figura 1: O primeiro exemplo que começamos a analisar produziu cinco executáveis.

Armado com os resultados do sandbox, nossa próxima etapa foi realizar uma análise de triagem em cada executável. Descobrimos que a amostra original e o mnb.exe eram conta-gotas, que dal.exe era um utilitário de limpeza para excluir os arquivos descartados e que daaca.exe e fsdffc.exe eram variantes do Plurox, uma família com relatórios existentes. Em seguida, passamos a analisar a amostra final descartada, que era dfsds.exe. Encontramos relatórios públicos breves do @ James_inthe_box na mesma amostra, identificando-o como DCRat e como um ladrão de credenciais e RAT . Também encontramos uma execução pública em sandbox que incluía a mesma amostra. Outros relatórios públicos descreveram o DCRat, mas na verdade analisaram o componente daaca.exe Plurox junto com o DCRat na amostra inicial.

Satisfeitos por o dfsds.exe ser um RAT sem relatórios públicos detalhados, decidimos realizar uma análise mais profunda.

Analisando o RAT do Dark Crystal

Análise inicial

Afastando-nos da nossa caixa de areia por um momento, realizamos análises estáticas no dfsds.exe. Optamos por iniciar a análise estática usando o CFF Explorer, uma boa ferramenta para abrir um arquivo PE e dividir suas seções em um formulário fácil de visualizar. Depois de visualizar o dfsds.exe no CFF Explorer, como mostra a Figura 2, o utilitário nos mostrou que é um executável .NET. Isso significava que podíamos seguir um caminho muito diferente para analisá-lo do que em uma amostra nativa de C ou C ++. As técnicas que poderíamos ter usado para começar a restringir a funcionalidade de uma amostra nativa, como examinar quais DLLs ele importa e quais funções dessas DLLs ele usa, não produziram resultados úteis para esse exemplo .NET. Conforme mostrado na Figura 3, o dfsds.exe importa apenas a função _CorExeMain do mscoree.dll. Poderíamos ter aberto o dfsds.exe no IDA Pro, mas o IDA Pro geralmente não é a maneira mais eficaz de analisar amostras do .NET; de fato, a versão gratuita do IDA Pro não pode manipular o código intermediário do .NET Common Language Infrastructure (CLI).


Figura 2: O CFF Explorer mostra que o dfsds.exe é um executável do .NET.


Figura 3: A tabela de importação para o dfsds.exe não é útil, pois contém apenas uma função.

Em vez de usar um desmontador como o IDA Pro no dfsds.exe, usamos um descompilador .NET. Felizmente para o engenheiro reverso, os descompiladores operam em um nível mais alto e geralmente produzem uma aproximação aproximada do código C # original. O dnSpy é um ótimo descompilador .NET. A interface do dnSpy exibe uma hierarquia dos namespaces e classes da amostra no Assembly Explorer e mostra o código da classe selecionada à direita. Ao abrir o dfsds.exe, o dnSpy nos informou que o nome original da amostra no momento do link era DCRatBuild.exe e que seu ponto de entrada está em <PrivateImplementationDetails> {63E52738-38EE-4EC2-999E-1DC99F74E08C} .Main, mostrado na Figura 4. Quando navegamos para o método Main usando o Assembly Explorer, encontramos um código semelhante ao C # que representa esse método na Figura 5. Sempre que o dnSpy exibe uma chamada para outro método no código, é possível clicar no nome do método de destino para acessá-lo e visualizar seu código. Clicando com o botão direito do mouse em um identificador no código e clicando em Analisar no menu de contexto, fizemos com que o dnSpy procure todas as ocorrências em que o identificador é usado, semelhante ao uso de referências cruzadas no IDA Pro.


Figura 4: O dnSpy pode nos ajudar a localizar o ponto de entrada da amostra


Figura 5: o dnSpy decompila o método Main em código semelhante ao C #

Fomos ao método SchemaServerManager.Main que é chamado a partir do método do ponto de entrada e observamos que ele faz muitas chamadas para ExporterServerManager.InstantiateIndexer com diferentes argumentos inteiros, como mostra a Figura 6. Navegamos para o método ExporterServerManager.InstantiateIndexer e descobrimos que está estruturado como uma declaração de switch gigante com muitas declarações e rótulos goto; A Figura 7 mostra um trecho. Isso não se parece com a saída típica do dnSpy, pois o dnSpy geralmente reconstrói uma aproximação aproximada do código C # original, embora com a perda de comentários e nomes de variáveis ​​locais. Essa estrutura de código, combinada com o fato de o código se referir à constante CipherMode.CBC , nos levou a acreditar queExporterServerManager.InstantiateIndexer pode ser uma rotina de descriptografia ou desofuscação. Portanto, o dfsds.exe provavelmente está ofuscado. Felizmente, os desenvolvedores .NET geralmente usam ferramentas de ofuscação que são um tanto reversíveis por meios automatizados.


Figura 6: SchemaServerManager.Main faz muitas chamadas para ExporterServerManager.InstantiateIndexer


Figura 7: ExporterServerManager.InstantiateIndexer parece ser uma rotina de desofuscação

Desobuscação

De4dot é um desobfuscador .NET que sabe como desfazer muitos tipos de ofuscações. A execução de de4dot -d (for detect) no dfsds.exe (Figura 8) nos informou que o .NET Reactor foi usado para ofuscá-lo.

> de4dot -d dfsds.exe

de4dot v3.1.41592.3405 Copyright (C) 2011-2015 [email protected]
Versão e código fonte mais recentes: https://github.com/0xd4d/de4dot

Reator .NET detectado (C:\…\dfsds.exe)

Figura 8: dfsds.exe é ofuscado pelo .NET Reactor

Após confirmar que o de4dot pode desobstruir o dfsds.exe, o executamos novamente para desobstruir a amostra no arquivo dfsds_deob.exe (Figura 9).

> de4dot -f dfsds.exe -o dfsds_deob.exe

de4dot v3.1.41592.3405 Copyright (C) 2011-2015 [email protected]
Versão e código fonte mais recentes: https://github.com/0xd4d/de4dot

Reator .NET detectado (C:\Usuários\usuário\Desktop\intelfirst\dfsds.exe)
Limpando C:\Usuários\usuário\Desktop\intelfirst\dfsds.exe
Renomeando todos os símbolos ocultos
Salvando C:\Users\usuário\Desktop\intelfirst\dfsds_deob.exe

Figura 9: de4dot desobstrui com êxito o dfsds.exe

Após desobstruir o dfsds.exe, executamos o dnSpy novamente no dfsds_deob.exe resultante. Quando descompilamos SchemaServerManager.Main novamente, os resultados foram muito diferentes, conforme mostrado na Figura 10. Contrastando a nova saída com a versão ofuscada mostrada anteriormente na Figura 6, encontramos o código desofuscado muito mais legível. Na versão desofuscada, todas as chamadas para ExporterServerManager.InstantiateIndexer foram removidos; como suspeito, aparentemente era uma rotina de decodificação de strings. Por outro lado, os nomes de classe mostrados no Assembly Explorer não foram alterados; o ofuscador deve ter substituído irrecuperavelmente os nomes das classes originais por nomes sem sentido, obtidos de uma lista padrão. Em seguida, observamos que dez linhas na Figura 10 contêm dados codificados em base64. Depois que a amostra foi removida com êxito, chegou a hora de extrair sua configuração e seguir o caminho do código da amostra até seus recursos de persistência e sinalizador inicial.


Figura 10: Desofuscando o dfsds.exe mostra que o método começa com alguma manipulação de caminho e acessa dados codificados em Base64

Configuração, Persistência e Beacon Inicial

Lembre-se de que na Figura 10 descobrimos que o método SchemaServerManager.Main possui uma variável local que contém dados codificados em Base64; decodificar esses dados revelou o que eles contêm. A Figura 11 mostra a configuração decodificada (com os URLs dos terminais C2 desamarrados):

> Echo TUhvc3Q6aHR0cDovL2RvbWFsby5vbmxpbmUva3NlemJseGx2b3Uza2NtYnE4bDdoZjNmNGN5NXhnZW
80dWRsYTkxZHVldTNxYTU0LzQ2a3FianZ5a2x1bnAxejU2dHh6a2hlbjdnamNpM2N5eDhnZ2twdHgy
NWk3NG1vNm15cXB4OWtsdnYzL2FrY2lpMjM5bXl6b24weHdqbHhxbm4zYjM0dyxCSG9zdDpodHRwOi
8vZG9tYWxvLm9ubGluZS9rc2V6Ymx4bHZvdTNrY21icThsN2hmM2Y0Y3k1eGdlbzR1ZGxhOTFkdWV1
M3FhNTQvNDZrcWJqdnlrbHVucDF6NTZ0eHpraGVuN2dqY2kzY3l4OGdna3B0eDI1aTc0bW82bXlxcH
g5a2x2djMvYWtjaWkyMzlteXpvbjB4d2pseHFubjNiMzR3LE1YOkRDUl9NVVRFWC13TGNzOG8xTlZF
VXRYeEo5bjl5ZixUQUc6VU5ERUY = | base64 -d

MHost: hxxp:[.]//domalo online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54 /
46kqbjvyklunp1z56txzkhen7gjci3cyx8ggkptx25i74mo6myqpx9klvv3/akcii239myzon0xwjl
xqnn3b34w, BHost: hxxp://domalo online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91 [.]
Dueu3qa54/46kqbjvyklunp1z56txzkhen7gjci3cyx8ggkptx25i74mo6myqpx9klvv3/akcii239
myzon0xwjlxqnn3b34w, MX: DCR_MUTEX-wLcs8o1NVEUtXxJ9n9yf, TAG: UNDEF

Figura 11: Decodificando os dados base64 no SchemaServerManager.Main revela uma cadeia de configuração

A Figura 11 mostra que os dados decodificados para uma cadeia de configuração contendo quatro valores: MHost, BHost, MX e TAG. Analisamos o código que analisa essa cadeia e descobrimos que o MHost e o BHost foram usados ​​como pontos de extremidade principal e de backup e comando e controle (C2). Observe que os valores de MHost e BHost na Figura 11 são idênticos; portanto, esta amostra não possui um terminal C2 de backup.

No dnSpy, é possível atribuir nomes significativos às classes e métodos, assim como é possível nomear identificadores no IDA Pro. Por exemplo, o método SchemaServerManager.StopCustomer escolhe o nome de um processo em execução aleatório. Clicando com o botão direito do mouse no identificador StopCustomer e escolhendo Edit Method, é possível alterar o nome do método para PickRandomProcessName , conforme mostrado na Figura 12.


Figura 12: Atribuir nomes significativos a métodos facilita a análise do programa

A continuação da análise do método SchemaServerManager.Main revelou que o exemplo persiste nas reinicializações. O algoritmo de persistência pode ser resumido da seguinte forma:

  1. O malware escolhe o nome de um processo em execução aleatório e depois se copia para %APPDATA%e C:\. Por exemplo, se svchost.exe estiver selecionado, o malware se copia para %APPDATA%\svchost.exe e C:\svchost.exe .
  2. O malware cria um atalho %APPDATA%\dotNET.lnk apontando para a cópia do malware em %APPDATA%.
  3. O malware cria um atalho chamado dotNET.lnk na pasta Inicialização do usuário conectado, apontando para %APPDATA%\dotNET.lnk .
  4. O malware cria um atalho C:\Sysdll32.lnk apontando para a cópia do malware em C:\.
  5. O malware cria um atalho chamado Sysdll32.lnk na pasta Inicialização do usuário conectado, apontando para C:\Sysdll32.lnk .
  6. O malware cria o valor do registro HKCU\Software\Microsoft\Windows\CurrentVersion\Run\scrss apontando para %APPDATA%\dotNET.lnk .
  7. O malware cria o valor do Registro HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Wininit, apontando para C:\Sysdll32.lnk .

Após as etapas de persistência, o malware verifica várias instâncias do malware:

  1. O malware dorme por um intervalo aleatório entre 5 e 7 segundos.
  2. O malware pega o hash MD5 da cadeia de configuração ainda codificada em base64 e cria o mutex cujo nome é a representação hexadecimal desse hash. Para este exemplo, o malware cria o mutex bc2dc004028c4f0303f5e49984983352 . Se isso falhar porque outra instância está em execução, o malware será encerrado.

O malware então sinaliza, o que também permite determinar se o host principal (MHost) ou o host de backup (BHost) deve ser usado. Para fazer isso, o malware constrói um URL de beacon com base no URL do MHost, faz uma solicitação para o URL de beacon e verifica se o servidor responde com o corpo de resposta HTTP “ok”. Se o servidor não enviar essa resposta, o malware usará incondicionalmente o BHost; esse código é mostrado na Figura 13. Observe que, como esse exemplo tem o mesmo valor de MHost e BHost (da Figura 11), o malware usa o mesmo ponto de extremidade C2, independentemente de a verificação ter êxito ou falha.


Figura 13: O malware faz uma solicitação HTTP com base no URL do MHost para determinar se deve usar o MHost ou o BHost

O algoritmo completo para obter o URL do beacon é o seguinte:

  1. Obter o MHost URL, ou seja, hxxp:[.]//domalo online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54
    / 46kqbjvyklunp1z56txzkhen7gjci3cyx8ggkptx25i74mo6myqpx9klvv3/akcii239my
    zon0xwjlxqnn3b34w .
  2. Calcule o hash SHA1 do URL completo do MHost, ou seja, 56743785cf97084d3a49a8bf0956f2c744a4a3e0.
  3. Remova o último componente do caminho da URL do MHost e, em seguida, acrescente o hash SHA1 acima e? Data = active. O URL farol completo é portanto hxxp:[.]//domalo on-line/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54
    / 46kqbjvyklunp1z56txzkhen7gjci3cyx8ggkptx25i74mo6myqpx9klvv3/56743785cf
    97084d3a49a8bf0956f2c744a4a3e0.php data = ativo? .

Após o sinalizador, o malware continua a enviar e receber mensagens com o C2 configurado.

Mensagens e recursos

Depois de executar a análise estática do dfsds.exe para determinar como ele seleciona o terminal C2 e confirma o URL do terminal C2, passamos para a análise dinâmica para coletar o tráfego C2 de amostra e facilitar a compreensão do código que gera e aceita mensagens C2. Felizmente para nossa análise, o malware continua a gerar solicitações para o terminal C2, mesmo que o servidor não envie uma resposta válida. Para escutar e interceptar solicitações no terminal C2 (domalo [.] Online) sem permitir o acesso à Internet por malware, usamos a ferramenta FakeNet-NG da FLARE . A Figura 14 mostra algumas das solicitações C2 de que o malware foi capturado pelo FakeNet-NG.


Figura 14: O FakeNet-NG pode capturar as solicitações HTTP do malware para o terminal C2

Ao comparar as mensagens geradas pelo malware e capturadas no FakeNet-NG com o código descompilado do malware, determinamos seu formato e tipo de mensagem. Observe que a última solicitação HTTP visível na Figura 14 contém uma lista de processos em execução. Ao rastrear o código descompilado, descobrimos que o método SchemaServerManager.ObserverWatcher.NewMerchant gerou essa mensagem. Renomeamos esse método para taskThread e atribuímos nomes significativos aos outros métodos que ele chama; o código resultante para esse método aparece na Figura 15.


Figura 15: O método que gera a lista de processos em execução e a envia ao terminal C2

Analisando mais o código, identificamos os componentes dos URLs que o malware usava para enviar dados para o terminal C2 e como eles são construídos.

Beacons

O primeiro tipo de URL é um farol, enviado apenas uma vez quando o malware é iniciado. Para esta amostra, a URL do beacon sempre foi hxxp://domalo [.] Online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54/46kqbjvyklunp1z56txzk
hen7gjci3cyx8ggkvqvx3: .

Solicitações GET, formato 1

Quando o malware precisa enviar ou receber dados do C2, ele envia uma mensagem. O primeiro tipo de mensagem, que denotamos como “formato 1,” é um pedido GET para URLs de forma hxxp:[.]//domalo online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54/46kqb
jvyklunp1z56txzkhen7gjci3cyx8ggkptx25i74mo6myqpx9klvv3/akcii239myzon0xwjlxqnn
3b34w/<haxixe> .php? tipo = __ ds_setdata & __ ds_setdata_user = <user_hash> & __ ds_setdata_ext = <message_hash> & __ ds_setdata_data = < mensage > , em que:

  • <hash> é MD5 (SHA1 (MHost)) , que para esta amostra é 212bad81b4208a2b412dfca05f1d9fa7 .
  • <user_hash> é um identificador exclusivo para a máquina na qual o malware está sendo executado. É sempre calculado como SHA1 (OS_version + nome_máquina + nome_usuário) conforme fornecido pela classe .NET System.Environment.
  • <message_hash> identifica que tipo de mensagem o malware está enviando para o terminal C2. O <message_hash> é calculado como MD5 (<message_type> + <user_hash>) , em que <message_type> é uma palavra-chave curta que identifica o tipo de mensagem e <user_hash> é calculado acima.
    • Existem valores para <message_type> para cada comando que o malware suporta; para valores possíveis, consulte a variável “msgs” no exemplo de código mostrado na Figura 19.
    • Observe que isso dificulta a observação visual do tipo de mensagem do tráfego de log ou a gravação de uma assinatura de rede estática para o tipo de mensagem, pois varia para cada máquina devido à inclusão do <user_hash> .
    • Um tipo de mensagem usa o valor u em vez de um hash para <message_hash> .
  • <message> são os dados da mensagem, que não são ocultados de forma alguma.

O outro tipo de mensagem comum é uma mensagem getdata . Estes são solicitações GET para URLs de forma hxxp:[.]//domalo online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54/46kqb jvyklunp1z56txzkhen7gjci3cyx8ggkptx25i74mo6myqpx9klvv3/akcii239myzon0xwjlxqnn3b34w/<haxixe>.php?type=__ds_getdata&__ds_getdata_user=<user_hash>&__ds_getdata_ext=<message_hash>&__ds_getdata_key=<key>, em que:

  • <hash> e <user_hash> são calculados conforme descrito acima para mensagens getdata.
  • <message_hash> também é calculado como descrito acima para mensagens getdata, mas descreve o tipo de mensagem que o malware espera receber na resposta do servidor.
  • <key> é MD5 (<user_hash>) .

Espera-se que o servidor responda a uma mensagem getdata com uma resposta apropriada para o tipo de mensagem especificado por <message_hash> .

Solicitações GET, formato 2

Alguns tipos de mensagens do malware para o C2 usam um formato diferente, que denominamos “formato 2”. Estas mensagens são solicitações GET de forma hxxp:[.]//domalo online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54/46kqbjvyklunp1z56txzkhen7gj
ci3cyx8ggkptx25i74mo6myqpx9klvv3/akcii239myzon0xwjlxqnn3b34w/<user_hash>.<message_hash>, em que:

  • <user_hash> é calculado conforme descrito acima para mensagens getdata.
  • <message_hash> também é calculado como descrito acima para mensagens getdata, mas descreve o tipo de mensagem que o malware espera receber na resposta do servidor. <message_hash> também pode ser a string comm .

A Tabela 1 mostra os possíveis <message_types> que podem ser incorporados ao <message_hash> como parte das mensagens do formato 2 para instruir o servidor sobre o tipo de resposta desejado. Ao contrário das mensagens de formato 1, as mensagens de formato 2 são usadas apenas para alguns valores <message_type>.

<message_type> Resposta desejada
s_comm O servidor envia uma resposta não vazia se uma solicitação de captura de tela estiver pendente
m_comm O servidor envia uma resposta não vazia se uma solicitação de microfone estiver pendente
RDK O servidor responde diretamente com as teclas pressionadas para reproduzir
comm O servidor responde diretamente com outros tipos de tarefas

Tabela 1: Tipos de mensagens quando o malware usa uma mensagem especial para solicitar tarefas do servidor

Pedidos POST

Quando o malware precisa fazer upload de arquivos grandes, ele faz uma solicitação POST. Estas solicitações POST são enviados para hxxp://domalo online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54/46kqb [.]
Jvyklunp1z56txzkhen7gjci3cyx8ggkptx25i74mo6myqpx9klvv3/akcii239myzon0xwjlxqnn
3b34w/<haxixe> .php , com os seguintes parâmetros nos dados POST:

  • nome é <usuário_hash> + “.” + <message_type> , em que <user_hash> é calculado conforme descrito acima e <message_type> é o tipo de dados que está sendo carregado.
  • upload é um arquivo com os dados sendo enviados para o servidor.

A Tabela 2 mostra os possíveis valores <message_type> , juntamente com o tipo de arquivo que está sendo carregado.

<message_type> Tipo de arquivo
jpg Captura de tela
zipstealerlog Log de ladrão de cookies
wav Gravação de microfone
Arquivo Arquivo enviado
bmp Imagem da webcam
RD.jpg Captura de tela do controle remoto

Tabela 2: Tipos de mensagens quando os arquivos são carregados no servidor

Recursos

Ao analisar o código que lida com as respostas à mensagem de comunicação (formato 2), foi possível inventariar os recursos do malware. A Tabela 3 mostra as palavras-chave usadas nas respostas junto com a descrição de cada recurso.

Palavra-chave Descrição
Concha Executar um comando shell
deleteall Exclua recursivamente todos os arquivos de C :, D :, F: e G:
closecd Feche a porta da unidade de CD-ROM
definir papel de parede Alterar o papel de parede de fundo
ddos Enviar pacotes TCP e UDP para um determinado host ou endereço IP
sair Faça logoff do usuário atual
keyboardrecorder Reproduzir pressionamentos de tecla como se o usuário os tivesse digitado
fm_newfolder Criar uma nova pasta
fm_rename Renomear ou mover um arquivo
ocultar Ocultar ícones da área de trabalho
keyloggerstart Iniciar o registro das teclas digitadas
exec_cs_code Compilar e executar código C #
msgbox Abra uma caixa de mensagens do Windows
fm_upload Transferir um arquivo do C2 para o cliente
rdp Gerar novamente o malware em execução como administrador
fm_zip Crie um arquivo ZIP a partir de uma árvore de diretórios e transfira-o do cliente para o C2
Webcam Tire uma foto da webcam
fm_unzip Descompacte um arquivo ZIP em um determinado caminho no cliente
keyloggerstop Parar de registrar as teclas digitadas
fm_drives Enumerar letras de unidade
cookiestealer Transferir cookies e credenciais salvas do navegador/FileZilla para o C2
fm_delete Excluir recursivamente um determinado diretório
desonrar Ocultar ícones da área de trabalho e barra de tarefas
fm_uploadu Transferir um arquivo do C2 para o cliente
tarefa Iniciar um processo
cleardesktop Girar a tela
lcmd Execute o comando shell e envie a saída padrão de volta ao C2
taskbarShow Mostrar barra de tarefas
prancheta Definir o conteúdo da área de transferência
cookiestealer_file Salvar cookies e credenciais em um arquivo local
newuserpass Crie uma nova conta de usuário local
bip Sinal sonoro para frequência e duração definidas
falar Use sintetizador de fala para falar texto
openchat Abrir janela de bate-papo
ocultar barra de tarefas Ocultar a barra de tarefas
RDStart Iniciar o controle remoto na área de trabalho do usuário
closechat Fechar janela de bate-papo
RDStop Interromper o controle remoto na área de trabalho do usuário
fm_opendir Listar o conteúdo do diretório
Desinstalar Remova o malware do cliente
taskkill Mate um processo
forkbomb Gerar infinitamente instâncias do cmd.exe
fm_get Transferir um arquivo do cliente para o C2
desktopShow Mostre ícones da área de trabalho
Clipboardget Transferir o conteúdo da área de transferência para C2
playaudiourl Reproduzir um arquivo de som
opencd Abra a porta da unidade de CD-ROM
desligar Desligue a máquina
reiniciar Reinicie a máquina
browseurl Abra um URL da web no navegador padrão

Tabela 3: Recursos do DCRat

Servidor Dark Crystal RAT de prova de conceito

Depois de coletar informações do Dark Crystal RAT sobre seus recursos e formato de mensagem C2, outra maneira de ilustrar os recursos e testar nossa compreensão das mensagens era escrever um servidor de prova de conceito. Aqui está um trecho de código que escrevemos contendo um servidor DCRat de barebones escrito em Python . Ao contrário de um servidor RAT real, este não possui uma interface de usuário para permitir que o invasor escolha e inicie comandos. Em vez disso, ele possui uma lista de comandos pré-escrita que é enviada ao RAT.

Quando o servidor é iniciado, ele usa o Python BaseHTTPServer para começar a ouvir solicitações da Web recebidas (linhas 166-174). Presume-se que as solicitações POST recebidas mantêm um arquivo que o RAT está carregando no servidor; este servidor assume que todos os uploads de arquivos são capturas de tela e os salva em “screen.png” (linhas 140-155). Para solicitações GET, o servidor deve distinguir entre beacons, mensagens comuns e mensagens especiais (linhas 123-138). Para mensagens comuns, as mensagens __ds_setdata são simplesmente impressas na saída padrão, enquanto o único tipo de mensagem __ds_getdata suportado é s_comm(comunicações de captura de tela), às quais o servidor responde com as dimensões de captura de tela desejadas (linhas 63 a 84). Para mensagens do tipo comm, o servidor envia quatro tipos de comandos em sequência: primeiro, oculta os ícones da área de trabalho; então, faz com que a string “Olá, isto é suporte técnico” seja falada; em seguida, exibe uma caixa de mensagem solicitando uma senha; finalmente, lança a Calculadora do Windows (linhas 86-121).

A Figura 16 mostra os resultados quando o Dark Crystal RAT é executado em um sistema que foi configurado para redirecionar todo o tráfego para domalo [.] Online no servidor de prova de conceito que escrevemos.


Figura 16: Os resultados quando uma instância do Dark Crystal RAT se comunica com o servidor de prova de conceito

Outros trabalhos e reconhecimento

Após a engenharia reversa do Dark Crystal RAT, continuamos o reconhecimento para ver quais informações adicionais poderíamos encontrar. Uma limitação de nossa análise foi que não desejávamos permitir que a amostra se comunicasse com o C2 real, portanto a mantivemos isolada da Internet. Para saber mais sobre o Dark Crystal RAT, tentamos duas abordagens: a primeira foi navegar no site do Dark Crystal RAT (files.dcrat [.] Ru) usando o Tor, e a outra foi dar uma olhada nos vídeos do YouTube de experimentos de outras pessoas. o servidor RAT Dark Crystal “real”.

Site do Dark Crystal RAT

Descobrimos que o Dark Crystal RAT tem um site em files.dcrat [.] Ru, mostrado na Figura 17. Observe que existem opções para baixar o RAT em si, além de alguns plugins; a extensão DCLIB é consistente com o código de carregamento do plug-in encontrado no RAT.


Figura 17: O site files.dcrat [.] Ru permite que os usuários baixem o Dark Crystal RAT e alguns de seus plugins

A Figura 18 mostra alguns plug-ins adicionais, incluindo plug-ins com capacidade de resistir à execução em uma máquina virtual, desativar o Windows Defender e desativar as luzes da webcam em determinados modelos. Nenhum plug-in foi incluído na amostra que estudamos.


Figura 18: Plugins adicionais listados no site do Dark Crystal RAT

A Figura 19 lista os downloads de software na página RAT. Levamos algum tempo para examinar esses arquivos; Aqui estão algumas coisas interessantes que descobrimos:

  • O DCRat listado no site é na verdade um “construtor” que compila uma compilação do RAT e uma configuração para a instalação do invasor. Isso é consistente com o nome DCRatBuild.exe mostrado na Figura 4. Em nosso breve teste do construtor, descobrimos que ele tinha uma verificação de licenciamento. Não tentamos contorná-lo quando encontramos vídeos públicos do YouTube do construtor DCRat em operação, como mostraremos mais adiante.
  • O DarkCrystalServer não é autônomo; é apenas um arquivo PHP que permite ao usuário fornecer um nome de usuário e senha, o que faz com que ele baixe e instale o software do servidor. Devido à necessidade de fornecer credenciais e se comunicar novamente com dcrat [.] Ru (Figura 20), não realizamos análises adicionais do DarkCrystalServer.


Figura 19: A página RAT lista o software para o desenvolvimento do RAT, do servidor, da API e do plug-in


Figura 20: O DarkCrystalServer solicita um nome de usuário e senha e chama de volta ao dcrat [.] Ru para fazer o download do software, para que não o aprofundemos.

Vídeos do YouTube

Como parte da confirmação de nossas descobertas sobre os recursos do Dark Crystal RAT que obtivemos por meio da engenharia reversa, encontramos algumas demonstrações no YouTube do construtor e do servidor DCRat.

O usuário do YouTube LIKAR tem uma demonstração do Dark Crystal RAT no YouTube . O autor demonstra o uso do software Dark Crystal RAT em um servidor com duas instâncias ativas do RAT. Durante o vídeo, o autor navega pelas várias telas do software. Isso facilitou a visualização de como uma ameaça cibernética usaria o RAT e a confirmação de nossas suspeitas de como ele funciona.

A Figura 21 mostra uma captura do vídeo às 3:27 . Observe que o software do construtor Dark Crystal RAT refere-se ao pacote DCRatBuild como um “servidor” em vez de um cliente. No entanto, observe que uma das opções era um tipo de Java ou C # (Beta). Ao assistir este vídeo do YouTube e fazer algumas pesquisas adicionais, descobrimos que o Dark Crystal RAT existe há algum tempo em uma versão Java. A versão C # é relativamente nova. Isso explicava por que não conseguimos encontrar relatórios anteriores detalhados sobre o assunto.


Figura 21: Uma demonstração do YouTube revelou que o Dark Crystal RAT já existia em uma versão Java, e a versão C # que analisamos está em beta

A Figura 22 mostra outra captura do vídeo às 6:28. A funcionalidade exibida na tela está alinhada com os recursos “msgbox”, “browseurl”, “clipboard”, “speak”, “opencd”, “closecd” e outros recursos que descobrimos e enumeramos na Tabela 6.


Figura 22: Uma demonstração do YouTube confirmou muitos dos recursos do Dark Crystal RAT que encontramos na engenharia reversa

Conclusão

Neste post, analisamos a amostra que a equipe da Intel de ameaças nos forneceu e todos os seus componentes. Por meio de nossa triagem inicial, descobrimos que seu componente “dfsds.exe” é o Dark Crystal RAT. Descobrimos que o Dark Crystal RAT era um executável .NET e a engenharia reversa. Extraímos a configuração do malware e, por meio da análise dinâmica, descobrimos a sintaxe de suas comunicações C2. Implementamos um pequeno servidor de prova de conceito para testar o formato correto dos comandos que podem ser enviados ao malware e como interpretar as capturas de tela carregadas. Por fim, analisamos como os atores de ameaças reais baixariam e usariam o Dark Crystal RAT.

Para concluir, os indicadores de comprometimento para esta versão do Dark Crystal RAT (MD5: 047af34af65efd5c6ee38eb7ad100a01) são apresentados na Tabela 4.

Indicadores de compromisso

RAT de cristal escuro (dfsds.exe)

Manipular artefatos
Nome do mutex bc2dc004028c4f0303f5e49984983352
Artefatos do Registro
Valor do registro HKCU\Software\Microsoft\Windows\Versão Atual\Run\scrss
Valor do registro HKCU\Software\Microsoft\Windows\Versão Atual\Run\Wininit
Artefatos do sistema de arquivos
Arquivo C:\Sysdll32.lnk
Arquivo %APPDATA%\dotNET.lnk
Arquivo Menu Iniciar\Programas\Inicialização\Sysdll32.lnk
Arquivo Menu Iniciar\Programas\Inicialização\dotNET.lnk
Arquivo %APPDATA%\<nome do processo aleatório> .exe
Arquivo C:\<nome do processo aleatório> .exe
Artefatos de rede
Solicitação HTTP hxxp:[.]//domalo online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91due
u3qa54/46kqbjvyklunp1z56txzkhen7gjci3cyx8ggkptx25i74mo6myqpx9kl
? VV3/212bad81b4208a2b412dfca05f1d9fa7.php data = ativa
Solicitação HTTP hxxp://domalo online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91due [.]
u3qa54/46kqbjvyklunp1z56txzkhen7gjci3cyx8ggkptx25i74mo6myqpx9kl
VV3/akcii239myzon0xwjlxqnn3b34w212bad81b4208a2b412dfca05f1d9f
a7.php? type = __ ds_getdata & __ ds_getdata_user = <user_hash> & __ ds_getdata_ex
t = <message_hash> & __ ds_getdata_key = <key>
Solicitação HTTP hxxp://domalo [.] online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54/46kqbjvyklunp
1z56txzkhen7gjci3cyx8ggkptx25
>
Conexão TCP domalo [.] on-line: 80
Conexão TCP ipinfo [.] ip
Pesquisa de DNS domalo [.] on-line
Pesquisa de DNS ipinfo [.] ip
Cordas
String estática DCRatBuild

Tabela 4: IoCs para esta instância do DCRat

Suporte ao produto FireEye para o Dark Crystal RAT

A Tabela 5 descreve como os produtos FireEye reagem à amostra inicial (MD5: b478d340a787b85e086cc951d0696cb1) e sua carga útil do Dark Crystal RAT, ou no caso da Mandiant Security Validation, permitem que as partes interessadas validem sua própria capacidade de detectar o Dark Crystal RAT.

Produto FireEye Suporte para Dark Crystal RAT
Segurança de rede FireEye (NX) Detecção de Backdoor.Plurox
Segurança de Email FireEye (EX e ETP) Detecções de Backdoor.MSIL.DarkCrystal, Backdoor.Plurox, Malware.Binary.exe, Trojan.Vasal.FEC3, Win.Ransomware.Cerber-6267996-1, fe_ml_heuristic
FireEye Endpoint Security (HX) Detecções de Trojan.GenericKD.32546165, Backdoor.MSIL.DarkCrystal
Análise de malware do FireEye (AX) Detecção de Backdoor.Plurox.FEC2
Detecção FireEye sob demanda (DoD) Detecções de Backdoor.Plurox.FEC2, FireEye.Malware
Validação de segurança mandante Ação interna em breve

Tabela 5: Suporte nos produtos FireEye para detectar o Dark Crystal RAT ou validar o recurso de detecção

Artigo traduzido e adaptado de: https://www.fireeye.com/blog/threat-research/2020/05/analyzing-dark-crystal-rat-backdoor.html

Curso - Engenharia Reversa na Forense Digital

Aqui você compreenderá a utilização da Engenharia Reversa aplicada em Forense Digital, bem como a Análise de Malware.

O curso aborda diversos conceitos de forma prática. O estudo é baseado, em sua maioria, no .NET e .NET Core, pois é uma tecnologia que está sempre em evolução, sendo adicionada inclusive em Linux e MAC, ou seja, com o .NET Core, agora é multiplataforma.

Analisando este ambiente, podemos entender que é de extrema importância e urgente necessidade aprender a dissecar malwares desenvolvidos em alguma linguagem do .NET e .NET Core, com C#, VB, etc…