Bitget Lost $388 Million Through a Flaw in Its Own Security Product. The Attacker Tested Its Limits First, and No One Was Told

On 24 September, at 18:31 UTC, someone moved 0.184 ETH out of one Bitget hot wallet and 193 TRX out of another. Both transfers were tiny, and both stayed below the exchange's risk-control threshold, so no alert fired, according to CEO Gracy Chen.

About half an hour later the same access was used for 17 larger transactions across eight blockchains, between 18:58 and 20:09 UTC. The exchange puts the total stolen at roughly $388 million.

What Bitget has said so far

According to The Hacker News and The Block:

• The way in was a zero-day in a third-party security product that Bitget used. The attacker exploited it to obtain high-level internal credentials, not to break a wallet or steal a private key.
• Fraudulent withdrawal commands were injected into the wallet backend. They ran as valid administrative operations, so the wallet system carried them out and the risk controls were bypassed.
• The attacker deleted traces of those commands. Chen called this the trickiest part of the incident.
• Only hot and warm wallets were affected. Bitget says cold wallets were untouched and, on its investigation so far, no private keys were compromised.
• Detection came from reconciliation, about seven minutes after the first large transfer. Bitget then blocked withdrawals platform-wide.
• The loss is being covered by the exchange's user protection fund, which Bitget says will be replenished. Bitcoin withdrawals reopened on 28 September, with other assets to follow.
• Mandiant and SlowMist are assisting. A formal incident report is expected. Chen has suggested the same group may be behind a previous suspected North Korean incident, pending that report.

The vulnerability has been patched, and Bitget has revoked and reissued internal credentials. Some details, including the product's name, have not been made public. Treat the attribution as unconfirmed until the report is out.

The security tool was the way in

Security products sit in a privileged place. They see traffic, hold credentials and often have the access needed to change how other systems behave. That is what makes them useful, and it is also why a flaw in one is worth a lot to an attacker. We saw the same pattern two weeks ago when Check Point's management servers were open to attackers for two months.

Bitget did nothing unusual by running third-party security software. What matters is what the attacker got: valid credentials with administrative reach. From that point on there was no exploit to detect. Everything after it looked like an administrator using an administrative system.

The two lessons in the timeline

The probe was the only warning, and it fell below the line. The two test transfers were sized to sit under a static threshold. A fixed limit tells an attacker exactly how much they can move without being noticed, and a probe can find that limit for the price of a few dollars. The useful signal was not the size of the transfers. It was that an account that normally did not initiate withdrawals started doing so, in an unusual way, minutes before a burst of activity.

Deleting traces only works if the traces live somewhere the attacker can reach. If the only record of a fraudulent command is on the system that ran it, then an attacker with administrative access can remove it. Detection here came from reconciliation, meaning a comparison of what the ledger says with what the wallets did. That was the right instinct, and it took seven minutes. Comparing balances is a control that does not depend on the logs an attacker can edit.

What to check this week

1. Inventory your privileged security tooling. List every product that holds admin credentials or can push commands into critical systems: EDR consoles, PAM vaults, WAF and firewall managers, backup tools. For each, ask what happens if it is compromised.
2. Alert on behaviour as well as amounts. A first-time action by an account, a service identity issuing an operation it has never issued, or a burst of activity right after a quiet probe should all create an alert, whatever the size.
3. Reconcile the things that matter. Balances, permissions and configuration should be compared against an independent source on a schedule, not only when something looks wrong.
4. Keep an off-box copy of the logs. If a tool's own audit log is the only record, assume an attacker with admin access can change it.
5. Rotate credentials that the tool holds. After any incident involving a security product, treat every secret it stored as exposed, as Bitget did.

Where Obiguard SOC fits

Obiguard SOC is for teams that need the evidence and the alert to sit somewhere the compromised system can't reach. Two parts apply directly to this incident.

A copy of the logs that the attacker didn't write. SOC ingests logs from your applications, cloud and infrastructure into a separate store. If a wallet service, admin console or security appliance later has its own records edited, the forwarded copy still shows the commands that ran, with host, level and time. In Live Logs you can search across every source at once, so a question such as "which admin identity issued a withdrawal at 18:58?" has one place to be answered.

Alerts you can write for the sequence, not only the size. SOC raises alerts from log-volume changes and rule matches, and each alert keeps an evidence timeline linked to the raw events behind it. A rule that matches any withdrawal command issued by an admin identity, whatever the amount, would have flagged the two probes. A sudden jump in admin-service log volume would have flagged the burst. Neither depends on a threshold the attacker can measure.

SOC will not stop a zero-day in a vendor's product, and it does not replace the reconciliation controls that caught this theft. What it does is shorten the time between the first odd action and someone looking at it, and it gives your investigators a record they can trust when the attacker has tried to erase the rest.

The question to take away

Bitget noticed in seven minutes, which is faster than most organisations manage. But the attacker still had the time to make 17 transfers, because the first two, the ones that mattered, raised nothing.

So the question is not is our security vendor patched? It is: if one of our privileged tools were compromised tonight, would the first strange thing it did reach a person before the tenth?

Explore Obiguard SOC or talk to us about sending your admin, wallet and security-tool logs to an independent timeline with alerts on the actions that should never happen quietly.