BitMEX ha revelado un intento fallido de hackeo por parte del Grupo Lazarus, exponiendo errores descuidados por parte de un colectivo vinculado desde hace mucho tiempo a la unidad de guerra cibernética de Corea del Norte.
Según una publicación de blog publicada por BitMEX el viernes, el equipo ahora ha configurado un sistema de monitoreo interno para detectar más infecciones y posiblemente detectar futuros errores de seguridad operativa.
Todo comenzó cuando un de BitMEX fue contactado en LinkedIn con una propuesta para trabajar en un NFT , pero la oferta coincidía con una táctica de phishing conocida utilizada por Lazarus, por lo que el empleado lo denunció de inmediato, iniciando una investigación completa.
El equipo de seguridad de BitMEX accedió a un repositorio de GitHub compartido por el atacante, que contenía un proyecto Next.js/React. Sin embargo, dentro se escondía un código diseñado para que el empleado ejecutara, sin saberlo, una carga maliciosa en su sistema. El equipo no ejecutó el código; procedieron directamente al análisis.
BitMEX analiza malware y encuentra huellas de Lazarus
Dentro del repositorio, los ingenieros de BitMEX buscaron el término "eval", una señal de alerta común en malware. Una línea de código había sido comentada, pero aun así revelaba intención. De estar activa, habría contactado con "hxxp://regioncheck[.]net/api/user/thirdcookie/v3/726" para obtener una cookie y ejecutarla. Ese dominio había sido previamente vinculado a Lazarus por la Unidad 42 de Palo Alto Networks, un equipo que ha tracla actividad cibernética de la RPDC durante años.
Otra línea estaba activa. Envió una solicitud a "hxxp://fash defi [.]store:6168/defy/v5" y ejecutó la respuesta. BitMEX recuperó manualmente ese JavaScript y descubrió que estaba muy ofuscado. Usando webcrack, una herramienta para desofuscar código, el equipo supuestamente eliminó las capas. El resultado final fue confuso pero legible, ya que parecía la fusión de tres scripts diferentes en uno.
Una parte del código conteníadentde extensiones de Chrome, lo que suele indicar malware que robadent. Una cadena, p.zi, parecía corresponder a un antiguo malware Lazarus utilizado en la campaña BeaverTail, otra operación previamente documentada por la Unidad 42. BitMEX decidió no volver a analizar el componente BeaverTail, ya que era público.
En cambio, se centraron en otro descubrimiento: el código conectado a una instancia de Supabase. Supabase es una plataforma de backend para desarrolladores, similar a Firebase. ¿El problema? Los desarrolladores de Lazarus no la bloquearon. Cuando BitMEX la probó, pudieron acceder a la base de datos directamente, sin necesidad de iniciar sesión ni protección.
Los piratas informáticos exponen los registros de los dispositivos infectados y sus propias direcciones IP
La base de datos de Supabase contenía 37 registros de máquinas infectadas. Cada entrada mostraba el nombre de usuario, el nombre de host, el sistema operativo, la dirección IP, la geolocalización y la marca de tiempo. BitMEX detectó patrones: algunos dispositivos aparecían repetidamente, lo que los identificaba como máquinas de desarrollo o de prueba. El formato de nombres para la mayoría de los nombres de host seguía la estructura 3-XXX.
Muchas IP provenían de proveedores de VPN. Un usuario, "Victor", se conectaba a menudo usando Touch VPN. Otro, "GHOST72", usaba Astrill VPN. Pero entonces Victor cometió un error. Una entrada vinculada a él tenía una IP diferente: 223.104.144.97, una IPdenten Jiaxing, China, de China Mobile. No era una VPN. Probablemente era la dirección IP real de un operador de Lazarus. BitMEX lo marcó como un fallo operativo importante.
BitMEX desarrolló una herramienta para hacer ping a la base de datos de Supabase. Desde el 14 de mayo, la herramienta ha recopilado 856 entradas de la base de datos, que datan del 31 de marzo. Entre ellas, había 174 combinaciones únicas de nombres de usuario y nombres de host. El sistema ahora funciona continuamente, buscando nuevas infecciones o más errores de los atacantes.
Al examinar las marcas de tiempo, BitMEX descubrió que la actividad de Lazarus disminuye entre las 8:00 a. m. y la 1:00 p. m. UTC, que corresponde a las 5:00 p. m. y las 10:00 p. m. en Pyongyang. Esto coincide con un horario de trabajo estructurado, lo que demuestra aún más que el grupo no está compuesto por simples hackers autónomos, sino por un equipo organizado.
El equipo de seguridad confirma el patrón Lazarus y la división interna
El Grupo Lazarus tiene un historial conocido de ataques de ingeniería social. Endentanteriores, como la filtración de Bybit, engañaron a un empleado de Safe Wallet para que ejecutara un archivo malicioso. Esto les dio acceso inicial.
Luego, otra parte del equipo tomó el control, accedió al entorno de AWS y modificó el código frontend para robar criptomonedas de billeteras frías. BitMEX afirmó que este patrón indica que el grupo probablemente está dividido en varios equipos: algunos se encargan del phishing básico y otros de las intrusiones avanzadas una vez obtenido el acceso.
BitMEX escribió: «A lo largo de los últimos años, parece que el grupo se ha dividido en múltiples subgrupos que no necesariamente tienen la misma sofisticación técnica». El equipo de seguridad afirmó que esta campaña siguió el mismo patrón. El mensaje inicial en LinkedIn era simple, mientras que el del repositorio de GitHub era poco profesional.
Pero el script posterior a la explotación demostró mucha más habilidad, claramente creado por alguien con más experiencia. Tras desofuscar el malware, BitMEX pudotraclos Indicadores de Compromiso (IoC) e incorporarlos a sus sistemas internos.
Renombraron las variables, limpiaron el script y siguieron su funcionamiento. La primera parte del código era nueva y, según se informa, enviaba datos del sistema (nombre de usuario, IP, etc.) directamente a Supabase, lo que trac para cualquiera que encontrara la base de datos abierta.
BitMEX tambiéndentlas máquinas utilizadas durante el desarrollo. Algunos ejemplos incluyen Victor@3-KZH, que se utilizó con Touch VPN y China Mobile. Otras, como GHOST72@3-UJS-2 y Super@3-AHR-2, utilizaron una combinación de Astrill, Zoog y Hotspot Shield. Los registros incluso mostraron cuentas de usuario como Admin@3-HIJ, Lenovo@3-RKS, GoldRock@DESKTOP-N4VEL23 y Muddy@DESKTOP-MK87CBC. Probablemente se trataba de entornos de prueba configurados por los atacantes.
