BitMEX frustra el intento de hackeo del Grupo Lazarus, expone las IPs de los hackers y fallos operativos

BitMEX ha levantado el telón sobre un intento de hackeo fallido por parte del Grupo Lazarus, exponiendo errores descuidados de una colectividad largamente vinculada a la unidad de ciberguerra 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 vigilar más infecciones y posiblemente capturar futuros errores de seguridad operativa.

Todo comenzó cuando un empleado de BitMEX fue contactado en LinkedIn con una propuesta para trabajar en un proyecto falso de mercado de NFT, pero la oferta coincidía con una táctica de phishing conocida utilizada por Lazarus, por lo que el empleado lo reportó de inmediato, iniciando una investigación completa.

El equipo de seguridad de BitMEX accedió a un repositorio de GitHub que el atacante compartió, el cual contenía un proyecto Next.js/React. Pero enterrado dentro había código diseñado para hacer que el ejecutara involuntariamente una carga maliciosa en su sistema. El equipo no ejecutó el código, fue directamente al análisis.

BitMEX disecciona el malware, encuentra huellas de Lazarus

Dentro del repositorio, los ingenieros de BitMEX buscaron el término eval, una bandera roja común en el malware. Una línea de código había sido comentada, pero aún revelaba la intención. Si estuviera activa, se habría comunicado con “hxxp://regioncheck[.]net/api/user/thirdcookie/v3/726” para obtener una cookie y ejecutarla. Ese dominio había estado previamente vinculado a Lazarus por Unit 42 de Palo Alto Networks, un equipo que ha rastreado la actividad cibernética de la RPDC durante años.

Otra línea estaba activa. Enviaba una solicitud a “hxxp://fashdefi[.]store:6168/defy/v5” y ejecutaba la respuesta. BitMEX obtuvo manualmente ese JavaScript y descubrió que estaba muy ofuscado. Usando webcrack, una herramienta para desofuscar código, el equipo reportedly retiró las capas. La salida final era desordenada pero legible, ya que parecía tres scripts diferentes fusionados en uno.

Una parte del código contenía identificadores de extensiones de Chrome, lo que generalmente apunta a malware de robo de credenciales. Una cadena, p.zi, parecía malware antiguo de Lazarus utilizado en la campaña BeaverTail, otra operación documentada previamente por Unit 42. BitMEX decidió no reanalizar el componente BeaverTail, ya que era de dominio público.

En cambio, se centraron en otro descubrimiento: el código se conectaba a una instancia de Supabase. Supabase es una plataforma backend para desarrolladores, algo así como Firebase. El problema? Los desarrolladores de Lazarus no la aseguraron. Cuando BitMEX la probó, pudieron acceder a la base de datos directamente, sin inicio de sesión ni protección.

Los hackers exponen registros de dispositivos infectados y sus propias IPs

La base de datos de Supabase tenía 37 registros de máquinas infectadas. Cada entrada mostraba el nombre de usuario, nombre del host, sistema operativo, dirección IP, geolocalización y marca de tiempo. BitMEX notó patrones: algunos dispositivos aparecían repetidamente, lo que los destacaba como máquinas de desarrollador o prueba. El formato de nomenclatura para la mayoría de los nombres de host seguía una estructura 3-XXX.

Muchas IPs provenían de proveedores de VPN. Un usuario, “Victor”, a menudo se conectaba usando Touch VPN. Otro, “GHOST72”, usaba Astrill VPN. Pero luego Victor cometió un error. Una entrada vinculada a él tenía una IP diferente: 223.104.144.97, una IP residencial en Jiaxing, China, bajo China Mobile. Esa no era una VPN. Era probablemente la dirección IP real de un operador de Lazarus. BitMEX la marcó como un grave fallo operativo.

BitMEX luego construyó una herramienta para seguir enviando pings a la base de datos de Supabase. Desde el 14 de mayo, la herramienta ha recopilado 856 entradas de la base de datos, que se remonta al 31 de marzo. Entre ellas, había 174 combinaciones únicas de nombres de usuario y host. El sistema ahora se ejecuta continuamente, buscando nuevas infecciones o más errores por parte de los atacantes.

Al examinar las marcas de tiempo, BitMEX encontró que la actividad de Lazarus disminuye entre las 8 a.m. y la 1 p.m. UTC, que son las 5 p.m. a las 10 p.m. en Pyongyang. Esto coincide con un horario de trabajo estructurado, dando más prueba de que el grupo no son solo hackers freelance, sino un equipo organizado.

El equipo de seguridad confirma el patrón de Lazarus y la división interna

El Grupo Lazarus tiene un historial conocido de ataques de ingeniería social. En incidentes anteriores como la brecha de Bybit, engañaron a un empleado de Safe Wallet para que ejecutara un archivo malicioso. Eso les dio acceso inicial.

Luego, otra parte del equipo tomó el control, accedió al entorno de AWS y cambió el código front-end para robar cripto de las billeteras frías. BitMEX dijo que este patrón muestra que el grupo probablemente está dividido en múltiples equipos: algunos haciendo el phishing básico, otros manejando las intrusiones avanzadas una vez que se obtiene 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 dijo que esta campaña siguió el mismo molde. El mensaje inicial en LinkedIn era simple, el repositorio de GitHub era amateur.

Pero el script de post-explotación mostró mucha más habilidad, claramente construido por alguien más experimentado. Después de desofuscar el malware, BitMEX pudo extraer Indicadores de Compromiso (IoCs) y alimentarlos en sus sistemas internos.

Renombraron las variables, limpiaron el script y siguieron su funcionamiento. La parte inicial del código era nueva, y según se informa enviaba datos del sistema (nombre de usuario, IP, etc.) directamente a Supabase, lo que facilitaba el seguimiento… para cualquiera que encontrara la base de datos abierta.

BitMEX también identificó máquinas utilizadas durante el desarrollo. Los ejemplos incluían Victor@3-KZH, que se usó con Touch VPN y China Mobile. Otros como GHOST72@3-UJS-2 y Super@3-AHR-2 usaron una mezcla 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. Estos eran probablemente entornos de prueba configurados por los atacantes.