CyphrQ
Menu

Bybit Hack 2025: How It Happened, the $1.5bn Loss and the FBI's Finding

How the 2025 Bybit hack happened: a compromised Safe{Wallet} developer machine, tampered web code, the FBI's North Korea attribution, and what to check.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

Incident: February 202510 min read

How did the Bybit hack happen? On or about 21 February 2025, attackers took roughly $1.5 billion in virtual assets from the crypto exchange Bybit. According to the investigators, they did not break into Bybit's own systems. They compromised a developer at Safe{Wallet}, the wallet service Bybit's signers used, and tampered with the web code those signers saw. The FBI attributes the theft to North Korea.

This is a case file. It sets out what the primary sources say, where they differ, and what to check in your own organisation. It is part of our Digital Assets coverage.

Case file

Field Value
Organisation Bybit (crypto exchange). Third party in the attack path: Safe{Wallet}
Region Global (digital assets)
Theft date On or about 21 February 2025 (FBI)
Disclosed FBI public service announcement dated 26 February 2025 (FBI)
Losses "approximately $1.5 billion USD in virtual assets", the FBI's wording. Sygnia says the attackers moved "over 400,000 ETH" (Sygnia)
Assets taken Virtual assets from Bybit's Ethereum cold wallet. No customer personal data is described in the sources we read
Penalty/action FBI attribution to North Korea ("TraderTraitor"); the FBI asks industry to block transactions linked to the Ethereum addresses it lists (51 on its page when checked on 25 October 2026) (FBI)
Regulator None involved in the sources we read. The FBI is the law-enforcement source
Status Attribution published by the FBI. We did not check later developments such as recoveries or court action

What did the FBI say about the Bybit theft?

The FBI's public service announcement is the main official source. It says North Korea was responsible for "the theft of approximately $1.5 billion USD in virtual assets" from Bybit, on or about 21 February 2025 (FBI IC3).

It calls the activity "TraderTraitor" and describes it as "this specific North Korean malicious cyber activity".

The announcement does not describe how the intruders got in. It focuses on what happens next. The FBI says the actors have converted some stolen assets to Bitcoin and other virtual assets, which are "dispersed across thousands of addresses on multiple blockchains". It expects further laundering and then conversion to fiat currency.

It also asks RPC node operators, exchanges, bridges, blockchain analytics firms, DeFi services and other virtual asset service providers to block transactions "with or derived from addresses TraderTraitor actors are using to launder the stolen assets". We do not reproduce the address list here. It is in the FBI's announcement.

We quote the amount only as the FBI states it.

What is Safe{Wallet}, and why does a multisig wallet matter here?

A multisignature ("multisig") wallet needs several people to approve a transaction before it moves funds. Think of a safe that needs three keys turned. Safe{Wallet} is a web interface teams use to propose, review and sign those transactions.

That design is meant to stop one stolen key from emptying the wallet. In this case, it did not. The signers approved a transaction that looked normal on screen. The attackers had changed what it actually did.

How did the Bybit hack reach Bybit's signers?

Two organisations describe the path. They agree on its shape. Neither is an independent court finding.

Safe's account. In a statement dated 28 February 2025, the Safe Ecosystem Foundation reported the Safe{Wallet} team's preliminary findings. The forensic review "concluded that this attack targeted to the Bybit Safe was achieved through a compromised Safe{Wallet} developer machine resulting in the proposal of a disguised malicious transaction". It adds: "The forensic review of external security researchers did NOT indicate any vulnerabilities in the Safe smart contracts or source code of the frontend and services" (Safe Ecosystem Foundation).

The Foundation says it does not operate Safe{Wallet}. It also attributes the attack to the Lazarus Group, which it describes as a state-sponsored North Korean group.

Sygnia's account. Sygnia, a forensic firm, published its investigation on 16 March 2025. In its timeline (Sygnia):

Date (2025) Event, per Sygnia
4 February A Safe{Wallet} developer's macOS workstation was compromised, likely through social engineering
5 February The developer's AWS access was used against Safe{Wallet}'s AWS infrastructure, using a hijacked active session token
19 February The timeline says JavaScript files on the storage bucket serving Safe{Wallet}'s web interface were modified
21 February Bybit started a cold-wallet transaction through the web interface; the attackers manipulated it and drained the funds
21 February, about two minutes later The malicious code was removed from the web interface

Sygnia also says the code "originated directly from Safe{Wallet}'s AWS Infrastructure". It does not state that Bybit's own systems were breached.

Where do the sources disagree on the Bybit timeline?

Sygnia's own article is not consistent on two points. Its timeline puts the file modification on 19 February, based on cache analysis. Elsewhere it says the tampered files were modified on 21 February at 14:15 UTC, about two minutes after the malicious transaction. It also gives the attackers' time in Safe's AWS environment as 5 to 17 February in one place and 5 to 21 February in another. It does not reconcile them. We report both and do not pick one.

What did the malicious code actually do?

According to Sygnia, the malicious JavaScript was served from app.safe.global via an AWS S3 storage bucket. Chrome cache files from all three signers' machines, and public web archives, contained the injected code.

Three behaviours matter:

  • It was targeted. The code ran only when the transaction source matched one of two contracts: Bybit's, and an unidentified one "likely associated with the attackers".
  • It changed the transaction and weakened checks. It altered the transaction content and tampered with validation functions, so checks on transactions and signatures were bypassed.
  • It used a delegate call. The manipulated transaction handed execution to a malicious contract that the attackers had already deployed. That contract added functions to sweep ETH and tokens out, without a further multisig approval.

The signers were looking at a real Safe{Wallet} page. The screen showed one thing; the transaction they signed did another. That is why having several signers did not help on its own.

On 24 February, Sygnia found the malicious code no longer on the live site.

Was Bybit's own infrastructure compromised?

The two forensic accounts we could read point to Safe{Wallet}'s environment, not Bybit's. Sygnia says the code came from Safe{Wallet}'s AWS infrastructure. Safe's statement says its review found no vulnerabilities in its smart contracts or front-end source code.

We tried to read Bybit's own incident pages for its account, but the pages timed out repeatedly. We have not relied on them or quoted any Bybit figure. We also did not read Verichains' report. Treat any claim here about what Bybit or Verichains said as unchecked.

Going deeper: for security and IT teams

Threat model. A state-linked group wants large, fast, irreversible value transfers. It needs no flaw in the blockchain or the multisig contract. It needs a trusted party in the signing workflow, here a front end that signers rely on to show them what they are approving. It gets the full balance of a wallet once enough signers approve one altered transaction.

Attack chain, mapped to MITRE ATT&CK. We mapped only techniques whose pages we opened, and only to stages Sygnia describes.

Stage (per Sygnia) ATT&CK technique Tactic
Developer's AWS access used against Safe{Wallet}'s infrastructure T1078.004 Valid Accounts: Cloud Accounts Stealth, Persistence, Privilege Escalation, Initial Access
Hijacked active session token used in place of a login T1550.001 Use Alternate Authentication Material: Application Access Token Lateral Movement (TA0008)

We have not assigned technique IDs to the initial workstation compromise, the web-file tampering or the on-chain steps. We did not open matching technique pages and do not want to guess.

Controls that would have attacked the chain. MITRE's mitigations for those two techniques are a useful checklist:

  • Bind tokens to the device. For T1550.001, MITRE lists M1013 Application Developer Guidance: "Consider implementing token binding strategies, such as Azure AD token protection or OAuth Proof of Possession". Sygnia says the attackers used a hijacked active session token and "failed to register an additional MFA". That suggests the session itself was the weak point. MFA at login does not protect a token stolen after login.
  • Restrict where tokens work. M1036 Account Use Policies for T1550.001: "Where possible, consider restricting the use of access tokens outside of expected contexts." For cloud accounts (T1078.004), MITRE's M1036 recommends conditional access policies that block logins from non-compliant devices or outside defined IP ranges.
  • MFA and privilege hygiene on cloud accounts. M1032 (require MFA for cloud accounts, especially privileged ones), M1026 Privileged Account Management (review privileged cloud permissions, consider just-in-time access) and M1027 (rotate passwords and access keys).
  • Integrity of what you serve. Our inference, not from a source we read: a front end that signers trust should have change control on the storage bucket that serves it, alerts on any change to production files, and a record of who changed what. Sygnia reports files being swapped out about two minutes after the theft. Alerting on changes to those objects is the control that targets that gap.
  • Verify before you sign. Safe's statement says it committed to lead an industry-wide effort to make transactions more verifiable. Until then, signers should check the transaction independently of the interface that proposed it, for example by comparing the decoded transaction data on a second, separate tool.

Detection and evidence. What Sygnia says helped: Chrome cache files from signers' hosts and public web archives preserved the injected JavaScript. If you run a signing workflow, treat browser caches and CDN or bucket version history as evidence to preserve, and enable object versioning and access logging on any bucket that serves code to your users. Rotate every credential after an incident. Safe says it "rotated all credentials" and rebuilt its infrastructure.

Questions for your vendors and team.

  • Which third-party web interfaces do our approvers rely on to see what they sign?
  • Who can change the production files behind them, from which devices, and who is alerted?
  • Are developer cloud sessions bound to a managed device, and how long do tokens last?
  • Does every high-value approval include a check made outside the interface that proposed it?
  • Do we get a post-incident report from critical suppliers, and does it say what was and was not examined?

What should your organisation do this quarter?

  1. List every third-party tool your staff use to approve payments or transfers, crypto or not.
  2. For each one, find out who can change the code it serves, and ask how changes are logged.
  3. Require a second, independent check of a high-value transaction before the final approval.
  4. Move developer and admin cloud access to managed devices with short-lived, device-bound sessions.
  5. Turn on versioning, logging and change alerts for any storage that serves code to your users.

Learn more

Key takeaways

  • The FBI says North Korea was responsible for "the theft of approximately $1.5 billion USD in virtual assets" from Bybit on or about 21 February 2025.
  • Safe's review and Sygnia's report both place the compromise at Safe{Wallet}, starting with a developer machine, not in Bybit's own systems. Safe says no vulnerability was found in its smart contracts or front-end source.
  • The malicious code showed signers a normal-looking transaction and ran only for Bybit's contract and one other.
  • Sygnia's article gives two dates for the file change, 19 and 21 February. We report both.
  • The weak points were a stolen developer session and an unmonitored place where production code was served from. A multisig wallet does not help if signers cannot see what they sign.
  • We could not read Bybit's own pages or Verichains' report, so this case file does not rely on them.

Sources