Bitget $387.5M Hack Review: Entry Through a Security Product

In the early hours of September 25, roughly $387.5 million was moved out of Bitget's hot and warm wallets in under three hours.

According to Bitget's statement and the interim findings from SlowMist and Mandiant, no private keys were leaked, the cold wallets were untouched and no on-chain contract was breached. The attackers first compromised a third-party security product, then used an employee's identity to reach the wallet servers, and from there wrote forged withdrawal instructions directly into the wallet system.

Bitget says the losses are covered by its protection fund and user assets are unaffected. Below is the attack path in chronological order, followed by a checklist smaller teams can work through right away.

1. Timeline

August 31: first malicious activity

Exploiting a zero-day in a service running on one node of third-party Product A, the attackers ran a hidden script, read the database password from environment variables and connected to the database.

September 23 and 25: spreading

The same script appeared on two more nodes. More than three weeks passed between the initial intrusion and the theft.

Early September 25: a borrowed identity, then the wallet servers

Posing as an internal employee, the attackers logged in to the management console of third-party Product B and used its task-dispatch and code-execution features to run commands on managed devices. Mandiant found that they planted a web shell on a Product B appliance, set up a remote-control channel, moved from there into the production wallet task servers and deployed malware.

01:49, September 25: a custom withdrawal tool starts running

SlowMist recovered the tool from deleted files. It had been written specifically around the withdrawal logic of Bitget's wallet system.

02:31, September 25: transfers begin

Two small test transfers below the risk-control threshold came first. About half an hour later, large transfers began across multiple chains and continued for roughly 2 hours 52 minutes. The forged instructions executed before any withdrawal record was created, so the risk-control check was bypassed entirely.

Afterwards: covering tracks

The attackers deleted traces of the forged instructions, tried to tamper with withdrawal records and attempted further BTC withdrawals.

Timings follow SlowMist's report. Bitget and several on-chain analytics firms link the attack to North Korean threat actors; there is no formal attribution yet.

2. Five things worth noting

1. The entry point was a security product

Companies buy security products to defend themselves, but these products usually sit inside the core network with broad privileges. A single zero-day turns them into a ready-made, high-privilege foothold.

2. The borrowed identity was genuine

In Bitget's words, the impersonated identity credentials were real and valid. To the system it looked like an ordinary employee login. A password plus a second factor alone cannot stop this kind of attack.

3. A console that can dispatch tasks is a master key to your servers

Product B's console could push tasks and execute code on devices, and that is the path the attackers took all the way to the wallet servers.

4. Risk controls only watched withdrawal records

The instructions ran before any record existed, so the risk-control step was never triggered.

5. More than three weeks of dwell time

The attackers were in by August 31 and struck on September 25. Catching any single anomaly in between could have changed the outcome.

3. Five checks smaller teams can run now

1. List every system that can run commands on your servers

Bastion hosts, ops platforms, automated release pipelines, and the admin consoles of EDR and other security products. For each one, confirm who can log in, from where, and what they can do to which machines.

2. Keep these consoles off the public internet

Put them behind zero trust: access only from company-managed devices, granted per identity, with every action logged.

3. Vet security products like any other vendor

Ask the same questions you would of any third-party software: are its privileges excessive, can you cut it off immediately if the vendor is compromised, and are its logs kept somewhere independent?

4. Verify withdrawals independently of the business system

Before signing, check the transaction that will actually go on-chain against the internal approval record, line by line. If they do not match, do not sign.

5. Watch for things that should not be there

New scripts on servers, unfamiliar database connections, late-night logins to admin consoles. The attackers spent more than three weeks inside the network, and each of these signals was a chance to catch them early.

Closing thoughts

In this incident the private keys, cold wallets and contracts all held up, and the money still left. For most smaller teams the real risk is likewise off-chain: employee laptops, ops platforms, third-party software and signing flows.

Sources

First published on X · Oct 19, 2026: View the original post on X ↗

Bitget's $387.5M Hack: The Attackers Came In Through a Security Product