Bybit’s signers approved what their screens showed, which was not what they signed

The week

On February 21, 2025, Bybit, a large cryptocurrency exchange where people buy, sell and store digital currencies, disclosed a theft. Attackers had taken roughly $1.5 billion in ether, a widely traded cryptocurrency, from one of its cold wallets. It happened during what looked like a routine transfer to a warm wallet. Several senior people had each checked the transfer on screen and clicked “approve.” Everything looked normal. Minutes later, the money was gone.

A word on the jargon. A crypto “wallet” is really a set of secret keys that control funds. A cold wallet keeps those keys offline and is used for large reserves, like a vault. A warm wallet is more connected and holds what is needed for day-to-day activity, like a till. Moving money from the vault to the till is ordinary housekeeping.

Bybit’s cold wallet was protected by a strong and common safeguard: it required multiple approvals, given through a third-party interface called Safe{Wallet}. No one person could move the money alone. Investigations found that attackers had compromised a developer’s computer at the interface provider and injected malicious code into its web application, aimed specifically at Bybit. The signers saw what appeared to be a normal transfer. The transaction they actually approved handed control of the wallet to the attackers.

The forensic detail, published over the following two weeks by investigators working for Bybit and for Safe, showed how narrow and patient the operation was. The malicious code was served from the cloud storage that delivered the Safe{Wallet} web application. It was written to activate only when the transaction came from Bybit’s cold wallet or one other address. Every other user of the interface saw normal behavior.

When the code did activate, it swapped the routine transfer for a different instruction. That instruction told the wallet to run code from a contract the attackers had deployed in advance, and that code replaced the logic governing the wallet itself. Once the signers approved, the attackers controlled the wallet and could move more than 400,000 ether out of it without any further approvals.

The timing was equally deliberate. The altered code had been live since February 19, two days before the theft. The malicious transaction executed at about 14:13 UTC on February 21. Roughly two minutes later, clean versions of the files were uploaded again, removing the most direct evidence from the live site.

On February 26 the FBI attributed the theft to North Korea, in activity it tracks as TraderTraitor. It was widely reported as the largest cryptocurrency theft to date. Bybit said it remained solvent and kept processing customer withdrawals, drawing on reserves and short-term loans.

The FBI’s public service announcement did more than name the culprit. It listed Ethereum addresses that held or had held the stolen funds, and asked node operators, exchanges, bridges and other virtual asset service providers to block transactions with, or derived from, those addresses. That request reflected how laundering works on public blockchains. The funds are visible to anyone, but stopping them depends on the businesses where thieves try to convert or move them. Bybit, for its part, opened a public bounty offering a share of any recovered funds to those who helped trace or freeze them.

On February 28 the Safe Ecosystem Foundation said the attack had been carried out through a compromised Safe{Wallet} developer machine, used to propose a disguised malicious transaction. It said outside forensic reviews had found no vulnerabilities in the Safe smart contracts or in the source code of its front end and services. Safe had paused its interface, rebuilt and reconfigured its infrastructure, rotated all credentials and begun restoring service in phases.

The method had precedents. In December 2024 the FBI and Japanese authorities had attributed the May 2024 theft of about $308 million in bitcoin from the Japanese exchange DMM Bitcoin to the same TraderTraitor activity. In that case an operator posing as a recruiter sent a “pre-employment test” to an employee of a wallet software company, and the attackers later used that access to manipulate a legitimate transaction. In October 2024 the lending protocol Radiant Capital lost about $50 million after malware on developers’ devices showed legitimate transactions in the signing interface while malicious ones were signed. Bybit applied the same idea to a far larger target.

Most coverage that week focused on crypto markets and on North Korea’s hacking program. Both mattered. But the more widely useful point was about how the theft worked. Every approver did their job. The control requiring several of them worked exactly as designed. What failed was the one thing everyone took for granted: that the screen in front of them was telling the truth. Any bank, insurer or treasury team that approves large payments by looking at a screen makes the same assumption.

Coverage of Bybit centered on crypto markets and North Korea. The method matters more widely. The multi-signature control worked as designed: several authorized people reviewed and approved the transaction. The attack succeeded because the screen they relied on had been altered, and the data they actually signed was not something a person could read.

Banks face a version of the same risk. Wires, treasury payments and securities settlements are approved by people looking at screens in applications that vendors often build and that browsers often deliver. Approval integrity can fail at four points along a payment’s life. They are when the approval interface is built and changed, when the approver views the transaction, when the payment is verified before release, and when a loss is chased afterward. Each point needs its own control, and a failure at any one can defeat the rest.

The four points weigh differently by type of institution. A community bank or credit union usually approves wires inside a portal supplied by its core processor. Most of its build risk therefore belongs to a vendor it can influence only through contract and oversight. A large bank builds much of its own payment tooling and owns its development pipeline, which makes part of the supply chain internal. A broker-dealer moving client cash and securities faces the same approval problem on different rails. A corporate treasury team approves payments in its bank’s online portal, so it relies on the bank’s interface while carrying much of the legal exposure. A bank that has moved into crypto custody faces Bybit’s exact problem. The controls below apply to all of them, with different owners.

Signatures, interfaces and the code between them

Multi-signature approval, or “multisig,” is the crypto version of a rule most finance teams know well: payments above a certain size need two or more signatures. In crypto, each signer holds a separate digital key, and the funds only move when enough of them sign the same transaction. It is designed to stop a single rogue insider or a single stolen key from emptying an account.

An interface is simply the screen and buttons people use to work with a system. Here, Safe{Wallet} provided the screens Bybit’s signers used to review and approve transactions. A web application is software that runs in a web browser rather than being installed on a computer. Its great convenience is that the supplier can update it centrally, at any time, and everyone gets the new version the next time they load the page. That same convenience is a risk: if an attacker can change the code on the supplier’s side, every user receives the attacker’s version without installing anything.

The technique is called a supply chain attack. Rather than attacking a well-defended target directly, the attacker compromises a supplier the target trusts and arrives through that trusted route.

The final piece is the gap between what a person sees and what they sign. Under the surface, a crypto transaction is a block of machine-readable data. The interface translates it into something a human can read: “transfer this amount to that address.” If the translation is honest, the human approves what they think they are approving. If the interface has been tampered with, it can show one thing and send something else for signature. Bybit’s signers were, in effect, approving data they could not read, on the word of an interface that had been tampered with.

What the signed data actually did

The altered transaction was more than a transfer to a new address. A large transfer to an unknown destination might have been caught by a device that showed the recipient. Instead it used a feature called delegatecall, which tells a smart contract wallet to run code stored in another contract as if it were its own. The attackers had deployed that other contract in advance. When it ran, it replaced the logic governing Bybit’s wallet with logic containing functions to sweep out ether and tokens. The multi-signature requirement still existed on paper. The wallet no longer enforced it.

The signers used hardware devices meant to protect their keys. Such devices are good at keeping a key secret and less good at explaining complex instructions. For a contract call like this one, signing devices commonly show a hash or raw data rather than a readable description, a practice the industry calls blind signing. The alternative, clear signing, means the device decodes the transaction itself and shows its effect in words. Bybit made the case for clear signing in institutional custody very hard to ignore.

The banking parallel is closer than it looks. A payment approver who confirms with a one-time code from a phone app is in the position of Bybit’s signers. The code proves who approved. It says nothing about what they approved, unless the code is tied to the amount and the payee.

The life of one large wire

Follow a single payment through a hypothetical organization: say, a regional bank sending a large wire on behalf of a corporate customer, or moving its own funds between accounts.

First, someone creates the payment instruction. That might be a clerk keying it in, a file arriving from the customer’s own systems, or a treasury platform generating it automatically. The instruction contains the essentials: amount, currency, beneficiary name, beneficiary account and the beneficiary’s bank.

Next, the instruction is routed for approval. Above a certain value, the bank’s policy requires two or more approvers, often at different levels of seniority. Each approver logs in to an application, frequently one bought from a vendor and increasingly one that runs in a web browser. They look at a summary of the payment, check it against what they expect and click to approve, sometimes confirming with a code from their phone or a physical token.

Once enough approvals are in, the payment is released to the payment network and travels, sometimes through one or more correspondent banks, to the beneficiary’s bank. For most wire payments, once the money arrives and is credited, getting it back depends on the cooperation of the receiving bank and, often, on speed.

Notice what every approver in that chain is relying on: the summary on their screen. They do not read the raw message that goes to the payment network. They trust that the application is showing them the same amount and beneficiary that will actually be sent. In normal times that trust is entirely reasonable. Bybit showed what happens when it is not, and it is why each of the four points below matters.

Count the parties involved in that one payment. There are the bank, the vendor that built the approval application, the company that hosts it and the browser on each approver’s machine. Behind all of them stand the developers who wrote and maintain the code. Every one of them is a place where what the approver sees could, in principle, be made to differ from what is sent. The good news is that each is also a place where a specific, affordable control can be applied.

Who carries the loss

Liability shapes how hard each party works on the screen. For commercial wire transfers in the United States, Article 4A of the Uniform Commercial Code governs. Broadly, a payment order the customer actually authorized binds the customer. For orders the customer disputes, a bank that followed a commercially reasonable security procedure agreed with the customer, in good faith, can generally treat the order as the customer’s own. Consumer protections under Regulation E largely exclude wires.

So when a corporate customer’s approver is deceived inside the bank’s own portal, any dispute turns on the security procedure. Both sides then have reason to want that procedure to cover what the approver actually saw, as well as who logged in. Organizations should confirm with counsel how these rules apply to their own agreements.

Where the screen’s data comes from

In most banks, the approval screen and the outgoing payment message are produced by different software. The approver sees a page drawn by a web application. The message that goes to Fedwire, CHIPS or SWIFT is built later by a payments engine or gateway, usually from the same database record. Between the two lie format conversions, enrichment, sanctions screening and routing.

Each of those steps is legitimate, and each is a place where the payment that leaves can drift from the payment that was approved, through error or through tampering. A reconciliation that compares the outgoing message with the approved record, field by field, closes that gap from the back end. Institutions should confirm that such a check exists for their highest-value payments, rather than assume it.

Build: the supply chain of the approval interface

The attackers never broke into Bybit’s own systems to plant the code. They compromised the company that supplied the interface, then targeted Bybit through it. That makes the approval tool part of the institution’s attack surface, the full set of places an attacker could get in, even when another company runs it.

Institutions should know who builds and hosts each interface used to approve high-value payments, how changes reach production and how quickly the institution would learn of malicious code. Web applications are a special case, because their code can change between one session and the next with no install for the customer to see. Controls include vendor commitments on development security and code signing, a way of digitally sealing software so that any unauthorized change is detectable. They also include notice of changes to approval screens and, where feasible, approval through an installed client or a pinned version that cannot change silently. Payment approval vendors belong in the critical tier of third-party oversight.

An installed client is no cure on its own. It moves the update problem rather than removing it, since a compromised update server can push a malicious version just as a compromised web host can. Its advantage is timing and visibility. An institution that controls when a new version is installed, and can check its signature first, gets a window to notice that something has changed. A web application that changes between page loads offers no such window unless the vendor builds one in.

The developer’s workstation was the entry point at Bybit’s supplier, and that detail matters for diligence. Questions about a vendor’s security usually focus on its production environment, the live systems that customers use. They should also cover how its engineers’ machines are protected. They should ask who can reach the build and deployment pipelines, the automated routes by which new code travels from a developer’s desk to customers. And they should establish whether any single developer can push code to the approval interface without review. A vendor that cannot answer those questions has not secured the part of its business attackers chose.

Session theft and the limits of login controls

The Safe developer’s account was protected by multi-factor authentication. The attackers went around it by stealing active cloud session tokens, the credentials a system issues after login so the user need not sign in again for each action. Many vendor assessments ask whether developers use multi-factor authentication and stop there.

A better set of questions covers how long sessions last and whether tokens are bound to a specific managed device. It asks whether access from unusual networks or tools triggers review, and whether deployment to production requires a second person rather than one developer’s live session. Those answers say far more about the risk Bybit exposed than a yes on multi-factor authentication.

For a web-delivered approval interface, a few further controls are specific and testable. Changes to the files served to customers can be monitored, so an unexpected modification raises an alert within minutes. Releases can be tied to a reviewed commit and signed, so served files can be checked against what was approved. Browsers can be told to reject scripts whose content does not match a published hash, a standard feature called subresource integrity, though it helps only when the page itself has not been altered. And the vendor can commit to notify customers before any change to the screens that display payment details.

How oversight differs by institution

US banking organizations work under the 2023 interagency guidance on third-party relationships, which expects more rigorous oversight of third parties that support critical activities. A payment approval tool clearly belongs in that category. Credit unions answer to the NCUA, whose examiners ask similar questions about vendor due diligence.

A community bank has little bargaining power over a large core processor on its own. It can still read the processor’s SOC 2 report for coverage of the development pipeline. It can ask, through user groups, for advance notice of changes to approval screens, and record the gap as a risk if the answers are thin. In the EU, DORA has applied since January 2025 to banks, payment institutions and crypto-asset service providers. It requires a register of ICT third-party arrangements and specific contract terms where providers support critical or important functions. Under any regime, the examiner’s underlying test is whether the institution knows who can change its approval screens.

View: making what is approved match what is executed

Approvers trust the screen to show the true beneficiary, amount and account. In Bybit’s case the display showed a routine transfer while the signed data did something else. Bank systems usually present human-readable details. The same gap still opens if the application, browser or endpoint, meaning the approver’s own computer, is compromised, or if details were altered upstream before the approver saw them.

Business email compromise, one of the costliest categories of cyber-enabled fraud in the FBI’s annual internet crime reports, exploits a version of this gap. In a typical case, a criminal impersonates a supplier or executive by email and asks for payment details to be changed. People approve details they believe are correct because they came through a trusted channel. Bybit was a technically sophisticated version of the same trick: the trusted channel was a screen rather than an inbox.

The control objective is to bring the approved view as close as possible to the executed instruction. Useful measures include showing key fields from the payment system’s own record rather than the request, and highlighting any beneficiary detail that differs from previous payments. Another is a dedicated, hardened workstation for high-value approvals: a computer locked down to do that one job, without email or general web browsing. In crypto, the equivalent is a signing device that decodes and displays the transaction on its own trusted screen.

Take a treasury analyst at a mid-sized manufacturer approving a supplier payment. Her approval screen pulls the beneficiary’s bank details directly from the bank’s payment record, not from the invoice or the request email. The account number differs from the one used for the last twelve payments to that supplier. So the field is highlighted in a different color, with the note “changed since last payment.” That single cue is often enough to make someone stop and ask.

The limit of a better display

A highlighted field is only as trustworthy as the software that draws it. If an attacker controls the application, as at Bybit, the highlighting can be suppressed along with everything else. Display controls therefore defend best against the common cases: an altered invoice, a spoofed email, a careless change to a vendor master file. Against a compromised interface they help less, which is why the next point, verification through a separate path, cannot be skipped for the largest payments.

Highlighting also wears out. If every payment carries a warning, approvers learn to click past warnings. The cue works when it is rare, which means tuning it to genuine changes in beneficiary details and not to every minor formatting difference.

What a hardened approval workstation involves

A dedicated approval machine is cheaper than it sounds and more demanding than buying a laptop. It runs only the payment application and the browser needed to reach it, with an allowlist that blocks other software. It has no email client and no general web access, since those are the routes malware usually arrives by. Administrator rights stay with IT. Updates follow a schedule, and the device is checked for tampering. Some institutions use a virtual desktop for the same purpose, which is easier to manage but shifts trust to the virtual desktop platform.

The burden falls on operations. Approvers must move to a separate device or environment, and travel or remote work makes that harder. A common compromise is a small pool of hardened devices for approvals above a threshold, with everyday approvals left on standard endpoints. The threshold then becomes the policy lever, and senior management should know where it is set and why.

Verify: a second path to the truth before release

The strongest defense against a deceptive display is confirmation through a channel the attacker does not control. For banks that means calling back a verified contact, using a number already on file rather than one supplied in the request, before paying a new or changed beneficiary. Other options are hardware tokens, small physical devices that display transaction details for signing on their own screen, and a release check that compares the outgoing instruction against an independent record. In crypto it means simulating the transaction in a separate tool before signing, to see what it would really do.

Independent verification is slower and costs money, so it should be proportionate. It should apply to the highest-value transactions, to non-routine ones and to any change in payment instructions. Bybit’s transfer looked routine, which is the case for not exempting routine transfers from the largest accounts. An institution can set a value threshold above which every movement, routine or not, gets a second-path check.

The trade-off is real and worth discussing openly. Treasury teams under time pressure will resist anything that slows payments. The answer is to apply the extra step only where the potential loss justifies it, and to make the check as quick as possible. A few minutes of delay on a handful of very large payments a day is a small price against a loss measured in the hundreds of millions.

Tying the confirmation to the content

A confirmation step protects against a deceptive screen only if it carries the payment’s content through a separate path. A one-time code proves presence. A transaction-signing device that shows the amount and beneficiary on its own display, and produces a code tied to them, proves what was approved.

European rules on strong customer authentication under the second Payment Services Directive already require this link for many electronic payments. The authentication code must be tied to the amount and the payee, a feature called dynamic linking. US institutions face no equivalent universal requirement, so for them it is a design choice.

A callback follows the same logic. It works when the caller uses a number taken from records created before the request, and reads the critical details back from the payment system rather than from the approval screen. Scripts help. So does a record of who called, when and on which number, because that record is what an examiner or auditor will ask to see. As voice cloning improves, callbacks to a known number remain sound. Callbacks to any number supplied in the request do not.

Names and accounts

Name checks add a different kind of verification. The United Kingdom’s Confirmation of Payee, introduced from 2020, warns a payer when the account name does not match the name entered. Such checks catch misdirected payments well. They would not have stopped Bybit, where the harmful step was a change to the wallet’s own logic, and they cannot detect an approver who was shown the wrong payment. They belong in the verify step alongside the controls above, never in place of them.

The blockchain equivalent

For institutions that sign blockchain transactions, verification means decoding the transaction on a separate system before signing and confirming its effect. Simulating it shows whether it would change ownership of the wallet or call code in another contract. A policy that blocks or flags delegatecall from treasury wallets, except in pre-approved cases, would have turned Bybit’s transaction into an exception requiring explanation.

Recover: chasing the loss fast

The final point assumes the others failed. Bybit kept operating because it had reserves, quick access to emergency funding and a clear public message within hours. The stolen funds were moved and laundered rapidly, and only a small portion was frozen.

For banks, the equivalents start with payment recall procedures that can begin within minutes. They also include standing contacts at correspondent banks, the other banks along a payment’s route that may be able to stop it. Large wire frauds should be reported quickly through the FBI’s Internet Crime Complaint Center, whose Recovery Asset Team works to freeze funds. Liquidity planning should include a large single loss. Recovery odds fall sharply after the first hours, so these steps need rehearsal as well as documentation.

A rehearsal can be simple. Suppose a regional bank runs a tabletop exercise once or twice a year. A facilitator announces that a large payment to an unfamiliar overseas account was released forty minutes ago, and the approver now believes it was fraudulent. The team then walks through what happens next, minute by minute. Someone has to start the recall and find a working number for the operations desk at the receiving bank’s correspondent. Someone files the report with the FBI’s Internet Crime Complaint Center, knowing what information it needs. And someone decides what to tell the customer and the board. Exercises like this regularly expose small but costly gaps. A contact left the correspondent bank months ago. A recall form needs a signature from someone on holiday. No one can find the password to the reporting portal. Every one of those gaps costs minutes, and minutes are what recovery depends on.

How recovery differs by rail

Recovery mechanics depend on what moved. A Fedwire payment is final once it settles, so getting it back depends on the receiving bank freezing the account and agreeing to return funds. For domestic wires, the IC3 Recovery Asset Team, set up in 2018, works with receiving institutions to freeze funds when victims report quickly. For international wires, the FBI’s Financial Fraud Kill Chain process can engage foreign counterparts, again only with a fast report.

Crypto has no recall at all. Funds can be frozen only where they touch an exchange, a stablecoin issuer or another business willing and able to act. That is why the FBI’s Bybit alert asked those businesses to block the listed addresses. By early March, Bybit reported that only about 3 percent of the stolen funds had been frozen.

Notification clocks

A large theft through a compromised vendor also starts regulatory clocks. US banking organizations must notify their primary federal regulator within 36 hours of determining that a computer-security incident has risen to the level of a notification incident. Federally insured credit unions must notify the NCUA within 72 hours of reasonably believing a reportable incident has occurred. Entities regulated by New York’s Department of Financial Services have a 72-hour notice requirement under Part 500.

Public companies that determine an incident is material must disclose it under the SEC’s cybersecurity rule within four business days of that determination. A suspicious activity report will usually be required as well. Mapping these clocks onto a single incident timeline in advance saves arguments on the day.

Communication is part of recovery too. A prompt, factual message to customers and counterparties protects liquidity as much as any funding line. If customers fear an institution is in trouble, they withdraw, and a theft becomes a run. Bybit’s quick public statement that it remained solvent and was still processing withdrawals was a recovery control in its own right.

Where an approval failure hurts most

• Money at scale. Approval controls protect the largest single movements an institution makes. A failure is rarely small.
• Controls that look strong on paper. Multi-person approval is exactly what auditors and regulators like to see. Bybit shows it can be satisfied in form and defeated in substance if everyone relies on the same compromised screen.
• Vendor dependence. More approval now runs through vendor-built, browser-delivered platforms. An institution’s security can be no better than its suppliers’ development practices.
• Sophisticated, persistent attackers. State-backed groups invest in patient, targeted operations, including compromising the people who write the software. Defending against them is a board-level risk question.
• Reputation and liquidity. How an institution communicates in the first hours after a loss can determine whether customers stay.

The strongest objection

A fair objection holds that banks are not crypto exchanges. Bank payment screens show readable fields, not opaque contract data. Banks run fraud analytics on outgoing payments, screen beneficiaries against sanctions lists and, for some payments, can recall funds. On that view, Bybit’s failure belonged to a young industry with immature tooling.

Part of that holds. A bank approver is less likely than a blockchain signer to approve data that cannot be read at all, and bank fraud models add a check no Safe user had. The core weakness still carries over. Bank approval screens are increasingly delivered by vendors through browsers, and an attacker who controls that code controls the readable fields too. Fraud analytics are tuned to customer behavior, and a large transfer between an institution’s own accounts, the kind Bybit was making, can look entirely normal to them. Wire recall works best against unsophisticated thieves. A state-backed group moves money onward within minutes.

Treating the screen as a control

A well-defended payment approval process treats the approver’s screen as a control, not as a given. The institution knows exactly which vendors build and host its approval tools, and holds them to critical-tier standards. Approvers see payment details drawn from the system of record, with changes highlighted. The largest movements, routine or not, get a second-path check. And recall, escalation and communications have been rehearsed, so they start within minutes.

The weak spots are familiar:

• Counting the number of approvers as the measure of strength, when all of them look at the same screen.
• Assessing a vendor’s production security while ignoring its developers’ machines and code pipelines.
• Exempting “routine” transfers from extra checks, which is exactly where an attacker will hide.
• Letting high-value approvals happen on everyday laptops used for email and web browsing.
• Having a recall procedure on paper that no one has practiced, with correspondent bank contacts that are out of date.

Who owns which point

The four points cut across organizational lines, which is one reason gaps survive. Vendor management usually owns the build point, through contracts and assessments, but rarely has the technical depth to question a supplier’s deployment pipeline. Payments operations owns the view and verify points day to day. The chief information security officer owns endpoint hardening and monitoring. Treasury and finance own liquidity planning for a large loss, and legal and communications own the first public message.

A workable arrangement names a single executive accountable for approval integrity end to end, often the head of payments or the chief operating officer, with the others as contributors. That person signs off on the approval threshold, the list of critical approval vendors and the exercise schedule. Without one owner, each function can reasonably believe another is covering the screen, and nobody is.

Evidence that the controls run

A few measures show whether the design is real. One is the share of payments above the threshold approved on hardened devices. Another is the share of new or changed beneficiaries confirmed by callback before release. A third is the time from detection to recall request in the last exercise. Others are the number of change notices received from approval-screen vendors in the past year, and the date of the last review of who can deploy code to those screens.

An examiner or internal auditor will usually ask for three things: the policy, evidence that it runs and the exceptions. A short quarterly report on these measures, owned by the head of payments operations and reviewed by the chief information security officer, supplies all three.

What the largest payments rely on

1. Which applications do we use to approve our largest payments, who builds and hosts each one, and how would we learn if its code were changed without our knowledge?
2. Are those vendors in our critical tier of third-party oversight, and have we asked how they protect their developers’ machines and code pipelines?
3. When an approver looks at a payment, where do the beneficiary and account details on screen actually come from, and do we flag details that differ from previous payments?
4. Above what value does every payment get a check through a separate channel, and are routine transfers exempt?
5. If a large fraudulent payment left today, how many minutes until we started a recall and contacted law enforcement, and when did we last rehearse it?

With hindsight

Bybit survived the theft. That alone was notable for an incident of this size, and it reflected the reserves, emergency funding and quick public communication described above.

Safe{Wallet} and outside investigators later published accounts tracing the compromise to a developer’s machine. That confirmed what the early reporting suggested: the approval interface itself had been the target, and the attackers had chosen the softest point in the supply chain rather than the hardest.

Safe’s fuller account, prepared with Google Cloud’s Mandiant and reported in early March 2025, filled in the chain. On February 4, a developer with elevated access downloaded a Docker project, probably after a social engineering approach, and the developer’s Mac was compromised. The attackers then hijacked the developer’s active AWS session tokens, which let them act in Safe’s cloud environment without facing multi-factor authentication. They timed their activity to the developer’s working hours to avoid notice. For anyone assessing a supplier, the implication was specific: authentication at login protects little if a valid session can be stolen afterward.

North Korea’s campaign continued. In December 2025 the blockchain analytics firm Chainalysis estimated that North Korean actors stole about $2 billion in cryptocurrency during the year, a record. That was roughly 60 percent of the global total of about $3.4 billion, and Bybit was by far the largest single incident. The FBI and others kept warning about related methods, including fake job applicants and compromised developers inside technology suppliers. The people who write and maintain software had become a deliberate target.

The laundering matched a pattern too. In early March, Bybit’s chief executive reported that about 77 percent of the stolen funds remained traceable, about 20 percent had gone dark and about 3 percent had been frozen. Most of the stolen ether had already been converted to bitcoin. Chainalysis later described North Korean laundering as following a roughly 45-day cycle, with rapid layering in the first days and heavy use of Chinese-language money movement services, cross-chain bridges and mixers. Speed and fragmentation kept most of the money out of reach, even though the blockchain recorded every move.

Tampering with code that runs in a user’s browser kept reappearing. In September 2025, attackers phished the maintainer of several widely used open-source JavaScript packages, including chalk and debug. They published versions built to intercept and rewrite cryptocurrency transactions in the browsers of sites that used them. The malicious versions were found and pulled quickly. The episode still showed how far down the software supply chain the code behind a screen can be changed.

Banking infrastructure moved in a helpful direction. The Fedwire Funds Service adopted the ISO 20022 message format in July 2025, carrying richer, more structured information about payers and payees. From October 2025, the EU’s Instant Payments Regulation required payment providers in the euro area to check that a payee’s name matches the account before sending a credit transfer. That joined the United Kingdom’s Confirmation of Payee. Both give a second source of truth about who is being paid. Neither checks the screen of an approver whose application has been altered.

US bank regulators also eased the path into crypto custody during 2025. In July 2025 the Federal Reserve, the FDIC and the OCC issued a joint statement on crypto-asset safekeeping that set out risk management considerations, including for the management of cryptographic keys. A bank entering that business inherits Bybit’s problem directly: signing data through software it may not fully control.

For banks, the relevance grew as treasury and payment approval moved further into browser-delivered platforms. Each such move brings real convenience: faster updates, no software to install, access from anywhere. Each also widens the set of people and systems that can, in principle, change what an approver sees.

Bybit’s most important contribution to the wider financial system was conceptual. It separated two ideas that are easy to treat as one: the number of people who approve a payment, and the reliability of what those people are shown. Adding approvers strengthens the first. Only controls on the interface, independent verification and hardened approval environments strengthen the second.

Wherever approval runs through a vendor’s interface, Bybit remains the clearest case for treating what an approver sees as a control in its own right. It is also the clearest case for asking suppliers hard questions about the developers whose code ends up on those screens.