A BitMEX revelou detalhes de uma tentativa frustrada de ataque cibernético do Grupo Lazarus, expondo erros grosseiros de um coletivo há muito ligado à unidade de guerra cibernética da Coreia do Norte.
De acordo com uma publicação no blog da BitMEX divulgada na sexta-feira, a equipe implementou um sistema de monitoramento interno para identificar novas infecções e possivelmente detectar futuros erros de segurança operacional.
Tudo começou quando um da BitMEX foi contatado pelo LinkedIn com uma proposta para trabalhar em um projeto falso de NFTs , mas a oferta correspondia a uma tática de phishing conhecida usada pelo grupo Lazarus, então o funcionário a denunciou imediatamente, dando início a uma investigação completa.
A equipe de segurança da BitMEX acessou um repositório do GitHub compartilhado pelo invasor, que continha um projeto Next.js/React. Mas, oculto no repositório, havia um código projetado para induzir o funcionário a executar, sem saber, um payload malicioso em seu sistema. A equipe não executou o código, partindo diretamente para a análise.
BitMEX analisa malware e encontra indícios do Lazarus
Dentro do repositório, os engenheiros da BitMEX pesquisaram o termo "eval", um sinal de alerta comum em malware. Uma linha de código estava comentada, mas ainda assim revelava a intenção. Se estivesse ativa, teria se conectado a "hxxp://regioncheck[.]net/api/user/thirdcookie/v3/726" para obter um cookie e executá-lo. Esse domínio já havia sido associado ao Lazarus pela Unit 42 da Palo Alto Networks, uma equipe que traca atividade cibernética da Coreia do Norte há anos.
Outra linha estava ativa. Ela enviou uma solicitação para “hxxp://fash defi [.]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 conseguiu remover as camadas. O resultado final era confuso, mas legível, pois parecia três scripts diferentes combinados em um só.
Uma parte do códigodentidentificadores para extensões do Chrome, o que geralmente aponta para malware de roubo dedent. Uma string, p.zi, parecia ser do antigo malware Lazarus usado na campanha BeaverTail, outra operação previamente documentada pela Unit 42. A BitMEX decidiu não reanalisar o componente BeaverTail, pois ele já era público.
Em vez disso, eles se concentraram em outra descoberta: o código conectado a uma instância do Supabase. O Supabase é uma plataforma de backend para desenvolvedores, semelhante ao Firebase. O problema? Os desenvolvedores do Lazarus não a protegeram adequadamente. Quando a BitMEX a testou, conseguiu acessar o banco de dados diretamente — sem login, sem proteção.
Hackers expõem registros de dispositivos infectados e seus próprios endereços IP
O banco de dados Supabase continha 37 registros de máquinas infectadas. Cada entrada mostrava o nome de usuário, nome do host, sistema operacional, endereço IP, geolocalização e data e hora. A BitMEX percebeu padrões — alguns dispositivos apareciam repetidamente, o que os destacava como máquinas de desenvolvimento ou de teste. O formato de nomenclatura da 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 Astrill VPN. Mas então Victor cometeu um erro. Uma entrada vinculada a ele tinha um IP diferente — 223.104.144.97, um IPdentem Jiaxing, China, pertencente à China Mobile. Não era uma VPN. Provavelmente era o endereço IP real de um operador do Lazarus. A BitMEX sinalizou isso como uma falha operacional grave.
A BitMEX então criou uma ferramenta para monitorar continuamente o banco de dados Supabase. Desde 14 de maio, a ferramenta coletou 856 entradas do banco de dados, algumas datando de 31 de março. Entre elas, havia 174 combinações únicas de nomes de usuário e nomes de host. O sistema agora funciona continuamente, buscando novas infecções ou mais erros cometidos pelos atacantes.
Ao analisar os registros de data e hora, a BitMEX descobriu que a atividade do Lazarus diminui entre 8h e 13h UTC, o que corresponde às 17h e 22h em Pyongyang. Isso coincide com um horário de trabalho estruturado, fornecendo mais evidências de que o grupo não é apenas formado por hackers freelancers, mas sim por uma equipe organizada.
A equipe de segurança confirma o padrão Lázaro e a divisão interna
O grupo Lazarus tem um histórico conhecido de ataques de engenharia social. Emdentanteriores, como a violação de dados da Bybit, eles enganaram um funcionário da Safe Wallet para que executasse um arquivo malicioso. Isso lhes deu acesso inicial.
Em seguida, outra parte da equipe assumiu o controle, acessou o ambiente da AWS e alterou o código front-end para roubar criptomoedas de carteiras frias. A BitMEX afirmou que esse padrão indica que o grupo provavelmente está dividido em várias equipes — algumas realizando o phishing básico, outras lidando com as intrusões avançadas após obterem acesso.
A BitMEX escreveu: “Ao longo dos últimos anos, parece que o grupo se dividiu em vários subgrupos que não necessariamente possuem o mesmo nível de sofisticação técnica”. A equipe de segurança afirmou que esta campanha seguiu o mesmo padrão. A mensagem inicial no LinkedIn era simples, e o repositório no GitHub, amador.
Mas o script de pós-exploração demonstrou muito mais habilidade, claramente desenvolvido por alguém mais experiente. Após a desofuscação do malware, a BitMEX conseguiutracIndicadores de Comprometimento (IoCs) e inseri-los em seus sistemas internos.
Eles renomearam variáveis, limparam o script e analisaram seu funcionamento. A parte inicial do código era nova e, segundo relatos, enviava dados do sistema (nome de usuário, IP etc.) diretamente para o Supabase, facilitando trac ... para qualquer um que encontrasse o banco de dados aberto.
A BitMEX tambémdentas máquinas usadas durante o desenvolvimento. Exemplos incluem Victor@3-KZH, que foi usada com Touch VPN e China Mobile. Outras, como GHOST72@3-UJS-2 e Super@3-AHR-2, usavam uma combinação de Astrill, Zoog e Hotspot Shield. Os registros mostraram até mesmo contas de usuário como Admin@3-HIJ, Lenovo@3-RKS, GoldRock@DESKTOP-N4VEL23 e Muddy@DESKTOP-MK87CBC. Provavelmente, esses eram ambientes de teste configurados pelos atacantes.
