Bitget Attacker used Small Test Transfers before $388M Theft

Two small transfers gave the attacker a quiet way to test Bitget's risk controls. About 30 minutes later, the exchange began processing much larger withdrawals, according to Bitget CEO Gracy Chen.

The sequence comes from Chen's account to The Block. Bitget has not yet published its formal incident report, so the timings and attack details remain based on the CEO's interview.

Two small transfers drew no alerts

The first unauthorized transfers occurred at 6:31 p.m. UTC on Sept. 24. They included 0.184 ETH from an Ethereum hot wallet and 193 TRX from a Tron hot wallet.

Both transfers were below Bitget's risk-control threshold, which means they didn't trigger an alert. Chen didn't disclose the threshold itself, so the size of the test payments can't be compared with Bitget's wider withdrawal limits.

That is the useful design flaw in the claimed sequence. A transfer control that only reacts to unusually large payments may pass a smaller one without noticing whether the request belongs to a legitimate session. The verified reporting doesn't show whether Bitget normally uses session checks, address controls or other rules that the test transfers bypassed.

Larger withdrawals followed within 30 minutes

At 6:58 p.m., the larger transfers began. Between 6:58 p.m. and 8:09 p.m., the attacker sent 17 transactions across Ethereum, XRP, Zcash, BNB Chain, Base, Arbitrum, Optimism and Avalanche.

Those transactions totalled about $361 million. Bitget later revised its total loss to $387.5 million, or roughly $388 million, after including additional transfers on Zcash and Tron. The reporting reviewed doesn't itemize the roughly $27 million difference between the two figures.

Chen said the attacker had already reached Bitget's internal management system by exploiting a zero-day vulnerability in a third-party security product. Fraudulent withdrawal commands were inserted directly into wallet-related backend systems, which treated them as legitimate.

The attacker also deleted traces left by those commands. Chen described that as the trickiest part of the incident, a revealing word choice. The first transfers checked the control system. The later activity then worked to erase evidence of how it had been reached.

Detection came after the large transfers began

Bitget's reconciliation system found a significant discrepancy at 7:05 p.m., seven minutes after the first large transfer. Its risk system then blocked withdrawals across the platform.

That response stopped the platform from processing user-initiated withdrawals, but it couldn't reverse the unauthorized transactions that had already passed through the wallet backend. The distinction matters. Detection worked once the discrepancy became large enough. The small test transfers hadn't crossed that line.

Part of Bitget's hot and warm wallet infrastructure was compromised. Its cold wallets and private keys weren't, according to the exchange. The stolen funds may therefore have been accessible through the transaction layer without giving the attacker direct control of the assets held in cold storage.

Cold storage protected those balances, but it didn't prevent commands from moving funds out of the exposed infrastructure.

The evidence gap is still important

A fast response is useful, but detection seven minutes into a large transfer leaves little room for error. It also doesn't answer the harder question: why did two small, unauthorized transfers pass without an alert?

Bitget says it has introduced stricter assessment criteria for third-party products, stronger deployment controls and independent verification for withdrawals. Those changes address how fraudulent commands may have entered the system. They may also reduce the chance that a weak signal will pass again, though the company hasn't explained the exact thresholds or rules involved.

There's a limit to what can be concluded before the formal report arrives. The test-transfer sequence, the zero-day claim and the detailed timeline all come from Chen. No independent report reviewed for this article had confirmed them.

Users resumed withdrawals by asset

Bitget reopened Bitcoin withdrawals first. Its CEO said Bitcoin returned because that pipeline was the first to be completed. The exchange processed more than 3,000 BTC in the first hour.

By 09:00 p.m. UTC on Sept. 28, 9,585 users had initiated withdrawals worth about 4,098 BTC since the resumption. The schedule applied equally to institutions, VIP customers and employees, according to Chen.

Ethereum withdrawals were scheduled for Sept. 29 across Ethereum, BNB Smart Chain, Arbitrum, Base and Optimism. USDT withdrawals were set for Sept. 30 across Ethereum, BNB Smart Chain, Solana and Tron.

Bitget's user protection fund was worth $465 million on Sept. 25. It will absorb the loss, and Chen said the fund will be replenished to at least $300 million within a week from corporate reserves.

The fund offers a financial cushion, not an explanation for the attack. Earlier reporting from Altcoin Buzz tracked the incident when Bitget's reported exposure was lower.

There's also no verified evidence that the theft has changed liquidity or prices for XRP or the other affected assets. Our follow-up on the attacker-linked XRP likewise found no confirmed sale.

For now, the strongest conclusion is narrow but important. Bitget's systems detected the large discrepancy within minutes, yet the attacker had apparently found a gap that let small transfers pass first. The pending incident report needs to explain that gap, including the missing threshold and the exact controls attached to third-party credentials, before readers can judge how much the security changes will reduce the risk.