Beyond Key Security: Controlling How Funds Move

At 18:31 UTC on September 24, two small transfers left Bitget’s hot wallets: 0.184 ETH and 193 TRX. According to CEO Gracy Chen, both were below the exchange’s risk-control threshold and neither triggered an alert. Approximately 30 minutes later, the large transfers began. Bitget’s final figure is roughly US$388 million, all of it from hot and warm wallets.

No private key was stolen. Bitget says the attacker exploited a zero-day vulnerability in a third-party security product, reached its internal management systems, used high-privilege credentials to access wallet-related backend servers, and wrote forged withdrawal commands directly into the wallet system. Those commands bypassed risk-control checks and were processed as legitimate. Cold wallets were unaffected.

About two weeks later, Ledger began investigating hardware wallets sold through CryptoBilis, a Malaysia-based reseller. Some of the devices contained an implant that read the 24-word recovery phrase from the screen during setup and sent it out over a mobile network. The implant did not modify the Secure Element or the operating system, so Ledger’s standard integrity checks could not detect it. On-chain investigators estimate losses of US86 million to US93 million; Ledger has not confirmed a total and says its chip, operating system and servers were not compromised.

The two attacks had little in common technically. What they share is that neither one broke the cryptography protecting a key. The first bypassed the key by exploiting the process that instructs it what to sign. The second captured the key at the moment it was created.

For platforms that process large volumes of deposits and withdrawals, this raises a practical question:

If someone obtained valid internal credentials tomorrow and started submitting withdrawals that looked routine, what would stop them?

Each fund flow carries a different risk

On most of these platforms, the wallet is no longer a technical add-on. Deposits, withdrawals, treasury transfers, merchant settlement and cross-border payouts increasingly run through the same layer, which means it has to deliver security, speed, control and auditability together.

Those flows do not carry the same risk, and they should not share the same rules:

Pay-in: every deposit traced to a customer, credited after a set number of confirmations, screened, then swept to treasury under defined rules.
Pay-out: fast, predictable withdrawals within limits, whitelists and approval thresholds.
Treasury: operating funds kept separate from reserves, with a higher bar to move reserves.
Settlement: balances isolated by merchant or entity, with a record of who approved and who signed.

Pay-in carries a risk that is easy to overlook. A platform cannot refuse a deposit: once funds are sent to an assigned address, they arrive on-chain regardless of their source. Any platform that accepts deposits should therefore expect to receive high-risk funds at some point. The available control is segregation. A dedicated address per customer keeps each deposit traceable, and keeping flagged funds out of treasury sweeps prevents them from mixing with funds that belong to other customers.

Pay-out is where the theft risk concentrates. Users judge a platform by how quickly withdrawals arrive, so teams are pushed to automate. The withdrawal path is also the final step before funds leave the platform, which makes it a primary target for attackers. A single approval policy rarely fits both demands, and the gaps tend to appear exactly where speed has been prioritized over verification.

Where controls usually break

When we review how platforms run these flows, the same weaknesses come up repeatedly. Most of them have nothing to do with how the key is stored.

Single points of failure: one device, administrator or recovery phrase can control critical assets.
Insufficient segregation: customer funds, operating funds and merchant balances share the same wallets.
Manual withdrawal processing that cannot keep pace with volume.
Weak approval controls: sign-off through chat messages, informal approvals or shared credentials.
No real-time screening of where funds are going before they leave.
Limited audit evidence of who requested, approved, signed or rejected a transaction.
Heavy integration burden that keeps engineering teams maintaining blockchain infrastructure.
Weak recovery planning for the loss of a device, a key share, an employee or a provider.

Both incidents correspond directly to items on this list. A recovery phrase captured during device setup is a single point of failure. Forged commands injected into a backend, preceded by small test transfers that stayed under the alert threshold, touch approval controls, screening and audit evidence at once.

Multi-signature arrangements carry similar risks. In February 2025, Bybit lost about US$1.5 billion after attackers tampered with the signing interface its signers relied on; the signers approved a transaction that was not the one they believed they were approving.

Two layers, and why both matter

Digital asset security can be understood as two layers.

Asset security protects the key itself. With multi-party computation (MPC), signing authority is split into shares held by different parties, and the shares are never combined into a complete key on any server, laptop or provider. Sensitive key operations run inside hardware-isolated trusted execution environments (TEE). Key generation, backup and recovery are designed so that losing one device, one person or one provider does not mean losing access. This is the layer that addresses attacks like the recovery-phrase implant: when no single phrase or device can reconstruct the key, capturing one component is not enough to move funds.

Operational security governs who can move funds, and under what rules. It covers role-based permissions, approval policies evaluated on amount, asset, destination, initiator, timing and risk score, address whitelists and velocity limits, risk screening (KYT) before signing, independent verification of transaction details by each signer, and complete audit trails. This is the layer that addresses attacks like the forged withdrawal.

Where a control is enforced matters as much as whether it exists. If the rules that decide whether a withdrawal may be signed live in the same backend that issues withdrawal requests, an attacker who controls that backend can often bypass them. Rules enforced at the signing layer, by parties independent of the request system, give a forged request one more set of checks to pass.

Neither layer can make up for weaknesses in the other.

One withdrawal, seven controls

A well-controlled withdrawal typically passes through seven steps:

The customer requests a withdrawal.
The platform runs its own account checks: balance, account status, internal risk rules.
The destination address is screened for risk before any approval.
Policy determines the approval path. Small withdrawals to whitelisted addresses within limits can be signed automatically by a co-signing service; larger ones require additional approval; high-risk destinations are blocked.
Authorized approvers review the transaction, seeing the actual destination and amount rather than whatever the requesting system displays.
The required parties sign together. No single person, device or server can produce the signature.
The platform receives status updates, and every step is recorded for audit.

Around these steps sit standing controls: per-transaction and daily limits, whitelists, velocity limits, and an emergency pause.

The emergency pause requires particular attention. In the timeline Bitget’s CEO shared, the reconciliation system flagged a discrepancy at 19:05 UTC and the platform then blocked user-initiated withdrawals. The large transfers had started at 18:58 and continued until 20:09. We do not know the full internal sequence, and we are not concluding anyone’s response.

The general lesson for any platform is that a pause only helps if it acts on the path the attacker is actually using. A pause that stops customer requests at the front end has no effect on commands that never passed through the front end.

Five questions to test your controls

A practical starting point is your largest daily withdrawal flow. Test it against these five questions:

Is there any single device, person or recovery phrase that could move these funds alone?
Where are your approval rules enforced, and could someone with admin credentials on the request system change or bypass them?
Would a few small test withdrawals followed by a large one trigger an alert, and who would see it?
Can each signer verify the real destination and amount independently of the screen the request came from?
If you needed an emergency pause right now, would it stop every path to signing, or only customer requests?

A question that is difficult to answer usually points to the control that needs attention first. A sound next step is to list every flow of funds and every system that can initiate a transfer, then decide which rules should be enforced outside those systems.

Sources

[1] Bitget, Bitget Security Incident (September 2026): Hack Timeline, Impact, and Latest Official Updates, last updated Oct. 13, 2026
[2] The Block, Bitget attacker tested risk controls with small transfers before $388 million theft, CEO says, Sept. 28, 2026
[3] The Hacker News, Ledger Finds Unauthorized Hardware Implant in CryptoBilis-Sold Wallet Amid Fund Theft Reports, Oct. 2026; BleepingComputer, Ledger confirms spy chip implant behind wallet crypto thefts, Oct. 12, 2026
[4] Forbes, Ledger’s Spy-Chip Attack: What We Know So Far, Oct. 23, 2026
[5] BleepingComputer, Lazarus hacked Bybit via breached Safe{Wallet} developer machine, Feb. 2025