The recent Bybit hack surprised the cryptocurrency industry due to the sheer volume of the loss, which involved an estimated $1.46 billion in Ethereum, as well as the vertical assault approach deployed. Rather than compromising Bybit’s core infrastructure, attackers targeted Safe{Wallet}, a provider of multi-signature wallet security.
The attack exposes serious gaps in Bybit’s operational security and Safe’s failure to detect unauthorised system changes.
This article offers a timeline of events, analyses Safe’s security flaws, investigates Bybit’s insufficient transaction processing procedures, and discusses what crypto organisations can learn from traditional banking.
Timeline of Events
Phase 1: Safe{Wallet}’s Infrastructure compromise (February 19, 2025)
- Attack Vector: Attackers compromised a Safe{Wallet} administrator or high-level developer machine, gaining access to Safe{Wallet}‘s AWS. This access allowed malicious JavaScript injection into Safe’s user interface.
- Modification of JavaScript Files: Hackers replaced legitimate JavaScript files with malicious code designed to manipulate transaction approvals, specifically targeting Bybit’s Ethereum multi-signature cold wallet. This allowed them to wait for the right transaction and avoid being detected for a small prize.
Phase 2: Execution (February 21, 2025)
- Unauthorised Transaction: During a routine transfer on February 21, 2025, at approximately 1416:11 UTC, Bybit’s signers, using the compromised Safe{Wallet} interface, inadvertently approved a malicious transaction. This resulted in the transfer of over 400,000 ETH ($1.46 billion at the time) to addresses controlled by the attackers.
- Transaction Details: The transaction can be viewed on Etherscan.io:
- Transaction Hash: 0xb61413c4…16ea9f072c
- From Address (Bybit: Cold Wallet 1): 0x0fa09C3A328792253f8dee7116848723b72a6d2e
- To Address (Bybit Exploiter): 0x1Db92e2EeBC8E0c075a02BeA49a2935BcD2dFCF4
- Bybit Exploit addresses list
- Concealment Efforts: Two minutes after executing the fraudulent transaction, the attackers restored the original JavaScript files in Safe{Wallet}’s AWS S3 bucket to cover their tracks and delay detection.
Phase 3: Detection and Attribution (February 21, 2025)
- Identification of Suspicious Activity: On February 21, 2025, blockchain investigator ZachXBT reported suspicious outflows totalling approximately $1.46 billion from Bybit’s wallets.
- Lazarus Group: Through detailed analysis, ZachXBT linked the stolen funds to the North Korean state-sponsored hacking group known as Lazarus Group. This was later confirmed by blockchain analytics company Arkham Intelligence.
Phase 4: Response and Recovery (February 22-25, 2025)
- Public Acknowledgment: Bybit’s CEO, Ben Zhou, confirmed the security breach and assured users that client assets remained secure, with withdrawals operating normally.
- Fund Recovery Efforts: Bybit secured emergency funding and collaborated with other crypto companies to replenish its reserves within 72 hours, stabilising the platform and restoring user confidence.
Safe{Wallet}’s Security flaws
The breach highlighted significant security flaws within Safe{Wallet}’s infrastructure:
- Lack of File Integrity Monitoring: It is safe to conclude that there is no real-time file integrity monitoring at the moment of the attack. This enabled the malicious JavaScript to be undetected until after the attack. The implementation might have prompted immediate notifications in the event of unauthorised modifications, preventing the attack. In the instance that an FIM was installed, the attackers deactivated or deceived it, which is virtually equally awful as not having one.
- Inadequate Access Controls: The compromise of one machine highlights the importance of strict access controls and multi-factor authentication in preventing unauthorised access to key infrastructure. Whatever was in place was insufficient, and/or it relied too heavily on common credential storage techniques to facilitate credential input. Since we’re dealing with AWS, we can predict session token manipulation.
- Lack of pre-authorised update schedules: Implementing a strict, pre-approved update schedule with detailed logging is an important security strategy that might detect unauthorised access, even if it comes from authorised machines. This strategy improves accountability and allows for the rapid detection of suspicious actions.
Bybit’s Operational Vulnerabilities
Several operational practices at Bybit contributed to the success of the attack.
- Reliance on Third-Party Interfaces: Bybit’s reliance on Safe{Wallet}’s web-based interface, rather than direct API connections, exposed it to vulnerabilities within Safe{Wallet}’s infrastructure. Direct API access could have mitigated the risk by reducing dependence on potentially compromised interfaces.
- Predictable Transaction Schedules: Routine transfers at predictable times allowed attackers a clear window to carry out their plan. Implementing randomised transfer schedules may have made it more difficult for attackers to predict and exploit such processes.
- Single Point of Failure: Maintaining a single primary cold wallet increases the danger. In the context of cryptocurrency exchanges, a cold wallet is an offline storage option for securely storing significant sums of digital assets away from online risks. While cold wallets are normally regarded as secure, transferring such a large amount in a single transaction, from a single regular source, created the ideal nightmare scenario.
Lessons from Traditional Banking
The incident offers critical lessons that cryptocurrency entities can learn from traditional banking practices. Even if innovation and development speed are reduced, the extra security is welcome.
- Segregation of Duties: Implementing multi-person approval processes for significant transactions can prevent unauthorised actions by a single compromised individual.
- Bybit was up to standard, with multiple signatures required, but needs to include some randomisation in its operations.
- Continuous Monitoring: Establishing real-time monitoring systems to detect unusual activities can facilitate prompt responses to potential threats. These systems must be implemented in external servers to prevent hackers from easily detect and disable them.
- If it is hard to believe that such systems were not implemented by Safe{Wallet}, it is not the first time we have seen similar occurrences.
- Comprehensive Audits: Regular security audits and penetration testing can identify and address vulnerabilities before they are exploited.
- Since the time frame was so short, audits would not have detected the anomaly to prevent the steal, and this is why the combination with real-time systems is critical.
- Robust Access Controls: Enforcing strict access controls and multi-factor authentication is not a need, it is the only way. There is no evidence that multi-factor was not used and since it is so common, we can expect it was.
- Zero Standing Privileges are used to mitigate the risk of unauthorised access and should be mandatory for critical systems.
- Incident Response Planning: Developing and regularly updating incident response plans ensures preparedness to handle security breaches effectively.
- Bybit answer to the hack was perfect. They were fully transparent, with live-streamed sessions to clarify the incident and showing up to several podcasts, presenting what was done to mitigate the damage, showing they were prepared for the worst.
Conclusion
The Bybit hack underscores the imperative for robust security measures within the cryptocurrency industry. Due to high volumes of funds held, crypto entities will always be a desirable target, and with Governmental level organisations, like The Lazarus Group, no one can be 100% confident.
By adopting comprehensive security protocols, learning from traditional banking practices, and ensuring vigilant monitoring of all components within their operational infrastructure, crypto entities can enhance their resilience against sophisticated cyber threats.