BitMEX frustra tentativa de hack do Grupo Lazarus, expõe IPs dos hackers e falhas operacionais

A BitMEX revelou uma tentativa de hack falhada pelo Grupo Lazarus, expondo erros grosseiros de uma coletividade há muito ligada à unidade de guerra cibernética da Coreia do Norte.

De acordo com um post no blog lançado pela BitMEX na sexta-feira, a equipe agora configurou um sistema de monitoramento interno para observar mais infecções e possivelmente capturar erros futuros de segurança operacional.

Tudo começou quando um funcionário da BitMEX foi contatado no LinkedIn com uma proposta para trabalhar em um projeto de marketplace de NFTs falso, mas a oferta correspondia a uma tática de phishing conhecida usada pelo Lazarus, então o funcionário imediatamente reportou, iniciando uma investigação completa.

A equipe de segurança da BitMEX acessou um repositório GitHub que o atacante compartilhou, que continha um projeto Next.js/React. Mas enterrado dentro havia código projetado para fazer o funcionário executar inadvertidamente uma carga maliciosa em seu sistema. A equipe não executou o código, foi direto para a análise.

BitMEX dissecar malware, encontra impressões digitais do Lazarus

Dentro do repositório, os engenheiros da BitMEX procuraram o termo eval, uma bandeira vermelha comum em malware. Uma linha de código havia sido comentada, mas ainda revelava a intenção. Se ativa, ela teria se comunicado com “hxxp://regioncheck[.]net/api/user/thirdcookie/v3/726” para buscar um cookie e executá-lo. Esse domínio havia sido anteriormente vinculado ao Lazarus pela Unit 42 da Palo Alto Networks, uma equipe que rastreia atividades cibernéticas da RPCD há anos.

Outra linha estava ativa. Ela enviou uma solicitação para “hxxp://fashdefi[.]store:6168/defy/v5” e executou a resposta. A BitMEX buscou manualmente esse JavaScript e descobriu que estava fortemente ofuscado. Usando o webcrack, uma ferramenta para desofuscar código, a equipe supostamente removeu as camadas. A saída final era confusa, mas legível, pois parecia três scripts diferentes colados em um.

Uma parte do código continha identificadores para extensões do Chrome, o que geralmente aponta para malware de roubo de credenciais. Uma string, p.zi, parecia malware antigo do Lazarus usado na campanha BeaverTail, outra operação anteriormente documentada pela Unit 42. A BitMEX decidiu não reanalisar o componente BeaverTail, pois já era público.

Em vez disso, eles se concentraram em outra descoberta: o código se conectava a uma instância do Supabase. O Supabase é uma plataforma de backend para desenvolvedores, algo como o Firebase. O problema? Os desenvolvedores do Lazarus não a bloquearam. Quando a BitMEX testou, eles conseguiram acessar o banco de dados diretamente—sem login, sem proteção.

Hackers expõem logs de dispositivos infectados e seus próprios IPs

O banco de dados Supabase tinha 37 logs de máquinas infectadas. Cada entrada mostrava o nome de usuário, nome do host, sistema operacional, endereço IP, geolocalização e carimbo de tempo. A BitMEX notou padrões—alguns dispositivos apareciam repetidamente, o que os destacava como máquinas de desenvolvedor ou teste. O formato de nomeação para a maioria dos nomes de host seguia uma estrutura 3-XXX.

Muitos IPs vieram de provedores de VPN. Um usuário, “Victor”, frequentemente se conectava usando a Touch VPN. Outro, “GHOST72”, usava a VPN Astrill. Mas então Victor errou. Uma entrada vinculada a ele tinha um IP diferente—223.104.144.97, um IP residencial em Jiaxing, China, sob a China Mobile. Isso não era uma VPN. Era provavelmente o endereço IP real de um operador do Lazarus. A BitMEX sinalizou isso como uma grande falha operacional.

A BitMEX então construiu uma ferramenta para continuar pingando o banco de dados Supabase. Desde 14 de maio, a ferramenta coletou 856 entradas do banco de dados, que remontam a 31 de março. Entre elas, havia 174 combinações únicas de nomes de usuário e host. O sistema agora roda continuamente, procurando novas infecções ou mais erros por parte dos atacantes.

Ao examinar os carimbos de tempo, a BitMEX descobriu que a atividade do Lazarus diminui entre 8h e 13h UTC, que são 17h às 22h em Pyongyang. Isso corresponde a um horário de trabalho estruturado, dando mais provas de que o grupo não é apenas alguns hackers freelancers—é uma equipe organizada.

Equipe de segurança confirma padrão do Lazarus e divisão interna

O Grupo Lazarus tem um histórico conhecido de ataques de engenharia social. Em incidentes anteriores, como a violação da Bybit, eles enganaram um funcionário da Safe Wallet para executar um arquivo malicioso. Isso lhes deu acesso inicial.

Então outra parte da equipe assumiu, acessou o ambiente AWS e alterou o código front-end para roubar criptomoedas de carteiras frias. A BitMEX disse que esse padrão mostra que o grupo provavelmente está dividido em várias equipes—algumas fazendo o phishing básico, outras lidando com as intrusões avançadas uma vez obtido o acesso.

A BitMEX escreveu: “Ao longo dos últimos anos, parece que o grupo se dividiu em múltiplos subgrupos que não são necessariamente da mesma sofisticação técnica.” A equipe de segurança disse que essa campanha seguiu o mesmo modelo. A mensagem inicial no LinkedIn era simples, o repositório GitHub amador.

Mas o script de pós-exploração mostrou muito mais habilidade, claramente construído por alguém mais experiente. Após desofuscar o malware, a BitMEX conseguiu extrair Indicadores de Comprometimento (IoCs) e alimentá-los em seus sistemas internos.

Eles renomearam variáveis, limparam o script e seguiram como funcionava. A parte inicial do código era nova, e reportedly enviava dados do sistema (nome de usuário, IP, etc.) diretamente para o Supabase, facilitando o rastreamento… para qualquer um que encontrasse o banco de dados aberto.

A BitMEX também identificou máquinas usadas durante o desenvolvimento. Exemplos incluíam Victor@3-KZH, que foi usada com a Touch VPN e China Mobile. Outras, como GHOST72@3-UJS-2 e Super@3-AHR-2, usaram uma mistura de Astrill, Zoog e Hotspot Shield. Os logs até mostraram contas de usuário como Admin@3-HIJ, Lenovo@3-RKS, GoldRock@DESKTOP-N4VEL23 e Muddy@DESKTOP-MK87CBC. Estes eram provavelmente ambientes de teste configurados pelos atacantes.