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

Bitget detected unauthorized wallet transfers about 30 minutes before attackers began draining hundreds of millions of dollars from the crypto exchange, raising questions about why its security response failed to contain the breach.

The exchange said its systems flagged unauthorized transfers at 18:31 UTC on Sept. 24 and that its security team immediately activated emergency protocols.

However, blockchain security firm Hypernative's reconstruction of the attack shows that most losses came later: $87.6 million left hot wallets at 19:01, and another $202.8 million left warm wallets at 19:16.

Those two bursts, completed in a combined 24 seconds, accounted for about three-quarters of the $387.5 million Bitget ultimately said was moved to attacker-controlled addresses.

The sequence suggests Bitget had roughly half an hour after its initial alert to prevent the first major wave and about 45 minutes before the largest transfer burst. It also shifts scrutiny from how the attacker first gained access to how the exchange responded once its own systems indicated something was wrong.

Hypernative said the attacker initially tested the compromised route at 18:31 with transfers of 0.84 ETH and 93 TRX to new addresses. After waiting about 28 minutes, the attacker moved $34.75 million of USDT at 18:58 before accelerating the drain across multiple blockchains.

Bitget's containment controls failed to stop the signing?

Bitget said its investigation found that the attacker compromised a backend system in its wallet infrastructure, spoofed withdrawal data, and tricked the exchange's authorization process into approving the transfers. The company said private keys were not compromised.

That attack path makes the response window especially significant. Hypernative said the transactions were signed by Bitget's own wallets and resembled ordinary customer withdrawals closely enough to pass through its infrastructure.

The security firm identified several controls that could have interrupted the attack after the initial alert.

One would have required every signed transfer to correspond with an independently stored customer withdrawal or approved treasury transaction. Such a check could have prevented a compromised backend service from creating its own authorization.

Hypernative also found unusual transaction parameters in the attacker's requests, including gas limits that differed from Bitget's normal withdrawal pipeline. Comparing proposed transactions against parameters normally generated by the exchange could have flagged the 18:31 test transaction before the larger withdrawals began.

Velocity limits provided another potential barrier. Hypernative said warm wallets moved $202.8 million across five networks within nine seconds at 19:16. Caps on how much individual wallet tiers could transfer within short periods, coupled with secondary approval requirements, could have delayed or blocked much of that wave.

Most critically, Hypernative said anomalous-transfer alerts could trigger an automatic suspension of the affected signer rather than relying on manual intervention. Instead, attacker-linked transfers continued until 21:23 UTC, almost three hours after Bitget's stated detection time.

Bitget has since said it remediated the vulnerability and that no further unauthorized transfers occurred after containment. Mandiant and SlowMist remain involved in the forensic investigation.

The unresolved issue is now what Bitget's security systems did with the 18:31 alert and why the compromised signing route remained operational long enough for roughly $290 million to leave in the two major waves that followed.