The $1.5B Bybit Hack & How OSINT Led to Its Attribution

On February 21st, 2025, Bybit got hit with the biggest crypto heist in history. The exchange, which ranks as the world’s second-largest cryptocurrency platform by trading volume, with over 60 million users worldwide, saw the Lazarus group steal over $1.4 billion in assets, including 401,347 ETH, directly from their cold wallet.

Founded in 2018 with a mission to redefine openness in the decentralized world through creating a simpler, accessible ecosystem for everyone, Bybit faced its biggest challenge yet. The attack was brutally simple: they tricked Bybit’s signers into approving what appeared to be legitimate transactions, but in fact were huge fund transfers to the attackers.

A decade of bulletproof security fell apart over a basic setup mistake that hackers exploited for their biggest payday.

This wasn’t their first rodeo. Lazarus APT grabbed around $660.5 million across 20 attacks in 2023. By 2024, they’d ramped up to $1.34 billion stolen across 47 incidents – more than doubling their haul. The Bybit breach alone netted them $160 million more than their entire 2024 spree combined.

Bybit’s CEO Ben Zhou wasn’t having it. He declared “war against Lazarus” and launched a bounty site to track down the stolen funds and help other victims whom this group has hit.

Timeline of the Attack

On February 21, Bybit performed a routine transfer of user funds from their cold wallet (a secure offline storage solution) to their warm wallet (an internet-connected wallet for operational accessibility). These transfers follow strict security protocols requiring multiple signatures from Bybit employees through a multisignature process. For these operations, Bybit uses Safe{Wallet}, a third-party multisig platform.

This process was normal until February 2025, when a Safe{Wallet} developer fell victim to a social engineering attack that compromised his workstation. This developer was one of the few personnel with elevated access privileges necessary for their duties.

Initial Access

In their investigation, Mandiant stated that AWS session tokens (temporary keys that allow requesting temporary credentials to an employer’s AWS account) were hijacked, likely through malware installed on Developer1’s workstation. These keys enable hackers to bypass MFA controls and access Safe{Wallet}’s AWS account.

According to Safe’s preliminary report, Developer1’s macOS workstation was compromised on February 4, 2025, when a Docker project named MC-Based-Stock-Invest-Simulator-main communicated with getstockprice[.]com, which resolved to IP address 70.34.245[.]118. The Docker project was no longer available on the system during analysis, but files remained in the ~/Downloads/ directory, indicating possible social engineering.

The attackers likely approached the developer through platforms like LinkedIn, Telegram, or Discord and convinced them to download an archive file containing a crypto-themed Python application. This initial access procedure is favored by Lazarus operators. The Python application included a Dockerized version that ran inside a privileged container. Unknown to the developer, this seemingly benign application enabled Lazarus operators to exploit an RCE vulnerability in the PyYAML library, providing code execution capabilities and subsequent control over the host system.

In previous attacks, TraderTraitor (UNC4899) has used stock-themed Docker projects, including a September 2024 incident where they tricked a crypto exchange developer via Telegram into running Docker malware that deployed PLOTTWIST for persistent macOS access.

The attacker gained access to Developer1’s AWS account through ExpressVPN, using a User-Agent string (distrib#kali.2024) associated with Kali Linux, an offensive security toolkit. Mandiant attributes this activity to UNC4899, which has previously used comparable infrastructure and techniques.

The attackers spent the next 12 days monitoring the AWS environment and planning their next steps. For accessing a web server, including committing code to a repository, AWS provides temporary session tokens that expire after 12 hours by default. The hackers hijacked these tokens to insert their own code. Day by day, their understanding of the system deepened, while their presence remained completely undetected.

Analysis of the subsequent network traffic indicates that UNC4899 utilized the open-source offensive framework MythicAgents tool Poseidon. Mandiant has observed UNC4899 using Mythic Poseidon, a Golang agent targeting macOS and Linux, in previous attacks.

    flowchart TD
	    A[Social Engineering] --> B[Malicious Docker App]
	    B --> C[PyYAML RCE Exploit]
	    C --> D[AWS Token Hijack]
	    D --> E[12-Day Reconnaissance]

Step-by-Step Attack Process

1. Impersonation: Project Team
   Attackers posed as a legitimate development team and contacted developers offering debugging assistance. They built trust by providing upfront payments through third-party services that left minimal forensic traces.

2. Impersonation: Trading Expert
   The threat actors pretended to be trading or quantitative specialists, distributing fake analysis tools that contained malicious code. This software established persistent backdoors on victim systems.

3. Internal Reconnaissance and Exploitation
   From compromised devices, attackers conducted network scans and exploited internal services and applications. They used VPN traffic to maintain stealth and avoid detection during their operations.

4. SSH Key Theft and Lateral Movement
   The attackers extracted SSH keys from critical servers and used these stolen credentials for lateral movement across the network. This eventually led to accessing wallet servers and stealing cryptocurrency.

5. Evidence Destruction
   To cover their tracks, attackers paid employees to delete malware from their systems and convinced victims to remove evidence themselves. This created significant delays in incident reporting and hindered the investigation process.

JavaScript Code Injection

According to SlowMist’s report, attackers who gained access to Safe{Wallet}’s system strategically manipulated the user interface that Bybit employees would see. They replaced legitimate JavaScript code with malicious code designed to redirect ETH transactions from intended destinations to wallets controlled by hackers.

The attack was highly targeted. The malicious code exclusively impacted Bybit’s wallet addresses, leaving other platform users unaffected. This precise targeting showcased the advanced nature of the operation.

For four days, users unknowingly operated with compromised code. The attackers had modified JavaScript resources hosted on AWS S3 buckets that served Safe{Wallet}’s web interface, injecting malicious code that manipulated transaction flows. The injected code contained specific activation conditions, programmed to execute transaction manipulation only when it detected Bybit’s cold wallet addresses.

This supply chain attack exploited Safe{Wallet}’s infrastructure to target a single high-value client while maintaining operational cover by preserving normal functionality for all other users.

Injected Code Analysis

SlowMists’s Team first used urlscan to capture changes to app.safe.global over the past few months and found that only the file “_app-52c9031bfa03da47.js” had been modified.

Recommended Reading

Netlas vs Urlscan: Tools Comparison

Examining Safe{Wallet} resources through public web archives revealed two critical snapshots of the platform’s JavaScript resources, both captured on February 19, 2025. Analysis of these snapshots showed a clear difference: the first contained the original, unmodified Safe{Wallet} code, while the second displayed the same resource now containing malicious JavaScript code. This timeline evidence directly confirms that the malicious transactions originated from compromised code within Safe{Wallet}’s AWS infrastructure, pinpointing the exact attack vector.

Modified Code Listing

The attacker’s malicious contract address in this breach has been traced to:

0xbdd077f651ebe7f7b3ce16fe5f2b025be2969516

The attack occurred through a sophisticated multi-stage process. Attackers first compromised the frontend code of app.safe.global, establishing their foothold in Safe{Wallet}’s infrastructure. When Bybit’s multisig owners accessed app.safe.global to authorize transactions, the Safe{Wallet} interface seemed completely normal, displaying legitimate destination addresses. Behind this facade, however, the attackers had embedded code that silently replaced the actual transaction data with malicious payloads right before they were sent to the blockchain.

This interface manipulation created a perfect trap. Bybit’s owners, recognizing familiar addresses and standard transaction details, unknowingly signed the altered transactions. Through this social engineering on a technical level, attackers gained complete control over Bybit’s multisig wallet contract, enabling them to carry out the massive theft while leaving virtually no trace of suspicious activity from the user’s perspective.

The removal of the malicious injection from the modified JavaScript resources was likely carried out by the attackers in an attempt to cover their tracks, further demonstrating the calculated nature of this operation.

Here’s an analysis of the code changed by the attackers:

This code operates by:

• Verifying if the signer is an authorized Bybit signer; if not, maintaining normal functionality
• Preserving the original transaction data intended for signature
• Replacing the transaction data with a different operation
• Presenting the modified transaction for authorization

This code silently modifies outgoing Safe Wallet transactions, redirecting funds or actions to an attacker-controlled address, but only when specific wallet addresses are involved. If a blacklisted signer is detected, the code reloads to avoid detection.

A critical detail reveals that the attacker modified the operation parameter from 0 (CALL) to 1 (DELEGATECALL). By using delegatecall, they executed malicious functions as if the Safe itself was calling them, running their code within the victim’s Safe context while skipping the usual multisig approval steps. This change effectively gave them full control and enabled unauthorized fund transfers.

The AnChain.AI team successfully decoded this transaction into two distinct components:

• Transfer Method ID: 0xa9059cbb [transfer(address,uint256)]
• DelegateCall Address to malicious smart contract bytecode deployed 3 days ago: 0xbdd077f651ebe7f7b3ce16fe5f2b025be2969516

The malicious contract that was injected enabled sweepETH and sweepERC20 functions, allowing the attacker to drain over 400,000 ETH (approximately $1.5 billion) from Bybit’s cold wallet while bypassing multisig authorization requirements.

AnChainAI reverse-engineered the Bybit exploit bytecode, uncovering four smart contract functions and identifying 50 additional similar smart contracts through embedding analysis.

Within two minutes of the malicious transaction’s execution and publication, updated JavaScript resources were uploaded to Safe{Wallet}’s AWS S3 bucket with the malicious code stripped out. The forensics investigation by Sygnia pinpointed the JavaScript resource modifications in the AWS S3 bucket on February 21, 2025, at 14:15:13 and 14:15:32 UTC, occurring roughly two minutes after the attack.

The initial findings show the attack originated from Safe{Wallet}’s AWS infrastructure rather than any compromise of Bybit’s systems. The forensic investigation found no evidence of infiltration within Bybit’s own infrastructure, indicating the breach was fully contained within Safe{Wallet}’s environment.

Bybit February 2025 Hack TTPs

Analyzing this attack, we can point out several key TTPs leveraged by the threat actors.

• T1090.002: External proxy usage (ExpressVPN) for concealing attacker activities
• T1036: Masquerading through fake cryptocurrency/trading applications and obfuscated malware
• T1588.004: Digital certificate acquisition for malware signing, based on historical operator patterns
• T1204.002: Social engineering to achieve execution of malicious files by victims.
• T1566.001: Spearphishing attachments targeting developers as the initial infection vector.

These reflect a pattern often associated with the Lazarus Group, though in this case, attribution has been made based on another indicator.

Attribution with Lazarus Group

FBI attributed the attack to ‘TraderTraitor’ (also known as UNC4899), a North Korean hacker unit operating under the Lazarus Group umbrella. However, the public found out about the Lazarus Group’s involvement through an investigation conducted by a private individual.

On February 22, 2025, blockchain investigator ZachXBT independently linked this attack to the Lazarus Group through on-chain analysis. This attribution was later confirmed by Arkham Intelligence in their tweet.

In this thread, ZachXBT publicly demonstrated comprehensive evidence supporting his successful attribution of the Bybit hack to the Lazarus Group. He established this connection by identifying overlapping addresses and transaction patterns across multiple high-profile cryptocurrency exchange breaches, including the Phemex hack, BingX hack, and Poloniex hack. Through detailed on-chain analysis, ZachXBT traced the movement of stolen funds and revealed a consistent pattern of address reuse and fund consolidation tactics that formed a clear digital fingerprint linking all these incidents to the same threat actor group.

The following addresses demonstrate the overlap between all attacks:

Phemex & ByBit Attack

Overlap address:

0x33d057af74779925c4b2e720a820387cb89f8f65

Bybit hack transactions on Feb 22, 2025:

0xc963e65b9ec39b11076f78990c31f29aaa80705c75312dafd1748479e3e94ed0

0x411374feedcfa560335f00c0fcfa0a3906fdcc33687e6f924dd78ebecc45cd00

Phemex hack transaction on Feb 20, 2025:

0x6262a3339842240aeebae4ebfe338dbc771aa0e2df8f5a1ebcd7f9b090bedfe3

BingX & ByBit Attack

Overlap address:

0xd555789b146256253cd4540da28dcff6e44f6e50

Bybit hack transaction:

0x4a366130118d750715c2d35fdc07509cf943fcc988fa5e6d02211e3d5472796e 

BingX hack transaction:

0x93424aa87731bb9b1d8cc1f708d2ac9f3faf914f368a00494d87cba3e7719e8c

Poloniex & ByBit Attack

Overlap Address:

0x15ec300a4895a86322f1a27dd9ba0b9f8297e65d

Bybit Hack:

0x83c7678492d623fb98834f0fbcb2e7b7f5af8950

0x96244d83dc15d36847c35209bbdc5bdde9bec3d8

Poloniex Hack:

0xa0495b9421b0e81479b5271a041c9f28fc555800

This comprehensive analysis now reveals a single entity connected to four major cryptocurrency exchange breaches (Bybit, Poloniex, Phemex, and BingX), all conclusively attributed to the Lazarus Group through on-chain evidence and shared infrastructure patterns.

ZachXBT has made over 920 addresses linked to the Bybit hack publicly accessible through his detailed investigation report.

Possible Similar Attacks

Two previous high-profile crypto heists – the WazirX heist (July 2024, $230M loss) and the Radiant Capital heist (October 2024, $50M loss) – show some level of similarity to the Bybit Heist.

Both the Bybit and Radiant Capital incidents involved sophisticated front-end manipulation attacks that exploited the multisig signing process. In these breaches, attackers compromised the wallet interface to display legitimate transaction data to users, while malicious transactions were signed and executed in the background.

This deceptive approach allowed the attackers to trick legitimate signers into unknowingly approving fraudulent transactions. These attacks focused on manipulating the user experience, creating a disconnect between what signers believed they were authorizing and what was actually being signed.

As described by Radiant Capital Post-Mortem, on October 18, 2024:

The devices were compromised in such a way that the front-end of Safe{Wallet} (f.k.a. Gnosis Safe) displayed legitimate transaction data while malicious transactions were signed and executed in the background.

Similarly, the preliminary findings shared by WazirX revealed:

The cyber attack stemmed from a discrepancy between the data displayed on Liminal’s interface and the transaction’s actual contents. During the cyber attack, there was a mismatch between the information displayed on Liminal’s interface and what was actually signed. We suspect the payload was replaced to transfer wallet control to an attacker.

This pattern of frontend manipulation appears to be a signature tactic employed by the Lazarus Group when targeting cryptocurrency trading entities, exploiting the trust users place in their wallet interfaces to execute fraudulent transactions while maintaining the appearance of legitimate operations.

Bybit-AppleJeus Connection

Based on CISA’s TraderTraitor advisory, the Bybit hack and AppleJeus campaigns share identical TTP:

Technical Signatures:

• Same Threat Actor: Both attributed to Lazarus Group/HIDDEN COBRA
• Target Profile: Cryptocurrency companies, exchanges, and blockchain employees
• Social Engineering: Job recruitment lures and fake crypto applications
• Infrastructure: Legitimate-looking cryptocurrency trading platforms

Operational Similarities:

• Certificate Abuse: Both used valid Sectigo certificates for legitimacy
• Domain Registration: Both registered domains mimic legitimate crypto businesses
• Persistence Mechanisms: Both established system-level persistence (services, LaunchDaemons)

ExpressVPN Attack Patterns

Multiple cybersecurity investigations have documented ExpressVPN’s prominent role in advanced threat actor operations. The Sygnia investigation into the Bybit hack revealed that attackers accessed AWS accounts through ExpressVPN IP addresses while using Kali Linux user-agent strings, a combination typical of red teams and threat actors.

This pattern extends beyond isolated incidents. Mandiant’s analysis of UNC4899 explicitly confirms the group’s reliance on ExpressVPN as core operational infrastructure. Their investigation exposed critical operational security failures, revealing threat actor infrastructure and associated IP addresses.

The trend continues with Operation Sharpshooter, where Lazarus Group leveraged ExpressVPN for proxy operations (MITRE technique T1090). This consistent use across multiple campaigns demonstrates how commercial VPN services have become integral to sophisticated threat actor toolkits.

These documented cases highlight a concerning pattern where legitimate privacy tools are systematically exploited to mask malicious activities across different threat groups and campaigns.

Recommended Reading

Hannibal Stealer: A Deep Technical Analysis

Modus Operandi of Lazarus

Understanding the Lazarus Group’s systematic approach enables security teams to develop targeted defenses against their evolving tactics, particularly their sophisticated social engineering campaigns and malware deployment through compromised legitimate platforms. This knowledge facilitates proactive threat detection and enhances incident response capabilities.

Phase 1: Initial Compromise

Attackers establish their foothold by infiltrating victim systems through targeted exploitation of organizational endpoints. They typically leverage remote code vulnerabilities or deploy social engineering tactics to direct employees toward malicious websites or applications. Once access is secured, they deploy custom malware to maintain persistence within the compromised environment. This methodology has been consistently observed across major operations, including the Sony Pictures breach, the 2016 Bangladesh Bank heist, and Operation Dream Job campaigns.

Phase 2: Lateral Movement

Following the initial compromise, attackers deploy their extensive arsenal of over 150 identified malicious tools to propagate throughout the target network. They systematically install backdoors across multiple systems, establishing a robust command infrastructure that enables persistent access and control over critical network segments.

Phase 3: Intelligence Gathering

The group conducts comprehensive reconnaissance to map the target’s financial infrastructure and harvest authentication credentials for critical financial systems. This phase involves systematic enumeration of backup servers, domain controllers, mail servers, and other repositories containing sensitive authentication data and system configuration details.

Phase 4: Financial System Exploitation

Attackers customize their malware to circumvent security controls within financial applications, enabling unauthorized transaction execution from victim accounts. Once the technical exploitation is complete, fund extraction becomes a procedural matter.

Phase 5: Asset Laundering

Following successful fund extraction, the attackers employ sophisticated money laundering techniques to obscure transaction trails. Stolen ETH is channeled through mixing services, including Tornado Cash, then traded across decentralized exchanges like Uniswap and ParaSwap to fragment the digital trail. The funds undergo multiple conversions between cryptocurrencies such as USDT and BTC before being distributed across accounts on exchanges with limited regulatory oversight, significantly complicating asset recovery efforts.

Bybit Attack Chain TTPs

Listed in the previous paragraph TTPs can be easily matched to the attack chain phases of the ByBit hack:

1. Initial Compromise Attackers deployed social engineering tactics, distributing malicious Python projects (StockInvestSimulator-main.zip) to employees. The payload exploited the pyyaml library for remote code execution while evading antivirus detection.

2. Privilege Escalation Following initial access, attackers manipulated users into configuring privileged: true in Docker settings, effectively granting administrative control over compromised systems.

3. Network Reconnaissance & Lateral Movement The threat actors conducted comprehensive internal network scanning, exploited vulnerable internal services, harvested SSH credentials, and leveraged existing trust relationships to access critical infrastructure, including wallet servers.

4. Asset Extraction Attackers executed large-scale cryptocurrency transfers from compromised wallets to attacker-controlled addresses.

5. Evidence Destruction The campaign concluded with sophisticated evasion techniques, utilizing legitimate enterprise tools as proxy infrastructure and systematically purging system logs to eliminate forensic evidence.

The Path Forward

As the 2025 M-Trends report highlights (Google M-Trends 2025 Report), threat actors are becoming more sophisticated, embedding themselves in systems for longer periods and combining technical exploits with social engineering. The described ByBit hack example is an excellent confirmation.

What is interesting about this case is that it was solved thanks to OSINT platforms and investigations. The attribution was made based on on-chain analysis. We also observed the utilization of platforms such as URLScan and WebArchive. It seems that OSINT is increasingly influencing information security, and this influence will likely continue to grow.

Indicators of Compromise

Below you will find a list of IOCs related to the ByBit case.