The Bybit Theft Started on Someone Else's Laptop
On February 21, roughly $1.5 billion in Ether left a Bybit cold wallet in a single transaction. Five days later the FBI attributed the theft to North Korean operators, the activity it tracks as TraderTraitor. Investigations published since then describe how it happened, and the mechanism matters more than the amount.
The exchange’s signers used a multi-signature wallet through the interface of Safe{Wallet}, a widely used wallet platform. According to the published findings, attackers compromised a Safe developer’s workstation, used that access to plant malicious JavaScript in the web interface’s hosted files, and targeted it at Bybit. When Bybit’s signers approved what looked like a routine transfer, the interface showed them one transaction and had them sign another. That transaction changed the wallet’s underlying logic and handed control to the attackers.
The cold wallet’s cryptography held. The multi-signature requirement held. Every signer did what the screen asked. The weak point was the interface the signers trusted to describe what they were approving.
Why this is a third-party risk story
It would be easy to file this under cryptocurrency and move on. The pattern is more general. Many organizations authorize high-value or high-impact actions through a vendor-hosted interface:
- treasury and payment approvals in banking portals
- production changes approved through CI/CD and deployment dashboards
- identity administration through cloud consoles
- configuration pushes through device-management and network-management consoles
In each case, the organization’s control is a human approval. That approval is only as good as the information displayed, and the display is software someone else builds, hosts and updates.
Traditional vendor reviews ask whether the vendor encrypts data, performs penetration tests and holds a certification. Those are reasonable questions. They rarely ask how the vendor protects the integrity of the code it serves to customers, or how a single developer’s compromised machine could reach production assets.
Questions to add to vendor reviews
For vendors whose interfaces sit in your approval paths, these questions get closer to the Bybit failure mode:
- How is front-end code deployed, and who can change it? Can one engineer’s credentials modify what customers load, or does a change require review and a separate deployment identity?
- Is served code integrity-checked? Are there controls, such as subresource integrity, signed releases or monitoring of hosted assets, that would detect an unauthorized change?
- How are developer endpoints secured? Developer workstations hold cloud credentials and session tokens. Ask about device controls and how long those credentials stay valid.
- Would you detect targeted changes? Malicious code that activates only for one customer is harder to spot. Ask what monitoring would catch it.
Not every vendor will have strong answers. What you’re after is an honest picture of where you rely on a vendor’s integrity in ways you hadn’t recognized.
Controls you own
Some of the most effective changes sit on your side:
Verify out of band. For the highest-value actions, confirm the details of what’s being signed through a second, independent channel. In the Bybit case, verifying the raw transaction data on a separate device would have shown the mismatch. The equivalent in a payment workflow is confirming beneficiary details through a channel the requesting system doesn’t control.
Treat “what you see” as an assumption. Approval procedures often say “review the transaction and approve”. Rewrite them to say what must be checked, and where.
Limit the blast radius. Splitting large holdings or payment authority so that one approval can’t move everything reduces the cost of any single deception.
Plan for the vendor being the incident. Your incident response plan probably covers a compromise of your own systems. Add a scenario where a trusted vendor’s interface is serving malicious content, including who decides to stop using it and how.
The broader pattern
North Korean operators have spent years targeting the software supply chain and the people who build it, often through fake recruiting approaches to developers. This theft is the clearest illustration yet of where that work leads: patient access to a vendor, used at the moment a customer’s controls depend most on that vendor’s honesty.
The organizations best placed to resist it are those that know which vendor interfaces sit in their critical approval paths, and have decided in advance how much to trust them.