Bitget Hack Drains $387.5 Million Through Spoofed Transfers

Cryptocurrency exchange Bitget lost roughly $387.5 million to attackers who broke into a backend system in its wallet infrastructure. The Bitget hack began around 18:31 UTC on September 24, when monitoring flagged unauthorized transfers leaving a handful of hot and warm wallets. Seven blockchain networks lost funds, and the exchange froze all withdrawals within hours. Withdrawals have returned in stages since September 28, and Bitget says its protection fund covers the full loss.

What Happened During the Bitget Hack

Bitget's security systems caught the hack at 18:31 UTC on September 24 and traced the unauthorized transfers to a limited number of hot and warm wallets. The initial assessment put the affected amount at $351.6 million. Further on-chain tracing raised that figure to roughly $387.5 million the following day. The revision reflected a fuller picture of where the funds travelled, not a second intrusion.

The theft spanned Ethereum, the XRP Ledger, Arbitrum, Avalanche, Optimism, BSC, and Base. Stolen assets included ETH, XRP, BNB, AVAX, USDT, USDC, and a range of smaller tokens. The XRP Ledger carried the largest single-chain loss, with roughly 93.7 million XRP moved to a freshly created address.

Two things stayed out of reach during the Bitget hack. The exchange's cold wallets hold the overwhelming majority of platform assets, and none of them moved. The self-custodial Bitget Wallet also runs on infrastructure entirely separate from the exchange. Customer balances remained accurate throughout, and both deposits and trading kept running while withdrawals sat frozen.

How the Bitget Hack Turned the Exchange's Own Controls Against It

The mechanics here matter more than the dollar figure. Attackers did not steal private keys, break cryptographic signing, or drain a smart contract. They compromised a critical backend system inside the wallet service, spoofed transaction data, and let Bitget's own authorization-signing process approve the transfers. Every control in the chain performed exactly asdesigned.

The signing infrastructure received what looked like legitimate internal instructions, validated them against its rules, and signed. Multi-signature schemes, hardware security modules, and the separation of hot and cold storage all defend against an attacker holding a stolen key. None of them help once the system deciding what gets signed already answers to someone else.

How the attackers reached that backend system remains undisclosed. Bitget says the intrusion method is still under active investigation, and the company has since patched the vulnerability involved. That gap is the most significant open question left by the Bitget hack. The initial access route determines what other exchanges running comparable architecture should be checking right now.

The North Korean Attribution

CEO Gracy Chen attributed the attack to North Korean operators, citing IP behaviour patterns and on-chain analysis consistent with known DPRK activity. No government agency has confirmed that assessment. Exchange-side attribution arrives fast and often proves accurate, but it carries less weight than a formal finding from law enforcement. For now the link reads as a working assessment rather than a settled fact.

The wider record supports the direction of travel. North Korean groups took $1.5 billion from Bybit's Ethereum cold wallet in February 2025, an operation the FBI later attributed to Lazarus. That attack compromised a software provider rather than the exchange itself. Blockchain analytics published in early 2025 placed total DPRK crypto theft above $6 billion since 2017, including 47 separate heists worth $1.34 billion across 2024 alone.

What connects those operations is method rather than victim profile. These groups have moved away from attacking cryptography and toward compromising the people, vendors, and internal systems sitting upstream of any signing decision. The Bitget hack follows that template closely, and the Bybit precedent shows how far upstream these operators will go.

Withdrawals, the Protection Fund, and Recovery Efforts

The Bitget hack forced a platform-wide withdrawal freeze on September 24, though deposits and trading stayed online throughout. Bitcoin withdrawals returned at 08:00 UTC on September 28. ETH across Ethereum, BSC, Arbitrum, Base, and Optimism follows on September 29, with USDT on September 30. Remaining tokens, fiat, and P2P assets resume from October 2.

The company's User Protection Fund holds 5,500 BTC, worth roughly $464 million at current prices. That covers the full loss with about $77 million to spare. Bitget has stated consistently that the withdrawal pause reflected a security review rather than any shortfall in assets. The distinction matters in a sector where frozen withdrawals have historically signalled insolvency rather than caution.

Investigators from Mandiant and SlowMist are working the incident alongside law enforcement and on-chain security firms. Several chains have frozen wallet addresses tied to the attacker. Bitget also launched a Recovery Bounty Program paying 5% of any funds recovered or frozen with outside help. The structure pulls independent blockchain analysts into the tracing effort.

What Exchange Operators Should Take From This

The uncomfortable lesson in the Bitget hack is that key custody was never the weak point. An exchange can hold its keys correctly, split signing authority across several parties, and keep the bulk of reserves offline. It can still lose hundreds of millions because the system generating transfer requests answered to someone else.

That shifts where defensive attention belongs for any platform running comparable infrastructure. Internal wallet-service software sits between a withdrawal request and a signature, and that orchestration layer needs the same monitoring intensity applied to key material itself. Independent validation of transfer instructions against expected behaviour helps, and so does hard segmentation between backend services and signing systems. Anomaly detection tuned to destination and volume, rather than authorization status alone, addresses this specific class of attack.

For users, the takeaway runs narrower but no less practical. Protection funds work when they are real, liquid, and large enough, and this one covered the event as intended. But funds held on any exchange stay exposed to that exchange's internal security. That remains a reasonable argument for self-custody of balances that do not need to sit on a trading platform.