Operação FlashHole: grupo Lazarus quebra a segurança e desafia os controles

Em janeiro, respondemos a uma nova campanha de ataques do Grupo Lazarus contra a Coreia do Sul, que sucedeu a Operação SyncHole do ano passado. Nessa nova operação, o grupo adotou uma cadeia de infecção por malware atualizada, que combinava malware antigo e novo. Nossa análise abrangente identificou a exploração de outro software de segurança obrigatório na Coreia do Sul e o uso da técnica de ataque watering hole. Vale destacar que, nessa campanha, o grupo selecionou as vítimas de forma mais criteriosa, enviando e-mails de spear phishing com links para sites falsos, mas relevantes para cada alvo, como páginas de portfólio e currículos personalizados. Demos a essa atividade o nome de Operação FlashHole.

Nossa análise revelou que os primeiros indícios dessa nova operação datam de julho do ano passado, o que sugere que o grupo começou a preparar a campanha pouco depois do fim da Operação SyncHole, que durou pelo menos quatro meses. Identificamos pelo menos três organizações sul-coreanas afetadas pela campanha, dos setores de software, construção e fabricação de equipamentos de comunicação por fio. Esses setores diferem dos atingidos na Operação SyncHole. Isso evidencia que o grupo amplia seu escopo de alvos ao longo do tempo.

Histórico

Mais de um ano após os primeiros registros da Operação SyncHole, detectamos uma cadeia de execução suspeita iniciada por um software legítimo da Coreia do Sul. Essa cadeia segue o mesmo padrão observado na operação anterior, mas, desta vez, o invasor explorou o CrossWeb EX, em vez do Cross EX, explorado na Operação SyncHole. Ambas as aplicações são mantidas pelo mesmo desenvolvedor e ambas estão relacionadas à segurança financeira. O CrossWeb EX é uma solução de segurança financeira exigida para acessar a maioria dos sites de bancos e órgãos governamentais da Coreia do Sul. O software criptografa as comunicações entre o navegador do usuário e o servidor web usando PKI (infraestrutura de chaves públicas). Esta não é a primeira vez que o Lazarus explora esse software. Em 2021, o grupo também o utilizou para implementar o downloader Racket e voltou a usá-lo em 2022 e 2023. Embora não tenhamos conseguido obter o código do exploit, identificamos que a cadeia de ataque leva à execução do malware na memória.

Observamos que o processo iniciado estava sendo executado com um nível de integridade alto. O processo principal, INISAFECrossWebEXSvc.exe, faz parte do bundle de instalação do INISAFE CrossWeb EX V3 versão 3.4.1.2, lançado em 2023, após o comunicado público do KrCERT.

Como já mencionamos em nosso artigo sobre a Operação SyncHole, esse padrão segue de perto a estratégia adotada há muitos anos pelo Grupo Lazarus para atacar alvos na Coreia do Sul. Como o CrossWeb EX e softwares semelhantes são obrigatórios para usuários sul-coreanos e normalmente são executados em segundo plano para interagir com o navegador, o grupo tem explorado esses programas como um vetor de ataque importante. Em 2025, um artigo apresentado no simpósio de segurança USENIX Security Symposium investigou vulnerabilidades em softwares de segurança de uso obrigatório na Coreia do Sul e demonstrou como esses programas podem criar, involuntariamente, uma enorme superfície de ataque.

Em julho de 2026, o governo sul-coreano e vários fornecedores locais de soluções de segurança também publicaram um comunicado conjunto de segurança que aborda técnicas de ataque comumente utilizadas pelo Lazarus, incluindo a exploração de softwares de segurança financeira. Embora o comunicado apresente pontos em comum com nossas descobertas nas Operações FlashHole e SyncHole, e o relatório de análise detalhada da AhnLab, intitulado Operação Double Barrel, também aborda uma ampla variedade de atividades recentes do Grupo Lazarus, estamos realizando uma classificação mais detalhada com base em suas TTPs. Discutiremos isso mais detalhadamente na seção Atribuição.

Vetor de infecção inicial

Embora não tenhamos conseguido determinar com precisão o que desencadeou a cadeia de infecção, nossa análise revelou um site suspeito hospedado no GitHub Pages que está associado à conta do GitHub utilizada como canal de C2. A conta do GitHub foi criada em setembro passado, e a versão inicial do site foi projetada para exibir o portfólio de um desenvolvedor sênior de dispositivos de rede. No entanto, em janeiro, esse site foi substituído por outro que apresentava um portfólio de design de interiores. O primeiro provavelmente foi acessado por um funcionário de uma empresa de equipamentos de comunicação por cabo, enquanto o segundo provavelmente afetou um alvo no setor de construção.

O primeiro site, que continha o currículo, apresentava uma fotografia supostamente de um candidato a emprego. No entanto, a ausência de metadados EXIF e a textura artificial da imagem sugerem que ela pode ter sido gerada por IA. Isso indica que o Grupo Lazarus incorporou a IA à sua estratégia de longa data, assim como outros agentes de ameaças que falam coreano (1, 2). O grupo também provavelmente utilizou IA para gerar o site usado como isca: o nome do candidato à vaga se assemelha a uma versão de “John Doe” adaptada ao estilo coreano, e o próprio portfólio continha informações aparentemente sem sentido e nomes de empresas aleatórias. Em seguida, o site gerado foi adaptado manualmente para cada alvo específico.

Os sites continham links incorporados que carregavam um arquivo JavaScript externo por meio de uma tag script.

• Link malicioso incorporado ao site com o currículo: hxxps://javadevhouse.co[.]kr/ajax/libs/jquery/1.7.3/jquery.min.js
• Link malicioso incorporado ao site de design de interiores: hxxps://pythonapischool[.]com/api/detach

Com base na análise, avaliamos, com grau de confiança de médio a alto, que os alvos receberam e-mails de phishing contendo links para o site malicioso, hospedado no GitHub Pages (usando o domínio <nome de usuário>.github.io). Após o acesso ao site, um exploit foi acionado contra o software CrossWeb EX. Essa avaliação está alinhada à abordagem recente do Grupo Lazarus, conforme descrito no comunicado conjunto do governo sul-coreano e de empresas de segurança.

Cadeia de infecção completa

Como resultado da exploração, sob o processo CrossWeb EX, o binário legítimo do Windows fsquirt.exe foi executado, sendo então injetado com shellcode que inclui uma DLL maliciosa, que era o malware TechHub. Com nossa análise extensa e minuciosa, identificamos vários payloads maliciosos e reconstruímos toda a cadeia de infecção. Essa cadeia de infecção é bastante complexa e revela as técnicas operacionais avançadas do Grupo Lazarus empregadas nos hosts-alvo, que ocultam tanto payloads maliciosos e suas intenções, quanto seu sofisticado framework de distribuição de malware. Esta última foi significativamente aprimorada em relação à campanha anterior do grupo, embora a nova operação tenha começado menos de um ano depois. É importante destacar que, durante a infiltração inicial, a cadeia de execução apresentada abaixo existe apenas na memória, o que evidencia os esforços consideráveis dos invasores para ocultar o comprometimento inicial.

Após o comprometimento inicial, o grupo buscou manter a persistência na rede instalando duas variantes de malware, TouchHub e TouchShift, por meio da técnica de DLL sideloading, usando o nome mscoree.dll. O TouchHub foi implementado pela primeira instância do TechHub. Em seguida, ele usou a técnica para iniciar o TouchShift, o que finalmente levou à execução em memória de outra instância do TechHub. Depois de ser iniciado pela segunda vez, o TechHub implementou outro par, ClientHub e LPEClient, em vez de executar o Cubridge diretamente. Apenas vestígios mínimos desses arquivos foram encontrados em disco; o restante do código malicioso persistiu exclusivamente na memória.

Como o Cubridge continua existindo apenas na memória durante a etapa inicial do comprometimento, suspeitamos que o grupo tenha projetado essa cadeia indireta e composta por várias etapas para reimplementar deliberadamente o Cubridge após estabelecer a persistência, uma vez que ele atua como o orquestrador mais sofisticado do ataque.

Conjunto de malware

A cadeia completa inclui variantes avançadas de famílias de malware conhecidas do Grupo Lazarus, como TechHub, Cubridge, TouchShift e LPEClient, além dos malware recém-identificado TouchHub e ClientHub.

TechHub, o início da cadeia

O TechHub, um malware do tipo downloader que desempenha um papel central nesse ataque, comunica-se com o GitHub usando um token de acesso pessoal (PAT). Ele atua como o payload inicial, dando início à cadeia de infecção e oferecendo funcionalidades suficientes para traçar o perfil dos hosts comprometidos e viabilizar a execução do payload subsequente.

Esta variante é uma versão mais avançada do malware denominado CLOUDBURST pela Mandiant e NickelLoader pela ESET. De acordo com os relatórios, a versão anterior se comunicava com um servidor de C2 por meio de HTTP(S) para buscar payloads adicionais. A iteração mais recente que encontramos, no entanto, comunica-se com o GitHub em vez disso e possui strings de comando atualizadas.

Identificamos três variantes do TechHub na cadeia: uma versão em memória, uma versão simples de DLL sideloading e uma versão que também usa DLL side loading e um serviço registrado do Windows. Dependendo de qual estágio carrega o malware, ele entra em contato com um repositório privado do GitHub por meio da API do GitHub, usando credenciais codificadas diretamente no código ou credenciais recuperadas de seu arquivo de configuração.

Quando o TechHub é carregado, ele cria um identificador (ID) hexadecimal de 4 bytes no intervalo de 0x1000 a 0xFFFF, ou lê um a partir do arquivo de configuração, para permitir que os invasores façam a distinção entre os hosts comprometidos. Em seguida, verifica uma issue do GitHub enviando a requisição GET /issues?state=[open/closed] para determinar se ainda há alguma comunicação anterior ativa. Caso encontre vestígios dessa comunicação, remove-os e, em seguida, inicia o processo de handshake.

1. Ele cria uma nova issue intitulada 1[ID] com o corpo hel, usando a requisição POST /issues, e define seu status como aberto.
2. Em seguida, ele recupera do repositório um arquivo cujo nome contém o valor 2[ID]. Esse arquivo contém a chave pública RSA.
3. Ele gera uma chave XOR aleatória de 16 bytes e a criptografa com a chave pública RSA fornecida, depois faz o upload do resultado prefixado com 1[ID] para o repositório.
4. O IV codificado no código-fonte passa por XORing com a chave de 16 bytes gerada e é, então, utilizado após o handshake.

Durante a troca, os nomes de arquivos seguem o padrão [1|2][ID][random-16-byte-key]. Em toda a sua comunicação. O prefixo “2” indica a entrega do repositório para o TechHub, enquanto “1” indica a entrega do TechHub para o repositório. A chave aleatória de 16 bytes no nome do arquivo é usada para criptografia ou descriptografia AES do conteúdo de cada arquivo, empregando um IV codificado no código-fonte ou um IV atualizado.

Após concluir a troca de chaves, o TechHub lê novamente um arquivo com o prefixo “2” e verifica se os dados recebidos correspondem a “hel”. Se a verificação for bem-sucedida, coleta informações detalhadas do host infectado. Esses dados são, então, criptografados e enviados para o repositório. Após transmitir as informações do dispositivo, o processo é finalizado atualizando o corpo da issue criada anteriormente de “hel” para “hey” usando PATCH /issues/[issue number]. Nesse momento, o malware está totalmente preparado para receber comandos do repositório.

O TechHub aceita quatro comandos. O comando laeca aciona a implementação do payload, que é empacotado no shellcode que carrega usando a técnica de reflective loading direto na memória.

Comando	Descrição
mqdrz	Coletar informações sobre o dispositivo e os processos em execução
laeca	Executar diretamente na memória o shellcode recebido
aqvxp	Encerrar o processo atual
rtcya	Beaconing após a conclusão do processo de handshake

Cubridge, o orquestrador do framework

Implementado no host comprometido por meio do TechHub, o Cubridge é capaz de recuperar diversos payloads por meio de vários métodos. Ele atua como o orquestrador central de todo o framework de malware, aceitando diversos plug-ins, módulos e ferramentas. Uma versão anterior do Cubridge também foi descrita nos relatórios que abordaram a versão precedente do TechHub. Nesses relatórios, a Mandiant o identificou como SIDESHOW, enquanto a ESET identificou um de seus módulos como LightlessCan.

Para estabelecer a comunicação com o servidor de C2, o Cubridge seleciona aleatoriamente um dos servidores de C2 predefinidos e cria uma URL C2 específica para cada requisição, seguindo o padrão [C2_URL]/[page1]/[page2]/[page3]. Isso é feito pela concatenação de termos de listas de palavras predefinidas. Nossa análise identificou um único servidor de C2 hard-coded – hxxps://cubedesign[.]co[.]kr/news/AABBCC – associado à instância examinada, configurada para a versão 5.1. Durante a geração da URL, AABBCC é substituído por um valor nulo. O segmento page3 recebe um número inteiro gerado aleatoriamente entre 10000000; e 99999999. Consequentemente, cada URL gerada é projetada para parecer legítima e ser exclusiva para cada requisição.

A lista predefinida para page1 é apresentada abaixo. O TechHub seleciona aleatoriamente um dos itens dessa lista.

A lista predefinida de palavras para page2 é mostrada abaixo:

Dessa forma, a URL hard-coded pode ser transformada posteriormente, por exemplo, em hxxps://cubedesign[.]co[.]kr/news/economy/article/12345678 seguindo as etapas descritas acima.

A autenticação usando uma requisição POST ao servidor de C2 requer três parâmetros no formato de pares chave-valor. Cada chave é gerada aleatoriamente com base em outros dicionários predefinidos de palavras. Os valores associados consistem em um ID de bot hexadecimal de 8 bytes gerado aleatoriamente, um token de autenticação fixo (KW4Ofw982CNJjxd51AVqkGAop) e um ID de sessão hexadecimal de 16 bytes gerado aleatoriamente.

O Cubridge utiliza um processo de handshake mais robusto que o TechHub, combinando os algoritmos RSA e RC6. Diferentemente do TechHub, ele ignora a etapa de criação do perfil do host e passa diretamente para a comunicação de comando e controle após o handshake. Durante a comunicação, o malware imita requisições do navegador, usando os cabeçalhos X‑CSRF‑Token e X‑Requested‑With para autenticação e o cabeçalho Upgrade‑Insecure‑Requests para requisitar dados adicionais.

O Cubridge oferece um amplo conjunto de funcionalidades, voltadas principalmente ao carregamento de payloads de estágios subsequentes. Os comandos empregam diversas técnicas, como injeção de DLL, reflective loading e injeção usando manual section mapping. Os payloads podem ser distribuídas em diferentes formatos:

• Plug-ins: extensões reutilizáveis que adicionam funcionalidades conforme necessário e podem ser executadas a qualquer momento, nos formatos shellcode e DLL
• Ferramentas: utilitários independentes, no formato DLL, que executam tarefas pontuais
• Módulos: componentes carregados uma única vez que permanecem ativos e oferecem um conjunto ampliado de funcionalidades

É provável que os comandos para plug-ins e shellcodes carreguem os mesmos tipos de plug-ins, pois ambos aceitam uma função exportada com estrutura semelhante para executar ações subsequentes. O shellcode pode ser gerado usando a ferramenta de código aberto sRDI, que permite empacotar um plug-in no formato DLL. É provável que os recursos de uma única DLL sejam utilizados para carregar uma ferramenta que funcione de forma independente, pois, quando uma única DLL é carregada, apenas seu ponto de entrada DllMain e seus parâmetros ficam acessíveis, sem que outras funções exportadas sejam disponibilizadas.

Comando	Tipo de payload	Descrição
0	–	Coletar informações sobre o dispositivo, incluindo o nome do computador, o fuso horário, o PID e outros dados semelhantes
1		Compactar o arquivo/diretório especificado usando o algoritmo legado ZipCrypto e a senha hard-coded: xdkiTajAAxc3i/w[<881fnC!G*cb1Dit2sh.gAk/
2		Criar um arquivo no caminho especificado
3	Possivelmente um plug-in	Injetar o payload DLL fornecido no processo de destino e carregá-lo por meio de reflective loading de DLL
4	Plug-in	Carregar um plug-in em forma de DLL usando reflective loading
5		Recuperar o endereço da função exportada especificada do plug-in de destino e executá-la com os parâmetros fornecidos
6		Recuperar todas as informações sobre os plug-ins carregados
7		Descarregar o plug-in especificado
8	Shellcode	Injetar o shellcode fornecido no processo de destino e carregá-lo usando injeção usando manual section mapping
9		Carregar o shellcode fornecido diretamente na memória
10		Recuperar o endereço da função de exportação especificada do shellcode de destino (que provavelmente é um plug-in em formato de shellcode) e executá-la com o parâmetro fornecido
11		Recuperar todas as informações sobre o shellcode carregado
12		Descarregar o shellcode especificado
13	–	Define o horário de execução agendado do Cubridge (em minutos) atualizando uma variável global
14		Define o horário de execução agendado do Cubridge (em minutos) atualizando uma variável global, ao mesmo tempo em que desativa o monitoramento também atualizando outra variável global
15		Encerrar a si mesmo de maneira controlada
16		Obter a configuração do Cubridge: recuperar as flags globais, o número de servidores de C2, os endereços de C2 etc
17		Atualizar as flags globais, o número de servidores de C2, os endereços de C2 etc
18	Ferramenta	Carregar uma DLL usando reflective loading com o parâmetro especificado
19		Configurar os parâmetros para carregar uma única DLL
20		Descarregar a única DLL
21	Módulo	Carregar o “módulo de ação” (ActionModule.dll) de forma reflective loading e executa a função de exportação AppinfoView
22		Carregar o “módulo de função” (FunctionModule.dll) em reflective loading e executa a função de exportação PresentationFontConfig

Os comandos 21 e 22 carregam, cada um, um módulo diferente. De acordo com seus nomes internos, o módulo de ação gerencia operações básicas de arquivos e processos, enquanto o módulo de função implementa os comandos padrão do Windows. O módulo de ação abrange os comandos 23–41, e o módulo de função lida com os comandos 42–79.

O módulo de ação lida com comandos de operação do sistema, interações com o sistema de arquivos e comportamento de processos. Ele é executado passando o comando e os parâmetros apropriados para a função de exportação AppinfoView. O módulo aceita 19 comandos, numerados de 23 a 41. Os resultados da execução são enviados primeiro ao Cubridge, que os encaminha ao servidor de C2.

Comando	Função
23	Obter o espaço em disco disponível em cada unidade
24	Obter informações sobre o arquivo ou diretório especificado
25	Executar o comando fornecido
26	Obter informações sobre o arquivo ou diretório especificado (semelhante ao comando 24)
27	Executar o comando fornecido no contexto do processo de destino (spoofing de PPID)
28	Executar o comando fornecido no contexto do processo de destino, na sessão especificada (spoofing de PPID + representação da sessão)
29	Obter informações detalhadas sobre os processos
30	Encerrar o processo fornecido
31	Suspender todas as threads pertencentes ao processo especificado
32	Retomar a execução de todas as threads pertencentes ao processo especificado
33	Excluir permanentemente o arquivo, sobrescrevendo todo o seu conteúdo com a seguinte sequência: 0 → 1 → bytes aleatórios → 1 → 0
34	Renomear o arquivo fornecido para :EFS (a área de fluxo de dados alternativo) e excluí-lo usando a API nativa SetFileInformationByHandle
35	Definir o diretório de trabalho atual
36	Copiar o arquivo especificado no caminho fornecido
37	Excluir o diretório especificado
38	Mover o arquivo especificado para o caminho fornecido
39	Criar o diretório fornecido
40	Iniciar uma tentativa de conexão não bloqueante com o endereço IP e a porta especificados (possivelmente para verificação de portas)
41	Ler o arquivo especificado

O módulo de função implementa comandos que emulam os comandos integrados do Windows. Semelhante ao módulo de ação, sua rotina DllMain inicializa todas as funções de comando compatíveis, que são acessadas posteriormente por meio da exportação PresentationFontConfig. Ao todo, ele oferece 38 comandos, numerados de 42 a 79. Acreditamos que este módulo seja baseado no LightlessCan anterior, mas é a primeira vez que o vemos na forma de um módulo separado.

Comando	Função
42	Captura todas as telas e as coloca em um arquivo comprimido usando o algoritmo legado ZipCrypto com a senha hard‑coded: xdkiTajAAxc3i/w[<881fnC!G*cb1Dit2sh.gAk/
43	Sincroniza os horários MAC (Modificado, Acessado e Criado) do arquivo fornecido no segundo argumento para corresponderem aos do arquivo fornecido como o primeiro argumento
44	Obtém informações sobre o diretório especificado
45	Obtém informações sobre a unidade especificada
46	Injeta o payload de DLL fornecido no processo de destino
47	Descarrega a DLL especificada do processo especificado
48	Implementa o comando ipconfig
49	Implementa o comando net
50	Implementa o comando netsh advfirewall firewall
51	Implementa o comando netstat
52	Implementa o comando ping -6
53	Implementa o comando reg
54	Implementa o comando sc
55	Implementa o comando ping
56	Implementa o comando whoami
57	Implementa o comando nslookup
58	Implementa o comando schtasks
59	Implementa o comando systeminfo
60	Implementa o comando arp
61	Chama a função CryptUnprotectData para recuperar a chave AES que o DPAPI protege. Extrai a chave usando a palavra-chave encrypted_key do arquivo Local State do Chromium localizado em: %LOCALAPPDATA%\Google\Chrome\User Data\Local State
62	Não implementado
63	Não implementado
64	Lê o arquivo especificado e descriptografe-o usando uma operação XOR  com a chave 0x59. Em seguida, extrai os caminhos do buffer descriptografado e compacta os arquivos e diretórios localizados nesses caminhos usando o algoritmo legado ZipCrypto e a senha hard-coded: xdkiTajAAxc3i/w[<881fnC!G*cb1Dit2sh.gAk/
65 ~ 79	Não implementado

Além dos módulos, também observamos que o agente da ameaça implementou diversos plug-ins e ferramentas.

Tipo de payload	Nome	Descrição
Plug-in	ADFinder (AdFinder.dll)	Executa consultas LDAP em um ambiente do Active Directory, recebendo seis argumentos, como o caminho do arquivo de log, o ADsPath, o filtro de pesquisa e os nomes dos atributos.
Plug-in	FileCollector (Dll.dll)	Percorre recursivamente todos os subdiretórios e arquivos do diretório fornecido, coletando informações detalhadas sobre cada um.
Ferramenta	Stealer de navegador	Pode ser injetado em navegadores baseados no Chromium, como Google Chrome, Microsoft Edge e Brave. Após ser injetado, extrai arquivos e credenciais dos navegadores da vítima, incluindo senhas salvas, favoritos, histórico, preferências e cookies.
Ferramenta	Coletor de processos	Realiza a iteração em todos os processos em execução, coletando o ID, o caminho e a linha de comando de cada processo.

O TouchHub instala um serviço para o TouchShift

Durante nossa análise, adquirimos uma amostra de malware anteriormente desconhecida do repositório privado do GitHub do TechHub, que serviu como um instalador principal para o TouchShift. Denominamos esse malware TouchHub. Ao ser executado, ele copia o arquivo legítimo printfilterpipelinesvc.exe para C:\Windows\System32\RasConv\ImeBroker.exe, registra-o como um serviço e grava no mesmo diretório um payload do TouchShift incorporado ao arquivo, denominada mscoree.dll. Após a criação, o malware sincroniza os timestamps MAC (Modificado, Acessado e Criado) de C:\Windows\System32\drivers\monitor.sys com os do arquivo recém-gravado para dificultar a análise forense.

Em seguida, ele passa pelo processo de registro de serviço coletando até 100 nomes de serviços legítimos registrados no grupo svchost netsvcs em HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost. Ele seleciona aleatoriamente um desses nomes, acrescenta duas letras aleatórias para formar um novo nome de serviço e usa esse nome para criar um serviço que executa a linha de comando hard-coded C:\Windows\System32\RasConv\ImeBroker.exe -TimeBroker com a descrição Microsoft Service. O serviço recém-criado é iniciado imediatamente.

De modo geral, o TouchHub cria três arquivos no diretório especificado para executar o TouchShift com privilégios de SYSTEM.

Caminho	Tipo	Descrição
C:\Windows\System32\RasConv\ImeBroker.exe	Arquivo executável registrado como um serviço	Copiado de C:\Windows\System32\printfilterpipelinesvc.exe
C:\Windows\System32\RasConv\mscoree.dll	Payload do TouchShift com carregamento lateral	Gravada pelo TouchHub, contém payloads maliciosos criptografados e inclui partes do conteúdo de uma DLL legítima, o que aumenta consideravelmente seu tamanho.
C:\Windows\System32\RasConv\ActivationStore.dat	Arquivo de configuração do TechHub	Gravado pelo TouchHub após a extração dos valores de configuração

TouchShift, um loader predominante empregado em várias cadeias de infecção

O TouchShift instalado pelo TouchHub é quase idêntico à versão descrita no blog da Mandiant, inclusive por utilizar a mesma função exportada maliciosa, LockClrVersion. Ele recebe o argumento fornecido pelo TouchHub e aplica uma operação XOR usando uma chave hard-coded. O valor resultante passa por XORing mais uma vez com o nome do arquivo do executável, e esse resultado é usado como a chave AES. Todas as strings envolvidas nesse processo (o argumento, a chave XOR e o nome do arquivo) devem ter exatamente 16 bytes. Se uma string for mais curta, ela será preenchida (padding) com bytes NULOS (\x00); se for mais longa, será truncada para 16 caracteres. Por exemplo, a amostra obtida apresentava a seguinte combinação de strings:

• Argumento: -TimeBroker\x00\x00\x00\x00\x00 (preenchido com bytes NULOS)
• Chave XOR hard-coded: x809G736iC3f8Wp8
• Nome do arquivo executável: ImeBroker.exe\x00\x00\x00 (preenchido com bytes NULOS)

Após derivar a chave, o malware descriptografa o payload incorporado usando AES-CBC-128 sem padding. Os dados descriptografados são um shellcode que começa com uma instrução call, que encapsula o payload do estágio seguinte. Essa carga foi identificada como a terceira versão do TechHub, que utiliza a técnica de DLL sideloading com um serviço registrado e lê o arquivo ActivationStore.dat como configuração externa.

ClientHub

Também identificamos um novo malware armazenado no repositório privado do TechHub, que denominamos ClientHub. Ele aceita diversos comandos, definidos por meio de uma máscara de bits (bitmask). Existem pelo menos duas versões do ClientHub: uma se comunica com sites por HTTP(S), enquanto a outra interage com a API do Dropbox usando credenciais.

Dependendo da versão, a configuração é obtida de recursos internos ou de um arquivo de configuração externo, C:\Program Files\Common Files\System\msadc\msadc.inc. A configuração inclui chaves e vetores de inicialização (IVs) para o algoritmo SNOW 1.0, horários de execução agendada e endereços de servidores de C2 criptografados com a cifra de fluxo SNOW. A cifra SNOW é uma família de cifras de fluxo de alta velocidade, utilizada para criptografar dados com segurança em redes de telecomunicações e redes sem fio. Esta é a primeira vez que essa cifra é identificada em um malware do Grupo Lazarus.

Para estabelecer a comunicação C2, o malware gera inicialmente uma matriz aleatória de 32 bytes. Posteriormente, ele sobrescreve partes dessa matriz com dados coletados do dispositivo comprometido. Como resultado, a matriz de 32 bytes contém uma combinação de bytes aleatórios e informações relevantes. Posteriormente, a matriz é usada como chave para o algoritmo SNOW, que descriptografa os dados recebidos do servidor de C2. Finalmente, a matriz de chaves é criptografada com uma chave pública RSA hard-coded e codificada em Base64.

Offset	Tamanho	Valor do campo
0	4	ID do processo atual
4	4	Primeiros quatro bytes das informações descriptografadas do servidor de C2.
8	7	Bytes gerados aleatoriamente
15	1	Valor de flag calculado que indica uma máquina de estados.
16	8	Hora atual do sistema, representada como uma estrutura FILETIME.
24	8	Bytes gerados aleatoriamente

O texto crifrado é entregue ao servidor de C2 por meio de requisições GET. Cada requisição contém cabeçalhos atípicos para malware: Sec-CH-UA, Sec-CH-UA-Platform, Sec-CH-UA-Mobile, Sec-Fetch-Mode e Sec-Fetch-Dest. Esses cabeçalhos são normalmente usados por navegadores legítimos baseados no Chromium e permitem que o malware imite o tráfego legítimo e evite a detecção. O servidor de C2 responde com comandos, entregando-os em um cabeçalho personalizado e no corpo da mensagem.

O campo body_type no cabeçalho determina como o payload subsequente é processada. Esse valor funciona como uma máscara de bits, com cada bit representando uma flag distinta (por exemplo, 0x1, 0x2, 0x4 etc.). O comportamento resultante também depende de o bit menos significativo (bit 0) estar definido: quando o valor é ímpar, o malware interpreta o corpo da mensagem recebida como um payload adicional, que é posteriormente carregada na memória. Por outro lado, quando o valor é par, o malware executa o payload carregado anteriormente.

O valor ímpar aceita quatro métodos distintos de carregamento com base no corpo da mensagem recebida e garante que cada método seja executado apenas uma vez.

Máscara de bits	Valor em decimal	Descrição	Resultado enviado para o C2
0x00000001	1	Carregamento de DLL: carrega o corpo recebido em reflective loading, juntamente com o parâmetro fornecido	A base da imagem do payload
0x00000011	3	Plug-in: carrega o corpo recebido em reflective loading, obtém o endereço de uma função no payload e, em seguida, executa essa função junto com o parâmetro fornecido	A base da imagem do payload, o endereço da função executada e o resultado da execução
0x00000101	5	Plug-in: carrega o corpo recebido em reflective loading, obtém o endereço de uma função no payload, mas não a invoca imediatamente	A base da imagem do payload, o endereço da função
0x00001011	11	Plug-in: executa o comportamento associado ao valor 3 e, em seguida, descarrega imediatamente após invocar o plug-in	–
0x00010001	17	Carregamento de DLL: carrega o corpo recebido de forma reflective loading, com o parâmetro fornecido, mantendo uma comunicação com persistência de estado por meio de uma sessão interativa contínua que utiliza um buffer compartilhado	A base de imagem do payload, o endereço do buffer compartilhado interativo e o resultado da execução

O valor par fornece dois métodos de invocação distintos para DLLs e plug-ins já carregados, que são associados à máscara de bits de valor ímpar. A flag 2 (0x10) permite que o payload carregado anteriormente com a máscara de bits 1, 3 ou 5 seja reutilizada e executada diretamente. O valor 16 (0x10000) corresponde à flag 17 (0x10001) no modo de carregamento e usa o buffer compartilhado interativo estabelecido para trocar dados. Todos os valores têm garantia de comportamento independente.

Máscara de bits	Valor em decimal	Descrição	Resultado enviado para o C2
0x00000010	2	Executa as DLLs e plug-ins carregados anteriormente junto com o parâmetro fornecido	O resultado da execução
0x00000100	4	Não implementado	–
0x00001000	8	Descarrega as DLLs e os plug-ins carregados anteriormente	O resultado da execução
0x00010000	16	Envia o parâmetro atualizado para o payload carregado pelo comando com o valor 17 e troca dados por meio da sessão interativa. Este comando também determina se deve recuperar o resultado da execução ou descarregar o payload.	O resultado da execução

Considerando o mecanismo de carregamento, identificamos quatro plug-ins implementados no alvo que funcionam perfeitamente com o ClientHub.

Plug-in	Descrição
Compressor de arquivos	Comprime o arquivo fornecido utilizando o algoritmo legado ZipCrypto (sem proteção por senha) e retorna os dados comprimidos.
Coletor de arquivos	Pesquisa todos os arquivos que correspondem ao padrão de pesquisa fornecido e coleta metadados, incluindo nome do arquivo, timestamps MAC (modificação, acesso, criação), tamanho do arquivo e valores de atributos.
Limpador de arquivos	Sobrescreve o arquivo especificado com bytes NULOS, renomeia-o com um nome gerado aleatoriamente com o mesmo comprimento e, em seguida, exclui o arquivo. Se for fornecido um diretório com um padrão de pesquisa, ele localiza todos os arquivos correspondentes, renomeia cada um com um nome gerado aleatoriamente de comprimento idêntico ao seu nome original e os exclui.
Monitor de unidade e sessão	Monitora alterações de sessão remota e alterações de unidade local durante o período fornecido (em intervalos de 10 minutos) e retorna as informações de status coletadas.

Além dos plug-ins, o ClientHub aceita o carregamento do malware LPEClient e a comunicação com ele. Constatamos que os valores 16 e 17 de body_type no ClientHub correspondem ao mecanismo de comunicação C2 do LPEClient.

LPEClient

O LPEClient é o único malware também observado na Operação SyncHole, o que indica que o agente o utiliza intensamente para a criação de perfis sofisticados de vítimas e para a entrega de payloads em diversas operações. O LPEClient apareceu pela primeira vez em 2019 e foi descoberto em 2020. Desde então, a ferramenta tem sido amplamente observada nas campanhas Dream Job e Cascade Hole, que tiveram a Coreia do Sul como alvo. Uma pesquisa recente da Check Point revelou que ele foi usado para implementar o malware FudModule por meio de uma vulnerabilidade do tipo zero day.

Com o passar do tempo, o LPEClient evoluiu continuamente, mas descobrimos que, recentemente, ele passou por uma grande reformulação operacional. Ele não contém mais o endereço do servidor de C2 em si; em vez disso, ele interage com o ClientHub por meio de um buffer compartilhado. Acreditamos que essa alteração tenha o objetivo de aprimorar o seu ocultamento.

A versão anterior coletava o nome do computador, o status da memória, as especificações da CPU, os detalhes do sistema operacional, a versão do arquivo ntoskrnl.exe, a tabela de firmware, o nome do antivírus, o nome do domínio, o nome do usuário, o nível de integridade do processo atual e uma sequência aleatória de bytes de 1.568 bytes. A variante recém-atualizada do LPEClient coleta basicamente as mesmas informações, no entanto, também introduz diversas alterações.

• Ele não coleta a versão do arquivo ntoskrnl.exe consultando o valor FileVersion. Em vez disso, ele lê a chave de registro HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\UBR ou a estrutura SYSTEM_BUILD_VERSION_INFORMATION para recuperar a parte da revisão do número da build do Windows, dependendo da build específica. Esses valores podem ser usados para inferir o nível de patch ou de atualização cumulativa do sistema.
• Para coletar informações sobre os produtos antivírus instalados, deixou de consultar um comando WQL e passou a ler diretamente o arquivo do repositório WMI. Agora, ele lê o arquivo C:\Windows\System32\wbem\Repository\OBJECTS.DATA e procura palavras-chave, como AntiVirusProduct, companyName e displayName, para identificar os produtos instalados.
• Ele também coleta informações sobre os estados das mitigações de segurança de baixo nível do Windows. Para isso, consulta a estrutura SYSTEM_KERNEL_VA_SHADOW_INFORMATION para obter o status da mitigação Kernel VA Shadow e a estrutura SYSTEM_SHADOW_STACK_INFORMATION para obter o status da proteção Shadow Stack (CET).

Além disso, ele gera um identificador exclusivo aleatório de 32 bytes aplicando o algoritmo HighwayHash com uma operação XOR usando a hora atual do sistema. As informações coletadas, incluindo o identificador gerado, são compactadas com o algoritmo XPRESS Huffman usando a configuração máxima de compactação. Em seguida, os dados compactados são concatenados ao ID da mensagem 0xF07D6B34 e criptografados com GOST (também conhecido como Magma), o padrão criptográfico nacional da Rússia, que utiliza uma estrutura semelhante à do DES, antes de serem enviados ao ClientHub por meio de um buffer compartilhado. Inicialmente, o KrCERT descreveu o algoritmo como um esquema personalizado semelhante ao DES. No entanto, análises posteriores realizadas por nós e pela Check Point confirmaram que se trata, na verdade, do algoritmo GOST. A chave é gerada aleatoriamente por meio de um algoritmo proprietário de geração de chaves e inserida no início da mensagem criptografada.

A próxima requisição lida com a troca de chaves entregando o ID de mensagem 0xA39CF278 juntamente com o identificador exclusivo gerado. A resposta é descriptografada usando o algoritmo AES‑CBC‑256. Para essa descriptografia, o hash SHA‑256 do valor aleatório de 1.568 bytes gerado anteriormente, originalmente enviado ao servidor de C2 durante a fase de coleta, serve como chave.

Por meio desse processo, o LPEClient obtém uma matriz de bytes composta por quatro blocos da resposta do servidor de C2, cada um medindo 1.568 bytes. Cada bloco contém uma chave pública ML-KEM-1024, em que ML-KEM é um mecanismo de encapsulamento de chaves pós-quântico padronizado pelo NIST e derivado do CRYSTALS-Kyber. O LPEClient gera quatro pares distintos de chaves compartilhadas e textos cifrados a partir desses blocos, criptografa os textos cifrados usando o algoritmo GOST e os transmite ao servidor de C2 por meio do ClientHub, juntamente com o identificador da mensagem 0xEF8C0D51 e o identificador associado. Com a fase de preparação para o recebimento de payloads agora concluída, o malware está preparado para receber os payloads encaminhados pelo ClientHub a partir do servidor de C2, junto com os parâmetros necessários. O uso da criptografia pós-quântica destaca que o grupo realmente pretende ocultar os payloads subsequentes.

A resposta à mensagem 0xEF8C0D51 é descriptografada com o algoritmo Threefish usando uma chave de 256 bytes, composta pelas quatro chaves compartilhadas distintas. O Threefish é uma cifra de bloco ajustável que aceita um valor de “ajuste” junto com a chave e a mensagem. O conceito de ajuste é semelhante ao de nonce ou vetor de inicialização, utilizados em diferentes tipos de cifras. Na comunicação do LPEClient, o ajuste para a descriptografia é derivado aplicando XOR no identificador exclusivo com 165(0xA5). Os primeiros quatro bytes da mensagem descriptografada devem especificar o comprimento do parâmetro, seguidos pelo próprio parâmetro e, em seguida, pelo payload. O payload deve ter mais que 4KB e começar com os caracteres 'MZ', o que indica que o payload descriptografado é um arquivo executável. O payload é então carregado usando a técnica de reflective loading para a memória. Após o carregamento bem-sucedido, o LPEClient envia o ID de mensagem 0xCB790A25 para o servidor de C2.

Antes de carregar o payload adquirido, o LPEClient adota medidas para contornar os produtos de segurança. Em vez de invocar VirtualProtect diretamente, o malware usa o HeapPageAllocator::ProtectPages identificado em jscript9.dll para modificar a proteção da página de memória da função MD4Update. Em seguida, o início da função é sobrescrito com uma sequência de códigos de operação (opcodes) hard-coded, que funciona como um stub de chamada de sistema (syscall) com os argumentos necessários. Usando o stub de syscall, o LPEClient desativa um hook de instrumentação de syscall em modo de usuário.
O processo geral de comunicação é o seguinte. Identificamos que o payload final efetivamente carregado era o Cubridge.

Comparação de plug-ins e módulos

Ao longo da investigação, identificamos diversos payloads implementados pelo TechHub, Cubridge e ClientHub. Esses payloads foram categorizados em ferramentas, plug-ins e módulos que constituem o framework modular de malware do grupo. Embora ainda não tenhamos determinado em quais condições específicas cada payload é implementado, as evidências sugerem que o conjunto de ferramentas do Grupo Lazarus está se tornando cada vez mais sofisticado e segmentado em componentes especializados, em vez de se concentrar em uma única backdoor abrangente. Também acreditamos que o TechHub e o Cubridge podem compartilhar ferramentas semelhantes.

Implementado via	Tipo de payload	Family
TechHub/Cubridge	Ferramenta	Coletor de processos, Stealer de navegador
Cubridge	Módulo	Módulo de ação, Módulo de função
Cubridge	Plug-in	ADFinder, FileCollector
ClientHub	Plug-in	Compressor de arquivos, Coletor de arquivos, Limpador de arquivos, Monitor de unidade/sessão

Essas modularizações não estão confinadas às instâncias pertencentes a esta campanha. Conforme observado anteriormente, padrões semelhantes foram identificados no CookiePlus, MISTPEN, SIGNBT e IMETHOD. Vale observar que reclassificamos a variante do ThreatNeedle utilizada na Operação SyncHole como a versão mais recente do IMETHOD, antecessor do ThreatNeedle, que vinha sendo utilizado desde pelo menos 2016.

Infraestrutura

Com base nas informações que obtivemos do malware TechHub, identificamos pelo menos três repositórios principais usados como servidor de C2 e um repositório de fallback. As evidências mais antigas mostram que o grupo utiliza o GitHub como servidor de C2 desde, pelo menos, julho do ano passado. Suspeitamos que todas as contas tenham sido criadas com endereços de e-mail sequestrados e disfarçadas de repositórios legítimos, por meio da cópia ou criação de projetos comuns, para evitar suspeitas.

Para os servidores de C2 do Cubridge e do ClientHub, o Grupo Lazarus utilizou apenas um número reduzido de sites legítimos sul-coreanos de mídia e design de interiores que haviam sido comprometidos. Posteriormente, observamos que também foram explorados diversos outros sites legítimos comprometidos, de diferentes setores. Além disso, uma amostra do ClientHub que detectamos utilizava o Dropbox como canal de C2.

Vítimas

Identificamos pelo menos três empresas sul-coreanas dos setores de software, construção e fabricação de equipamentos para comunicação por fio que foram comprometidas pela Operação FlashHole. No entanto, assim como na operação anterior, continuamos confiantes de que um número consideravelmente maior de organizações, de um espectro mais amplo de setores, foi afetado.

O setor de software é o único visado tanto na campanha SyncHole quanto na FlashHole. Isso sugere que o invasor está fortemente interessado em comprometer o setor, roubar código-fonte, encontrar vulnerabilidades e usá-las para novos ataques.

Atribuição e vínculos com outras campanhas

A Operação FlashHole é a onda mais recente de uma campanha mais ampla, a Cascade Hole, que explora vulnerabilidades em softwares sul-coreanos para distribuir malware direcionado à Coreia do Sul. Embora a cadeia de infecção por malware tenha evoluído significativamente em comparação com o ano passado, avaliamos, com grau de confiança de médio a alto, que o mesmo agente é responsável pelas operações SyncHole e FlashHole. Essa avaliação se baseia no vetor inicial, nos alvos, na cadeia de múltiplos estágios e nas melhorias técnicas e operacionais. Em particular, o uso do LPEClient é um forte indicador que respalda essa avaliação.

As variantes de malware utilizadas no ataque estão historicamente associadas aos conjuntos de ferramentas observados na notória campanha Dream Job do Grupo Lazarus. Versões anteriores do TechHub (também conhecido como CLOUDBURST e NickelLoader), do Cubridge (também conhecido como SIDESHOW e LightlessCan) e do TouchShift já foram identificadas nessa campanha, especialmente entre 2022 e 2023.

Também descobrimos que tanto o CookiePlus quanto o ClientHub compartilham sobreposições significativas: nome de classe, caminho de configuração e plug-ins. Com base nisso, avaliamos, com grau de confiança de médio a alto, que o ClientHub é uma versão avançada do CookiePlus.

Desde pelo menos julho do ano passado, aproximadamente quando a Operação SyncHole começou a perder força, também observamos vários ataques relevantes contra a Coreia do Sul que empregaram o backdoor COPPERHEDGE e tiveram como alvo diversas organizações sul-coreanas. Curiosamente, os horários de início dessas atividades coincidem com as primeiras evidências que identificamos para a Operação FlashHole. Embora o backdoor fizesse parte da segunda fase da Operação SyncHole, desde então ele vem operando de forma independente, com seu próprio loader personalizado. Esses incidentes envolveram cadeias de infecção por malware e ferramentas distintas das utilizadas nas operações SyncHole e FlashHole.

Conforme observado pela AhnLab em seu relatório, o mesmo backdoor provavelmente foi identificado em uma atividade atípica, especificamente em uma infecção pelo ransomware Gunra. Nossa investigação também revelou que uma infecção por backdoor levou à exfiltração de dados para um site da dark web conhecido por vazamentos, claramente distinto do Gunra. O site parece ter sido criado exclusivamente para essa atividade. Em resumo, diferentemente do que ocorre em outros ataques, o backdoor também foi utilizado em conjunto com ransomware e para a exfiltração de dados.

Outro aspecto importante é que a recente campanha Dream Job emprega uma cadeia de malware atualizada que, desde meados de 2024, envolveu principalmente o MISTPEN e o ForestTiger em vez de seu arsenal anterior, que incluía ferramentas como o TechHub e o Cubridge. As versões atualizadas desse malware mais antigo, no entanto, ressurgiram agora como parte da Operação FlashHole. Considerando essas mudanças e todos os aspectos dos TTPs de cada ataque, organizamos uma classificação para cada um deles.

Conclusão

Nossa análise indica que o Grupo Lazarus começa a preparar novas operações pouco depois de concluir campanhas anteriores, aprimorando ferramentas existentes para, por fim, implementar uma cadeia de infecção por malware mais sofisticada. O grupo continua utilizando a versão avançada do LPEClient para realizar o reconhecimento dos sistemas e distribuir payloads, o que indica que a ferramenta é gerenciada com rigor e mantida regularmente. Ironicamente, o grupo parece ter adotado uma criptografia pós-quântica mais segura antes de muitos produtos legítimos de segurança. Essas observações sugerem o envolvimento de um desenvolvedor dedicado, enquanto outros integrantes coordenam um cenário de ataque abrangente contra empresas de software recém-selecionadas como alvos.

Antecipamos que os ataques especializados à Coreia do Sul continuariam. No entanto, não prevíamos que várias campanhas de ataque seriam conduzidas simultaneamente, cada uma utilizando diferentes tipos de software e ferramentas. Vale destacar que o cluster COPPERHEDGE parece estar envolvido na monetização dos ataques, enquanto a Operação FlashHole tem foco em espionagem. Estamos monitorando de perto essas mudanças para compreender suas motivações e seus objetivos finais.

Em outubro do ano passado, o governo sul-coreano anunciou um plano abrangente de cibersegurança que prevê o fim da obrigatoriedade de instalação de softwares de segurança pelos usuários a partir de 2026. Estimamos que as operações que exploram esses softwares continuarão bastante ativas por algum tempo, buscando maximizar sua eficácia antes que esses softwares sejam totalmente eliminados ou que suas vulnerabilidades sejam mitigadas.
Os produtos da Kaspersky detectam os exploits e malware utilizado nesse ataque com as seguintes classificações: MEM:Trojan.Win64.Shellcode.gen, Trojan.Win64.DLLhijack.* e Trojan.Win64.Lazarus.*.

Indicadores de comprometimento

Hashes de arquivo

TouchShift
ec84d6cb2ae7974767aedac246b50a3e             mscoree.dll
a28cba214058fcae2883d8cffc883abd                mscoree.dll
c105d6b16f544582772de0159f24c00a               mscoree.dll
2f8475a90a25624ed02f1d18d4e6d65d              mscoree.dll
676fabe30a28b53925fba98e34b35986              mscoree.dll
b4a7eff35f048f06fb0a2d7631f23a7d                  mscoree.dll

ClientHub Loader
ff07641dc56914dd90ee0bd7404d7ad7               liblzma.dll

Caminhos de arquivos

C:\ProgramData\Dell\Dell1.tmp
C:\ProgramData\Dell\Dell3.tmp
C:\ProgramData\Package.txt
C:\ProgramData\RasConv\mscoree.dll
C:\ProgramData\Apple\mscoree.dll
C:\ProgramData\ssh\mscoree.dll
C:\ProgramData\qorestor\mscoree.dll
C:\ProgramData\Dell\mscoree.dll
C:\ProgramData\Dell\Dell1.tmp
C:\ProgramData\Dell\Dell3.tmp
C:\Windows\System32\RasConv\mscoree.dll
C:\Windows\System32\RasConv\ActivationStore.dat
C:\Windows\System32\DrvConh\mscoree.dll
C:\Windows\System32\DrvConh\ActivationStore.dat
C:\Program Files\Common Files\System\msadc\msadc.inc
C:\ProgramData\desktops.ini

Servidores de C2

javadevhouse.co[.]kr
pythonapischool[.]com
hxxps://cubedesign[.]co[.]kr/news            C2 do Cubridge
hxxps://cubedesign[.]co[.]kr/mobile/fashion            C2 do Cubridge
hxxps://fp-news[.]co[.]kr/shop/cart                                C2 do Cubridge
hxxps://k-wbc[.]co[.]kr/skin/social/social_view.php         C2 do ClientHub
hxxps://rcsh[.]co[.]kr/modules/bbs/tiles/bbs_div/inputForm.php    C2 do ClientHub
hxxps://www[.]ksog[.]org/insert_file/handle.php                   C2 do ClientHub