Ledger CryptoBilis hack: an implant read recovery phrases off the screen and still passed Genuine Check — how a business that gets paid into its own wallet should hold crypto

What happened in the Ledger CryptoBilis hack, hour by hour

CryptoBilis sold Ledger hardware wallets in Indonesia, Malaysia and the Philippines and was listed as an authorized seller in those markets. On Friday, October 9, 2026, wallets set up on devices it had sold were drained in a coordinated sweep. Here's the timeline, in UTC, from Bitquery's on-chain investigation:

• September 25 to October 7: about two weeks of rehearsal. The attacker set up control addresses three minutes apart on September 25, then ran 21 small test loops on TRON and 20 on Ethereum.
• 04:59:57 to 05:00:00, October 9: 30 TRON wallets lose control to the attacker's key in three seconds.
• 05:07:48 to 05:07:54: 25 TRON wallets sign the same approval, and $29 million leaves in six seconds.
• 05:07:59 to 05:56: Ethereum, then Solana. At 05:54:20, 111 bitcoin wallets are emptied in a single block.
• 12:00: the first drain addresses are posted publicly. 12:09: Tether starts blacklisting. 13:32: Ledger says it is investigating and asks the reseller to stop all sales and shipments.

On October 10, Ledger confirmed that "one of the impacted users' devices contained an unauthorized hardware implant," as reported by CoinDesk. CryptoBilis suspended sales of its whole hardware wallet inventory. On October 11, Ledger said that all confirmed cases involve devices sold through CryptoBilis, that "the volume of impacted devices is limited," and that its own systems and direct sales channels weren't affected.

The loss figure is still moving. On October 12, trackers put it between $93.2 million and $94.5 million. Bitquery has since revised its count to $102.0 million after adding wallets on Solana, BNB Chain, Polygon and more TRON addresses. Ledger hasn't published a total, and on-chain counts measure wallets, not customers.

The per-chain wallet counts add up to more than 324, and that's the first lesson. One recovery phrase controls addresses on every chain. When the attacker had a seed, they had the victim's TRON, bitcoin and EVM balances at once.

Why Genuine Check passed: it verifies the chip, not the box

Ledger devices keep keys in a secure element, a tamper-resistant chip. Genuine Check is a cryptographic challenge that proves the chip was made and provisioned by Ledger. It does that job well. But Ledger's own threat model for device genuineness spells out the limit: "A Genuine check cannot detect unauthorized physical modifications to the hardware, such as spying implants, if the original Secure Element remains intact." The same page says the check "cannot verify the device's physical supply chain history."

The recovery phrase is generated inside the secure element, but it has to be shown on the screen so you can write it down. The screen sits outside the chip. Ledger hasn't published a technical description of the implant it found. Researchers who opened tampered devices bought through other channels describe a small circuit board hidden behind the screen, with a microcontroller, an LTE modem and an eSIM. It reads the words as they appear and sends them out over the mobile network, with no help from the owner's computer or Wi-Fi. A device like that has a genuine chip, produces a valid seed and passes every check. It just isn't the only thing that saw the seed.

Two practical consequences follow. First, setup is the most exposed moment in self-custody. A seed leaked at setup is leaked forever, however carefully the device is stored afterwards. Second, the standard advice wasn't enough here. Ledger's page says buying "directly from Ledger or Authorised Resellers is safer". CryptoBilis was an authorized reseller.

The attacker waited for the balances

The most useful detail for a business is about timing, not hardware. Ledger told customers who bought from CryptoBilis in the last 90 days to act. Bitquery found that about 6 in 10 drained wallets were first funded within that window, but more than 8 in 10 were first funded in June or later. One wallet was funded on September 15 and lost 7 million USDT. Another received 80 BTC on September 29 and was among the 111 bitcoin wallets emptied in one block ten days later.

We don't know who owned those wallets. But balances like that look more like a trading desk or a company treasury than personal savings. And the pattern is clear. The attacker collected seeds for months, rehearsed for two weeks, and drained most of it in under an hour. A compromised seed costs whatever sits on it on the day the attacker moves. Nobody knows when that day is, so the only things a business controls are how much sits there, and for how long.

That's the same balance-times-time logic we used for issuer freezes after the Conduit v. Tether lawsuit. Different threat, same lever.

Freezes recovered about a tenth

Tether started blacklisting nine minutes after the first public post and ended up freezing $10.0 million across 20 wallets. That's fast. It was also seven hours after the drain began. By then the attacker had swapped $23.7 million of USDT into USDD, which Tether can't freeze, bridged $20 million to Ethereum, and started routing ETH through Tornado Cash. Bitcoin can't be frozen by anyone. Bitquery also flagged about 2.38 million USDC in two wallets that Circle could freeze, but most of the stolen value was out of reach of any issuer.

Freezes cut both ways. On October 9 we wrote about a business whose USDT was frozen for over a year by mistake. Three days later, the same freeze power was the only thing that recovered any money. Neither case is something to plan around. Freezes are an issuer's decision, not your security model. If your plan depends on someone else freezing stolen funds in time, you don't have one.

Self-custody fails differently from custody, so design for it

This hack will be used as an argument against holding your own keys. It isn't one. Custodial failures in the last few months were about the custodian: the Bitget hack paused withdrawals for up to 7.5 days, and a stablecoin card issuer shut down overnight. A business can't fix a custodian's security or solvency. It can only hope.

Self-custody risk is different. It sits in things the business controls: which devices it buys, how many seeds it keeps, how much each one holds, and how many people must sign to move money. None of the CryptoBilis victims were drained because a blockchain failed or a payment was reversed. They were drained because one seed controlled everything, and, as far as anyone can tell, that seed was compromised before the first deposit arrived.

So the goal isn't a device that can't be compromised. It's a setup where one compromised device can't take much.

Business crypto wallet security: a setup that survives one bad device

A checklist for any business that receives crypto or stablecoins into its own wallets:

1. Buy signing devices direct from the manufacturer. Ship them to the business, and keep a register: serial number, purchase date, channel, and who set each one up. "Authorized reseller" wasn't enough this time.
2. Split roles across separate seeds. A receiving wallet where customer payments land. A treasury that holds what you keep. A payout wallet funded only before each batch. One seed per role, so one leaked phrase can't reach all three.
3. Put the treasury behind multisig. For example, two of three signers, each key on a device bought through a different channel, ideally from different manufacturers. One implant, one seed, one tainted batch: none of them can move the money alone.
4. Cap the receiving wallet and sweep on a schedule. Decide how many days of revenue it may hold, then move the rest to treasury daily or weekly. That number is your worst case if its seed leaks.
5. Watch outgoing transactions, not only incoming ones. A watch-only wallet or a block-explorer alert on your addresses tells you within minutes if money leaves without a reason.
6. Never type, photograph or share a recovery phrase. Ledger reminds users it will never call, DM or ask for the 24 words. Neither will Payzum.
7. Write the incident playbook now. Who moves funds to a fresh seed on a new device, who contacts the issuer if stablecoins are stolen, and who files the police report. In this case the first public alert came seven hours after the drain.

Ledger's own advice for anyone who bought from CryptoBilis: don't set up an unused device, and if one is already in use, move the funds to a new seed on a device bought directly from Ledger. Given Bitquery's data, apply that to purchases since June, not only the last 90 days.

Where Payzum fits, and where it doesn't

Payzum is a non-custodial crypto payment processor. Payments settle directly into wallets you control, and Payzum never holds, pools or controls the funds. That's why this checklist matters to our customers: the wallet that receives the money is yours, so its security is yours too. What Payzum adds:

• Settlement into the wallet you choose. A simple receiving wallet you sweep, or straight into a multisig. There's no Payzum balance in between for anyone to hack, pause or freeze.
• Funds you can move in seconds. Confirmations typically take about 0.4 seconds on Solana and about 2 seconds on Base and Polygon, so sweeps run on your schedule, not a settlement queue's.
• One token to manage. Accept crypto on Bitcoin, Ethereum, Solana, Polygon, Base, Arbitrum, Optimism, BNB Chain and Avalanche, with optional auto-conversion to USDC or USDT.
• Staff who never touch keys. The POS shows a fresh QR code for each sale, and cashiers log in with a PIN. Keys stay with the owners, and analytics show every sale by cashier and terminal.
• Payout wallets funded per batch. CSV mass payouts in BTC, LTC and DOGE, and stablecoin payouts on Polygon, Arbitrum, Optimism, Base, BNB Chain and Avalanche, so the payout wallet only holds what the next batch needs.
• Protection for the account that decides where money goes. Whoever can change your settlement address can redirect your next payment. Payzum accounts use 2FA, encrypted secrets, signed webhooks and a full audit log.

The limits, stated plainly: Payzum can't protect a seed that leaked during setup, can't reverse a theft, and can't freeze tokens. If a device you bought is compromised, the funds on its seed are at risk whatever processor you use. What Payzum gives you is a payment flow with no custodian in the middle, so the only keys that matter are ones you control and can design around.

How it works, step by step

1. Set up your wallets first. Separate seeds for receiving and treasury, devices bought direct, and multisig for the treasury.
2. Point Payzum at your receiving wallet. Choose the networks and tokens you accept, and whether payments auto-convert to USDC or USDT.
3. Turn on the ways you charge. Online, that means hosted checkout, payment links and buttons, drop-in plugins (WooCommerce, Magento 2, PrestaShop, Shopify and others), invoices or subscriptions. In store, the POS with PIN-protected cashiers.
4. Reconcile, then sweep. Signed webhooks push each payment into your systems, and you move balances to treasury on the schedule you set.

What this means for different businesses

• A café or shop taking payments at the counter. Cashiers use the POS with their PIN and never see a recovery phrase. The receiving wallet holds a few days of sales at most and is swept to treasury by the owner.
• An online store with a plugin. Payments auto-convert to USDC or USDT and land in a receiving wallet. A weekly sweep to a multisig treasury keeps a leaked seed from costing more than a week's revenue.
• A B2B exporter invoicing in stablecoins. Tickets are large and infrequent, so settle invoices straight into the multisig. Invoices with expiry and overpayment detection tie each payment to one buyer.
• A platform paying affiliates, sellers or contractors. Fund the payout wallet right before each batch. If its seed ever leaks, the loss is one batch, not the float.
• An API seller paid by AI agents. With x402, agents pay USDC on Base per call. Payzum sits in front of your API as a proxy, and an external facilitator settles each payment to your wallet. Small payments add up quickly, so sweep them like store revenue.

Three ways to hold what customers pay you

Fair objections

"Doesn't this prove we should keep crypto on an exchange?"

No. It proves that one seed is a single point of failure. An exchange is a single point of failure too, just one you can't inspect or redesign. Self-custody lets you split the risk across seeds, signers and time. Custody only lets you choose whose risk to take.

"We bought our devices directly from Ledger. Are we fine?"

Ledger says its direct channels weren't affected, and nothing we've seen contradicts that. But the lesson isn't about one reseller. Any device from any manufacturer can be lost, tampered with or misused. A treasury that needs two signers doesn't depend on any one device being perfect.

"Multisig sounds like overkill for a small business."

Size it to the balance. If your receiving wallet holds a few days of sales and you'd survive losing them, one well-sourced device is a reasonable trade-off. Once the treasury holds more than you could afford to lose, add signers. That's usually long before it reaches the 7 million USDT one victim lost here.

"Should we stop using hardware wallets?"

No. Nothing suggests the secure element was broken. The attack went around it, through the supply chain. Phones and browser wallets have their own risks. Keep using hardware, and stop treating any single device as the whole security plan.