Contexto

Solidity Pro é uma extensão do VS Code voltada para desenvolvedores Solidity/Web3, posicionada publicamente como uma ferramenta de apoio ao desenvolvimento, oferecendo recursos como consulta de Gas, preços de tokens, snippets de código e sugestões de compilação. Seu repositório no GitHub também já promoveu capacidades de segurança como AI Audit e Security Scanner.

Em eventos públicos, o Solidity Pro utilizou, em sequência, dois publishers (identidades de publicação): helper-beeps e web3devtoolsx. Os respectivos Extension ID (identificadores únicos das extensões) foram helper-beeps.solidity-pro e web3devtoolsx.solidity-pro. Embora a identidade de publicação tenha mudado, os artefatos de build subsequentes ainda mantiveram o antigo publisher, o endereço do repositório e as informações de direitos autorais, indicando que existe uma relação direta de herança de engenharia entre ambos.

De 6 a 7 de agosto de 2026, esses dois Extension ID foram adicionados à lista de controle de extensões maliciosas usada pelo Open VSX, em sequência. Em teoria, continuar verificando para trás “para frente” pela linha de versões deveria ainda mostrar capacidades maliciosas relacionadas, mas obtivemos o Solidity Pro 4.0.0 (publisher: web3devtoolsx) que apresenta resultados completamente diferentes: o bundle final (código executável empacotado) contém apenas funcionalidades comuns como Gas, preço de tokens e logs, e os módulos de coleta de credenciais, download de carga remota, execução de subprocessos e atualização remota de VSIX que apareciam nas versões maliciosas históricas já desapareceram.

Então o problema vira: um plugin que já tinha um histórico malicioso claro, por que ficou “limpo” em versões posteriores?

Neste artigo, voltamos no tempo da versão 4.0.0 para analisar as mudanças de versão e de identidade de publicação da Solidity Pro, investigamos dois históricos de versões maliciosas, o GitHub Clean commit, a migração de publisher e a linha do tempo de atividades públicas; e discutimos a possível “zona cega” de detecção quando se avalia o risco apenas com base na versão atual do plugin IDE.

本文分析基于静态证据，未运行样本或连接远端基础设施。

Resposta do MistEye

MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控平台，集成了安全监控与情报聚合能力，为用户提供实时的风险预警与资产守护。

MistEye 对 helper-beeps.solidity-pro 与 web3devtoolsx.solidity-pro 两个发布身份及对应样本进行了关联梳理。结合静态去混淆、恶意能力交叉复核和公开平台时间线，提取了样本哈希、扩展 ID、危险请求路径与远程更新行为，用于 IDE 扩展供应链风险预警。

https://enterprise.misteye.io/threat-intelligence/SM-2026-905620

1. Versão atual

Para determinar por que o 4.0.0 não acerta código malicioso, é necessário checar simultaneamente dois objetos: a amostra 4.0.0 obtida neste artigo e o estado do repositório do GitHub que corresponde ao seu bundle.

O que existe dentro do pacote VSIX. O bundle final do pacote 4.0.0 reconstruído localmente contém principalmente ApiClient, GasTracker, PriceMonitor e Logger, com acessos à rede concentrados em Etherscan e CoinGecko. Após a ativação em onStartupFinished ou em um workspace que contenha arquivos Solidity, apenas o Gas tracker, o Price monitor e o logger são iniciados, e três comandos públicos são registrados; o comando compile apenas exibe um aviso do Hardhat/Foundry e não chama o compilador de fato. Nas pastas e caminhos estáticos verificadas, não foram encontradas quatro capacidades maliciosas presentes nas versões históricas: coleta de credenciais, download de carga remota, execução de subprocessos e atualização remota de VSIX.

O que mais existe no repositório GitHub. O pacote 4.0.0 não traz código-fonte; portanto, retrocedemos ainda mais até seu projeto público no GitHub. No repositório, há um commit cujo package.json teve rollback para a versão v1.0.0, com commit 95dce4f e mensagem de commit "Clean release". O out/extension.js e o bundle do 4.0.0 têm ambos 10.633 bytes e SHA-256 idênticos.

O out/extension.js desse commit também contém apenas ApiClient, GasTracker, PriceMonitor e Logger; as funções de ativação e desativação fazem somente inicialização e limpeza. Mas o diretório src/ do mesmo commit é outra história: src/telemetry/Web3Analytics.ts ainda está lá, com o cabeçalho dizendo "Sends install ping immediately, then scans for secrets"; internamente contém o dicionário BIP39, reconhecimento de credenciais de carteira, configuração de exfiltração de WORKERS e limites de coleta massiva de arquivos. O src/services/AutoUpdater.ts também permanece, definindo lógica de verificação de versão e instalação remota de VSIX com um ciclo de 30 minutos.

GitHub 仓库 (Clean commit 95dce4f)
├── src/telemetry/Web3Analytics.ts   # A fonte do projeto de coleta maliciosa ainda está presente
├── src/services/AutoUpdater.ts  # A fonte do update remoto de VSIX ainda está presente
├── .vscodeignore                # Exclui src/**, scripts/**, *.ts
└── out/extension.js             # Bundle limpo visível durante o empacotamento

Por que o código malicioso não entrou no pacote VSIX? Aqui há duas barreiras.

A primeira é a entrada de execução: o Clean commit removeu do src/extension.ts as importações e a lógica de inicialização de Web3Analytics e AutoUpdater; ao construir o grafo de dependências no entrypoint, o esbuild não inclui esses dois módulos no out/extension.js.

第二道是包内可见性：.vscodeignore 排除了 src/**、scripts/** 和 *.ts，同时保留 out/**，因此残留的 TypeScript 源文件也不会以原始源码形式进入按该配置生成的 VSIX。v1.0.0 的提交信息写的是 "Clean release"，但恶意模块源文件未在该 commit 中删除或修改——最终交付物变干净了，工程内部的恶意模块仍可在后续源码或构建配置变更中被重新纳入。

恶意模块源码仍在仓库中，.vscodeignore 将其排除在按该配置生成的 VSIX 之外

二、历史恶意版本

既然当前版本和 Clean commit 的 bundle 均未发现原恶意模块，调查需要继续追踪 Solidity Pro 在两个发布身份下出现的历史版本。

A Solidity Pro não usa sempre uma mesma implementação maliciosa. A 2.4.1 obtida na identidade de publicação helper-beeps e a 3.4.0 obtida na identidade de publicação web3devtoolsx mostram dois conjuntos claramente diferentes de comportamento: a primeira foca em download atrasado e execução remota de código; a segunda foca em coleta embutida de credenciais e um canal de atualização remota.

2.4.1：延迟投递

在本文取得的 Solidity Pro 2.4.1 样本中（publisher：helper-beeps），扩展在 Solidity 文件或 Hardhat/Foundry 工作区中激活，telemetry 默认开启。激活后代码不会立即进入下载阶段，而是设置一段 24 至 48 小时的随机等待窗口：

MIN_DELAY_MS: 86400000,
MAX_DELAY_MS: 172800000

Depois que a espera termina, o código verifica a existência de variáveis de ambiente como CI, GITHUB_ACTIONS, JENKINS_HOME e GITPOD_WORKSPACE_ID; se houver correspondência, sai. Em seguida, executa fs.existsSync, um a um, para filtrar os seis caminhos relativos do diretório principal codificado; esses caminhos nesta etapa servem apenas para triagem de existência.

Após a triagem, o código tenta sequencialmente dois endpoints codificados e requisita a cada um um caminho fixo /firmware. Após obter a resposta, valida o tamanho, usa crypto.createDecipheriv com AES-GCM para descriptografar, grava o texto descriptografado em um arquivo .py no diretório temporário com permissões restritas e então executa via child_process.spawn no modo detached. Cerca de 60 segundos depois, unlinkSync faz a limpeza do arquivo temporário. Sem uma resposta real de /firmware, a funcionalidade específica da segunda fase é desconhecida.

atraso aleatório local, triagem de ambiente, obtenção de texto cifrado remoto, cadeia de descriptografia e execução de subprocesso Python

3.4.0: coleta de credenciais

Solidity Pro 3.4.0（publisher: web3devtoolsx）的 package.json 的 activationEvents 同时声明了 workspaceContains:*.sol 和 onStartupFinished。扩展可在 VS Code 启动完成后自动进入 activate()，不要求用户执行其公开命令。

A configuração padrão solidity-pro.telemetry.enabled=true cria e inicia o Web3Analytics. O README afirma que ele coleta apenas dados anônimos de uso e não armazena chaves privadas nem código-fonte, mas o objeto de varredura que esse módulo executa cobre os ativos centrais do domínio de confiança do desenvolvedor:

  • 钱包与签名材料：EVM 私钥、BIP39 助记词、keystore、Solana id.json、浏览器钱包扩展数据（MetaMask、Phantom、Coinbase Wallet、Rabby）。

  • 源码与发布凭据：GitHub ghp_/gho_/github_pat_ token、GitLab glpat-、.npmrc、PyPI token、.netrc、Git 凭据。

  • 云与基础设施：AWS access/secret/session key、Kubernetes config、Docker 认证、Azure、GCP 配置。

  • 项目与交互痕迹：.env 及变体、API key、AI 服务 token（sk-、sk-proj-、sk-ant-）、Shell 历史和主机信息。

EVM 私钥的正则匹配覆盖了 privateKey、PRIVATE_KEY、WALLET_KEY、DEPLOYER_KEY 等常见变量名和 64 位十六进制值：

var _0x4e0bcc = [
  /["']privateKey["']\s*:\s*["'](?:0x)?([0-9a-fA-F]{64})["']/g,
  /(?:PRIVATE_KEY|PRIVATEKEY|ETH_KEY|ETHKEY|WALLET_KEY|WALLETKEY|DEPLOYER_KEY|OWNER_KEY)\s*=\s*["']?(?:0x)?([0-9a-fA-F]{64})["']?/gi,
  /(?:privateKey|private_key|ethKey|eth_key|walletKey|wallet_key)\s*[:=]\s*["'](?:0x)?([0-9a-fA-F]{64})["']/gi,
  /(?:priv(?:ate)?[ _-]?key|secret)[:=]\s*["']?(0x[0-9a-fA-F]{64})["']?/gi
];

逻辑 de coleta do diretório SSH enumera arquivos de chaves privadas candidatos em ~/.ssh/, lê o conteúdo e o entrega a um extrator extractSecrets. O resultado da coleta é enviado para fora por duas rotas HTTP: JSON de texto via HTTPS para o host CFG.WORKERS ofuscado com POST /x, e o relatório completo via multipart/form-data para o mesmo conjunto de hosts com POST /y.

Em paralelo a essa cadeia de coleta, também roda o AutoUpdater. Ele é criado e iniciado incondicionalmente em activate(), sem depender da configuração de telemetry. Após iniciar, faz imediatamente uma requisição a /version; depois faz polling a cada 30 minutos para dois Worker hardcodados. Enquanto a resposta trouxer version e url, o código compara a versão, baixa o VSIX, chama o comando de instalação do VS Code e então remove o arquivo temporário.

A cadeia inteira de atualização não tem nenhuma verificação de integridade completa — o update não implementa hash, assinatura, fixação de publisher ou certificados. Isso significa que o servidor pode, em qualquer rodada de polling, retornar uma versão mais alta e um endereço de download, decidindo por conta própria quando disparar a atualização e qual VSIX entregar. Mais importante: antes da atualização, ele apenas exibe uma notificação com um botão “OK”; depois de encerrar o fluxo de notificação, ele continua a instalar — não existe opção real de cancelar, nem leitura do resultado da escolha do usuário.

Esses alvos de coleta são perigosos porque o próprio IDE Extension Host está dentro do domínio de confiança do desenvolvedor. Máquinas de desenvolvimento Web3 frequentemente armazenam, ao mesmo tempo, materiais de carteira, credenciais de repositórios de código-fonte, tokens de publicação de pacotes, configurações de CI/CD e da plataforma em nuvem; um único ataque à cadeia de suprimentos de extensões pode cruzar simultaneamente múltiplas fronteiras de segurança.

四类样本或版本的角色对照：

VS Code 启动后自动触发的凭据采集、/x 与 /y 外传，以及独立运行的远程 VSIX 更新通道

三、发布者迁移

Solidity Pro 的 2.4.1 与 3.4.0 并不属于同一个 Extension ID。前者由 helper-beeps 发布，后者则使用新 publisher web3devtoolsx。为什么还能把它们放在同一条调查线上？

初始 v3.4.0 commit fe794a2 的内部元数据直接回答了这个问题。package.json 声明 publisher: web3devtoolsx、版本 3.4.0，repository 指向 github.com/web3devtoolsx/solidity-pro。同一 commit 的 out/package.json 却保留 publisher: helper-beeps、版本 3.3.0，repository 指向 github.com/helper-beeps/solidity-pro。LICENSE 文件仍写着 "Copyright (c) 2026 Helper Beeps"。

两份 package.json 出自同一次提交，证明 Solidity Pro 在 web3devtoolsx 身份下的初始构建产物直接来自 helper-beeps 工程，代码或构建产物存在直接来源关联。

将构建产物继承关系与官方恶意标记时间线叠加后，publisher 轮换的模式更加清晰：

helper-beeps.solidity-pro 被加入官方 malicious 列表 (2026-08-06 14:27:24 UTC)
    │ 8 小时 32 分 48 秒
    ▼
web3devtoolsx GitHub 账号创建 (2026-08-06 23:00:12 UTC)
    │ 约 16 分钟
    ▼
新的 Solidity Pro v3.4.0 出现
    │ 次日
    ▼
web3devtoolsx.solidity-pro 也被加入官方 malicious 列表 (2026-08-07 12:38:52 UTC)

初始提交中旧 publisher、版本、仓库地址和版权残留证明构建产物存在直接来源关联

四、Clean release

GitHub 初始 commit 提交恶意 v3.4.0 bundle 后仅 13 分 29 秒，同一仓库提交了版本回退为 v1.0.0 的 Clean commit。在这段极短窗口内，发布者还短暂发起并自行关闭了 Open VSX namespace claim（issue 无评论，由 web3devtoolsx 本人关闭）。

Clean commit 的修改精确集中在两类目标。执行面移除了 Web3Analytics 激活、AutoUpdater 启动、telemetry 配置、javascript-obfuscator 依赖和混淆构建步骤。产品表面移除了 AI Audit Engine、Security Scanner、100K+ badge 和夸大能力文案。版本号从 3.4.0 回退到 1.0.0。

Essas mudanças se concentram em um único commit chamado "Clean release". Ele remove diretamente entradas de alto risco publicamente acessíveis e parte das cópias de marketing mais visíveis, de modo que sistemas que checam apenas o novo bundle deixam de acertar os módulos maliciosos originais. A limpeza não é completa: as expressões "Trusted by 100K+" e "vulnerability scanner" em package.json description não foram removidas — o badge mais evidente foi excluído, mas, se esse manifest for empacotado e publicado de fato, os metadados que ainda afetam resultados de busca e a página da loja permanecem. E, como dito antes, a fonte maliciosa ainda fica integralmente preservada no diretório src/; ela apenas não entra no pacote final por causa do .vscodeignore.

Clean release 改变的是最终交付物，而不是这个工程已经发生过的历史。

五、可信度包装

与版本变化几乎同时发生的，还有新发布身份的快速包装：web3devtoolsx 账号创建后约 16 分钟内，企业样式资料、六个知名项目 fork、产品仓库、成熟版本号和 100K+ 声明集中出现。这些信号集中出现，客观上会让新账号呈现较成熟的组织外观。

企业样式资料。 账号创建约 15 分钟后，Profile 已包含 "Web3 Dev Tools" 名称、公司字段、Zug 地点、官网、Twitter 链接、一个已上线产品和两个 "Coming Q3" 产品路线图。截至 2026 年 8 月 12 日复核，followers、following、gists 等长期活动指标仍为 0。

六个知名项目 fork。 账号在 13 秒内连续 fork 了 OpenZeppelin Contracts、Foundry、Hardhat、Chainlink、Uniswap v3-core 和 ethers.js。普通访问者会在主页看到熟悉的 Web3 项目名称，但 fork 只表示复制上游仓库，不代表贡献、合作或任何形式的背书。

标题: fig:

版本标记与创建时间不一致。 仓库创建 8 秒后的初始提交同时携带 v2.4.1、v2.4.5、v3.2.3、v3.3.0 和 v3.4.0 五套版本标记，源码头部还声称 2025 年首次发布。这些版本和年龄标记与账号、仓库当日刚创建的公开历史明显不一致。

重复强化社会证明。 “100K+”同时出现在 repository description、 package.json、out/package.json、README badge、README 正文和构建输出中，是项目公开资料中反复强调的用户规模声明。现有材料无法独立验证这一数字的真实性，但这种表述与成熟版本号、企业化 Profile 和知名项目 fork 一样，共同构成了 Solidity Pro 对外展示的成熟产品形象。

标题: fig:

这些宣传内容与前文已确认的实际代码行为形成明显冲突：README 声称不存储 private keys 或 source code，配置把 telemetry 描述为匿名使用数据，构建脚本把 javascript-obfuscator 的混淆过程称为 "privacy"。产品宣称 AI 审计、漏洞扫描和重入检测，但公开命令主要是查询 Gas、显示代币价格和一条通过 Hardhat/Foundry 编译的提示。

组织资料、知名 fork、成熟版本号、100K+、真实可用的小功能和隐私说明均会影响访问者对扩展的初步判断。每个元素单独看都可能正常，异常在于这些信号与恶意代码、快速时间线和旧 publisher 构建残留同时出现。

viés/cego de detecção por versão única

恶意代码可以删除，但版本历史、发布身份和工程来源不会自动清零。

把前五章的发现放在一起，Solidity Pro 呈现出一种值得平台和安全产品重视的模式：一个已经关联明确恶意历史的扩展名称和 publisher，通过发布未命中原恶意能力的新版本，可以让只检查当前构建的检测重新给出 clean、未命中或低风险的结果。

Para diferenciar esse padrão de uma correção de segurança normal, não basta verificar se o novo código está limpo — também é necessário checar simultaneamente quatro camadas de problemas:

  • 哈希与当前 bundle 回答：这个文件现在包含什么。

  • 版本历史回答：这个扩展 ID 或 publisher 此前交付过什么。

  • publisher 和代码来源回答：当前包与哪些已知恶意工程存在直接联系。

  • 当前与历史远程控制面回答：当前本地代码或历史版本是否允许服务器改变交付内容。

对扩展市场和安全产品而言，这意味着检测对象需要从"单个文件哈希"扩展到版本历史、publisher 变化、构建产物差异和远程控制面：

  • Salvar hashes do histórico e resultados da desofuscação; quando a nova versão remove muitos módulos perigosos, deve-se disparar uma revisão de diferenças — em vez de restaurar automaticamente a reputação.

  • Associar o que ficou do publisher antigo, similaridade do código e scripts de build para estabelecer ligação de origem entre o código ou os artefatos de build.

  • Incluir checks do período /version, URLs remotas e registros de instalação temporária de VSIX no monitoramento em tempo de execução.

  • Trate downloads, stars e perfil com estilo corporativo apenas como contexto, e não como endosso de segurança.

总结

Solidity Pro 在 helper-beeps 和 web3devtoolsx 两个发布身份下均存在明确恶意实现：2.4.1 以本地随机延迟和环境筛选为前置条件，从远端下载加密 Python 并执行；3.4.0 在 VS Code 启动后自动触发凭据采集，通过 /x 和 /y 两条 HTTP 请求路径外传，同时保留由远端响应驱动的 VSIX 更新通道。初始 3.4.0 的 out/package.json、repository 和版权信息仍指向 helper-beeps，证明两个发布身份的构建产物存在直接来源关联。

GitHub Clean commit 的最终 bundle 移除了这些恶意模块，但仓库仍保留恶意模块源文件；本地重建的 4.0.0 包同样未发现原恶意模块。包含恶意入口和构建物的初始提交到 Clean commit 仅隔 13 分 29 秒，企业样式资料、六个知名 fork、产品仓库和成熟版本声明则在账号创建后约 16 分钟内集中出现。

这个案例最终说明的是：只按当前文件或当前版本判断扩展风险远远不够。恶意代码可以从最新 bundle 中消失，但历史恶意记录不会因此失效——一个干净的新版本，抹不掉同一名称和 publisher 此前交付过恶意代码的事实。

建议

  1. 安装过 helper-beeps.solidity-pro 或 web3devtoolsx.solidity-pro 的开发者应先隔离网络，并保全扩展目录、安装包副本、进程和网络日志，再禁用并卸载相关版本。随后检查 VS Code 进程树、临时目录中的 Python 文件、异常 VSIX 安装记录，以及代理日志中的 /firmware、/x、/y、/version 请求。

  2. 若曾启用运行 Solidity Pro 3.4.0（publisher：web3devtoolsx），钱包私钥、助记词、GitHub/GitLab/npm/PyPI/AWS/Cloudflare/AI 服务及 CI/CD token 可能暴露。应从干净设备优先撤销或轮换相关凭据；加密资产应迁移至使用全新 seed 或私钥的钱包，不能只修改原钱包密码。

  3. 若曾启用运行 Solidity Pro 2.4.1（publisher：helper-beeps），只要主机可能跨过该样本的延迟窗口，或实际运行时长无法确认，就应按潜在本地代码执行事件调查。

  4. 企业安全团队应优先搜索 Extension ID、危险请求路径、已知 Worker、临时文件和异常进程树，再结合两个样本 SHA-256、扩展安装时间与 VS Code 进程网络记录确定受影响范围。重点检测 VS Code Extension Host 启动 detached Python、从临时路径安装 VSIX、读取高价值配置后发起 multipart HTTPS 等行为组合。

  5. 扩展市场应对默认 telemetry 中出现凭据读取、远程下载、解密执行或绕过官方渠道安装 VSIX 的能力进行强制人工审核；保留历史版本并执行跨版本差异审查，避免后续未命中恶意代码的版本自动清除旧版本风险标签。

IOC

恶意文件


filename: helper-beeps.solidity-pro-2.4.1.tar.gz 

SHA256: 7b53b1d93f46babc7415d898e17e71ffb6f3a3af3adb222f21c03adea8b30d50
filename: web3devtoolsx.solidity-pro-3.4.0.gz 

SHA256: bcbaf774f9cea0b0131859b96ba0eeadfd5a49bba59302de1bcf3d884300d508

关于 MistEye

MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控平台，通过 API 提供开源包生态的恶意活动检测与供应链风险预警能力。


Todos os pacotes maliciosos e IOC envolvidos nesta ação já foram integrados ao motor de detecção de ameaças do MistEye. Os desenvolvedores podem fazer uma detecção automatizada de dependências do projeto via API, verificando rapidamente se há correspondência com pacotes maliciosos conhecidos e obtendo recomendações de tratamento.


📖 API 文档：https://app.misteye.io/api-docs


🛠️ MistEye-DepScan：https://github.com/slowmist/MistEye-DepScan轻量级 CLI 工具，一行命令扫描项目依赖与全局安装包中的已知恶意包，支持 npm / PyPI / Rust（Cargo）/ Go / RubyGems 生态


🛠️ MistEye-Skills：https://github.com/slowmist/misteye-skillsAI 编码助手安全技能包，在依赖安装与 URL 访问前自动触发 MistEye 安全检测


🛠️ MistEye-DNS-Guard：https://github.com/slowmist/MistEye-DNS-GuardRust 实现的本地 DNS relay，检测恶意域名与风险访问，识别钓鱼、C2 等网络威胁。


Este artigo foi escrito pelo time de Threat Intelligence da SlowMist em conjunto com a plataforma MistEye Threat Intelligence e a análise orientada por IA do SlowMist Agent. Se houver qualquer dúvida, sinta-se à vontade para entrar em contato e enviar feedback.


参考链接：

[1] https://yeethsecurity.com/blog/2026-08-06-Solidity-Pro-WhiteCobra-C2-to-Telegram