Bytebit Attack: $1.5B stolen through malicious JavaScript

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 c/side. 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

Using the analysis by @S1r1u5_ on X.

Here is the step-by-step technical details 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. Essentially, 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. That delegated execution to an attacker’s contract.
4. Changing the Safe’s Storage
   • By using delegatecall, the hacker’s contract effectively 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.

In short:

1. Front-End Attacks Are UnderestimatedPeople often focus on backend servers, but a simple change in the website code can trick users into signing anything.
2. Human ErrorSocial engineering relies on people being rushed or trusting the content of emails. A carefully crafted fake message can fool even well-trained staff.
3. Delegatecall + Proxy PatternsMany crypto wallets and DeFi protocols use “proxy” contracts for flexibility. Unfortunately, if an attacker flips the pointer to their own code, they can take full control.
4. Deceptive InterfacesThe interface showed everything as “legitimate,” so signers had no idea they were approving malicious transactions.
5. Complex SystemsEven with multiple layers of security, a single failure in user awareness or front-end integrity can bring everything down.

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 & 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 c/side could have helped

c/side is a solution that analyzes first-party client-side scripts and proxies third-party JavaScript 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 c/side, 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