The CryptoBilis Drain: Anatomy of a Hardware-Wallet Supply-Chain Attack

On October 9, 2026, hundreds of crypto wallets were emptied in a campaign whose defining feature was that the victims had done nothing obviously wrong. They had bought a hardware wallet — the tool whose entire purpose is to keep keys out of reach — and the device itself had been compromised before it reached them. The episode is worth a full report not because of its size, but because of where it locates the failure: one step upstream of the user, in a reseller supply chain that no claimant inspects and that no exchange or airdrop guide covers. What follows is the dated record as of publication, with every figure attributed and every gap left unfilled.

Incident summary

Two headline figures are in circulation and they measure different things. The $86 million figure is an analyst's floor, from ten public theft addresses identified by Specter. The $93.2 million figure is Bitquery's count of money actually leaving victim wallets, excluding internal transfers between the attacker's own addresses. Neither is wrong; they are different scopes, and — as with the unlock figures elsewhere this week — we print both rather than average them.

What happened, on-chain

Bitquery's reconstruction gives the campaign an unusual degree of structure. The main wave began at 05:07 UTC on October 9, when dozens of wallets on TRON, BNB Chain, Polygon and Ethereum signed the same approval within seconds of one another. At 05:54 UTC, 111 Bitcoin wallets were emptied in a single block. Further wallets were drained through the day, the last at 16:37 UTC. That pattern — many wallets, identical action, tightly clustered in time — is the signature of a single operator holding many keys, not of hundreds of independent phishing incidents.

The TRON concentration is the detail most relevant to this site's readers. About three-quarters of the loss was USDT on TRON — the same rail most airdrop claimants use to move stablecoin value, and the chain on which a claimed token is most often converted. A compromise that targets TRON USDT balances is, in effect, a compromise that targets the on-ramp and off-ramp of the airdrop farming workflow.

The two-week preparation

The drain was not improvised. Bitquery found that the attacker's control addresses on TRON and Ethereum were funded on September 25 and ran roughly twenty test cycles each over the following two weeks: send a wallet a few dollars and some gas, have it approve, pull the money back. The last two test cycles ran twenty-three seconds apart on October 7 — two days before the full drain. On TRON, thirty of the victim wallets had a new key added to their permissions minutes before the drain executed.

The test cycles are the most instructive part of the record. Twenty rehearsals per address over two weeks is expensive in time and attention, and it suggests the operator was not exploiting a single bug but validating a prepared capability across many wallets at once — the signature of a supply-chain compromise, where the attacker already holds the keys and simply stages the extraction. The permission-key additions on TRON are consistent with that reading: they happen minutes before the drain, giving victims no window to notice.

Read the economics and the picture sharpens further. The attacker funded the control addresses on September 25 and spent two weeks sending small amounts and pulling them back — a pattern that costs little in absolute terms but requires persistence and, crucially, requires the attacker to already possess the addresses' keys. Test cycles are only useful if you can sign from the target wallet; if the operator could not, the rehearsal would prove nothing. So the two-week run-up is not evidence of the exploit being discovered over time. It is evidence of an exploit that was already complete and being drip-tested for reliability, which is the opposite of how a contract bug is usually exploited — quickly, opportunistically, and in a single transaction.

That distinction has a practical consequence for how a holder should think about prevention. Against a contract bug, the defence is code review and time; against a prepared supply-chain capability, the defence is provenance — knowing where the device came from and refusing the ones you cannot verify. The two defences do not overlap, and the second is the one almost no airdrop guide mentions, because until this week the threat it addresses was largely theoretical for retail claimants.

The response, dated

The freeze-and-trace sequence deserves emphasis because it shows both the reach and the limit of centralised recovery. Tether's ~$10 million freeze worked because USDT is issuer-controlled and the issuer can block addresses at will. The attacker's response — swapping some funds into USDD, a stablecoin Tether does not control — worked because a freeze only reaches the assets its issuer holds power over. The money then moved toward exchange deposit addresses, which is the point at which recovery stops being technical and becomes a matter of a centralised exchange identifying the account behind an address and law enforcement acting on it. The complication Bitquery flags is real: if the intermediary wallets also serve uninvolved customers, any freeze risks catching the wrong people.

Reading Ledger's 90-day advisory

Buried in the day-one guidance is the detail carrying the most operational weight: buyers from the previous 90 days were told not to set up their devices, and those who already had were told to move assets to a new device with a new recovery phrase. That one instruction reframes the incident from a forensic question into a user-action question, and its scope is wider than the 315-wallet count suggests.

A 90-day window is a statement about inventory, not about victims. It implies the reseller's stock could have been compromised at any point in the recent past, so the set of at-risk devices is defined by when they were sold rather than by whether they have been swept. Most of those buyers will never appear in a loss figure, because a device not yet funded with meaningful value has nothing to drain. The visible victim count is therefore a floor on the exposure and a poor proxy for it: it counts the wallets that happened to hold value on October 9, not the devices whose integrity is in question.

The recommended remedy carries its own cost, and the cost is why the count matters. Migrating to a new device and a new recovery phrase means re-deriving every address, moving every balance and, for anyone running claims, re-registering the new addresses wherever eligibility is tracked. For a single holder that is an afternoon; for a claimant juggling several campaigns it is a coordination problem, because an airdrop snapshotted to an old address does not follow the assets to the new one. That is the practical reason the advisory matters even to readers whose device was bought elsewhere: the fix for a compromised signer is disruptive enough that it is worth confirming provenance before, not after.

How the money moved after the drain

Tracing the outflow is where the case stops being a story about one reseller and becomes a story about how recovery actually works. Three movements are documented in the days after October 9, and each one narrows the options left to the victims.

The sequence is instructive precisely because of how each step limits the next. The freeze worked only on USDT, because USDT is the asset an issuer can block at will. The attacker's counter-move — swapping part of the haul into USDD, a stablecoin outside Tether's control — is the predictable response, and it converts an asset a third party can reach into one only the market can price. From there the funds move toward exchange deposit addresses, which is where a technical trail becomes an account-based one: a deposit address is only useful to investigators if the exchange behind it can name the customer, and only recoverable if law enforcement can act on that name quickly enough.

Read as a whole, the trail covers a small fraction of the loss in concrete terms — roughly $10 million frozen and $3.89 million traced, against a reported $86–93.2 million. That is not a criticism of the responders; it is the arithmetic of a drain designed, from the two-week rehearsal onward, to be spent before it could be stopped. The lesson for anyone holding stablecoin balances is the reverse of comforting: the assets most recoverable after a theft are also the ones an attacker knows to move first, which is why the freeze lands early and the trace lands late.

Where the failure sits in the custody stack

Read against the way most holders think about self-custody, this drain fails at the one layer normally assumed to be safe. The standard model of custody risk has three layers: the key (does anyone else know it?), the signing environment (is the device that holds it trustworthy?), and the transaction (what is the wallet actually approving?). Hardware wallets exist to collapse the first two layers into a single guarantee — that the key never leaves the chip and the chip signs only what its owner confirms. This drain breaches that chain before the device ever reaches the buyer, which means the guarantee is void at the moment of purchase, not at the moment of use.

Seen this way, the drain is not a break in the cryptography — it is a break in provenance. The two halves of that reading matter differently. The reassuring half is that Ledger's own systems and direct sales channels were reportedly unaffected, which concentrates the fault in a distribution step a buyer can, in principle, route around. The troubling half is that the victim's recourse depends entirely on where the device was bought — a distinction almost no airdrop guide mentions, because until this week the threat it addresses was largely theoretical for retail claimants.

A second structural point follows from the table. Three of the four layers are things a holder can act on — generate fresh keys, verify the screen, check the seller. Only the fourth, recovery, sits outside the holder's hands, and it is also the weakest: a freeze reached roughly a tenth of the loss and, in the same move, taught the attacker which assets to swap out of. The practical weight of that asymmetry is that a buyer's leverage is almost entirely upstream of a loss — in procurement and key hygiene — while the tools available afterwards are thin, slow and dependent on third parties. That is the reverse of how most security advice is ordered, and it is the single most transferable point in this case.

What this means for airdrop claimants

Three practical readings. First, custody hygiene now includes provenance: buying a hardware wallet through an unverified reseller introduces a risk that no amount of careful signing behaviour addresses, because the tampering happens before the buyer touches the device. Second, the recovery asymmetry is the one the rest of this week's news keeps repeating — the attacker needed two weeks of preparation and a supply chain, while the defender needed only to buy from a different seller. Third, the asset mix matters: this loss fell on TRON USDT, which is where a great deal of claimed value is parked and moved, so the operational lesson lands directly on claimants who hold stablecoins between claims.

What we cannot say from the public record: how the devices were altered, by whom, or how many are affected. Ledger's 72-hour update says the number is limited and all confirmed cases trace to CryptoBilis; it has not published a root-cause report. Until it does, the honest position is the one the data supports — a coordinated, well-prepared drain concentrated in one reseller's devices, with a large portion of the loss appearing as TRON USDT, and a partial freeze and trace in progress.

Turned into a procedure, the case suggests a short checklist that costs nothing to run. Verify the seller before the device, not after: buy direct or from a reseller the manufacturer openly lists, and treat an unusually cheap unit on a marketplace as a provenance question rather than a bargain. Generate the seed on the device itself and never accept a pre-filled recovery phrase — a device that arrives pre-initialised is the clearest warning sign this case produced. Keep large stablecoin balances out of a single always-on wallet, so that one compromised key cannot reach the whole position. And assume the recovery tools are thin: a freeze that reached about a tenth of the loss cannot be the plan, so the realistic defence sits upstream of the event rather than after it.

None of that is exotic, and that is the point. The drain did not defeat a careful operator through cleverness; it defeated the assumption that "hardware wallet" and "safe" are the same word regardless of where the hardware came from. For a claimant who holds tokens between an airdrop and a sale, that assumption is load-bearing — and this week it was the assumption, not the device's cryptography, that failed.

What to watch next

Three things would change this report's conclusions. First, a Ledger root-cause report: if it establishes how the devices were altered and where in the supply chain it happened, the story moves from "a reseller problem" to a named process failure with a fixable step. Second, movement of the 203.8 BTC identified in the trace: the funds sitting in the flagged Bitcoin address have not moved as of the reporting, and any transfer would either signal a cash-out attempt or a further laundering stage. Third, whether the Binance deposit addresses resolve to identified accounts. That is the single thread most likely to convert a partial freeze into a recovery, and the single thread most complicated by the intermediary wallets that also served uninvolved customers.

A fourth item is quieter but more consequential for this site's readers. If buyers respond by migrating to new devices and new seeds, the drain will have produced a measurable shift in custody behaviour — and if they do not, it will confirm the more uncomfortable reading, which is that the failure was attributed to one reseller and filed away. The distinction between those two outcomes is the difference between a security event that changed habits and one that only changed headlines, and it will be visible in wallet-migration activity long before any root-cause report arrives.

Sources

FAQ

Related Reading

• Token Airdrop Weekly News Review — October 5 – 11, 2026
• NEAR's $3.8M Week: An ETF Debut, an Exploit, and a Full Recovery
• Token Airdrop Weekly Intelligence — October 5 – 11, 2026
• ARC Goes Live With No Token: The Counter-Example to CNPY