Bybit Hacking Incident Analysis: How Can Cryptocurrency Exchanges Strengthen Their Security?

The $1.4 billion hacking incident that occurred on February 21, 2025, at the cryptocurrency exchange Bybit sent shockwaves throughout the cryptocurrency industry. The theft of a massive amount of cryptocurrency assets, including 401,347 Ethereum, shows that even the top 10 global cryptocurrency exchanges, presumed to maintain high security, are not immune to hacking.  

This blog post aims to provide a detailed analysis of the Bybit hacking incident, examining the causes, impact, and potential security enhancement measures.

Incident Summary and Timeline

• February 18th: The attacker deployed a malicious contract, marking the beginning of the hack.
• February 21st: A massive amount of Ether was transferred from Bybit's multi-signature cold wallet to an unknown address. All transactions were recorded on the blockchain.  

Technical Analysis: Sophisticated Attack Techniques

This hacking incident was a highly sophisticated attack that exploited vulnerabilities between the Safe{Wallet} platform and Bybit's internal systems. The attacker injected malicious JavaScript code into the app.safe.global platform, which Bybit signers used for transaction management. This malicious code was designed to remain dormant until specific conditions were met, activating at a specific time to target high-value assets.  

Malicious Code Injection and Analysis

The attacker injected malicious JavaScript code into app.safe.global, accessed by Bybit signers. This code was designed to operate only under specific conditions, remaining undetected by ordinary users while targeting high-value assets.  

Two key JavaScript files were modified for the attack: _app-52c9031bfa03da47.js and 6514.b556851795a4cbaa.js. These files were subtly altered to manipulate critical functions related to transaction execution, signing, and gas limit calculations.

• One file modified the executeTransaction and signTransaction calls. 
• The other file modified the useGasLimit call.
• The last modified time of one of the malicious JavaScript files was traced back to February 19th.  
• The normal JavaScript file was likely replaced with malicious code on February 19th.

Code Analysis: Patches and Exploits

The malicious code targeted specific addresses and transaction types. It verified the signer and Safe addresses against a predefined target list. If a signer's address was identified as a target, the page would reload to prevent the signing of proposals.

The core of the hack focused on the Safe address. If the Safe address was a target and the current transaction operation was set to its default value (0), the malicious code would be executed.

Detailed Patch Analysis:

1. executeTransaction Call Patch:
   
   • The transaction was rewritten to divert funds to the attacker's address.  
   • It checked if the Safe address was a target and if the transaction operation was set to 0.
   • If both conditions were met, the transaction data was modified to transfer funds to the attacker's address.  
   • The original transaction data was temporarily stored and restored after the malicious transaction was executed.‍
2. signTransaction Call Patch:‍
   • Similar to the executeTransaction patch, this modified the transaction data to execute the attack if the Safe address was targeted and the transaction operation was set to its default value (0).
   • If the signer's address was on the target list, the page would reload, hindering legitimate transaction approvals.
   • Like the executeTransaction patch, the original transaction data was temporarily stored and restored.‍
3. useGasLimit Call Patch:‍
   • This patch was designed to return a specific gas limit value (218207) for targeted Safe addresses.
   • By manipulating the gas limit, malicious transactions could be executed without triggering alarms.

Exploitation of the Safe{Wallet} Platform

The attackers exploited vulnerabilities in the Safe{Wallet} platform. By injecting malicious code into the transaction signing process, they were able to alter transaction details while displaying a normal address on the UI, deceiving signers into approving malicious transactions.  

The attackers bypassed the multi-signature mechanism by manipulating the UI and altering transaction data, tricking signers into authorizing the transfer of funds to the attacker's control. The UI displayed a normal transaction, but the actual data was modified to transfer funds to the attacker.  

Potential API Key Leak and S3 Bucket Compromise

Investigations suggest a potential compromise of Safe.Global's AWS infrastructure, with the possibility of the AWS S3 or CloudFront account/API Key being leaked or compromised. This could have allowed the attacker to modify JavaScript files hosted on Safe.Global's infrastructure.  

Evidence Supporting API Key Leak

1. JavaScript File Modification: The malicious JavaScript files were modified on February 19th, before the actual hack on February 21st, suggesting unauthorized access to Safe.Global's servers.
2. Modification Time: The modification timestamps align with the attack timeline, indicating a deliberate and organized attack.
3. Wayback Archive Analysis: Analysis shows the normal JavaScript file was replaced with malicious code on February 19th.  
4. Chrome Cache Data: Chrome cache files show that resources served from Safe{Wallet}'s AWS S3 bucket on February 21st were last modified on February 19th.
5. Response Headers: Response headers for the modified JavaScript resources indicate modification in the AWS S3 bucket on February 21st at 14:15:13 and 14:15:32 UTC, approximately two minutes after the malicious transaction was executed.  

Risks of API Key Leakage

Leaked API keys or compromised AWS S3 accounts can have severe consequences, allowing attackers to:

• Modify Website Content: Inject malicious code into the Safe{Wallet} platform.  
• Redirect User Transactions: Alter transaction details to send funds to attacker-controlled addresses.  
• Access Sensitive Data: Access sensitive data stored in AWS S3 buckets.

The Attacker: North Korean Lazarus Group

The FBI has attributed the Bybit hack to the North Korean hacking group TraderTraitor, also known as the Lazarus Group. The Lazarus Group has a history of sophisticated cyberattacks targeting cryptocurrency exchanges and financial institutions for financial gain.  

• North Korea was responsible for approximately $800 million in stolen cryptocurrency in 2024 alone.
• The scale of North Korean attacks is about five times larger than those by other actors, demonstrating their focus on high-impact operations.  
• These attacks are believed to circumvent international sanctions and fund the North Korean regime.
• The Lazarus Group has been linked to attacks on Sony Pictures, the Central Bank of Bangladesh, and the WannaCry ransomware attack.

Bybit's Response and Recovery Efforts

Bybit has taken several steps to address the breach and restore user trust:

• Prompt Disclosure and Transparent Communication: Bybit acknowledged the hacking incident and promptly informed users with transparency.
• Compensation for Affected Users: Bybit fully compensated affected users, preventing the loss of customer funds.
• Bounty Program: Bybit has implemented a bounty program, offering rewards for information leading to asset recovery.  
• Security Enhancement: Bybit is strengthening its security systems to prevent future attacks.  
• ETH Purchase: Bybit purchased over 1 trillion won worth of ETH to cover the losses.
• Security Review: Bybit's legal and security teams are investigating the incident.

Safe{Wallet}'s Actions

Safe{Wallet} also acknowledged the system breach and took the following actions:

• JavaScript Resource Modification: JavaScript resources in the AWS S3 bucket appear to have been modified on February 21st, approximately two minutes after the malicious transaction.
• Malicious Code Removal: Safe{Wallet} removed the malicious code that was found in the Chrome cache files and served via their AWS S3 bucket.

Implications for the Cryptocurrency Industry

The Bybit hacking incident highlights crucial areas for improvement in the cryptocurrency industry:

• Strong Security Protocols: Exchanges and wallet providers need to invest in robust security measures.  
• Smart Contract Security: Thorough audits and testing of smart contracts are crucial.
• Supply Chain Security: Increased vigilance regarding supply chain security is necessary to prevent malicious code injection.
• User Education: Users should be educated about phishing attacks and social engineering techniques.
• Collaboration and Information Sharing: Industry-wide collaboration and information sharing are essential for threat identification and prevention.
• Multi-Factor Authentication: Implement multi-factor authentication to secure platforms.

Conclusion: Towards a Secure Ecosystem

The Bybit hacking incident serves as a stark reminder of the risks faced by the cryptocurrency industry. This incident should be a catalyst for all stakeholders, including exchanges and related businesses, to reinforce security measures. Collective wisdom and collaboration are crucial for building a more secure and trustworthy cryptocurrency ecosystem.

The Risk of API Key Leakage

While investigations are ongoing, the Bybit hacking incident may have been caused by the leakage of an API key that granted access to Safe{Wallet}’s S3 or CloudFront. With the increasing use of cloud systems and SaaS services, hacking incidents caused by the leakage of non-human identities like API keys are on the rise. Therefore, it is critical to monitor API key leakage centrally and implement measures to mitigate threats related to non-human identities.  

Cremit provides internal monitoring for non-human identity leaks and accurate API key detection. If you need assistance, start here or contact us

‍