What matters here isn’t when Bitget got hacked. It’s what happened in the half hour after it noticed.

Blockchain security firm Hypernative has reconstructed the timeline of Bitget’s Sept. 24 breach, and it shows the exchange’s own systems flagged unauthorized wallet activity well before the two transfer waves that accounted for roughly three-quarters of the $387.5 million loss. That sequencing shifts the central question in the case from how the attacker got in to why the compromised signing route kept working after Bitget says it already knew something was wrong.

Key Takeaways

  • Bitget says it detected unauthorized transfers at 18:31 UTC on Sept. 24, according to CryptoSlate.
  • Hypernative traced an $87.6 million drain at 19:01 and a $202.8 million drain at 19:16, a combined $290.4 million moved in two bursts totaling 24 seconds.
  • Attacker-linked transfers continued until 21:23 UTC, nearly three hours after Bitget’s stated detection time.
  • Bitget CEO Gracy Chen told Cointelegraph the breach originated in a vulnerability in a third-party security product, not compromised private keys.
  • Bitget has floated a possible North Korea link based on VPN infrastructure patterns, according to LavX News, though Chen called those indicators preliminary.

The Gap Between Detection and the Big Withdrawals

Hypernative’s data shows the attacker first tested the compromised route at 18:31 UTC with small transfers, 0.84 ETH and 93 TRX, to new addresses, per CryptoSlate. After waiting about 28 minutes, the attacker moved $34.75 million in USDT at 18:58 before the drain accelerated across multiple chains.

The two largest bursts followed: $87.6 million left hot wallets at 19:01, and $202.8 million left warm wallets at 19:16, completed in a combined 24 seconds. That means Bitget had roughly 30 minutes after its initial alert to intervene before the first major wave, and about 45 minutes before the largest one. Attacker-linked transfers didn’t stop until 21:23 UTC, almost three hours after the 18:31 detection point CryptoSlate cites.

How the Signing Route Was Compromised

Bitget’s own account of the intrusion, relayed to Cointelegraph, points to a vulnerability in a third-party security product rather than a direct breach of its wallet code. Chen said the attacker used that flaw to obtain high-level internal credentials, then issued fraudulent withdrawal commands that Bitget’s authorization process approved as if they were ordinary customer transactions. Private keys were not compromised, and cold wallets were not affected, according to both CryptoSlate and Cointelegraph.

That path matters for the response-window question because the fraudulent transfers were signed by Bitget’s own wallets and resembled normal withdrawals closely enough to clear its infrastructure, per CryptoSlate’s reporting on Hypernative’s findings. A compromised credential, not a broken signature scheme, is what let the attacker’s requests through after the system had already logged the 18:31 alert.

The Controls That Weren’t Triggered

Hypernative identified several checks that, if active, could have interrupted the attack once the first alert fired. One would have required every signed transfer to match an independently stored withdrawal or treasury record, which could have stopped a compromised backend from generating its own authorization. Another involved comparing transaction parameters, including gas limits, against Bitget’s normal withdrawal pipeline; the attacker’s 18:31 test transaction reportedly carried parameters that diverged from that baseline.

Velocity limits are the most concrete gap. Hypernative noted that warm wallets moved $202.8 million across five networks within nine seconds at 19:16, a pace that caps on transfer volume per time window, paired with secondary approval requirements, could have slowed or blocked. Hypernative said the most direct fix would have been automatic suspension of the affected signer once anomalous-transfer alerts fired, rather than relying on manual response, which is what CryptoSlate frames as the unresolved issue in Bitget’s account.

Bitget has since said the underlying vulnerability was remediated and that no unauthorized transfers occurred after containment. The company told Cointelegraph it has since restricted internal access, added independent verification for withdrawals, and increased monitoring for unusual activity. Mandiant and SlowMist remain involved in the forensic investigation, per both CryptoSlate and Cointelegraph.

Broader Attribution and Fund Response

Separate from the response-window question, Bitget has raised the possibility that North Korean state-backed hackers were behind the intrusion, citing IP addresses linked to VPN infrastructure the group has used before, according to LavX News. Chen told Cointelegraph those indicators are still being assessed and were only preliminary. LavX reported the stolen assets included Ether, XRP, USDT, USDC, Avalanche, BNB and tokenized gold, moved across Ethereum, the XRP Ledger, Avalanche, BNB Smart Chain and Arbitrum, with stablecoins converted to Ether through decentralized exchanges within minutes to avoid issuer freezes.

Bitget’s loss estimate moved from an initial $351.6 million to $387.5 million after further audits, LavX reported, and the exchange says its User Protection Fund, cited at more than $464 million, will cover the shortfall.

What to Watch

Bitget has begun a staged withdrawal restart across affected chains that started Sept. 28, and the outcome of the Mandiant and SlowMist forensic review, along with any confirmed North Korea attribution, will determine what Bitget discloses about why its compromised signing route stayed active for nearly three hours after its systems first flagged the intrusion.

Sources