BitMEX thwarts Lazarus Group’s hack attempt, exposes hacker IPs and ops flaws

BitMEX has pulled the curtain back on a failed hack attempt by the Lazarus Group, exposing sloppy mistakes by a collective long tied to North Korea’s cyber warfare unit.

According to a blog post released by BitMEX on Friday, the team has now set up an internal monitoring system to watch for more infections and possibly catch future operational security errors.

The whole thing started when a BitMEX employee was contacted on LinkedIn with a proposal to work on a fake NFT marketplace project, but the offer matched a known phishing tactic used by Lazarus, so the employee immediately reported it, starting a full investigation.

BitMEX’s security team accessed a GitHub repository the attacker shared, which contained a Next.js/React project. But buried inside was code designed to get the employee to unknowingly execute a malicious payload on their system. The team didn’t run the code, they went straight to analysis.

BitMEX dissects malware, finds Lazarus fingerprints

Inside the repo, BitMEX engineers searched for the term eval, a common red flag in malware. One line of code had been commented out, but it still revealed intent. If active, it would’ve reached out to “hxxp://regioncheck[.]net/api/user/thirdcookie/v3/726” to fetch a cookie and execute it. That domain had previously been linked to Lazarus by Palo Alto Networks’ Unit 42, a team that’s tracked DPRK cyber activity for years.

Another line was active. It sent a request to “hxxp://fashdefi[.]store:6168/defy/v5” and executed the response. BitMEX manually fetched that JavaScript and found it was heavily obfuscated. Using webcrack, a tool for deobfuscating code, the team reportedly pulled the layers off. The final output was messy but readable, as it looked like three different scripts smashed into one.

One part of the code contained identifiers for Chrome extensions, which usually points to credential stealing malware. One string, p.zi, looked like older Lazarus malware used in the BeaverTail campaign, another operation previously documented by Unit 42. BitMEX decided not to re-analyze the BeaverTail component, as it was already public.

Instead, they focused on another discovery: the code connected to a Supabase instance. Supabase is a backend platform for developers, sort of like Firebase. The problem? The Lazarus devs didn’t lock it down. When BitMEX tested it, they were able to access the database directly—no login, no protection.

Hackers expose infected device logs and their own IPs

The Supabase database had 37 logs of infected machines. Each entry showed the username, hostname, operating system, IP address, geolocation, and timestamp. BitMEX noticed patterns—some devices appeared repeatedly, which made them stand out as developer or test machines. The naming format for most hostnames followed a 3-XXX structure.

Many IPs came from VPN providers. One user, “Victor,” often connected using Touch VPN. Another, “GHOST72,” used Astrill VPN. But then Victor messed up. One entry linked to him had a different IP—223.104.144.97, a residential IP in Jiaxing, China, under China Mobile. That wasn’t a VPN. That was likely the real IP address of a Lazarus operator. BitMEX flagged it as a major ops failure.

BitMEX then built a tool to keep pinging the Supabase database. Since May 14, the tool has collected 856 entries from the database, which dates back to March 31st. Among them, there were 174 unique combinations of usernames and hostnames. The system now runs continuously, looking for new infections or more mistakes by the attackers.

By examining timestamps, BitMEX found that Lazarus activity drops between 8am and 1pm UTC, which is 5pm to 10pm in Pyongyang. This matches a structured working schedule, giving further proof the group isn’t just some freelancing hackers—it’s an organized team.

Security team confirms Lazarus pattern and internal split

The Lazarus Group has a known history of social engineering attacks. In earlier incidents like the Bybit breach, they tricked an employee at Safe Wallet into running a malicious file. That gave them initial access.

Then another part of the team took over, accessed the AWS environment, and changed the front-end code to steal crypto from cold wallets. BitMEX said this pattern shows the group is likely split into multiple teams—some doing the basic phishing, others handling the advanced intrusions once access is gained.

BitMEX wrote, “Throughout the last few years, it appears that the group has divided into multiple subgroups that are not necessarily of the same technical sophistication.” The security team said this campaign followed that same template. The initial message on LinkedIn was simple, the GitHub repo amateurish.

But the post-exploitation script showed far more skill, clearly built by someone more experienced. After deobfuscating the malware, BitMEX was able to extract Indicators of Compromise (IoCs) and feed them into their internal systems.

They renamed variables, cleaned the script, and followed how it worked. The early part of the code was new, and it reportedly sent system data (username, IP, etc.) straight into Supabase, making tracking easy… for anyone who found the open database.

BitMEX also identified machines used during development. Examples included Victor@3-KZH, which was used with Touch VPN and China Mobile. Others like GHOST72@3-UJS-2 and Super@3-AHR-2 used a mix of Astrill, Zoog, and Hotspot Shield. Logs even showed user accounts like Admin@3-HIJ, Lenovo@3-RKS, GoldRock@DESKTOP-N4VEL23, and Muddy@DESKTOP-MK87CBC. These were likely test environments set up by the attackers.

KEY Difference Wire helps crypto brands break through and dominate headlines fast