Bitget hackers sat inside its security tools for 25 days before stealing $387.5 million

Hackers who stole $387.5 million from Bitget got in through two third-party security products, with the earliest activity traced to August 31, 25 days before the theft, according to forensic reports from Google Cloud’s Mandiant and blockchain security firm SlowMist.

The Bitget hack was far deeper than a conventional private-key theft. The attackers reached the exchange’s production wallet infrastructure and used customized tools to generate fraudulent withdrawal instructions.

Neither Bitget nor the investigators has named the affected vendors, which raises a wider question: whether the same products, and the same vulnerability, are running at other exchanges, custodians or financial institutions.

Attackers compromised the systems protecting Bitget

Bitget first detected unauthorized transfers from parts of its hot and warm wallet infrastructure at 18:31 UTC on September 24. It initially estimated losses at $351.6 million, then raised the confirmed figure to about $387.5 million after accounting for additional assets on Zcash and Tron.

The new reports show that September 24 was only the final stage of a much longer attack.

Mandiant said an attacker obtained unauthorized privileged access to two third-party security appliances, identified only as appliances A and B. The attacker installed a web shell on appliance B and set up a command-and-control connection. From there, Mandiant said, the intruder moved laterally into Bitget’s production wallet job server and deployed malicious software packages.

Bitget says there is no evidence the private keys controlling its wallets were stolen, and its cold wallets were unaffected. The evidence instead indicates the attacker compromised the infrastructure around the wallet system and caused legitimate signing infrastructure to process unauthorized instructions.

SlowMist traces first malicious activity to August 31

SlowMist’s interim findings push the timeline back further. The firm traced the earliest malicious activity visible in the available logs to August 31, about 25 days before the theft.

According to SlowMist, a service on one node of an unnamed third-party system it calls “Product A” was hit by a zero-day vulnerability. The attacker allegedly ran a hidden script through the service process, retrieved a database password from an environment variable and connected to the database. Similar activity later appeared on two more Product A nodes, on September 23 and September 25.

SlowMist then found activity involving a second system, “Product B.” The attacker allegedly entered Product B’s management platform using an internal employee identity, then tried to inject system commands into task parameters, change server configurations and deploy malicious components.

It remains unclear how the attacker obtained that employee identity, or whether the Product A compromise directly enabled access to Product B. SlowMist said this part of the lateral-movement chain is still under investigation.

A custom tool was built for Bitget’s withdrawal system

Investigators also recovered a deleted program from the compromised environment. SlowMist describes it as a highly customized withdrawal tool built around Bitget’s wallet withdrawal logic. It was allegedly capable of falsifying risk-control parameters, constructing withdrawal requests and triggering Bitget’s normal withdrawal process.

That helps explain how hundreds of millions of dollars moved even though the private keys were not compromised. Rather than stealing keys and signing transactions independently, the attacker appears to have manipulated the trusted systems that tell the wallet infrastructure what to sign.

The distinction could matter for how exchanges design supposedly independent security layers around hot and warm wallets.

Transfers continued for hours after detection

Bitget says its reconciliation system flagged a significant discrepancy at 19:05 UTC on September 24, triggering an automatic platform-wide withdrawal block. Emergency response procedures began minutes later.

Mandiant found, however, that unauthorized Ethereum transfers continued alongside legitimate internal wallet operations until about 21:23 UTC on September 24 (05:23 UTC+8 on September 25). Bitget says signing and wallet withdrawal services were not fully shut down until 21:44 UTC.

Blocking customer withdrawals therefore did not immediately close the attacker’s route into the internal wallet-processing system. That leaves a second unanswered question: why the exchange could stop ordinary users from withdrawing while fraudulent instructions were apparently still reaching its signing infrastructure.

Bitget says users will not bear the loss

Bitget maintains that customer account balances were unaffected and that the platform will absorb the loss. On September 30, it said it had replenished its Protection Fund to more than $300 million, after deploying the fund following the breach.

BTC, ETH and USDT withdrawals have been restored in phases. Bitget’s published schedule calls for the remaining supported tokens, fiat withdrawals and P2P services to resume at 08:00 UTC on October 2. Asset tracing and recovery efforts are continuing.

The biggest unanswered question is outside Bitget

The most consequential missing information may be the names of Product A and Product B. If Product A was breached through a genuine zero-day, other organizations running it could have been exposed before the weakness was identified and patched.

Neither SlowMist nor Mandiant has disclosed the vendors, the affected software versions or a CVE identifier, and there is no public confirmation that another company was compromised through the same weakness. Until the vendors are named, exchanges and other institutions cannot tell from the public reports whether they use the affected products.

The Bitget breach may therefore point to a broader weakness in crypto security architecture: an exchange can protect its private keys and still be vulnerable if attackers compromise the systems authorized to tell those keys what to sign.