Summary: Bitget had 30 minutes to contain its hack before $290 million started moving

Published: 25 days ago
Based on article from CryptoSlate

The $387 Million Security Gap: Bitget’s Missed Window

A recent forensic reconstruction of the $387.5 million Bitget breach reveals a critical 30-minute gap between the initial detection of unauthorized activity and the massive drain of assets. Despite the exchange's security systems flagging suspicious transfers early, the delay in effective containment allowed attackers to siphon hundreds of millions of dollars from both hot and warm wallets in mere seconds. The timeline suggests that while the initial alert occurred at 18:31 UTC, the most significant losses did not happen until nearly 45 minutes later, raising urgent questions regarding the exchange's emergency protocols.

A Costly Discrepancy in Containment

The breach began with small test transactions that were immediately flagged by Bitget's internal security systems, yet the bulk of the theft occurred much later. Blockchain security firm Hypernative noted that $87.6 million left hot wallets at 19:01, followed by a staggering $202.8 million from warm wallets at 19:16. These two major bursts were completed in a combined 24 seconds, representing roughly three-quarters of the total stolen funds. This sequence highlights a significant failure in the exchange's ability to act on its own alerts, as the attacker was given ample time to move from initial probing to full-scale exploitation.

Exploiting the Authorization Pipeline

The investigation into the attack vector reveals that the private keys themselves were not compromised; instead, the attacker targeted the backend infrastructure of the wallet. By compromising a backend system and spoofing withdrawal data, the attacker effectively tricked the exchange’s authorization process into approving the transfers as legitimate customer requests. Because the transactions were signed by Bitget’s own wallets and resembled ordinary withdrawal traffic, they bypassed standard security filters. Hypernative pointed out that unusual transaction parameters, such as abnormal gas limits and the sheer velocity of the transfers, were clear red flags that could have been used to trigger an automatic suspension of the affected signing service.

Lessons in Velocity and Verification

The aftermath of the Bitget breach underscores the necessity of automated safeguards over manual intervention in high-speed crypto environments. Security experts suggest that the implementation of velocity limits—caps on how much a specific wallet tier can transfer within a short window—could have significantly hampered the attacker's progress. Furthermore, requiring every signed transfer to match an independently stored customer request would have prevented the compromised backend from creating its own authorizations. While Bitget has since remediated the vulnerability and engaged forensic firms like Mandiant and SlowMist, the industry remains focused on why the compromised signing route remained operational for nearly three hours after the first alert.

Cookies Policy - Privacy Policy - Terms of Use - © 2025 Altfins, j. s. a.