Campanha atribuída ao Lazarus mira organizações russas com documentos Office e backdoor KEYMARBLE

Documentos maliciosos com macros foram preparados para vítimas na Rússia e levaram a uma variante atualizada do KEYMARBLE, com comunicação criptografada via wolfSSL e C2 em porta 443.

Componente	Documentos Office maliciosos em formatos XLS e DOC, cadeia de download e backdoor KEYMARBLE associado ao ecossistema Lazarus.
Vetor	Arquivos Office criados para vítimas russas tentavam induzir o usuário a habilitar macros; pelo menos uma entrega ocorreu em arquivo ZIP com documento PDF isca chamado NDA_USA.pdf.
Impacto	Execução do KEYMARBLE como ferramenta de administração remota, coleta de informações do sistema e espera por comandos de operador após contato com servidor C2.
Prioridade	Bloquear documentos Office com macros não confiáveis, caçar downloads de CAB disfarçados, revisar tráfego TLS incomum para porta 443 e isolar hosts que criaram artefatos compatíveis com a cadeia.
Artefatos	Amostras enviadas ao VirusTotal entre 26 e 31 de janeiro de 2019 a partir de origens na Rússia, com metadados semelhantes, autor home e página de código coreana.
IoCs	Servidor comprometido com payload em hxxp://37.238.135[.]70/img/anan.jpg; C2 hardcoded 194[.]45[.]8[.]41 na porta 443; arquivo temporário Thumbss.db usado para certificado PEM.
Mitigação	Restringir macros, inspecionar anexos ZIP com documentos duplos, revisar conexões persistentes a destinos raros e correlacionar execução do Office com criação de CAB, expansão de arquivo e atividade de rede subsequente.

Resumo técnico

Uma campanha direcionada contra organizações localizadas na Rússia usou documentos Office maliciosos como estágio inicial de infecção e culminou na entrega de uma variante atualizada do backdoor KEYMARBLE. A atividade apresenta vínculos técnicos com ferramentas, técnicas e padrões historicamente associados ao Lazarus, embora a atribuição permaneça condicionada por artefatos e sobreposição de TTPs, não por confirmação direta do operador. O ponto mais relevante para defesa é a combinação de iscas específicas para vítimas russas, macros pouco ofuscadas, uso de serviços legítimos ou servidores comprometidos para estágio intermediário e encapsulamento do payload em CAB para reduzir detecção.

A seleção de alvos é incomum dentro do padrão descrito para operações norte-coreanas, que costumavam ser associadas a tensões envolvendo Estados Unidos, Japão e Coreia do Sul, além de campanhas financeiras globais. Nesta operação, os documentos foram adaptados para organizações russas e carregavam metadados recorrentes, incluindo autor home e página de código coreana. A campanha também ocorreu no mesmo período de uma operação separada contra empresas sul-coreanas de segurança, mas os procedimentos observados diferem, reforçando a hipótese de múltiplas frentes operacionais com ferramentas e objetivos distintos dentro do mesmo ecossistema de ameaça.

Fluxo técnico

A cadeia começava com documentos Office em variantes XLS e DOC contendo macros maliciosas. As iscas visuais tentavam convencer a vítima a habilitar conteúdo ativo, condição necessária para disparar o código da macro. As macros eram simples, sem técnicas avançadas de ofuscação, e essa simplicidade aparentemente contribuiu para baixa detecção em mecanismos de análise. Em uma fase inicial, o fluxo incluía um segundo estágio baixado antes do payload final; posteriormente, os operadores alteraram a cadeia para que as macros baixassem e executassem diretamente o backdoor Lazarus no terceiro estágio, reduzindo etapas e pontos de falha.

Um dos documentos continha lógica relacionada a Dropbox no cabeçalho Host da requisição HTTP, detalhe que se alinhou a outra amostra vinculada à campanha que buscava o estágio seguinte diretamente no Dropbox. Pelo menos uma entrega foi empacotada em ZIP com um PDF isca chamado NDA_USA.pdf, apresentado como documento benigno para dar legitimidade ao conjunto. O PDF fazia referência a um NDA para StarForce Technologies, empresa russa de soluções de proteção contra cópia de software, enquanto o arquivo Office no mesmo pacote carregava a lógica de execução maliciosa.

O payload final era recuperado como arquivo CAB hospedado em servidor comprometido e disfarçado como imagem JPEG no caminho defangado hxxp://37.238.135[.]70/img/anan.jpg. O servidor apresentava um site pouco convincente para um suposto departamento de informação da South Oil Company, estava localizado no Iraque e hospedado pela EarthLink Ltd. Communications&Internet Services. O encapsulamento em CAB reduziu a taxa de detecção observada na amostra, em comparação com o mesmo backdoor fora desse contêiner. Após expansão, o componente resultante era o KEYMARBLE, um RAT de propósito geral.

O KEYMARBLE executava uma fase de inicialização com resolução dinâmica de funções Win32. Nessa etapa, nomes de funções eram descriptografados em tempo de execução e resolvidos para uma tabela global de endereços usada nas chamadas posteriores. O mecanismo usava código aberto McbDES2 para descriptografia DES dos nomes de funções, um detalhe útil para engenharia reversa e criação de detecções comportamentais. Em seguida, o malware preparava estruturas de comunicação e componentes relacionados ao wolfSSL para autenticação e criptografia de tráfego.

A variante gravava no disco um certificado PEM embutido no diretório temporário com o nome Thumbss.db. O conteúdo era lido e processado por uma função interna chamada ProcessFile, que alimentava estruturas globais usadas na comunicação criptografada. Para contato externo, o malware criava um socket, configurava modo não bloqueante por ioctlsocket com argumento 0x8004667E e tentava conectar ao endereço 194[.]45[.]8[.]41 na porta 443. As tentativas eram repetidas indefinidamente em intervalos de 30 minutos até sucesso.

Depois da primeira conexão, o KEYMARBLE emitia um beacon. A identificação da máquina era derivada de MD5(ProductID | MAC), combinando o valor de SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductId com o endereço MAC obtido por GetAdaptersInfo. Essa identificação só era enviada após solicitação explícita do servidor; antes disso, o campo de dados do beacon permanecia vazio. O loop principal aguardava códigos de comando vindos do C2, recebidos em duas etapas: primeiro o tamanho dos dados e depois o código do comando. A variante analisada tinha 18 comandos, menos que os 22 observados em amostra anterior, com códigos na faixa de 0x1234556 a 0x1234578 e diferenças em alguns handlers.

Superfície afetada

A superfície exposta concentra-se em estáções Windows cujos usuários recebem documentos Office por canais de entrega compatíveis com anexos, arquivos ZIP ou compartilhamento de documentos. A execução depende de interação do usuário para habilitar macros, mas a baixa complexidade da macro e a aparência de documentos legítimos tornam o caso relevante para ambientes que ainda permitem conteúdo ativo em arquivos originados fora do domínio corporativo. Organizações russas foram o alvo observado, mas os controles defensivos aplicáveis são os mesmos para qualquer ambiente que trate documentos Office externos com permissões permissivas.

A presença de Dropbox em um dos estágios e de servidor comprometido para payload final amplia a superfície de monitoramento. Bloqueios baseados apenas em reputação de domínio podem falhar quando infraestrutura legítima ou previamente comprometida aparece no caminho de entrega. O uso de CAB disfarçado como imagem também exige inspeção por tipo real de arquivo, não apenas por extensão ou caminho. Para times de segurança, o caso combina três camadas de risco: engenharia social baseada em documento, execução de macro e comunicação de backdoor com tráfego criptografado em porta normalmente permitida.

• Estáções Windows com Office configurado para permitir macros após decisão do usuário.
• Gateways de e-mail, proxies e sandboxes que classificam anexos ZIP e documentos Office sem análise de macro efetiva.
• Controles de rede que permitem conexões TLS de hosts de usuário para destinos raros na porta 443 sem inspeção de anomalia.
• Ambientes que confiam em extensão de arquivo e não validam conteúdo CAB disfarçado de imagem.

Hunting e telemetria

A investigação deve começar pela correlação entre abertura de documentos Office, criação de processos filhos, conexões HTTP ou TLS e gravação de arquivos temporários. Eventos em que WINWORD.EXE ou EXCEL.EXE antecedem download de arquivo CAB, expansão de conteúdo ou execução de binário desconhecido devem receber prioridade. A cadeia descrita também deixa oportunidades de detecção em metadados de documentos: autor home, página de código coreana e nomes de arquivos preservados em submissões originadas na Rússia são pistas de triagem, embora não devam ser usados isoladamente como prova de comprometimento.

Na rede, procure tentativas repetidas de conexão a um mesmo destino externo na porta 443 em intervalos próximos de 30 minutos, especialmente quando partem de estáções de usuário após abertura de documentos. O endereço 194[.]45[.]8[.]41 e o caminho hxxp://37.238.135[.]70/img/anan.jpg são indicadores diretos desta campanha, mas o valor operacional mais duradouro está em detectar o padrão: download de CAB com tipo de conteúdo inconsistente, endpoint comprometido servindo arquivo com nome de imagem e posterior beacon criptografado por biblioteca embarcada. Em endpoint, a criação de Thumbss.db no diretório temporário como certificado PEM é um sinal forte quando aparece em sequência com execução de documento Office.

A análise de memória e engenharia reversa pode confirmar resolução dinâmica de APIs, uso de DES via McbDES2, estruturas wolfSSL e o dispatcher de comandos. Para operações de DFIR, a confirmação deve ser feita sem executar a amostra em ambiente produtivo. O objetivo é reconstruir a linha do tempo: recebimento do arquivo, habilitação de macro, requisições de download, criação de artefatos em disco, inicialização do backdoor e comunicação com C2. Essa sequência reduz falsos positivos e ajuda a separar simples recebimento de anexo malicioso de execução efetiva.

• Processos do Office criando filhos, gravando CAB ou acionando expansão de arquivo logo após abertura de documento externo.
• Arquivo Thumbss.db em %TEMP% com conteúdo compatível com certificado PEM, associado a processo suspeito.
• Conexões periódicas para 194[.]45[.]8[.]41 na porta 443 ou destinos raros com padrão semelhante de beacon.
• Downloads de CAB ou binário servidos por caminhos com extensão de imagem, incluindo hxxp://37.238.135[.]70/img/anan.jpg.
• Documentos XLS ou DOC com macros simples, metadados de autor home e página de código coreana em campanhas direcionadas.

Mitigação

A resposta deve priorizar contenção de execução de macros e bloqueio da cadeia de entrega. Políticas de Office devem impedir macros em documentos obtidos da internet, anexos externos ou arquivos extraídos de ZIP sem validação. Gateways e EDR precisam tratar documento Office com macro como evento de risco quando há tentativa subsequente de download, mesmo quando a macro não contém ofuscação sofisticada. Sandboxes devem avaliar o comportamento após habilitação de conteúdo, validar tipo real do arquivo baixado e acompanhar redirecionamentos ou cabeçalhos incomuns, incluindo uso indevido de serviços legítimos.

Em hosts suspeitos, isole a máquina antes de coletar artefatos, preserve logs de processo, rede, DNS, proxy e arquivos temporários, e verifique se houve contato com C2. A simples presença de documento malicioso não confirma execução; a confirmação depende de sinais como processos filhos do Office, download do CAB, criação do certificado temporário, execução do KEYMARBLE ou beacon externo. Quando houver execução, credenciais usadas no host devem ser tratadas como potencialmente expostas ao operador, mas o escopo de impacto precisa ser validado por evidência local, sem assumir exfiltração ou movimentação lateral se esses sinais não aparecerem.

No perímetro e na rede, bloqueie indicadores defangados associados à campanha e crie detecções para classes de comportamento. Monitore conexões TLS persistentes de estáções de usuário para IPs raros, especialmente quando precedidas por documentos Office. Revise permissões de saída para hosts que não precisam acessar diretamente a internet, e use inspeção de conteúdo para impedir CAB disfarçado de imagem. Em paralelo, atualize regras de detecção para KEYMARBLE com base em características estruturais, como uso de wolfSSL, certificado PEM temporário, cálculo de identificador com ProductID e MAC, e dispatcher de comandos em faixa compatível.

A validação pós-contensão deve reconstruir todos os pontos de entrada possíveis: anexos, ZIPs, compartilhamentos, downloads e e-mails com iscas relacionadas a contratos ou NDA. Remova amostras de caixas postais, bloqueie hashes internamente quando disponíveis no ambiente, reanalise endpoints que receberam o mesmo arquivo e confirme se não há tarefas, serviços ou executáveis remanescentes associados ao payload. A prioridade defensiva não é apenas bloquear um IP ou um arquivo, mas reduzir a chance de recorrência do padrão de ataque: documento convincente, macro simples, estágio remoto e RAT com comunicação criptografada.

• Bloquear macros de documentos externos e aplicar política de abertura protegida para arquivos vindos de e-mail, internet ou ZIP.
• Criar correlações entre Office, download de CAB, criação de arquivos em %TEMP% e conexão externa na porta 443.
• Bloquear ou monitorar 194[.]45[.]8[.]41 e 37.238.135[.]70, mantendo os indicadores defangados em documentação e relatórios.
• Inspecionar arquivos servidos como imagem quando o conteúdo real for CAB, executável ou arquivo compactado.
• Isolar hosts com sinais de execução do KEYMARBLE, preservar evidências e validar comunicação C2 antes de escopo final do incidente.