I know everyone is talking about the ByBit attack, and this is probably the hundredth article you’ve read on the topic, but I still think it’s worth sharing a few thoughts on it.
What Happened?
In short, the North Korean Lazarus Group managed to steal $1.5 billion from ByBit’s cold wallet. The cold wallet was a Safe multisig wallet, and the transaction was signed by all authorized parties since, from the user interface, it appeared to be a completely valid transaction.
It later turned out that the Safe UI had been compromised. The attackers obtained AWS S3 credentials from a developer’s machine, which allowed them to modify the UI.
That’s the story in a nutshell. I don’t think pointing fingers or assigning blame is particularly useful. Instead, it makes much more sense to focus on the key takeaways and how this technology can be even more secure.
I understand hindsight is always 20/20, and I’m not claiming I would have done any better. The Safe team does excellent work, and everything I’ll discuss here concerns components outside of Safe itself (the smart contract-based multisig wallet).
I tweeted my thoughts after the incident. In this article, I’d like to elaborate on them in more detail.
Modules and Guards
One of the best features of a Safe wallet is that its capabilities can be extended using modules and guards. Modules add new functionalities to the wallet, while guards perform checks before a transaction is executed. These features make the wallet highly customizable and significantly enhance its security.
For example, it’s possible to restrict the wallet to only allow ERC-20 transactions (in this case, the malicious transaction was executed via a delegatecall). It’s also easy to implement a rule requiring additional signatures for transactions above a certain threshold—similar to how banks allow users to set limits for high-value transactions.
Even the proper use of just this one feature could prevent many attacks or at least minimize potential losses.
Immutable UI
Every system is only as strong as its weakest component. In this case, the weakest link wasn’t the developer whose S3 credentials were stolen—it was something much deeper. No matter how secure Web3 technology is (blockchain and smart contracts), if the Web2-based UI is vulnerable, the entire system remains at risk.
The obvious solution is to use an immutable Web3 UI. Technologies like IPFS, Ethereum Swarm, or other Web3 storage solutions can provide this. The simplest implementation is to store the UI content hash as a constant variable in the smart contract, ensuring that any UI change requires modifying the smart contract itself.
This approach fully binds the UI to the smart contract, making it impossible to alter the interface without first hacking the contract itself. With this simple solution, UI-based attacks can be effectively prevented.
Separate Device
Even if the smart contract is secure and the UI is immutable, the system remains vulnerable if the signers’ devices can be compromised. If an attacker gains access to a signer’s device, they can still replace the UI on the client side.
For this reason, anyone holding large amounts in a cold wallet should use a dedicated device—for example, an iPad—exclusively for signing transactions. This device should serve only this purpose: no other applications installed, no email or web browsing, only the necessary environment for signing transactions.
If someone is managing billions of dollars, spending a few hundred dollars on a dedicated signing device is hardly a significant expense.
External Transaction Auditing Oracle
An external auditor can be added to the wallet as an additional signer, a module, or a guard to review transactions and block them if they appear suspicious. Detecting such suspicious transactions can be done using relatively simple patterns—for example, moving an unusually large amount of funds or executing a delegatecall.
In case of a suspicious transaction, the external auditing system can notify the signers, prompting them to manually review the transaction. If they still deem it legitimate, they can re-sign it as a confirmation, adding an extra layer of security.
Conclusion
There is no such thing as an unbreakable system, but the simple solutions outlined above can make an attack significantly more difficult. If someone is managing billions of dollars, it’s well worth investing some time and effort into implementing these straightforward security measures.
I cannot emphasize enough that all these solutions build upon Safe’s brilliant architecture, and features like modules and guards.
As the saying goes, what doesn’t kill you makes you stronger. And today, Safe is stronger than ever!
