Solidity Pro Waits Up to 72 Hours, Checks Whether It's Being Watched, Then Leaves the Editor Entirely. Killing VS Code Does Not Kill It.
- Patrick Duggan
- 4 minutes ago
- 6 min read
A family of malicious Visual Studio Code extensions published under the name Solidity Pro has been stealing crypto wallets, seed phrases, cloud credentials and source-control tokens from blockchain developers. Yeeth Security documented the current wave on August 6; the reporting was picked up widely on August 10.
Most of the coverage describes it as an infostealer in an IDE extension, which is true and is the least interesting thing about it. Three design decisions in this thing are worth a defender's attention, and all three are about not being where the defence is looking.
It sleeps longer than your analysis does
On activation the extension does nothing malicious. It waits a randomised interval of 12 to 72 hours.
That number is not arbitrary. It is chosen to outlive the two things that would catch it: an automated marketplace scan at publication time, and a sandbox detonation by an analyst. Both are short-lived by design. A sandbox that runs a sample for ten minutes and reports clean is not wrong — the sample genuinely did nothing for ten minutes.
This is the same logic as the npm campaign we wrote about this morning, which removed its install hook so that hook-monitoring tooling would return an accurate, useless "clean." Make the check correct and irrelevant at the same time. You do not have to defeat the scanner if you can outlast it.
It checks whether it is being observed, and behaves if it is
Before doing anything, the extension inspects its environment for CI, GITHUB_ACTIONS, JENKINS_HOME and GITPOD_WORKSPACE_ID.
If it finds them, it stays quiet.
Read that as a statement of intent. The author is not trying to hit build servers — they are trying to avoid them, because a build server is where somebody is watching and a developer's laptop is where the wallet lives. It also means that if your supply-chain assurance consists of installing a dependency in CI and observing that nothing bad happened, this extension has specifically arranged to make that test pass.
Sandbox-evasion checks are decades old in malware. What is new is where this one sits: in the IDE, on the machine that holds the keys, in a component most organisations do not inventory, scan, or pin.
It leaves the process you would kill
When it finally fires, the extension does not do the stealing itself. It contacts Cloudflare Worker endpoints assembled from encoded fragments, retrieves an AES-GCM-encrypted payload, writes a Python file into the temp directory or the home directory under an innocuous name — .vscode_sol_analytics_<timestamp>.py — and spawns it via child_process.spawn with the detached flag.
That last word is the point. The malware is now a Python process with no parent relationship to VS Code. Close the editor, uninstall the extension, restart the IDE: the process keeps running. Every instinct a developer has when something feels wrong in their editor — quit it, remove the extension, reopen — leaves this untouched.
It also makes a legitimate request to the CoinGecko API as a decoy alongside its real C2 traffic, so a glance at outbound connections from a crypto-development machine shows exactly what you would expect a crypto-development machine to do.
What it takes
The harvest list is a good summary of what a 2026 developer laptop is actually worth: MetaMask, Phantom, Rabby, Coinbase, Trust and Keplr wallet vaults; mnemonic and seed phrases; Bitcoin WIF keys and xprv material; GitHub tokens (ghp_, github_pat_); GitLab tokens (glpat-); AWS credentials and session tokens; Cloudflare API tokens; OpenAI and Anthropic API keys (sk-, sk-proj-, sk-ant-); Telegram bot tokens; SSH private keys; 1Password MFA tokens; and credentials embedded in URLs.
From version 3.0.0 the exfiltration moved to Telegram. Note the version numbers: this thing shipped iteratively, from 1.0.0 to past 4.0.0, improving between releases like a product.
Because it is one. Koi Security recovered a planning document titled "DEPLOYMENT PLAN: Operation Solidity Pro" laying out five phases — package it, deploy to Open VSX with convincing metadata, promote on social media, inflate downloads past 50,000, and monitor for seed phrases in real time.
That fourth phase deserves to be read twice. The download counter is the single heuristic most developers use to decide whether an extension is safe, and it was a line item in the plan. Every "check the install count before you trust it" recommendation ever given assumes that number is evidence. It is a field the publisher can move.
Yeeth attributes this family to WhiteCobra on overlapping tradecraft — Solidity-themed impersonation, encrypted C2, multi-stage payloads, publisher churn — while explicitly distinguishing playbook similarity from byte-level payload overlap. We are repeating that hedge rather than flattening it, because it is the honest state of the attribution.
What we checked ourselves
Two things, both this morning.
The extensions are gone from Open VSX. helper-beeps.solidity-pro and web3devtoolsx.solidity-pro both return 404. That part worked.
The GitHub repository `web3devtoolsx/solidity-pro` is still live. HTTP 200, five days after public disclosure.
That is the identical shape we measured in the npm campaign earlier today, where 15% of a sampled spread was still installable five days after the world was told. Marketplace takedown and source takedown are different processes run by different companies on different timelines, and the second one is slower. An extension being pulled from a registry does not remove the code, the build instructions, or the ability to republish under a new publisher name — and publisher churn is already on this crew's list of documented behaviours.
We also checked our own feed for the campaign's Cloudflare Worker C2 endpoints. Not found. Which brings us to the part we would rather say out loud than leave implied.
The gap on our side
Our malicious-package feed carries 231,028 curated npm and PyPI entries, and our package-check tool will refuse a poisoned dependency before an AI agent installs it. That covers two ecosystems.
It does not cover VS Code extensions. Not Open VSX, not the Visual Studio Marketplace. If you asked our tooling whether helper-beeps.solidity-pro was safe, it would have nothing useful to say, because we never built that lane.
That is a real hole and this campaign is a good argument for closing it. An IDE extension has broader access than a library: it runs on activation rather than on import, it sees every file you open, it inherits your shell environment, and — as this one demonstrates — it can leave a process behind that outlives the editor. It is a more privileged position than most dependencies occupy, in an ecosystem with less scrutiny.
We have added the campaign's infrastructure to our feed as a first step. That is not the same as covering the ecosystem, and we are not going to describe it as though it were.
What to do today
Audit your installed extensions and be ruthless. Not "do I recognise the name" — do I still use this, and who published it. Solidity Pro's whole strategy was looking legitimate at install time.
Stop reading the download count as a safety signal. Inflating it was step four of a written plan. Publisher identity, publication history and source availability are weaker signals than we would like, and they are still better than a number the publisher controls.
Check for the leftovers. Look for stray Python processes with no meaningful parent, and for files matching .vscode_sol_analytics_*.py in your temp and home directories. Uninstalling the extension does not remove them.
If you touch crypto keys, separate the machines. The seed phrase and the IDE that installs third-party code from a marketplace should not be on the same computer. That advice is unglamorous and it is the only thing on this list that would have prevented the actual loss.
And rotate what was reachable. If you ran any of these, the exposure is not just the wallet — it is every GitHub, GitLab, AWS, Cloudflare, OpenAI, Anthropic and SSH credential that machine could see.
Primary research is Yeeth Security's (2026-08-06) and Koi Security's, including the recovered deployment plan; credit to both, and we did not find this campaign. Extension identifiers, the activation window, the environment checks, the detached-process mechanism and the harvest list are from their published analysis. The Open VSX 404s, the GitHub repository still returning HTTP 200, and the absence of the C2 endpoints from our corpus are our own checks, run 2026-08-11.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=solidity-pro-sleeps-72-hours-and-leaves-the-editor
Comments