Worok: grupo de ciberespionagem que utiliza novas ferramentas

A equipe de pesquisa da ESET descobriu recentemente a utilização de ferramentas até o momento desconhecidas em ataques direcionados contra órgãos de governo e empresas de alto perfil, principalmente na Ásia. Estes ataques foram realizados por um grupo de espionagem chamado Worok, que está ativo desde pelo menos 2020. O conjunto de ferramentas utilizado pelo Worok inclui CLRLoad, um loader C++, PowHeartBeat, um backdoor no PowerShell, e PNGLoad, um loader no C# que utiliza esteganografia para extrair componentes maliciosos escondidos em arquivos PNG.

Grupo Worok

Durante a divulgação da vulnerabilidade ProxyShell (CVE-2021-34523) no início de 2021, a equipe de pesquisa da ESET detectou algumas atividades de vários grupos APT que tentavam explorar as falhas no Microsoft Exchange. Uma delas apresentou características comuns com o grupo TA428:

• Horário de atividade;
• Mercados verticais direcionados;
• Utilização do ShadowPad.

Os demais elementos do conjunto de ferramentas são bastante diferentes: por exemplo, o TA428 participou do ataque ao Able Desktop em 2020. Consideramos que os vínculos não são suficientemente fortes para considerar que o Worok e o TA428 sejam o mesmo grupo; os dois podem compartilhar ferramentas e ter interesses comuns. Portanto, decidimos criar um grupo e o chamamos de Worok. O nome foi escolhido depois de um mutex em um loader utilizado pelo grupo. Podemos fazer uma ligação deste grupo com atividades realizadas depois da utilização de variantes das mesmas ferramentas. De acordo com a telemetria da ESET, o Worok está ativo desde o final de 2020 e continua atuante até o momento.

No final de 2020, o Worok tinha como alvo governos e empresas em vários países, em particular:

• Uma empresa de telecomunicações na Ásia Oriental;
• Um banco na Ásia Central;
• Uma empresa da indústria marítima do sudeste asiático;
• Um órgão público no Oriente Médio;
• Uma empresa privada na África Austral.

Houve uma interrupção significativa nas atividades do grupo entre maio de 2021 e janeiro de 2022, mas o Worok voltou a operar em fevereiro de 2022, tendo como alvo:

• Uma empresa de energia na Ásia Central;
• Um órgão público no Sudeste Asiático.

A Figura 1 mostra as regiões e o perfil dos alvos de ataque.

Imagem 1. Mapa das regiões e perfil dos alvos.

Tendo em conta os perfis dos alvos de ataque e as ferramentas que foram utilizadas contra essas vítimas, acreditamos que o principal objetivo do grupo Worok seja roubar informações.

Análise técnica

Embora a maioria dos acessos iniciais sejam desconhecidos, em alguns casos durante 2021 e 2022 observamos a utilização de exploits contra as vulnerabilidades ProxyShell. Nestes casos, os webshells são normalmente carregados após a exploração dessas falhas para proporcionar persistência na rede da vítima. Os operadores utilizaram vários implantes para ganhar mais capacidades.

Depois de obter o acesso inicial, os operadores implantam várias ferramentas disponíveis publicamente para realizar o reconhecimento, como Mimikatz, EarthWorm, ReGeorg, e NBTscan, na rede das vítimas, e depois incluir seus implantes personalizados: um loader de primeiro estágio, seguido por um loader .NET de segundo estágio (PNGLoad). Infelizmente, não conseguimos recuperar nenhum dos payloads finais. Em 2021, o loader de primeira fase era um CLR em assembly (CLRLoad), enquanto que em 2022 foi substituído, na maioria dos casos, por um backdoor para a vulnerabilidade PowerShell com múltiplas capacidades (PowHeartBeat); ambas as cadeias de execução podem ser vistas na Figura 2.

Figura 2: Cadeias de ataque do grupo Worok.

CLRLoad: Loader CLR no assembly

O CLRLoad é um PE genérico para Windows que observamos em ambas as versões de 32 e 64 bits. É um loader escrito em C++ que carrega a seguinte etapa (PNGLoad), que deve ser um arquivo DLL do conjunto Common Language Runtime (CLR). Este código é carregado a partir de um arquivo localizado em disco em um diretório legítimo, presumivelmente para enganar as vítimas ou os responsáveis por incidentes para que pensem que se trata de um software legítimo.

Algumas amostras do CLRLoad começam decodificando o caminho completo do arquivo cujo conteúdo será carregado na etapa seguinte. Estes caminhos de arquivo estão codificados com um XOR de byte único, com uma chave diferente em cada amostra. Descodificados ou em texto simples, estes caminhos de arquivo são absolutos e encontramos os seguintes:

• C:\Program Files\VMware\VMware Tools\VMware VGAuth\xsec_1_5.dll
• C:\Program Files\UltraViewer\msvbvm80.dll
• C:\Program Files\Internet Explorer\Jsprofile.dll
• C:\Program Files\WinRar\RarExtMgt.dll
• C:\Program Files (x86)\Foxit Software\Foxit Reader\lucenelib.dll

Em seguida, é criado um mutex e observamos um nome diferente em cada amostra. O loader verifica este mutex; se ele o encontra, acaba saindo, porque o loader já está em funcionamento. Em uma das amostras, foi encontrado o mutex Wo0r0KGWhYGO, que deu nome ao grupo Worok.

O CLRLoad então carrega uma CLR no assembly a partir do caminho do arquivo possivelmente decodificado. Como código não gerenciado, o CLRLoad consegue isso em variantes de 32 bits chamando o CorBindToRuntimeEx através da API do Windows, enquanto em variantes de 64 bits o mesmo ocorre através do CLRCreateInstance.

PowHeartBeat: backdoor para PowerShell

PowHeartBeat é um backdoor com todas as funções está escrito via PowerShell, ofuscado usando várias técnicas como compressão, criptografia e codificação. Com base na telemetria ESET, acreditamos que o PowHeartBeat substituiu o CLRLoad em campanhas mais recentes como a ferramenta utilizada para lançar o PNGLoad.

A primeira camada do código do backdoor consiste em vários fragmentos do código PowerShell codificado com base64. Uma vez que o payload é reconstituída, ele é executado através do IEX. Depois de decodificado, outra camada de código ofuscado é executada. Este processo pode ser visto na Figura 3.

Figura 3: Extrato da função principal decodificada na segunda camada do PowHeartBeat.

A segunda camada do backdoor descriptografa a camada seguinte do seu código com base64, que, em seguida, é decriptografada com Triple DES (modo CBC). Após a decriptação, este código é descomprimido usando o algoritmo gzip, que gera a terceira camada de código do PowerShell, que é o atual backdoor. Esta etapa se divide em duas partes principais: a configuração e a manipulação de comandos do backdoor.

A camada principal do código do backdoor também é escrita em PowerShell e usa HTTP ou ICMP para se comunicar com o servidor C&C. Este processo funciona assim como podemos ver na Figura 4.

Figura 4. Funcionamento do PowerHeartBeat.