Bitget’s security systems detected unauthorised wallet transfers around 30 minutes before attackers began moving hundreds of millions of dollars, raising questions about why the exchange did not contain the breach.
The exchange said its systems flagged suspicious transfers at 18:31 UTC on 24 September, prompting its security team to activate emergency protocols immediately.
However, an analysis by blockchain security firm Hypernative found that the largest losses occurred later. A total of $87.6m was taken from hot wallets at 19:01, followed by a further $202.8m from warm wallets at 19:16.
Those two waves were completed in a combined 24 seconds and accounted for about three-quarters of the $387.5m Bitget eventually said had been transferred to addresses controlled by the attackers.
The timeline indicates the exchange had roughly 30 minutes to stop the first major withdrawals and about 45 minutes before the largest burst began. The focus is therefore shifting from how the attacker initially gained access to how Bitget responded after its own systems had identified a problem.
How the attack developed
Hypernative said the attacker first tested the compromised route at 18:31 by sending 0.84 ETH and 93 TRX to newly created addresses.
After waiting about 28 minutes, the attacker transferred $34.75m in USDT at 18:58, before rapidly increasing the operation across several blockchains.
Bitget said its investigation concluded that a backend system within its wallet infrastructure had been compromised. The attacker allegedly manipulated withdrawal data and deceived the exchange’s authorisation process into approving the transactions. Bitget said its private keys were not compromised.
According to Hypernative, the transactions were signed by Bitget’s own wallets and were sufficiently similar to standard customer withdrawals to pass through the exchange’s systems.
The security firm identified several measures that might have interrupted the attack after the initial warning. One proposed safeguard would require every signed transfer to match an independently stored customer withdrawal or an approved treasury transaction, preventing a compromised backend service from generating its own authorisation.
Hypernative also found unusual transaction settings, including gas limits that differed from Bitget’s normal withdrawal process. Comparing proposed transactions with the parameters usually generated by the exchange could have identified the 18:31 test transfer before the larger withdrawals began.
Limits on transaction speed and value could have provided another barrier. At 19:16, warm wallets moved $202.8m across five networks in nine seconds. Restrictions on the amounts different wallet tiers could send within short periods, alongside additional approval requirements, might have delayed or stopped much of that activity.
Hypernative said the most important safeguard would have been an automatic suspension of the affected signer when anomalous transfers were detected. Instead, transfers linked to the attackers continued until 21:23 UTC, almost three hours after Bitget’s stated detection time.
Bitget has since said it fixed the vulnerability and that no further unauthorised transfers occurred after containment. Mandiant and SlowMist remain involved in the forensic investigation.
