Bybit Attack: $1.5B stolen through malicious JavaScript

TL;DR: Bybit Safe Wallet UI injection timeline

• The signing UI failed: Multisig did not fail Bybit. The signing UI did. Attackers rewrote what the signer saw in the browser, so five approvers rubber-stamped a delegatecall that pointed at attacker code.
• One year of script history: The malicious script only fired for a predefined signer list and moved $1.5 billion after the delegatecall swapped the master copy. cside stores every third-party script for up to a year so you can see the exact injected build after the fact.
• Monitor treasury JavaScript: If your treasury interface loads any third-party JavaScript, monitor it at runtime today. If it does not, still assume the vendor supplying the wallet UI does, because Safe did.

Short on time? See cside's in-browser Magecart and skimmer blocking. It covers everything below in one deployment.

On February 21, 2025, the cryptocurrency world witnessed one of the biggest crypto thefts to date. Hackers stole $1.5 billion from Bybit, a major cryptocurrency exchange. They leveraged social engineering, which shows that security as a whole goes beyond passwords and firewalls.

Investigations by security firms and an official FBI Public Service Announcement claim that this hack is linked to the Lazarus Group, a North Korean cybercriminal organization known for stealing large amounts of money to fund their country's activities (e.g., The Bangladesh Bank heist). The FBI calls this particular North Korean operation "TraderTraitor."

What happened

Bybit uses a multisignature wallet to protect its funds. A multisig-wallet is a vault that needs multiple keys from different employees to open. No single person can move the money and coins alone.

However, the hackers didn't access the vault directly. Instead, they altered the user interface (the front end) that employees use to approve transactions, tricking the key holders into signing fake transactions without realizing it.

How it happened

1) Front-End (Client-Side) Attack

The attackers injected malicious JavaScript into the website interface where Bybit's employees normally approve transactions. This malicious code was hidden in such a way that everything looked normal on the screen, but behind the scenes, it changed important details.

Most companies solely focus on backend security or hardware wallets. But if the front end is compromised, it can silently alter transactions before a user even clicks "Approve." This is why we built cside, to let websites monitor dependencies in the browser of their users and avoid attacks like these.

The hackers used phishing emails and fake messages to convince employees the transfers were routine.

2) Delegatecall + Proxy trick

Even though Bybit used a multisig "vault," the malicious JavaScript changed the transaction type from a normal "call" to something called "delegatecall."

• Delegatecall let the hackers run their own code as if it were part of the vault contract.
• They used this to change the vault's "master copy" address, a key part of how this particular wallet works, to point to the attackers' contract.
• With that change in place, the attackers could run special "sweep" functions that emptied the vault of $1.5 billion.

Technical deep dive

Based on the analysis by @S1r1u5_ on X, here is a step-by-step breakdown of how the Safe{Wallet} was compromised:

1. Malicious JavaScript Injected: the attackers added malicious code into app.safe.global/_next/static/chunks/pages/_app-4f0dcee809cce622.js after one of the compromised developers pushed it to production.
2. Targeted executeTransaction(): the malicious JS only triggered if it recognized a predefined list of signers (in this case, Bybit's multisig owners).
3. Switching to delegatecall: instead of a normal call, the malicious code changed the operation to 1, which is delegatecall, delegating execution to an attacker's contract.
4. Changing the Safe's Storage: by using delegatecall, the hacker's contract rewrote the Safe wallet's masterCopy storage slot.
5. New Master Copy Drains Funds: the new malicious "master copy" contract contained sweepETH() and sweepERC20() functions, letting the attacker drain $1.5 billion in cryptocurrency.

This chain of events let the attacker bypass all the normal multisignature protections, as it appeared in the wallet interface as a valid transaction.

Why client-side attacks are hard to investigate

When hackers strike through client-side code (the JavaScript and HTML running in your web browser), gathering forensic evidence afterwards can be especially tricky:

1. Ephemeral data: browser sessions are short-lived, and logs of exactly which JavaScript files were loaded, and how they changed, can be incomplete or non-existent. Unlike server-side logs, front-end logs often aren't persistently stored.
2. Rapid deployment and updates: modern web applications frequently update or redeploy code. When an attacker injects malicious scripts, they may revert them just as quickly, leaving only a brief window of time to capture evidence.
3. Limited server logs: even if the server side is secure, the real action is happening in the user's browser. Standard server logs can show that a file was served, but not necessarily what changes were made to that file or how it behaved once executed.
4. Lack of version control transparency: some teams don't keep a public record of every front-end build. If the malicious change was introduced via a compromised build pipeline, forensic teams need detailed version histories, and those can be poorly tracked or easily manipulated.
5. Dependent on third parties: client-side code often pulls from external libraries or CDNs. If the malicious script was injected through a third-party service, forensics teams have to coordinate with external providers who may not keep detailed logs or might be slow to cooperate.

For forensic investigators, all of this means reconstructing a client-side attack can involve piecing together partial browser caches, developer console logs, deployment histories, and whatever versioning data is available from the build pipeline. It can be done, but it's significantly more challenging than investigating a traditional server-side compromise, where you typically have clearer logs and direct access to the compromised system.

How cside could have helped

cside analyzes first-party client-side scripts and inspects third-party JavaScript on our side before it runs on your site. We even store the scripts for up to a year, offering full forensics where today you have a blind spot. If Bybit had used cside, any unexpected or malicious modifications to the Safe wallet interface could have been caught and blocked, potentially preventing this entire attack.

References: https://x.com/lookonchain/status/1892965762186522975 https://x.com/lookonchain/status/1892971811807387877 https://x.com/lookonchain/status/1893223657838633177