Most install decisions close inside an hour. You add the extension, it does the job it advertised, nothing catches fire, and you move on. Two campaigns disclosed this month wait that hour out on purpose. One sat idle for 12 to 72 hours before contacting its operators, and the other did its work during installation and then went quiet. For a Bitcoiner, the gap between ‘I tested it’ and ‘it woke up’ is exactly where a signing session or a node login tends to happen.
The delay is a line item, not an accident
On August 10, researchers at Yeeth Security documented two publishers, helper-beeps and web3devtoolsx, shipping an extension called Solidity Pro. Versions 1.0.0 through 2.4.1 beaconed to a Cloudflare Worker after a random delay of 12 to 72 hours, then pulled an encrypted Python payload that executed outside the editor. From version 3.0.0 the operators dropped the staging step and embedded the stealer directly in the extension's main script. The researchers were blunt about what the wait buys: by the time the malicious branch runs, the user has already decided the extension is useful, and automated scanners have moved on.
Koi Security ties the campaign to a cluster it tracks as WhiteCobra, which targets developers on VS Code, Cursor, and Windsurf. Koi recovered the group's own planning file, titled ‘DEPLOYMENT PLAN: Operation Solidity Pro,’ with revenue targets between $10,000 and $500,000 per campaign and an instruction to run a download-inflation script ‘until the target of 50,000 downloads is reached.
This will provide social proof for developers discovering the extension.’ They bought residential proxies to make the bots look real. Koi puts the group at 24 malicious extensions and under three hours from packaging to monetization, with fresh uploads landing every week to replace the ones the marketplaces pull.
Five days later, OpenSourceMalware surfaced a second timer-shaped campaign. StubMaker placed 16 typosquatted RubyGems, including activesupmport, brumdler, and a cluster of near-miss internationalization package names, in front of anyone whose fingers slipped.
The gems abuse the extconf.rb build hook, which runs automatically at install time, to fetch a 22 MB Rust loader from a GitHub release and launch a Go stealer. Collected data leaves as a password-protected archive uploaded to a file host, with the download link sent over unencrypted HTTP. A day later, 37 npm packages appeared on the same infrastructure.
Read the whole shopping list
Half the stealer's shopping list reads like someone else's casino. MetaMask, Phantom, Rabby, Coinbase, Trust, Keplr. Not your problem, and not your money.
Then the list keeps going. It also takes Bitcoin WIF and xprv strings, SSH private keys, GitHub and GitLab tokens, AWS keys and session tokens, and 1Password MFA tokens. A WIF string is a single private key formatted for import. An xprv is an entire account branch, every past address and every future one, in a single line of text. Neither needs a smart contract or a bridge to be worth money. If either has ever touched the filesystem of the machine you code on, whether in a test wallet, an old backup, a recovery scratch file, or a screenshot folder you forgot about, it is on the list.
The SSH key deserves separate billing. Bitcoiners tend to run infrastructure: a node, a Lightning box, a backup server, a monitoring dashboard. The key that reaches all of it usually lives on the laptop that also installs the tools.
Rafael's Monday
Rafael runs Bitcoin Core at home and signs from an air-gapped device using Sparrow on his work laptop. On Friday afternoon he installs a Solidity extension for a contract audit a client asked about. It works. He watches it for twenty minutes, decides it is fine, and closes the question. Saturday he builds and signs a PSBT. Nothing goes wrong, because nothing is supposed to yet.
Monday the timer fires. His seed never left the air-gapped signer, and the attacker cannot spend from it, which is the part the hardware did correctly. What the attacker takes instead is his wallet's output descriptor, which reveals every address he has ever used and every address he will use next, his labeled transaction history, the SSH key to his node, and a GitHub token with write access. He has not lost a sat. He has lost the map, and the front door to everything the map describes. The theft that follows, whenever the operator decides to run it, will not look like a hack. It will look like someone who already knows him.
Install as though the payload is on a timer
The routine that fails here is the one that ends when your attention does. Rebuild it around the assumption that the software is patient.
1. Keep the machine that explores away from the machine that signs. A separate box, or at minimum a separate user account. This is the cheapest control on the list and the one most people skip, because their laptop is fast enough to do both.
2. Install unfamiliar tooling inside a dev container rather than on the host. Extensions installed into the container cannot see your home directory or the SSH keys sitting in it.
3. Discount the download count entirely. Fifty thousand installs is a purchasable number, and WhiteCobra's own manual says so. Check how old the publisher account is and whether its name matches the project's real organization. A brand-new account behind a familiar tool name is the whole attack.
4. Pin versions and disable automatic extension updates. The version you audited is not the version that will be running on Thursday, and this campaign shipped clean releases before the hostile ones.
5. Give the stealer less to find. SSH keys with passphrases, tokens scoped to one repository instead of an account, no plaintext keys or seed material anywhere on a machine that installs software. Assume anything readable will eventually be read.
6. If you must install on the working machine, treat 72 hours as the observation window rather than twenty minutes, and watch outbound connections rather than the editor's behavior. The user interface is not where the activation shows up.
If you already ran one
Work from a different, known-clean device and treat the suspect machine as hostile until it is wiped. Rotate the tokens and SSH keys first, because those are the pivot into everything else, and revoke rather than regenerate. Check your node and server logs for logins you did not make. Move funds only where a hot key or an xprv could have been on that filesystem, and rebuild those wallets from a clean environment. Never type a recovery phrase into the machine you are investigating, and do not trust its replacement until you have built it from scratch yourself.
Final thoughts
Supply chain attacks used to be an argument about which packages to install. This generation is an argument about when you stopped paying attention. The operators know that human verification is a burst of attention followed by permanent assumption, and they have priced that gap at 12 to 72 hours. Bitcoin gives you final settlement and no recourse, so the discipline has to sit upstream of the signature, in the boring decision about what gets to run near your keys. Watch the tool for as long as it is willing to wait.
