Bitget hack: analysis of the attack and exploited flaws

A first trace, twenty-four days before the flight. Cybersecurity company SlowMist dates the oldest malicious activity found in systems linked to the Bitget hack to August 31. The fraudulent transfers, detected on September 24 in universal time, then took away nearly $387.5 million.

The investigation describes an attack carried out through two third-party security products and a server linked to the wallet management application. However, it does not yet make it possible to reconstruct all the movements of the attacker between these different components.

Key Points

SlowMist dates the intrusion to August 31, almost a month before the fraudulent transfers spotted on September 24

A flaw unknown to the publisher, with no patch available, served as a gateway for attackers

The siphoning of warm wallets places the compromise at the level of internal validation procedures

Bitget's protection fund, endowed with 300 million dollars at its creation, remains less than the stolen sum

Bitget hack: a zero-day and several compromised systems

According to the SlowMist investigation report, the first trace goes back to a service installed on a node of a security product called “Product A”. The attacker exploited a zero-day flaw, that is to say a vulnerability which did not yet have a patch available at the time of its exploitation.

A script hidden in the service's process allowed it to read an environment variable containing the database password and then connect to it. SlowMist found comparable activity on two other nodes on September 23 and 25.

During the night of September 24 to 25, the attacker also accessed the administration platform of a second security product using the identity of an employee. He then attempted to inject commands, modify the configuration of the servers and deposit several malicious files there.

The main tool recovered had been deleted by the attacker. Designed specifically for Bitget's withdrawal system, it could falsify control parameters, construct fraudulent requests, and directly call the process responsible for executing them.

The program began operating at 1:49 a.m. on September 25, according to the UTC+8 time used in the report. The first confirmed outflow on the blockchain occurred at 2:31 a.m., with 93 TRX, followed eleven seconds later by 0.84 ETH. Transfers continued for approximately two hours and fifty-two minutes across multiple networks.

Falsified withdrawals without theft of private keys

The investigation therefore locates the weakness in the infrastructure responsible for preparing and controlling withdrawals. The attacker would not have needed to directly seize the private keys: his tool transmitted fraudulent orders presented as valid to the system.

After the transfers began, he also attempted to modify the database records directly. Two fake bitcoin withdrawals were processed before failing. The logs then show views of their status and retries.

According to Bitget, the incident affected some of its hot and warm wallets, while its cold wallets remained intact. This distinction comes from the platform itself, SlowMist speaking more broadly of a theft from hot wallets. The investigation does not establish that a human signing procedure would have been directly compromised.

Bitget claims that its protection fund covered the entire loss. Created with a floor of $300 million, it held more than $464 million before the attack, more than the $387.5 million ultimately recorded. The platform also ensures that its customers' balances and its separate self-custody application are not affected.