Stealth Falcon atacando os céus do Oriente Médio com Deadglyph

Durante anos, o Médio Oriente manteve a sua reputação de terreno fértil para ameaças persistentes avançadas (APT). No meio do monitoramento rotineiro de atividades suspeitas nos sistemas de clientes importantes, alguns deles baseados nesta região, a ESET Research se deparou com um backdoor muito sofisticado e desconhecido que chamamos de Deadglyph. Derivamos o nome de artefatos encontrados no backdoor (como 0xMORTOSB001, mostrado também em REF_Ref111452440h mesa 1
), juntamente com a presença de um homoglifo ataque. Até onde sabemos, esta é a primeira análise pública deste backdoor anteriormente não documentado, usado por um grupo que exibe um notável grau de sofisticação e experiência. Com base na segmentação e em evidências adicionais, atribuímos Deadglyph com alta confiança ao grupo Stealth Falcon APT.

A arquitetura do Deadglyph é incomum, pois consiste em componentes cooperantes – um é um binário x64 nativo e o outro é um assembly .NET. Essa combinação é incomum porque o malware normalmente usa apenas uma linguagem de programação para seus componentes. Essa diferença pode indicar o desenvolvimento separado desses dois componentes, ao mesmo tempo que aproveita os recursos exclusivos das linguagens de programação distintas que eles utilizam. Linguagens diferentes também podem ser aproveitadas para dificultar a análise, porque o código misto é mais difícil de navegar e depurar.

Os comandos backdoor tradicionais não são implementados no binário backdoor; em vez disso, eles são recebidos dinamicamente do servidor de comando e controle (C&C) na forma de módulos adicionais. Esse backdoor também possui vários recursos para evitar ser detectado.

Nesta postagem do blog, daremos uma olhada mais de perto no Deadglyph e forneceremos uma análise técnica desse backdoor, sua finalidade e alguns dos componentes adicionais que obtivemos. Também estamos apresentando nossas descobertas sobre Deadglyph no LABScon 2023 conferência.

Pontos-chave do post do blog:

• A ESET Research descobriu um backdoor sofisticado com arquitetura incomum que chamamos de Deadglyph.
• Os componentes principais são criptografados usando uma chave específica da máquina.
• Os comandos backdoor tradicionais são implementados por meio de módulos adicionais recebidos de seu servidor C&C.
• Obtivemos três dos módulos – criador de processos, leitor de arquivos e coletor de informações.
• Atribuímos Deadglyph ao grupo Stealth Falcon.
• Além disso, encontramos um downloader de shellcode relacionado; postulamos que ele poderia ser usado para instalação do Deadglyph.

A vítima da infiltração analisada é uma entidade governamental do Médio Oriente que foi comprometida para fins de espionagem. Uma amostra relacionada encontrada no VirusTotal também foi carregada na plataforma de verificação de arquivos desta região, especificamente do Catar. A região alvo é representada no mapa em REF_Ref143614671h Figura 1
.

Stealth Falcon (também conhecido como Project Raven ou FruityArmor) é um grupo de ameaças ligado aos Emirados Árabes Unidos de acordo com MITRE. Ativo desde 2012, o Stealth Falcon é conhecido por ter como alvo ativistas políticos, jornalistas e dissidentes no Oriente Médio. Foi descoberto e descrito pela primeira vez por Laboratório cidadão, que publicou um análise de uma campanha de ataques de spyware em 2016.

Em janeiro de 2019, a Reuters publicou um relatório investigativo no Projeto Raven, uma iniciativa que supostamente emprega ex-agentes da NSA e visa os mesmos tipos de alvos que o Stealth Falcon. Com base nestes dois relatórios referentes aos mesmos alvos e ataques, a Amnistia Internacional concluiu (mostrado em REF_Ref144978712h Figura 2
) que Stealth Falcon e Project Raven são na verdade o mesmo grupo.

Em setembro de 2019, nós pesquisa publicada em um backdoor, atribuído ao Stealth Falcon, que usava uma técnica incomum, Background Intelligent Transfer Service, para comunicação C&C. Agora revelamos o resultado de nossa análise aprofundada do que provavelmente é a mais nova adição ao conjunto de ferramentas de espionagem do Stealth Falcon.

Porta dos fundos Deadglyph

A cadeia de carregamento do Deadglyph consiste em vários componentes, conforme ilustrado em REF_Ref144978760h Figura 3
. O componente inicial é um carregador de shellcode do registro, que carrega o shellcode do registro. Este shellcode extraído, por sua vez, carrega a parte x64 nativa do backdoor – o Executor. O Executor posteriormente carrega a parte .NET do backdoor – o Orquestrador. Notavelmente, o único componente no disco do sistema como um arquivo é o componente inicial, que está na forma de uma biblioteca de vínculo dinâmico (DLL). Os componentes restantes são criptografados e armazenados em um valor binário de registro.

Embora o método preciso do vetor de comprometimento inicial ainda não tenha sido determinado, suspeitamos que um componente do instalador esteja envolvido na implantação de outros componentes e no estabelecimento de persistência no sistema.

No restante desta seção, analisamos cada componente.

Carregador de shellcode do registro

O componente inicial do Deadglyph é uma pequena DLL com uma única exportação, chamada 1. Este componente é persistido usando Assinatura de eventos do Windows Management Instrumentation (WMI) e serve como um carregador de shellcode de registro. É executado através da linha de comando rundll32 C:WINDOWSSystem32pbrtl.dll,#1.

O carregador de shellcode do registro inicia sua operação descriptografando o caminho para o shellcode criptografado armazenado no registro do Windows, usando RC4. Suspeitamos que o caminho seja único para cada vítima; no caso aqui analisado, o caminho do registro foi:

SoftwareClassesCLSID{5abc7f42-1112-5099-b082-ce8d65ba0c47}cAbRGHLg

A chave de registro raiz é HKLM or Hkcu, dependendo se o processo atual está sendo executado com privilégios elevados ou não. A mesma lógica pode ser encontrada em outros componentes.

Depois disso, o carregador deriva uma chave RC4 específica da máquina usando o UUID do sistema recuperado do tabela de firmware SMBIOS bruta. Usando essa chave, ele carrega, descriptografa e executa o shellcode. É importante destacar que esta abordagem de derivação de chave garante que a descriptografia adequada não ocorrerá se o carregador for executado em um computador diferente.

Curiosamente, o carregador também pode ser configurado por um sinalizador em seu .dados seção para usar uma chave codificada para descriptografar o shellcode, em vez da chave específica da máquina.

Detectamos um ataque homóglifo imitando a Microsoft Corporation no INFORMAÇÃO DA VERSÃO recurso deste e de outros componentes do PE. Este método emprega caracteres Unicode distintos que parecem visualmente semelhantes, mas neste caso não idênticos, aos caracteres originais, especificamente a letra maiúscula grega San (U+03FA, Ϻ) e a letra minúscula cirílica O (U+043E, о) em ϺicrоsоFt Corpоratiоn.

Shellcode do registro

Composto por duas partes, o shellcode do registro consiste em uma rotina de descriptografia e um corpo criptografado. Primeiro, a rotina de descriptografia gira cada byte do corpo criptografado para a esquerda em um (ROL 0x01). Posteriormente, o controle é transferido para esse corpo descriptografado. O corpo descriptografado consiste em um carregador PE e um arquivo PE, sendo este último o Executor, que representa a parte nativa do backdoor. Este carregador é responsável por analisar e carregar o arquivo PE associado.

Executor

O Executor é a parte nativa x64 do backdoor Deadglyph, que faz o seguinte:

• carrega sua configuração,
• inicializa o tempo de execução do .NET,
• carrega a parte .NET incorporada do backdoor (o orquestrador) e
• atua como uma biblioteca para o orquestrador.

Primeiro, duas configurações padrão incorporadas no .dados seção são descriptografados por AES. As configurações abrangem vários parâmetros, incluindo chaves de criptografia, configurações de segurança e evasão e o ponto de entrada do componente subsequente.

Durante a execução inicial, essas duas configurações padrão são armazenadas no registro do Windows, de onde são carregadas nas execuções subsequentes, possibilitando a implementação de atualizações. O caminho do registro para cada configuração é gerado com o seguinte formato:

{HKCU|HKLM}SoftwareClassesCLSID{}(padrão)

é um GUID gerado, exclusivo para cada vítima.

Depois disso, o tempo de execução do .NET é inicializado e, em seguida, o Executor RC4 descriptografa a parte .NET do backdoor conhecida como Orchestrator. O orquestrador está localizado dentro do .rsrc seção do Executor. A configuração especifica o método de execução do orquestrador como ponto de entrada. Além disso, é fornecida uma estrutura distinta para facilitar a acessibilidade das funções do Executor pelo Orquestrador.

Após iniciar o Orchestrator, o Executor atua como uma biblioteca de suporte para o Orchestrator. O Executor contém muitas funções interessantes; descrevemos alguns deles na seção a seguir, no contexto de sua utilização pelo Orchestrator e outros módulos carregados.

Orquestrador

Escrito em .NET, o Orchestrator é o principal componente do backdoor Deadglyph. A função principal deste componente envolve estabelecer comunicação com o servidor C&C e executar comandos, muitas vezes facilitados pela função intermediária do Executor. Em contraste com os componentes anteriores, o Orchestrator é ofuscado, empregando o .NET Reactor. Internamente, o backdoor é conhecido como agente, que é um nome comum para a parte do cliente em várias estruturas pós-exploração.

Inicialização

O Orchestrator primeiro carrega sua configuração e dois módulos incorporados, cada um acompanhado de seu próprio conjunto de configurações, a partir dos recursos. Esses recursos são Desinflar comprimido e AES criptografado. Eles são referenciados por um ID com hash SHA-1 em um nome de recurso. Uma visão geral desses recursos é fornecida em REF_Ref111452440h mesa 1
.

Tabela 1. Recursos do orquestrador

Nome do recurso	ID (decimal)	ID (hexadecimal)	Descrição
43ed9a3ad74ed7ab74c345a876b6be19039d4c8c	2570286865	0x99337711	Configuração do orquestrador.
3a215912708eab6f56af953d748fbfc38e3bb468	3740250113	0xDEEFB001	Módulo de rede.
42fb165bc9cf614996027a9fcb261d65fd513527	3740250369	0xDEEFB101	Configuração do módulo de rede.
e204cdcf96d9f94f9c19dbe385e635d00caaf49d	3735924737	0xDEADB001	Módulo temporizador.
abd2db754795272c21407efd5080c8a705a7d151	3735924993	0xDEADB101	Configuração do módulo temporizador.

A configuração do orquestrador e dos módulos incorporados é armazenada em formato XML. Um exemplo de configuração do orquestrador é mostrado em REF_Ref111452611h
Figura 4
.

A descrição das entradas de configuração do Orchestrator é mostrada em REF_Ref111452782h mesa 2
.

Tabela 2. Entradas de configuração do orquestrador

Após o carregamento dos componentes do recurso, vários threads são criados para realizar tarefas distintas. Um desses threads é responsável por realizar verificações de ambiente, função implementada dentro do Executor. Outro thread é dedicado a estabelecer comunicação periódica com o servidor C&C, possibilitando a recuperação de comandos. Por último, um conjunto de três threads é empregado com a finalidade de executar comandos recebidos e posteriormente transmitir qualquer saída gerada de volta ao servidor C&C.

O thread de verificação de ambiente monitora os processos em execução para identificar os indesejados. Este thread opera com duas listas distintas de nomes de processos. Se um processo da primeira lista for detectado, a comunicação C&C e a execução de comandos serão pausadas até que o processo indesejado não exista mais. Se houver uma correspondência para qualquer processo na segunda lista, o backdoor é imediatamente encerrado e desinstalado.

Nenhuma das listas foi configurada na instância analisada, portanto não sabemos quais processos normalmente podem ser verificados; acreditamos que provavelmente se destina a evitar ferramentas de análise que possam detectar atividades suspeitas e levar à descoberta do backdoor.

Comunicação

O Orchestrator utiliza dois módulos integrados para comunicação C&C – Temporizador e Rede. Assim como o Orchestrator, esses módulos são ofuscados pelo .NET Reactor. A configuração de ambos os módulos é fornecida pelo Orchestrator. Dentro do Orchestrator, está incluída uma configuração predefinida para os módulos; opcionalmente, o orquestrador também pode carregar uma versão de configuração atualizada do registro:

{HKCU|HKLM}SoftwareClassesCLSID{}

O backdoor contém uma medida de segurança interessante relacionada à comunicação. Se o backdoor não conseguir estabelecer comunicação com o servidor C&C por um período que ultrapasse um limite predefinido, configurado no Executor, um mecanismo de autodesinstalação será acionado. Este limite de tempo é especificado em horas e foi fixado em uma hora no caso examinado.

Esta abordagem serve um propósito duplo. Por um lado, evita a geração de solicitações de rede redundantes para um servidor inacessível. Por outro lado, reduz as chances de detecção subsequente caso os operadores percam o controle da porta dos fundos.

Módulo temporizador

Este pequeno módulo executa o retorno de chamada especificado em um intervalo configurável. É usado pelo Orchestrator em combinação com o módulo Network para comunicar-se periodicamente com o servidor C&C. Para evitar a criação de padrões detectáveis ​​nos logs da rede, o intervalo de execução está sujeito a randomização, com base em um percentual especificado na configuração. Na instância analisada, o intervalo foi definido para cinco minutos, com variação de ±20% introduzida para aleatoriedade.

Outro método para evitar padrões de rede detectáveis ​​na comunicação periódica pode ser encontrado na geração de solicitações enviadas ao servidor C&C. Este mecanismo, implementado no Executor, envolve a inclusão de padding de comprimento variável, composto por bytes aleatórios, dentro das requisições, resultando em requisições de diversos tamanhos.

Módulo de rede

O módulo Rede implementa a comunicação com os servidores C&C especificados em sua configuração. Ele pode enviar dados para um servidor C&C usando solicitações HTTP(S) POST. Notavelmente, oferece vários mecanismos para adquirir detalhes de configuração de proxy. Este recurso sugere um foco potencial em ambientes onde o acesso direto à Internet não está disponível.

Um exemplo de configuração descriptografada (e embelezada) é mostrado em REF_Ref144978805h Figura 5
.

As entradas de configuração contêm detalhes relacionados às comunicações de rede – URLs C&C, agente de usuário HTTP e, opcionalmente, uma configuração de proxy.

Ao se comunicar com o servidor C&C, um protocolo binário personalizado com conteúdo criptografado é usado sob HTTPS.

comandos

O orquestrador recebe comandos do servidor C&C na forma de tarefas, que são enfileiradas para execução. Existem três tipos de tarefas processadas:

• Tarefas do orquestrador,
• Tarefas do executor, e
• Carregar tarefas.

Os dois primeiros tipos são recebidos do servidor C&C e o terceiro é criado internamente para carregar a saída de comandos e erros.

Tarefas do orquestrador

As tarefas do Orchestrator oferecem a capacidade de gerenciar a configuração dos módulos Rede e Timer, e também de cancelar tarefas pendentes. A visão geral das tarefas do Orchestrator é mostrada em REF_Ref111101783h mesa 3
.

Tabela 3. Tarefas do orquestrador

Tarefas do executor

As tarefas do executor oferecem a capacidade de gerenciar o backdoor e executar módulos adicionais. É notável que a funcionalidade backdoor tradicional não está inerentemente presente no próprio binário. Em vez disso, essas funções são obtidas do servidor C&C na forma de arquivos PE ou shellcode. A extensão total do potencial do backdoor permanece desconhecida sem estes módulos adicionais, que desbloqueiam efetivamente as suas verdadeiras capacidades. Uma visão geral das tarefas do módulo é mostrada em REF_Ref117677179h mesa 4
, que inclui detalhes sobre os poucos módulos identificados. De forma similar, REF_Ref117677188h mesa 5
fornece uma visão geral das tarefas de gerenciamento associadas ao Executor.

Tabela 4. Tarefas do Executor – módulos

Formato	Descrição
0x??–0x63	Desconhecido
0x64	Leitor de arquivos
0x65	Desconhecido
0x66	Desconhecido
0x67	Desconhecido
0x68	Desconhecido
0x69	Criador do processo
0x6A	Desconhecido
0x6B	Desconhecido
0x6C	Coletor de informações
0x6D	Desconhecido
0x6E	Desconhecido

Tabela 5. Tarefas do executor – gerenciamento

Formato	Descrição
0x6F-0x76	Não implementado
0x77	Definir configuração do Executor
0x78	Obtenha a configuração do Executor
0x79-0x7C	Não implementado
0x7D	Atualizar
0x7E	desistir
0x7F	Desinstalar

O comando que define a configuração do Executor pode alterar:

• listas de processos indesejados,
• limite de tempo de falha de comunicação C&C, e
• prazo para execução de módulos adicionais.

Módulos

Conseguimos obter três módulos únicos do servidor C&C, cada um correspondendo a um tipo de tarefa Executor diferente, conforme mostrado em REF_Ref117677179h mesa 4 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003100310037003600370037003100370039000000
. Com base nas informações disponíveis, estimamos que existam nove a quatorze módulos no total. Como os módulos são na verdade comandos backdoor, eles têm uma operação básica para executar e, opcionalmente, retornam sua saída. Os módulos que obtivemos são DLLs com uma exportação sem nome (ordinal 1), em que resolvem as funções de API necessárias e chamam a função principal.

Quando executados, os módulos recebem uma função de resolução de API, que pode resolver APIs do Windows e APIs do Executor personalizadas. As APIs do Windows são referenciadas por um hash DWORD, calculado a partir do nome da API e de sua DLL. Valores hash pequenos (<41) são tratados especialmente, referenciando a função API do Executor. A API Executor compreende um total de 39 funções acessíveis aos módulos. Essas funções referem-se a uma variedade de operações, incluindo:

• operações de arquivo,
• criptografia e hash,
• compressão,
• Carregamento PE,
• acessar a representação de token e
• utilidade.

No restante desta seção, descrevemos os módulos que obtivemos.

Criador do processo

Módulo 0x69 executa a linha de comando especificada como um novo processo e fornece a saída resultante de volta ao orquestrador. O processo pode ser criado por um usuário diferente e seu tempo de execução pode ser limitado. Notavelmente, um incomum API de trabalho é usado na funcionalidade deste módulo.

Este módulo foi servido com a linha de comando cmd.exe /c lista de tarefas /v.

Presumimos que ele serve como um comando ocioso emitido automaticamente, enquanto os operadores aguardam que algo interessante aconteça no computador comprometido.

Coletor de informações

Módulo 0x6C coleta informações extensas sobre o computador por meio de consultas WMI e as repassa ao orquestrador. São coletadas informações sobre o seguinte:

• sistema operacional,
• adaptadores de rede,
• software instalado,
• unidades,
• serviços,
• motoristas
• processos,
• usuários,
• variáveis ​​de ambiente, e
• software de segurança.

Leitor de arquivos

Módulo 0x64 lê o arquivo especificado e passa o conteúdo de volta ao orquestrador. Opcionalmente, pode excluir o arquivo após a leitura.

Vimos este módulo usado para recuperar o arquivo de dados do Outlook da vítima

c:UsuáriosAppDataLocalMicrosoftOutlookoutlook.ost.

Cadeia com downloader shellcode

No processo de investigação do Deadglyph, encontramos um arquivo CPL duvidoso assinado com um certificado expirado e sem referenda com carimbo de data e hora, que havia sido carregado no VirusTotal do Catar. Após um exame mais detalhado, ficou evidente que este arquivo CPL funcionava como um downloader de shellcode de vários estágios, compartilhando certas semelhanças de código com Deadglyph. A cadeia de carregamento é ilustrada em REF_Ref143693067h Figura 6
.

Na sua forma inicial, que serve de primeira etapa, este dossier prevê ter uma . Cpl extensão (arquivo do Painel de Controle) e deve ser executado por meio de uma ação de clique duplo. Após a execução desta maneira, o shellcode incorporado passa por descriptografia XOR e os processos em execução são verificados para identificar um processo host adequado para injeção subsequente.

If avp.exe (um processo do Kaspersky Endpoint Security) está em execução, %windir%system32UserAccountBroker.exe é usado. Caso contrário, o navegador padrão será usado. Em seguida, ele cria o processo host em estado suspenso, injeta o shellcode sequestrando seu thread principal e retoma o thread.

A segunda etapa, o shellcode, consiste em duas partes. A primeira parte do shellcode resolve hashes de API, usando a mesma técnica exclusiva de cálculo de hash empregada no Deadglyph, e descriptografa strings com nomes de processos. Ele inicia um thread de autoexclusão com a tarefa de substituir e posteriormente apagar o arquivo do primeiro estágio. Em seguida, o shellcode passa a inspecionar os processos atualmente ativos, visando uma solução de segurança.

Se algum dos processos especificados for detectado, o shellcode cria um thread dormente com a prioridade mais baixa (THREAD_PRIORITY_IDLE) e permite que ele permaneça ativo por 60 segundos antes de encerrar sua operação. Este intervalo é provavelmente implementado como medida de precaução para evitar certos mecanismos de detecção empregados por soluções de segurança. Finalmente, o shellcode invoca a execução da segunda parte do seu código.

A segunda parte do shellcode carrega um arquivo PE incorporado com o estágio três e chama sua exportação com número ordinal 1.

O terceiro estágio, uma DLL, serve como um carregador .NET e contém a carga útil em seu .rsrc seção.

Para carregar a carga, o tempo de execução do .NET é inicializado. Durante a inicialização do .NET, duas técnicas intrigantes são executadas, aparentemente destinadas a escapar do Windows Verificação da interface de verificação antimalware (AMSI):

• O carregador .NET conecta temporariamente o GetModuleHandleW importar no carregado clr.dll, enquanto liga ICorRuntimeHost::Iniciar. O gancho altera o valor de retorno quando GetModuleHandleW é chamado com NULL. Ele retorna um ponteiro para um PE fictício sem seções.
• Em seguida, ele corrige sutilmente o AmsiInitialize importar string de nome no .rdata seção do carregado clr.dll para amsiiinicializar.

O quarto estágio é um assembly .NET, ofuscado com ConfuserEx, que serve como um downloader de shellcode. Primeiro, ele descriptografa XOR sua configuração em formato XML a partir de seus recursos. Uma versão embelezada da configuração extraída é apresentada em REF_Ref143695453h Figura 7
. As entradas de configuração contêm detalhes relacionados à comunicação de rede e aos processos da lista de bloqueio.

Antes de continuar, ele verifica os processos em execução em uma lista de processos da lista de bloqueio da configuração. Se uma correspondência for detectada, a execução será interrompida. É importante ressaltar que na instância analisada esta lista de bloqueio não foi configurada.

Em seguida, ele envia uma solicitação HTTP GET ao servidor C&C para recuperar algum shellcode, usando parâmetros especificados na configuração (URL, User-Agent e, opcionalmente, Proxy). Lamentavelmente, durante a nossa investigação não conseguimos adquirir nenhum shellcode do servidor C&C. No entanto, levantamos a hipótese de que o conteúdo recuperado poderia servir como instalador do Deadglyph.

Depois disso, o shellcode recuperado é executado em um thread recém-criado. Depois de esperar até que o thread shellcode termine a execução, o downloader shellcode remove todos os arquivos localizados no diretório %WINDIR%ServiceProfilesLocalServiceAppDataLocalTempTfsStoreTfs_DAV.

Por fim, tenta se deletar após um intervalo de 20 segundos, utilizando o comando subseqüente, antes de concluir sua operação e sair:

escolha cmd.exe /C Y /N /D Y /T 20 & Del /f /q

Essa autoexclusão não faz sentido nesta cadeia. Isso se deve ao fato de que o downloader do shellcode é executado dentro de um navegador ou processo do sistema após ser injetado, em vez de operar como um executável independente. Além disso, o arquivo inicial já foi excluído na segunda etapa. Esta observação sugere que o shellcode downloader pode não ser uma carga exclusiva desta cadeia e também pode ser usado separadamente em outras operações.

Conclusão

Descobrimos e analisamos um backdoor sofisticado usado pelo grupo Stealth Falcon que chamamos de Deadglyph. Ele possui uma arquitetura incomum e seus recursos de backdoor são fornecidos por seu C&C na forma de módulos adicionais. Conseguimos obter três desses módulos, revelando uma fração de todas as capacidades do Deadglyph.

Notavelmente, Deadglyph possui uma gama de mecanismos de contra-detecção, incluindo monitoramento contínuo de processos do sistema e implementação de padrões de rede aleatórios. Além disso, o backdoor é capaz de se desinstalar para minimizar a probabilidade de sua detecção em certos casos.

Além disso, nossa investigação nos levou à descoberta de uma atraente cadeia de download de shellcode de vários estágios no VirusTotal. Suspeitamos que esta cadeia de downloader provavelmente seja aproveitada no processo de instalação do Deadglyph.

Para quaisquer dúvidas sobre nossa pesquisa publicada no WeLiveSecurity, entre em contato conosco em ameaçaintel@eset.com.
A ESET Research oferece relatórios privados de inteligência APT e feeds de dados. Para qualquer esclarecimento sobre este serviço, visite o Inteligência de ameaças ESET Disputas de Comerciais.

IoCs

Arquivos

SHA-1	Nome do arquivo	Detecção	Descrição
C40F1F46D230A85F702DAA38CFA18D60481EA6C2	pbrtl.dll	Win64/Deadglyph.A	Carregador de Shellcode do Registro.
740D308565E215EB9B235CC5B720142428F540DB	N/D	Win64/Deadglyph.A	Deadglyph Backdoor – Executor.
1805568D8362A379AF09FD70D3406C6B654F189F	N/D	MSIL/Deadglyph.A	Deadglyph Backdoor – Orquestrador.
9CB373B2643C2B7F93862D2682A0D2150C7AEC7E	N/D	MSIL/Deadglyph.A	Módulo de rede do orquestrador.
F47CB40F6C2B303308D9D705F8CAD707B9C39FA5	N/D	MSIL/Deadglyph.A	Módulo de temporizador do orquestrador.
3D4D9C9F2A5ACEFF9E45538F5EBE723ACAF83E32	N/D	Win64/Deadglyph.A.gen	Módulo criador de processos.
3D2ACCEA98DBDF95F0543B7C1E8A055020E74960	N/D	Win64/Deadglyph.A	Módulo leitor de arquivos.
4E3018E4FD27587BD1C566930AE24442769D16F0	N/D	Win64/Deadglyph.A	Módulo coletor de informações.
7F728D490ED6EA64A7644049914A7F2A0E563969	N/D	Win64/Injector.MD	Primeira etapa da cadeia de download de shellcode.

Certificados

Número de série	00F0FB1390F5340CD2572451D95DB1D92D
Impressão digital	DB3614DAF58D041F96A5B916281EA0DC97AA0C29
Assunto CN	RHM LIMITED
Assunto O	RHM LIMITED
Assunto L	St. Albans
Assuntos	Hertfordshire
Assunto C	GB
E-mail	rhm@rhmlimited[.]co.uk
Válido de	2021-03-16 00:00:00
Valido para	2022-03-16 23:59:59

Servidores C&C

IP	Domínio	Visto pela primeira vez	Comentário
185.25.50[.]60	xadrezlinkss[.]com	2021-08-25	Servidor Deadglyph C&C.
135.125.78[.]187	easymathpath[.]com	2021-09-11	Servidor Deadglyph C&C.
45.14.227[.]55	junte-se à saúde[.]com	2022-05-29	Servidor C&C do downloader Shellcode.

Técnicas MITER ATT e CK

Esta tabela foi construída usando versão 13 da estrutura MITER ATT & CK.

Tática	ID	Nome	Descrição
Desenvolvimento de Recursos	T1583.001	Adquirir infraestrutura: domínios	Stealth Falcon registrou domínios para servidores C&C e para obter um certificado de assinatura de código.
	T1583.003	Adquirir Infraestrutura: Servidor Privado Virtual	Stealth Falcon usou provedores de hospedagem VPS para servidores C&C.
	T1587.001	Desenvolver recursos: malware	Stealth Falcon desenvolveu malware personalizado, incluindo carregadores personalizados e backdoor Deadglyph.
	T1588.003	Obter recursos: certificados de assinatura de código	Stealth Falcon obteve um certificado de assinatura de código.
Execução	T1047	Windows Management Instrumentation	Deadglyph usa WMI para executar sua cadeia de carregamento.
	T1059.003	Interpretador de comandos e scripts: Shell de comando do Windows	O downloader Shellcode usa cmd.exe para excluir a si mesmo.
	T1106	API nativa	Um módulo Deadglyph usa Criar Processo W e CreateProcessAsUserW Funções API para execução.
	T1204.002	Execução do usuário: arquivo malicioso	A cadeia de download do shellcode exige que o usuário clique duas vezes e execute-o.
Persistência	T1546.003	Execução acionada por evento: assinatura de evento da instrumentação de gerenciamento do Windows	O carregador Deadglyph inicial é persistido usando assinatura de evento WMI.
Evasão de Defesa	T1027	Arquivos ou informações ofuscados	Os componentes Deadglyph são criptografados. Deadglyph Orchestrator e módulos incorporados são ofuscados com o .NET Reactor. O downloader shellcode é ofuscado com ConfuserEx.
	T1070.004	Remoção do Indicador: Exclusão de Arquivo	Deadglyph pode desinstalar-se. A cadeia de download do shellcode se exclui e exclui arquivos do cache do WebDAV.
	T1112	Modificar Registro	Deadglyph armazena sua configuração e carga criptografada no registro.
	T1134	Manipulação de token de acesso	Deadglyph pode se passar por outro usuário.
	T1140	Desofuscar / decodificar arquivos ou informações	Deadglyph descriptografa strings criptografadas. A cadeia do downloader shellcode descriptografa seus componentes e configurações.
	T1218.011	Execução de proxy binário do sistema: Rundll32	O carregador Deadglyph inicial é executado usando rundll32.exe.
	T1480.001	Guardas de Execução: Chaveamento Ambiental	Deadglyph é criptografado usando uma chave específica da máquina derivada do UUID do sistema.
	T1562.001	Prejudicar defesas: desabilitar ou modificar ferramentas	O downloader shellcode evita a varredura AMSI aplicando patches clr.dll em memória .
	T1620	Carregamento de código reflexivo	Deadglyph carrega reflexivamente seus módulos usando um carregador PE personalizado.
Discovery	T1007	Descoberta de serviço do sistema	A O módulo Deadglyph descobre serviços usando a consulta WMI SELECIONE * DE Win32_Service.
	T1012	Registro de consulta	A cadeia do downloader shellcode consulta o registro para o navegador padrão.
	T1016	Descoberta de configuração de rede do sistema	Um módulo Deadglyph descobre adaptadores de rede usando consultas WMI SELECIONE * DE Win32_NetworkAdapter e SELECIONE * FROM Win32_NetworkAdapterConfiguration onde InterfaceIndex=%d.
	T1033	Proprietário do sistema/descoberta de usuário	Um módulo Deadglyph descobre usuários com a consulta WMI SELECIONE * DE Win32_UserAccount.
	T1057	Descoberta de Processo	Um módulo Deadglyph descobre processos usando consulta WMI SELECIONE * DE Win32_Process.
	T1082	Descoberta de informações do sistema	Um módulo Deadglyph descobre informações do sistema, como versão do sistema operacional, unidades, variáveis ​​de ambiente e drivers usando consultas WMI.
	T1518	Descoberta de software	Um módulo Deadglyph descobre software instalado usando consulta WMI SELECIONE * DE Win32_Product.
	T1518.001	Descoberta de Software: Descoberta de Software de Segurança	Um módulo Deadglyph descobre software de segurança usando consultas WMI SELECIONE * DO Produto AntiVirus, SELECIONE * DO Produto AntiSpyware e SELECIONE * DO Produto Firewall. A cadeia do downloader shellcode verifica os processos em execução em busca de uma solução de segurança.
Coleção	T1005	Dados do sistema local	Deadglyph possui um módulo para leitura de arquivos.
Comando e controle	T1071.001	Protocolo de camada de aplicativo: protocolos da Web	Deadglyph e o downloader shellcode se comunicam com o servidor C&C por meio do protocolo HTTP.
	T1090	procuração	Deadglyph e o downloader shellcode podem usar proxy HTTP para comunicação C&C.
	T1573.001	Canal criptografado: criptografia simétrica	Deadglyph usa AES para criptografar comunicações C&C.
exfiltration	T1041	Exfiltração no canal C2	Deadglyph usa o canal C&C para exfiltração.

• Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
• PlatoData.Network Gerativa Vertical Ai. Capacite-se. Acesse aqui.
• PlatoAiStream. Inteligência Web3. Conhecimento Amplificado. Acesse aqui.
• PlatãoESG. Carbono Tecnologia Limpa, Energia, Ambiente, Solar, Gestão de resíduos. Acesse aqui.
• PlatoHealth. Inteligência em Biotecnologia e Ensaios Clínicos. Acesse aqui.
• Fonte: https://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/