Bitget $387.5M Crypto Theft: Zero-Day Security Appliance Breach and Wallet Server Lateral Movement

On September 30, Bitget published findings from two independent investigations. Blockchain security firm SlowMist and Google Cloud's cyber-defense arm Mandiant said the threat actors accessed Bitget's wallet environment after compromising two security appliances with zero-day exploits. Neither firm has named the vendors or products. SlowMist calls them "Product A" and "Product B." Those are investigator labels, and there is no public CVE, vendor advisory or list of affected versions to patch against yet.

This matters well beyond crypto. Firewalls, VPN concentrators, monitoring agents and other security appliances usually get deep network access and a lot of trust by default. Any enterprise running them should pay attention.

What the investigators found​

The two reports cover different time windows, and together they show the attackers were inside for weeks before the theft.

SlowMist's interim report goes back the furthest. As of September 29, the investigation found malicious activity involving a specific third-party security product and the wallet application host, as well as a highly customized withdrawal tool used by the attacker. The key findings:

• August 31: The earliest malicious activity identified in the available logs dates to August 31. A service running on one of Product A's nodes was affected by a zero-day vulnerability. The attacker ran a hidden script under the service process, launched a command to read the environment variable containing the database password, and connected to the database.
• September 23 and 25: Similar hidden-script activity was observed on two other nodes, according to SlowMist.
• Theft night: According to Bitcoin.com's UTC conversion of SlowMist's timeline, the attacker used an internal employee's identity at 16:07 UTC on September 24 to log into Product B's management platform and made three attempts in a row to inject system commands.

Mandiant's findings, released through Bitget, focus on the final stage: "on September 24, 2026, a threat actor gained unauthorised privileged access to Bitget's third party security appliances A and B. The threat actor deployed a web shell onto the security appliance B and established a Command-and-Control (C2) connection. Using the persistent access on security appliance B, the threat actor moved laterally to Bitget's production wallet job server and deployed malicious packages."

The two accounts don't conflict. Mandiant dates privileged appliance access to September 24. SlowMist's logs show earlier activity on Product A starting August 31. The likely reading is that the attackers had been in one environment for weeks and moved to the high-value targets on the night of the theft. The investigators have not resolved every step, though. Both firms said they are still mapping the exact path between systems.

Summary: A zero-day in an unnamed security product gave the attackers a foothold by August 31. A stolen employee identity, a web shell and lateral movement got them to the wallet servers on September 24.

How the theft worked, minute by minute​

The theft itself was quick, automated and planned in advance. SlowMist recovered, from deleted files, a custom tool that forged withdrawal parameters and called Bitget's withdrawal process. In UTC:

Time zones explain the date confusion in coverage. SlowMist logs in UTC+8, so the first transfer at 18:31 UTC on September 24 shows up in its report as 02:31 on September 25. Both dates refer to the same event. The 18:31 UTC start matches the minute Bitget first said its systems detected unauthorized transfers on September 24.

The attackers also tried to cover their tracks. The attacker also tried to modify withdrawal records directly in the wallet database and trigger additional Bitcoin withdrawals. SlowMist said two fabricated BTC withdrawal orders entered processing but returned errors, after which the attacker reviewed logs, checked order status and made further attempts.

The table shows the uncomfortable gap. Bitget's automated reconciliation caught the discrepancy about 34 minutes after the first transfer. Yet on-chain activity continued for roughly another two hours. The public record doesn't yet explain why. Bitget's own timeline says it began moving funds to cold wallets at 20:40 UTC, because it had not yet ruled out a private-key compromise, and shut down withdrawal and signing services at 21:44 UTC.

Keys weren't stolen. The approval process was tricked.​

Bitget says the attacker never had its keys. Its incident page says attackers may have exploited a vulnerability in a third-party security product to get high-level internal credentials, then sent fraudulent withdrawal commands that the wallet system executed, bypassing existing risk controls. According to Cos's summary of both reports, Mandiant found no evidence that Bitget's private keys were leaked and confirmed that cold wallets were not affected.

That is the main lesson here. The signing system did what it was built to do: sign requests that looked authorized. The compromise happened earlier in the chain, where requests are created and checked. Strong key storage doesn't help much if an attacker can make the system that decides what to sign trust forged data.

The damage, the refund promise and the reopening​

• Amount: In a Sept. 25 update, Bitget said about $387.5 million was transferred to attacker-controlled addresses across several networks. That revised an earlier estimate of $351.6 million. Bitget's later pages round the figure to about $388 million and say the change came from reclassifying transactions, not from a second theft.
• Scope: Bitget says 12 hot- and warm-wallet addresses were involved, across 11 blockchains including Ethereum, XRP Ledger, TRON, Zcash, Arbitrum, Base and Avalanche. It says cold wallets were untouched and that Bitget Wallet, its separate self-custody product, was not affected.
• Coverage: Bitget says its Protection Fund of more than $464 million covers the loss and that user balances are unaffected. These are the company's own statements, not independent audit findings.
• Withdrawals: BTC withdrawals resumed September 28 and ETH on September 29. USDT on Ethereum, BSC, Solana and Tron was scheduled for 08:00 UTC on September 30, and other tokens, fiat and P2P are scheduled for October 2. Deposits and trading stayed open throughout.
• Recovery: Bitget is offering a bounty of 5% of any funds frozen or recovered through eligible help and has published the attacker's addresses. According to Bitcoin.com, SlowMist's tracking has flagged laundering through CoW Protocol and Chainflip, and Near Intents froze part of one attempt.

Attribution: an allegation, not a verdict​

CEO Gracy Chen has publicly pointed to North Korea, citing IP behavior patterns and on-chain analysis. Tom's Hardware reported she linked suspicious IP addresses to VPN infrastructure previously used by North Korean groups. The comparison to the $1.5 billion Bybit theft, which the FBI attributed to North Korean hackers in February 2025, is an obvious one. Bitget's own updated explainer is more careful: it says the company will not speculate on attribution without verified findings. SlowMist has not yet disclosed the attacker's identity, nor announced the final scale of losses or the scope of affected systems. Until investigators formally say otherwise, treat the North Korea link as plausible but unproven.

What enterprise IT teams should take from this​

Without vendor names, there is nothing specific to patch. You can still check your environment against how this attack worked. The steps below are general industry practice, not Bitget's published remediation:

1. Map what your security appliances can reach. Can your monitoring, EDR, VPN or management appliances talk to production databases or payment and transaction servers? Mandiant's account depends on an appliance being a launch point for lateral movement.
2. Remove secrets from environment variables where you can. The first step SlowMist documented was reading a database password from a service's environment. Use a secrets vault with short-lived credentials instead.
3. Hunt for scripts running under appliance service processes and unexpected database connections from appliance nodes. Look back at least to late August, and further if your logs allow.
4. Watch management-console logins by employee accounts at odd hours or from unusual origins, and alert on command-execution features in those consoles.
5. Keep logs, and store them off the systems they describe. The attacker deleted files and tried to edit database records. Logs stored on a separate system with their timestamps kept consistent are what allowed SlowMist to reconstruct the timeline.
6. Add approval steps that don't depend on a single system being trustworthy. Bitget now requires multiple approvals for critical operations and has strengthened withdrawal verification. For any high-value workflow, such as payments, privileged changes or data exports, a single compromised backend should not be able to approve itself.
7. Treat reconciliation alerts as a trigger to stop activity. Bitget detected the problem at 19:05 UTC and transfers continued until 21:23. An alert only helps if something stops the activity quickly.

The bottom line​

Bitget's reported attack path went through tools meant to protect the network. It began with a zero-day in an unnamed security product on August 31 and ended with a forged-withdrawal tool that made the wallet system approve the theft. The reports are still interim: the vendors are unnamed, the route between systems isn't fully mapped, and attribution isn't confirmed. The practical takeaway already holds, though. Every security appliance with broad network access is a target in its own right, so audit it and segment it like any other critical system.