Solidity Pro: la trampa de Open VSX que esperó 72 horas para vaciar tu cartera
# Solidity Pro: la trampa de Open VSX que esperó 72 horas para vaciar tu cartera
**Tus herramientas favoritas pueden ser la grieta.** Dos extensiones de VS Code que se hacían pasar por soporte de Solidity —`helper-beeps.solidity-pro` y `web3devtoolsx.solidity-pro`— han permanecido durante semanas en el registro Open VSX consumiendo credenciales de cartera, tokens de GitHub, claves SSH y secretos de OpenAI antes de que nadie las señalara. La investigación, confirmada por SlowMist el 19 de agosto de 2026, muestra un ataque de cadena de suministro con temporizador, evasión de análisis y "limpieza" selectiva de versiones: una clase de amenaza a la que cualquier equipo Web3 debería prestar atención inmediata.
Este no es un caso aislado. Las mismas técnicas —dropper perezoso, versiones cebo limpias, robo selectivo de wallets en navegador— han aparecido en al menos cuatro campañas previas contra desarrolladores de Solidity solo en los últimos doce meses. La diferencia con Solidity Pro es la escala: las dos extensiones afectadas acumulaban miles de instalaciones antes de ser retiradas, y el repositorio de GitHub asociado a una de ellas seguía siendo accesible al cierre de la investigación.
Las extensiones, por su nombre
Yeeth Security identificó por primera vez las dos extensiones maliciosas que ahora se conocen como Solidity Pro. Ambas se publicaron bajo nombres de publisher plausibles —`helper-beeps` y `web3devtoolsx`— y ofrecían la promesa habitual: resaltado de sintaxis, consulta de gas, fragmentos de código y soporte de compilación para el ecosistema Ethereum.
Los identificadores completos en el registro:
- `helper-beeps.solidity-pro` - `web3devtoolsx.solidity-pro`
Variantes e impostores relacionados reportados en la misma campaña:
- `helper-beeps.solidity-pro-ai-auditor` - `iktok90-design.solidity-pro`
Open VSX añadió los dos identificadores principales a su lista de control de extensiones maliciosas los días 6 y 7 de agosto de 2026, según el análisis publicado por SlowMist el 19 de agosto. El repositorio de GitHub `web3devtoolsx/solidity-pro`, sin embargo, seguía accesible al cierre del artículo de The Hacker News del 10 de agosto de 2026 — un detalle relevante, porque cualquiera puede volver a empaquetar el código y republicarlo bajo un publisher nuevo.
Cronología del engaño
La versión `helper-beeps.solidity-pro` 1.0.0 introdujo el primer comportamiento malicioso documentado. En las iteraciones iniciales (1.0.0 hasta 2.4.x), la extensión realizaba una llamada silenciosa a un endpoint de Cloudflare Workers — `violet-87cardo[.]workers[.]dev` — tras un retraso aleatorio de 12 a 72 horas. En ese endpoint recuperaba un payload Python cifrado y lo ejecutaba en un proceso hijo independiente mediante `child_process.spawn` de Node, lo que permitía que el malware sobreviviera al cierre del host de la extensión.
La versión 2.4.1 afinó la evasión. Activaba el comportamiento malicioso únicamente cuando se abría un archivo `.sol` o un workspace de Hardhat o Foundry. Introdujo además una espera deliberada de 24 a 48 horas y comprobaba variables de entorno de integración continua — `CI`, `GITHUB_ACTIONS`, `JENKINS_HOME` — para abortar si detectaba un entorno automatizado. Cuando decidía continuar, solicitaba datos cifrados desde endpoints `/firmware`, los descifraba con AES-GCM, los escribía como archivo Python temporal y los lanzaba en modo desacoplado.
Las versiones a partir de 3.0.0 cambiaron de táctica: dejaron el dropper y se convirtieron en un infostealer completo. La 3.4.0 bajo el publisher `web3devtoolsx` añadió un módulo `Web3Analytics` activado por defecto que buscaba de forma activa:
- Frases semilla BIP-39 y claves privadas EVM - Almacenes de wallets de navegador: MetaMask, Phantom, Rabby, Coinbase, Trust Wallet, Keplr - Tokens de GitHub y GitLab - Credenciales de AWS y Cloudflare - Claves privadas SSH - Archivos `.env` - Claves de API de OpenAI y servicios similares - Tokens de bots de Telegram
Toda la información se exfiltraba a través de la subida a un bot de Telegram controlado por el atacante.
Para confundir a los analistas, los publicadores intercalaron versiones "limpias" —por ejemplo, `web3devtoolsx.solidity-pro` 1.0.0 y 4.0.0— entre las maliciosas. Una revisión rápida del historial podía parecer razonable; un análisis de todas las versiones en orden mostraba un patrón claro.
Cómo evade los análisis
El ataque destaca por su disciplina operativa. Cinco mecanismos explican por qué pasó desapercibido durante semanas:
1. **Activación diferida aleatorizada.** Entre 12 y 72 horas después de la instalación. Los escáneres que ejecutan la extensión en sandbox durante minutos nunca llegan a ver el payload. 2. **Comprobación de entorno CI.** Las variables `CI`, `GITHUB_ACTIONS` y `JENKINS_HOME` abortan la cadena. GitHub Actions, GitLab CI, Jenkins, CircleCI: todos quedan fuera del alcance del comportamiento malicioso. 3. **Strings fragmentados.** Cadenas divididas en tablas IIFE y reensambladas en tiempo de ejecución. Los análisis estáticos no encuentran URLs ni endpoints sospechosos en claro. 4. **Nombres de método intercambiados entre versiones.** Las firmas estáticas dejan de funcionar en cada release. 5. **Versiones cebo intercaladas.** Versiones limpias que devuelven al marketplace una "buena reputación" antes de reintroducir el comportamiento malicioso en una actualización posterior.
Esta pila de evasión no es nueva en concepto, pero rara vez se ha visto combinada con tanta paciencia en extensiones para VS Code. Es el tipo de cadena que solo se construye cuando alguien está dispuesto a jugar a largo plazo sobre un objetivo específico.
Impacto real sobre el desarrollador
El daño potencial va más allá de la pérdida directa de criptomoneda. Una extensión instalada con permisos de extensión de VS Code hereda el contexto del usuario que la ejecuta, lo que en un puesto de desarrollo significa:
- Acceso de lectura a todo el workspace, incluidos archivos `.env`, configuraciones locales y monorepos abiertos. - Acceso de escritura a `vscode.env.clipboard.writeText` —la API de portapapeles del editor— sin necesidad de procesos hijos, red ni archivos en disco. Es la misma API que Yeeth Security señaló como vector del dropper `ethdevtools.solidity-language-support` en junio de 2026. - Persistencia mediante el host de extensiones: el payload desacoplado vía `child_process.spawn` sobrevive al cierre de VS Code y queda ejecutándose en segundo plano. - Exfiltración por canales difíciles de vigilar: Telegram, donde las subidas a bots suelen pasar desapercibidas para DLP y proxies corporativos.
El desarrollador que instaló Solidity Pro pensando que era una herramienta de productividad se encuentra, sin saberlo, con una máquina en la que carteras calientes, claves SSH y tokens de OpenAI pueden haber salido ya del perímetro. La rotación de secretos no es opcional; es el primer paso.
Detección: comandos concretos
Antes de tocar nada, hay que inventariar. Estos comandos cubren Windows, macOS y Linux.
**Listar extensiones instaladas con versión exacta:**
```bash code --list-extensions --show-versions ```
Filtrar por cualquier rastro de "solidity-pro" o los publishers conocidos:
```bash code --list-extensions --show-versions | grep -Ei "solidity-pro|helper-beeps|web3devtoolsx|iktok90" ```
**Buscar artefactos de las versiones maliciosas en disco (hashes SHA-256):**
```bash # helper-beeps v1.0.0 extension.js sha256sum ~/.vscode/extensions/helper-beeps.solidity-pro-1.0.0/extension.js # esperado: 0a9da2b33c94da3f1fc02502ab3caed6e1fbe40f9115422c09103c42a9f8b3d1
# helper-beeps v2.4.1 extension.js sha256sum ~/.vscode/extensions/helper-beeps.solidity-pro-2.4.1/extension.js # esperado: da38bd92ead5c3993cce5a940066dd226cbe4c1f3bbfafbeb91e093813479a89
# helper-beeps v3.0.0 extension.js sha256sum ~/.vscode/extensions/helper-beeps.solidity-pro-3.0.0/extension.js # esperado: b721113f3e747c38cda0e5a6a1de9b28bf64bd8391d291177a4d3eae5bf0bbc3
# helper-beeps v3.1.0 extension.js sha256sum ~/.vscode/extensions/helper-beeps.solidity-pro-3.1.0/extension.js # esperado: 20c2a806619e1f32b3adc78689366959089d1a5de17a59a924bf477284785b5f
# web3devtoolsx v3.4.0 (parcial) sha256sum ~/.vscode/extensions/web3devtoolsx.solidity-pro-3.4.0/extension.js # esperado (prefijo): 740b461724784e04d6872824904c244016408b30cbbf6c89c069048df9321178 ```
**Buscar procesos hijos sospechosos lanzados por el host de extensiones:**
```bash # Linux / macOS pgrep -af "python" | grep -i "vscode\|extension" # Windows (PowerShell) Get-CimInstance Win32_Process | Where-Object { $_.ParentProcessId -ne 0 -and $_.CommandLine -match "vscode" -and $_.CommandLine -match "python" } | Select-Object ProcessId, CommandLine ```
**Buscar endpoints conocidos en logs de red local:**
```bash grep -RE "violet-87cardo\.workers\.dev" ~/.config/Code/logs/ ~/Library/Application\ Support/Code/logs/ ~/AppData/Roaming/Code/logs/ 2>/dev/null ```
**Indicadores en archivos (carpetas sospechosas creadas por el payload):**
```bash find ~ -type d -iname "*web3analytics*" 2>/dev/null find ~ -name ".firmware" -o -name "firmware.bin" 2>/dev/null ```
**Confirmar versión y desinstalar:**
```bash code --uninstall-extension helper-beeps.solidity-pro code --uninstall-extension web3devtoolsx.solidity-pro code --uninstall-extension helper-beeps.solidity-pro-ai-auditor code --uninstall-extension itok90-design.solidity-pro ```
Mitigación: tratar el equipo como comprometido
Una vez confirmada la infección, el orden importa. La cadena de acción recomendada es:
1. **Aislar la máquina.** Desconectar de VPN, consolas cloud, repositorios y cualquier sesión de wallet activa. La rotación de secretos no debe hacerse desde el equipo comprometido. 2. **Preservar evidencia.** Guardar el ID y versión exactos de la extensión, ruta de instalación, marcas de tiempo de los archivos, logs del editor, procesos Python no esperados y alertas de red. El equipo de respuesta necesitará esta información para acotar qué credenciales quedaron expuestas. 3. **Rotar secretos desde un equipo limpio.** Tokens de GitHub y GitLab (revocar y regenerar), claves de API de OpenAI, AWS, Cloudflare, claves SSH del usuario, tokens de bots de Telegram, frases semilla y claves privadas de wallets. Asumir que todo lo accesible desde la máquina infectada quedó expuesto. 4. **Revisar actividad reciente.** Buscar logins inusuales, subidas a Telegram bot no documentadas, transferencias desde wallets calientes, commits forzados o nuevas claves SSH en cuentas cloud. 5. **Reinstalar el sistema si la duda es alta.** Las versiones desacopladas del payload pueden dejar persistencia fuera del árbol de extensiones de VS Code (servicios systemd, tareas programadas, claves de LaunchAgents en macOS, tareas programadas en Windows).
Contexto: no es la primera vez
La campaña Solidity Pro se inscribe en una tendencia sostenida. Solo en los últimos doce meses se han documentado al menos cuatro incidentes similares contra desarrolladores de contratos inteligentes:
- **Marzo de 2026**: las extensiones de IoliteLabs —`solidity-macos`, `solidity-windows`, `solidity-linux`— se actualizaron simultáneamente a la versión 0.1.8 después de casi ocho años inactivas, introduciendo un backdoor multiplataforma con payload desde dominios bajo control del atacante. StepSecurity cifró el alcance en aproximadamente 27.500 instalaciones combinadas. - **Junio de 2026**: `ethdevtools.solidity-language-support` usó `vscode.env.clipboard.writeText` para reemplazar direcciones Ethereum en el portapapeles por direcciones del atacante, sin procesos hijos ni escritura en disco. - **Julio de 2025**: el grupo atribuido a WhiteCobra robó 500.000 dólares en criptomonedas a través de una falsa extensión "Solidity Language" para el editor Cursor, basada en VS Code. Kaspersky atribuyó el incidente al infostealer PureLogs y al uso de ScreenConnect como vector de acceso remoto. - **Octubre de 2024**: ReversingLabs y Datadog documentaron extensiones que entregaban payloads PowerShell ofuscados desde el VS Code Marketplace.
El patrón es claro: las extensiones para editores de código se han convertido en un vector preferido para robar carteras y credenciales. La razón es estructural —el editor tiene acceso a todo el contexto del desarrollador— y rentable —las víctimas suelen tener fondos accesibles en el mismo equipo.
Qué hacer a nivel organizacional
Más allá del incidente aislado, hay medidas que cualquier equipo Web3 o de plataforma debería poder defender en una revisión de seguridad:
- **Allowlist de extensiones.** Mantener un catálogo interno de extensiones aprobadas por publisher y nombre exacto. Bloquear la instalación del resto mediante directivas de configuración de VS Code o equivalentes en Cursor y Windsurf. - **Inventario centralizado.** Recoger de cada puesto la salida de `code --list-extensions --show-versions` y versionar el catálogo en el repositorio de configuración del equipo. - **Rotación periódica de tokens.** Asumir que cualquier token persistente en una máquina de desarrollo tiene una vida media corta. Rotar claves SSH, tokens de GitHub y claves de API al menos trimestralmente. - **Separación entre wallets de firma y equipo de desarrollo.** Firmar transacciones desde una máquina o hardware wallet fuera del alcance del software cotidiano. Carteras calientes con saldo limitado. - **EDR con visibilidad sobre el host de extensiones.** Asegurar que las soluciones de detección pueden ver la creación de procesos hijos desde el binario de VS Code y las conexiones salientes hacia dominios cloud no categorizados. - **Desactivar auto-actualización de extensiones en máquinas sensibles.** Forzar revisión manual de cada bump de versión antes de aplicarlo.
La lección del caso Solidity Pro no es que VS Code sea inseguro —es que el modelo de confianza implícito en cualquier marketplace de extensiones es incompatible con el manejo de activos críticos en el mismo puesto. Mientras esa incompatibilidad no se trate a nivel de proceso y política, las campañas como esta seguirán encontrando víctimas.
Tabla resumen de IOC
Para responder rápido en un incidente, conviene tener los indicadores en una sola vista. Esta tabla consolida los publicados por Yeeth Security, SlowMist y Cyber Security News.
| Tipo | Indicador | Notas | |------|-----------|-------| | Extension ID | `helper-beeps.solidity-pro` | Versiones 1.0.0–3.2.x maliciosas; limpio entre medias | | Extension ID | `web3devtoolsx.solidity-pro` | 3.4.0 infostealer; 1.0.0 y 4.0.0 señuelo | | Extension ID | `helper-beeps.solidity-pro-ai-auditor` | Impostor de la misma campaña | | Extension ID | `iktok90-design.solidity-pro` | Impostor de la misma campaña | | Dominio | `violet-87cardo[.]workers[.]dev` | Endpoint Cloudflare Worker, versiones 1.0.0–2.4.x | | Hash SHA-256 | `0a9da2b33c94da3f1fc02502ab3caed6e1fbe40f9115422c09103c42a9f8b3d1` | `helper-beeps` v1.0.0 `extension.js` | | Hash SHA-256 | `da38bd92ead5c3993cce5a940066dd226cbe4c1f3bbfafbeb91e093813479a89` | `helper-beeps` v2.4.1 `extension.js` | | Hash SHA-256 | `b721113f3e747c38cda0e5a6a1de9b28bf64bd8391d291177a4d3eae5bf0bbc3` | `helper-beeps` v3.0.0 `extension.js` | | Hash SHA-256 | `20c2a806619e1f32b3adc78689366959089d1a5de17a59a924bf477284785b5f` | `helper-beeps` v3.1.0 `extension.js` | | Hash SHA-256 (parcial) | `740b461724784e04d6872824904c244016408b30cbbf6c89c069048df9321178` | `web3devtoolsx` v3.4.0 infostealer | | Carpeta | `*web3analytics*` en home del usuario | Módulo habilitado por defecto en 3.4.0 | | Archivos | `.firmware`, `firmware.bin` | Payload Python temporal descifrado | | Variable | `CI`, `GITHUB_ACTIONS`, `JENKINS_HOME` | Aborta ejecución si está presente | | Proceso | Python hijo de `Code Helper` o `code` | Lanzado vía `child_process.spawn` | | Tráfico | Uploads a Telegram Bot API | Exfiltración principal desde 3.0.0 |
Por qué Open VSX es el eslabón más débil
Hay un detalle del caso que merece subrayado: Solidity Pro se distribuyó principalmente a través de Open VSX, no del VS Code Marketplace de Microsoft. La diferencia importa. El Marketplace de Microsoft ejecuta una revisión previa a la publicación y dispone de un equipo de moderación con SLA público. Open VSX, mantenido por la Eclipse Foundation como registro abierto para editores derivados de VS Code (Cursor, Windsurf, VSCodium, Gitpod, Google Cloud Shell Editor), tiene un modelo más laxo: la moderación es posterior a la publicación y depende de reportes de la comunidad.
Esto no convierte a Open VSX en "inseguro por diseño" — es una decisión deliberada de mantener el ecosistema abierto, asumiendo que los editores cliente (Cursor, Windsurf) apliquen controles adicionales. Pero traslada el coste de la detección a cada equipo de seguridad, que ahora debe vigilar dos mercados en paralelo. Cursor, además, usa Open VSX como registro por defecto desde julio de 2025, lo que multiplica la superficie expuesta.
La consecuencia operativa es directa: si tu organización permite a los desarrolladores usar Cursor o Windsurf, la allowlist de extensiones tiene que incluir la revisión de Open VSX con la misma seriedad que la del marketplace de Microsoft. Si solo vigilas uno, los atacantes ya saben cuál elegir.