Altered Code on the Signers' Page Cost Bybit's Cold Wallet $1.46 Billion

Seven hours on February 21, 2025, from a routine transfer to a report to the authorities

At 13:30 UTC on February 21, 2025, Bybit started a routine transfer from an Ethereum multisig cold wallet to a hot wallet, sending 30,000 ETH first. Less than an hour later, the funds in that cold wallet had been moved out.

The times for that day come from Bybit Security Incident: Timeline of Events and FAQs, published on Bybit Learn on March 3, 2025, and are given in UTC.

Why a cold wallet can be robbed at all comes down to signing. A cold wallet keeps its private keys offline, but money only leaves when someone signs; a multisig wallet needs several people to sign separately, and each signer first has to see what the transaction is. The layer that shows the transaction to the signers is the part that was tampered with in this incident.

Altered JavaScript in the Safe{Wallet} signing page

Sygnia's report Sygnia's Investigation into the Bybit Hack: What We Know So Far, published on March 16, 2025, takes the attack down to the code. Its key findings:

• JavaScript resources in the AWS S3 bucket hosting the Safe{Wallet} web interface were modified on February 19, 2025, two days before the transfer on the 21st.
• The malicious code had a trigger condition: it only ran when the transaction came from one of two contract addresses. One was Bybit's contract address; the report did not identify the other. For transactions from any other address, the code did nothing.
• The attack transaction used delegatecall to replace the contract's implementation with a malicious version, hijacking control of Bybit's cold wallet.
• Two minutes after the malicious transaction was sent, the attacker removed the malicious code from the Safe{Wallet} web interface.
• What was breached was a Safe{Wallet} developer's workstation, and the attacker used stolen credentials to get into Safe{Wallet}'s AWS account; Bybit's own infrastructure was not directly compromised.

delegatecall is one way Ethereum contracts call each other: the caller borrows another contract's code and runs it against its own storage. Under that rule, once the implementation behind a multisig wallet contract is swapped out this way, who can move the money in that wallet changes with it.

Safe's side of the story appears in the Bybit timeline entry for February 22 at 01:08: Safe confirmed that its codebase had not been compromised and contained no malicious dependencies, that other Safe addresses were unaffected, and that it had paused Safe{Wallet} functionality for a review. Safe's statement is about the codebase and its dependencies; Sygnia's report is about the web assets hosted in the S3 bucket and a Safe{Wallet} developer's workstation.

At 15:17 on February 26, Ben Zhou published the preliminary reports from Sygnia Labs and Verichains. Both traced the root cause to malicious JavaScript on the Safe{Wallet} platform and found no vulnerability in Bybit's own infrastructure.

Four assets taken and the ETH gap closed within 72 hours

According to Bybit's official timeline, only one cold wallet was compromised, and the $1.46 billion loss was spread across four assets:

The four USD values add up to 1.12 + 0.25316 + 0.04413 + 0.023 ≈ $1.440 billion, about $20 million less than the $1.46 billion total on the same page, and the official page does not explain the gap. Nor are those the only figures in circulation: the same page's introduction says “almost $1.5 billion” and another passage says “$1.4 billion”, while the FBI announcement says “approximately $1.5 billion”. The $1.46 billion in the title of this case is the total loss listed in Bybit's timeline.

The following days, in UTC:

Hacken's updated proof of reserves report and the closing of the client-asset ETH gap within 72 hours are recorded in the same timeline entry. The 15,000 cmETH recovered equal the amount of cmETH stolen; the loss list puts that portion at $44.13 million while the recovery entry says nearly $43 million, and the two figures come from different entries in the timeline.

The FBI's February 26 attribution to TraderTraitor

On February 26, 2025, the FBI's Internet Crime Complaint Center (IC3) issued public service announcement I-022625-PSA, titled North Korea Responsible for $1.5 Billion Bybit Hack. It states that North Korea (DPRK) was responsible for stealing approximately $1.5 billion in virtual assets from the cryptocurrency exchange Bybit “on or about February 21, 2025”, and that the FBI refers to this North Korean malicious cyber activity as “TraderTraitor”.

The announcement adds that TraderTraitor is moving quickly to convert some of the stolen assets into bitcoin and other virtual assets dispersed across thousands of addresses on multiple blockchains, and that the FBI expects these assets to be further laundered and eventually converted to fiat currency.

Its HOW YOU CAN HELP section asks the private sector to act: the FBI encourages RPC node operators, exchanges, bridges, blockchain analytics firms, DeFi services and others to block transactions with addresses used to launder the funds, and the announcement lists 50 Ethereum addresses.

On attribution, the sources agree. Bybit's timeline records ZachXBT submitting evidence at 19:09 on February 21 that linked the attack to Lazarus Group; Sygnia's report cites the FBI attribution and identifies TraderTraitor as Lazarus Group / UNC4899, a North Korea-linked threat group.

Signing checks that don't rely on the web page

Bybit was running an institutional multisig cold wallet, and an individual's holdings are far smaller, but the checks are the same whenever you use a multisig or sign with a hardware wallet connected to a web tool.

1. Every signer on a multisig should check the raw transaction data on the hardware wallet's screen and look at two things at minimum: the target contract address and the call type. The recipient and amount shown on the web page are drawn by the page itself; if the page has been altered, what it shows changes with it.
2. If all you meant to do was send some coins and the device screen shows a delegatecall, or an operation that changes a contract's implementation, stop at that step. For an ordinary transfer, either kind of call is a warning sign on its own.
3. If you connect a hardware wallet to a web wallet or a DApp front end, the device screen is still what you check. A web tool with injected code can look exactly as it always does, so a page that looks the same as last time is no proof that it's safe.
4. If the screen shows only a hash or a string of hex data and you can't read the target contract and call type from it, treat the transaction as not yet checked, and sign only once you know what it is going to call.
5. Check routine operations one by one with the same steps.