Trabalho: O panorama geral

Os investigadores da ESET encontraram recentemente ataques direcionados que utilizaram ferramentas não documentadas contra várias empresas de alto perfil e governos locais, principalmente na Ásia. Esses ataques foram conduzidos por um grupo de espionagem até então desconhecido que chamamos de Worok e que está ativo desde pelo menos 2020. O conjunto de ferramentas do Worok inclui um carregador C++ CLRLoad, um backdoor PowerShell PowHeartBeat e um carregador C# PNGLoad que usa esteganografia para extrair arquivos maliciosos ocultos. cargas úteis de arquivos PNG.

Quem é Workok?

Durante o ProxyShell (CVE-2021-34523) divulgação de vulnerabilidade no início de 2021, observamos atividade de vários grupos APT. Um exibiu características comuns com Monte incluído:

• Tempos de atividade
• Verticais segmentados
• Uso do ShadowPad

O resto do conjunto de ferramentas é muito diferente: por exemplo, o TA428 participou do Compromisso de desktop capaz em 2020. Consideramos que as ligações não são suficientemente fortes para considerar o Workok como o mesmo grupo que o TA428, mas os dois grupos podem partilhar ferramentas e ter interesses comuns. Decidimos criar um cluster e chamamos-lhe Workok. O nome foi escolhido após um mutex em um carregador utilizado pelo grupo. Outras atividades com variantes das mesmas ferramentas foram então vinculadas a este grupo. De acordo com a telemetria da ESET, o Worok está ativo desde o final de 2020 e continua ativo até o momento desta redação.

No final de 2020, a Workok tinha como alvo governos e empresas em vários países, especificamente:

• Uma empresa de telecomunicações no Leste Asiático
• Um banco na Ásia Central
• Uma empresa da indústria marítima no Sudeste Asiático
• Uma entidade governamental no Oriente Médio
• Uma empresa privada na África Austral

Houve uma quebra significativa nas operações observadas de 2021-05 a 2022-01, mas a atividade Workok regressou em 2022-02, visando:

• Uma empresa de energia na Ásia Central
• Uma entidade do setor público no Sudeste Asiático

A Figura 1 apresenta um mapa térmico visual das regiões e verticais alvo.

Considerando os perfis dos alvos e as ferramentas que vimos implantadas contra estas vítimas, pensamos que o principal objetivo do Workok é roubar informações.

Análise técnica

Embora a maioria dos acessos iniciais sejam desconhecidos, em alguns casos, durante 2021 e 2022, vimos explorações usadas contra as vulnerabilidades do ProxyShell. Nesses casos, normalmente os webshells são carregados após a exploração dessas vulnerabilidades, a fim de fornecer persistência na rede da vítima. Em seguida, os operadores usaram vários implantes para obter mais capacidades.

Uma vez adquirido o acesso, os operadores implementaram múltiplas ferramentas de reconhecimento publicamente disponíveis, incluindo Mimikatz, Minhoca, ReGeorg e NBTscane, em seguida, implantaram seus implantes personalizados: um carregador de primeiro estágio, seguido por um carregador .NET de segundo estágio (PNGLoad). Infelizmente, não conseguimos recuperar nenhuma das cargas finais. Em 2021, o carregador de primeiro estágio era um assembly CLR (CLRLoad), enquanto em 2022 foi substituído, na maioria dos casos, por um backdoor PowerShell completo (PowHeartBeat) – ambas as cadeias de execução são representadas na Figura 2. Essas três ferramentas são descritas em detalhes nas subseções a seguir.

Figura 2. Cadeias de compromisso de trabalho

CLRLoad: carregador de montagem CLR

CLRLoad é um Windows PE genérico que vimos nas versões de 32 e 64 bits. É um carregador escrito em C++ que carrega o próximo estágio (PNGLoad), que deve ser um Montagem do Common Language Runtime (CLR) Arquivo DLL. Esse código é carregado a partir de um arquivo localizado no disco em um diretório legítimo, presumivelmente para enganar as vítimas ou os responsáveis ​​pelo incidente, fazendo-os pensar que se trata de um software legítimo.

Alguns exemplos de CLRLoad começam decodificando o caminho completo do arquivo cujo conteúdo serão carregados no próximo estágio. Esses caminhos de arquivo são codificados com um XOR de byte único, com uma chave diferente em cada amostra. Decodificados ou em texto não criptografado, esses caminhos de arquivo são absolutos, sendo os seguintes os que encontramos:

• C:Arquivos de programasVMwareFerramentas VMwareVMware VGAuthxsec_1_5.dll
• C: Arquivos de programasUltraViewermsvbvm80.dll
• C:Arquivos de ProgramasInternet ExplorerJsprofile.dll
• C: Arquivos de programasWinRarRarExtMgt.dll
• C:Arquivos de programas (x86)Foxit SoftwareFoxit Readerlucenelib.dll

A seguir, um mutex é criado e vimos um nome diferente em cada amostra. O carregador verifica esse mutex; se encontrado, ele sai, porque o carregador já está em execução. Em uma das amostras, o mutex Wo0r0KGWhYGO foi encontrado, o que deu ao grupo o nome de Workok.

CRLLoad então carrega um assembly CLR do caminho do arquivo possivelmente decodificado. Como código não gerenciado, CRLLoad consegue isso via CorBindToRuntimeEx Chamadas de API do Windows em variantes de 32 bits ou CLRCreateInstance chamadas em variantes de 64 bits.

PowHeartBeat: backdoor do PowerShell

PowHeartBeat é um backdoor completo escrito em PowerShell, ofuscado usando várias técnicas, como compactação, codificação e criptografia. Com base na telemetria da ESET, acreditamos que o PowHeartBeat substituiu o CLRLoad nas campanhas mais recentes do Worok como a ferramenta usada para lançar o PNGLoad.

A primeira camada do código backdoor consiste em vários pedaços de código PowerShell codificado em base64. Uma vez que a carga útil é reconstruída, ela é executada via IEX. Uma vez decodificado, outra camada de código ofuscado é executada, que podemos ver na Figura 3.

Figura 3. Trecho da função principal decodificada da segunda camada do PowHeartBeat

A segunda camada do backdoor, primeira base64, decodifica a próxima camada de seu código, que é então descriptografado com DES triplo (modo CBC). Após a descriptografia, esse código é descompactado usando o gzip algoritmo, fornecendo assim a terceira camada de código do PowerShell, que é o backdoor real. Ele é dividido em duas partes principais: configuração e tratamento de comandos backdoor.

A camada principal do código backdoor também é escrita em PowerShell e usa HTTP ou ICMP para se comunicar com o servidor C&C. Funciona conforme ilustrado na Figura 4.

Figura 4. Funcionamento do PowHeartBeat

Configuração

A configuração contém vários campos, incluindo número de versão, configuração de proxy opcional e endereço C&C. A Tabela 1 descreve os significados dos campos de configuração nas diferentes versões que observamos.

Tabela 1. Significados dos campos de configuração

A Figura 5 mostra um exemplo da configuração extraída de uma amostra PowHeartBeat (SHA-1: 757ABA12D04FD1167528FDD107A441D11CD8C427).

Figura 5. Exemplo de configuração

Encriptação de dados

PowHeartBeat criptografa logs e conteúdo adicional de arquivo de configuração.

O conteúdo do arquivo de log é criptografado por meio de XOR de múltiplos bytes com uma chave especificada em texto não criptografado na amostra. Interessantemente, ID do Cliente é usado como sal para o índice na matriz de chaves. A chave é uma matriz de 256 bytes, idêntica em todas as amostras que encontramos. O conteúdo adicional do arquivo de configuração é criptografado por meio de XOR de múltiplos bytes com o valor de Chave secreta como sua chave.

Comunicações C&C

PowHeartBeat usou HTTP para comunicações C&C até a versão 2.4 e depois mudou para ICMP. Em ambos os casos a comunicação não é criptografada.

HTTP

Em um loop infinito, o backdoor envia uma solicitação GET ao servidor C&C, solicitando a emissão de um comando. A resposta criptografada é descriptografada pelo backdoor, que processa o comando e grava a saída do comando em um arquivo cujo conteúdo é então enviado ao servidor C&C por meio de uma solicitação POST.

O formato das solicitações GET é o seguinte:

Observe que a solicitação é construída usando os campos de configuração de mesmo nome.

Na resposta do servidor C&C, o terceiro byte do conteúdo é o identificador do comando que indica o comando a ser processado pelo backdoor. Nós vamos chamá-lo id_comando. O conteúdo restante da resposta será passado como argumento para o comando que é processado. Este conteúdo é criptografado com o algoritmo mostrado na Figura 6, ID da tarefa sendo o valor do cookie com o nome CookieTaskIdvalor da configuração.

Figura 6. Algoritmo de criptografia de dados de conteúdo de solicitações

A resposta do servidor C&C também contém outro cookie, cujo nome é especificado pelo backdoor CookieTerminalId variável de configuração. O valor deste cookie é repetido na solicitação POST do backdoor e não deve estar vazio. Após executar o comando backdoor, PowHeartBeat envia o resultado como uma solicitação POST para o servidor C&C. O resultado é enviado como um arquivo cujo nome é .png.

ICMP

A partir da versão 2.4 do PowHeartBeat, o HTTP foi substituído pelo ICMP, enviando pacotes com timeout de seis segundos e sendo não fragmentado. A comunicação através do ICMP é provavelmente uma forma de evitar a detecção.

Não há grandes mudanças nas versões 2.4 e posteriores, mas notamos algumas modificações no código:

• PowHeartBeat envia um pacote de pulsação em cada loop que contém a string a B C D e F G H I J K L M N o p q R S T U V W x y Z, antes de solicitar um comando. Isso informa ao servidor C&C que o backdoor está pronto para receber comandos.
• Solicitações para obter comandos executados pelo backdoor contêm a string abcdefghijklmnop.

Os pacotes de pulsação têm o formato descrito na Figura 7.

Figura 7. Layout do pacote de pulsação

A diferença entre ID do Cliente e bandeira do cliente é a de que ID do Cliente difere em cada amostra, enquanto bandeira do cliente é o mesmo em todas as amostras que usam ICMP. bandeira de batimento cardíaco indica que o backdoor está enviando uma pulsação. A resposta do servidor C&C tem o formato descrito na Figura 8.

Figura 8. Layout de resposta do servidor C&C

bandeira aqui indica se há um comando a ser emitido para o backdoor. As solicitações para obter comandos têm o formato descrito na Figura 9.

Figura 9. Layout para solicitações de obtenção de comandos

Observe que o modo ICMP do backdoor permite receber uma quantidade ilimitada de dados, divididos em pedaços, e as variáveis comprimento dos dados, posição atual e comprimento total são usados ​​para acompanhar os dados transmitidos. As respostas a essas solicitações têm o formato descrito na Figura 10.

Figura 10. Layout de respostas às solicitações de obtenção de comandos

Como nas respostas HTTP, o identificador do comando é o terceiro byte do dados,.

Após sete respostas ICMP consecutivas com conteúdo vazio ou formatado de forma inconsistente, as transferências entre o backdoor e o servidor C&C são consideradas concluídas.

Em relação às solicitações de envio do resultado do comando emitido para o servidor C&C, o modo servidor é alterado para modo post, e a string final (abcdefghijklmnop) é alterado para os dados do resultado.

Comandos de backdoor

PowHeartBeat possui vários recursos, incluindo execução de comandos/processos e manipulação de arquivos. A Tabela 2 lista todos os comandos suportados pelas diversas amostras analisadas.

Tabela 2. Descrições dos comandos PowHeartBeat

Em caso de erros do lado do backdoor, o backdoor utiliza um identificador de comando específico 0x00 na solicitação POST ao servidor C&C, indicando assim que ocorreu um erro.

Observe que antes de enviar as informações de volta ao servidor C&C, os dados são compactados com gzip.

PNGLoad: carregador esteganográfico

PNGLoad é a carga útil de segundo estágio implantada pela Worok em sistemas comprometidos e, de acordo com a telemetria da ESET, carregada por CLRLoad ou PowHeartBeat. Embora não vejamos nenhum código no PowHeartBeat que carregue diretamente o PNGLoad, o backdoor tem a capacidade de baixar e executar cargas adicionais do servidor C&C, que é provavelmente como os invasores implantaram o PNGLoad em sistemas comprometidos com o PowHeartBeat. PNGLoad é um carregador que usa bytes de arquivos PNG para criar uma carga útil para execução. É um executável .NET de 64 bits – ofuscado com Reator .NET – que se disfarça de software legítimo. Por exemplo, a Figura 11 mostra os cabeçalhos CLR de uma amostra mascarada como uma DLL WinRAR.

Figura 11. Exemplo de uma DLL WinRAR falsa

Uma vez desofuscado, apenas uma classe estará presente. Nesta aula há um Caminho Principal atributo contendo o caminho do diretório que o backdoor pesquisa, incluindo seus subdiretórios, por arquivos com um . Png extensão, conforme mostrado na Figura 12.

Figura 12. Painel do . Png listagem de arquivos

Cada . Png arquivo localizado por esta pesquisa de Caminho Principal é então verificado quanto a conteúdo incorporado esteganograficamente. Primeiro, o bit menos significativo dos valores R (vermelho), G (verde), B (azul) e A (alfa) de cada pixel é obtido e montado em um buffer. Se os primeiros oito bytes desse buffer corresponderem ao número mágico visto na Figura 13 e o próximo valor de oito bytes, controle, for não nulo, o arquivo passará na verificação de conteúdo esteganográfico do PNGLoad. Para esses arquivos, o processamento continua com o restante do buffer descriptografado com um XOR de múltiplos bytes, usando a chave armazenada no arquivo PNGLoad. SecretKeyBytes atributo e, em seguida, o buffer descriptografado é descompactado com gzip. Espera-se que o resultado seja um script do PowerShell, que é executado imediatamente.

Figura 13. Formato do buffer PNGLoad criado a partir do processamento . Png arquivos

Curiosamente, as operações realizadas pelo PNGLoad são registradas em um arquivo cujo caminho está armazenado na variável LogFilePath. As operações só são registradas se estiver presente um arquivo cujo caminho é especificado pela variável interna IfLogFilePath.

Não conseguimos obter uma amostra . Png arquivo usado junto com PNGLoad, mas a forma como o PNGLoad funciona sugere que ele deve funcionar com arquivos PNG válidos. Para ocultar a carga maliciosa, o Worok usa objetos Bitmap em C#, que obtêm apenas informações de pixel dos arquivos, não os metadados do arquivo. Isso significa que o Workok pode ocultar suas cargas maliciosas em imagens PNG válidas e de aparência inócua e, assim, ocultar-se à vista de todos.

Conclusão

Worok é um grupo de ciberespionagem que desenvolve as suas próprias ferramentas, bem como aproveita as ferramentas existentes, para comprometer os seus alvos. Roubar informações das suas vítimas é o que acreditamos que os operadores procuram porque se concentram em entidades de alto perfil na Ásia e em África, visando vários sectores, tanto privados como públicos, mas com uma ênfase específica em entidades governamentais. Os tempos de atividade e o conjunto de ferramentas indicam possíveis ligações com o TA428, mas fazemos esta avaliação com baixa confiança. Seu conjunto de ferramentas personalizado inclui dois carregadores – um em C++ e outro em C# .NET – e um backdoor do PowerShell. Embora a nossa visibilidade seja limitada, esperamos que o esclarecimento deste grupo encoraje outros investigadores a partilhar informações sobre este grupo.

IOCs

Arquivos

Caminhos de arquivo

Alguns dos Caminho Principal, LogFilePath e IfLogFilePath valores que encontramos nas amostras PNGLoad:

Network

Mutexes

Nas amostras CLRLoad, os nomes mutex que encontramos são:

aB82UduGX0EX
ad8TbUIZl5Ga
Mr2PJVxbIBD4
oERiQtKLgPgK
U37uxsCsA4Xm
Wo0r0KGWhYGO
xBUjQR2vxYTz
zYCLBWekRX3t
3c3401ad-e77d-4142-8db5-8eb5483d7e41
9xvzMsaWqxMeu

Uma lista abrangente de Indicadores de Compromisso (IoCs) e amostras pode ser encontrada em nosso repositório GitHub.

Técnicas MITER ATT e CK

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