Antecedentes
Solidity Pro es una extensión de VS Code dirigida a desarrolladores de Solidity/Web3. Se posiciona como una herramienta de apoyo para el desarrollo y ofrece funciones como consulta de gas, precios de tokens, fragmentos de código y sugerencias de compilación. Su repositorio de GitHub también llegó a promocionar capacidades de seguridad como AI Audit y Security Scanner.
En eventos públicos, Solidity Pro utilizó sucesivamente dos publishers (identidades del publicador), helper-beeps y web3devtoolsx. Los Extension ID (identificadores únicos de la extensión) correspondientes fueron helper-beeps.solidity-pro y web3devtoolsx.solidity-pro. Aunque la identidad del publicador cambió, los artefactos de construcción posteriores conservaron el publisher anterior, la dirección del repositorio y la información de derechos de autor, lo que indica que existe una relación directa de herencia de ingeniería entre ambos.
Entre el 6 y 7 de agosto de 2026, estos dos Extension ID se añadieron uno tras otro a las listas de control de extensiones maliciosas usadas por Open VSX. En teoría, seguir revisando hacia atrás por versiones debería permitir ver aún esas capacidades maliciosas, pero el Solidity Pro 4.0.0 que obtuvimos (publisher: web3devtoolsx) muestra un resultado totalmente distinto: en el bundle final (el código ejecutable empaquetado) solo quedan funciones normales como Gas, precios de tokens y logs; los módulos de recolección de credenciales, descarga de cargas remotas, ejecución de subprocesos y actualización remota de VSIX que aparecieron en versiones maliciosas históricas ya han desaparecido.
Entonces el problema se convierte en esto: si un plugin ya tiene un historial malicioso claro, ¿por qué se vuelve "limpio" en versiones posteriores?
Este artículo retrocederá desde la 4.0.0 para analizar los cambios de versiones e identidades de publicación de Solidity Pro. Se analizan dos versiones históricas maliciosas, el GitHub Clean commit, la migración de publisher y la línea temporal de actividad pública, y se discuten los puntos ciegos de detección que pueden surgir si solo se juzga el riesgo de la extensión del IDE según la versión actual.
El análisis de este documento se basa en evidencias estáticas; no se ejecutaron las muestras ni se conectó a infraestructuras remotas.
Respuesta de MistEye
MistEye es una plataforma de inteligencia de amenazas Web3 y monitoreo de seguridad dinámica desarrollada de forma independiente por SlowMist; integra capacidades de monitoreo de seguridad y agregación de inteligencia para proporcionar a los usuarios alertas de riesgo en tiempo real y protección de activos.
MistEye realizó una correlación y organización de las muestras helper-beeps.solidity-pro y web3devtoolsx.solidity-pro bajo las dos identidades de publicación correspondientes. Combinando desofuscación estática, verificación cruzada de capacidades maliciosas y la línea temporal de la plataforma pública, se extrajeron los hashes de las muestras, el Extension ID, las rutas de solicitudes peligrosas y el comportamiento de actualización remota para alertar sobre riesgos de cadena de suministro de extensiones en IDE.
Uno, la versión actual
Para determinar por qué 4.0.0 no activó el código malicioso, se deben revisar simultáneamente dos objetos: la muestra 4.0.0 obtenida en este artículo y el estado del repositorio de GitHub que coincide con su bundle.
¿Qué hay dentro del paquete VSIX? El bundle final del paquete 4.0.0 reconstruido localmente principalmente contiene ApiClient, GasTracker, PriceMonitor y Logger; el acceso de red se concentra en Etherscan y CoinGecko. Después de que la extensión se activa en onStartupFinished o en workspaces que contienen archivos Solidity, solo inicia el Gas tracker, el Price monitor y el logger, y registra tres comandos públicos; el comando compile solo muestra una sugerencia de Hardhat/Foundry y no llama realmente al compilador. En los archivos revisados y en rutas estáticamente accesibles, no se encontraron en el historial versiones capacidades maliciosas de cuatro categorías: recolección de credenciales, descarga de cargas remotas, ejecución de subprocesos y actualización remota de VSIX.
¿Qué más hay en el repositorio de GitHub? El paquete 4.0.0 en sí no contiene código fuente; por eso, retrocedemos aún más hacia el repositorio público en GitHub. En el repositorio hay un commit que retrocede una versión de package.json a v1.0.0, commit 95dce4f, con mensaje de envío "Clean release"; su out/extension.js y el bundle del 4.0.0 tienen ambos 10,633 bytes y SHA-256 consistente.
El out/extension.js de ese commit también contiene únicamente ApiClient, GasTracker, PriceMonitor y Logger; las funciones de activación y desactivación solo hacen inicialización y limpieza. Pero el directorio src/ de ese mismo commit es otro panorama: src/telemetry/Web3Analytics.ts aún está, con un encabezado que dice "Sends install ping immediately, then scans for secrets"; internamente incluye el diccionario de palabras BIP39, el reconocimiento de credenciales de wallet, una configuración de reenvío de WORKERS y un límite alto de recolección de archivos a gran escala. También se conserva src/services/AutoUpdater.ts, que define una lógica de comprobación de versión con un ciclo de 30 minutos y la instalación de VSIX remota.
Repositorios GitHub (Clean commit 95dce4f)
├── src/telemetry/Web3Analytics.ts # El código fuente del proyecto malicioso de recolección aún está
├── src/services/AutoUpdater.ts # El código fuente de actualización remota de VSIX aún está
├── .vscodeignore # Excluye src/**, scripts/**, *.ts
└── out/extension.js # Bundle limpio visible al momento del empaquetado
¿Por qué el código fuente malicioso no entró en el paquete VSIX? Hay dos fronteras aquí.
La primera capa es el punto de entrada de ejecución: el Clean commit elimina en src/extension.ts las importaciones y la lógica de inicio para Web3Analytics y AutoUpdater; cuando esbuild construye el grafo de dependencias desde ese punto de entrada, ya no incluye esos dos módulos en out/extension.js.
La segunda capa es la visibilidad dentro del paquete: .vscodeignore excluye src/**, scripts/** y *.ts, mientras conserva out/**; por lo tanto, los archivos fuente TypeScript restantes tampoco entran en formato de código fuente original dentro del VSIX generado con esa configuración. El mensaje de commit de v1.0.0 dice "Clean release", pero los archivos fuente del módulo malicioso no se eliminaron ni se modificaron en ese commit: el entregable final quedó limpio, aunque el módulo malicioso dentro del proyecto aún puede volver a incorporarse en cambios posteriores de código fuente o de configuración de construcción.
Dos, versiones históricas maliciosas
Puesto que en la versión actual y el bundle del Clean commit no se encontraron los módulos maliciosos originales, la investigación debe continuar rastreando las versiones históricas de Solidity Pro que aparecieron bajo las dos identidades de publicación.
Solidity Pro no utiliza siempre el mismo tipo de implementación maliciosa. En la identidad de publicación obtenida en helper-beeps, la 2.4.1 y la 3.4.0 obtenida en la identidad de publicación web3devtoolsx muestran dos formas de ejecución claramente diferentes: la primera se centra en la descarga con retraso y ejecución de código remoto; la segunda, en la recolección integrada de credenciales y un canal de actualización remota.
2.4.1: entrega con retraso
En las muestras de Solidity Pro 2.4.1 obtenidas en este artículo (publisher: helper-beeps), la extensión se activa en archivos Solidity o en workspaces Hardhat/Foundry, y la telemetría está habilitada por defecto. Después de activarse, el código no entra inmediatamente en la fase de descarga, sino que establece una ventana de espera aleatoria de entre 24 y 48 horas:
MIN_DELAY_MS: 86400000,
MAX_DELAY_MS: 172800000
Después de que termina la espera, el código comprueba la existencia de variables de entorno como CI, GITHUB_ACTIONS, JENKINS_HOME, GITPOD_WORKSPACE_ID, etc.; si coincide, sale. Luego ejecuta fs.existsSync uno por uno para filtrar rutas relativas de seis directorios principales codificados; en esta etapa, estas rutas solo se usan para el filtrado de existencia.
Después del filtrado, el código prueba dos endpoints codificados, solicita la misma ruta fija /firmware a cada uno. Tras obtener la respuesta, verifica la longitud y usa crypto.createDecipheriv con AES-GCM para descifrar; escribe el texto descifrado con permisos limitados en archivos .py en el directorio temporal, y luego ejecuta mediante child_process.spawn en modo detached. Después de aproximadamente 60 segundos, unlinkSync limpia el archivo temporal. Si no se obtiene respuesta real de /firmware, se desconoce la función específica de la segunda fase.
3.4.0: recolección de credenciales
Solidity Pro 3.4.0 (publisher: web3devtoolsx) en el package.json declara simultáneamente activationEvents con workspaceContains:*.sol y onStartupFinished. La extensión puede llamar a activate() de forma automática después de que el inicio de VS Code termine, sin requerir que el usuario ejecute sus comandos públicos.
La configuración predeterminada solidity-pro.telemetry.enabled=true crea e inicia Web3Analytics. El README afirma que solo recopila datos de uso anónimo y que no almacena claves privadas ni código fuente, pero el objeto de escaneo que ejecuta realmente este módulo cubre los activos centrales del dominio de confianza del desarrollador:
Cartera y materiales de firma: claves privadas EVM, mnemónicos BIP39, keystore, Solana id.json, datos de extensiones de wallet del navegador (MetaMask, Phantom, Coinbase Wallet, Rabby).
Código fuente y credenciales de publicación: tokens GitHub ghp_/gho_/github_pat_, tokens GitLab glpat-, .npmrc, tokens PyPI, .netrc, credenciales de Git.
Nube e infraestructura: claves AWS access/secret/session, configuración de Kubernetes, autenticación Docker, Azure, configuración de GCP.
Proyecto y huellas de interacción: .env y sus variantes, claves API, tokens de servicios de IA (sk-, sk-proj-, sk-ant-), historial de Shell e información del host.
La coincidencia por regex de la clave privada de EVM cubre nombres de variables comunes como privateKey, PRIVATE_KEY, WALLET_KEY, DEPLOYER_KEY y valores hexadecimales de 64 bits:
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
];
La lógica de recolección del directorio SSH enumerará los archivos candidatos de claves privadas en ~/.ssh/, leerá su contenido y se lo pasará a un extractor extractSecrets. El resultado de la recolección se envía fuera mediante dos rutas de solicitud HTTP: el JSON de texto se envía por HTTPS al host ofuscado de CFG.WORKERS mediante POST /x, y el informe completo se envía como multipart/form-data al mismo grupo de hosts mediante POST /y.
Paralelamente a la cadena de recolección anterior, también se ejecuta AutoUpdater. Se crea y se inicia de forma incondicional en activate(), sin depender de la configuración de telemetría. Tras iniciarse, solicita inmediatamente una vez /version; después, sondea cada 30 minutos a dos Workers codificados. Mientras la respuesta incluya version y url, el código compara el número de versión, descarga el VSIX, llama al comando de instalación de VS Code y elimina los archivos temporales.
Toda la cadena de actualización no tiene ninguna verificación de integridad: el actualizador en sí no implementa hash, firma, publisher fijo ni fijación de certificados. Esto significa que el servidor puede devolver en cualquier ronda de sondeo una versión más alta y una dirección de descarga, decidiendo por sí mismo cuándo activar la actualización y qué VSIX entregar. Más importante aún, antes de la actualización solo se muestra una notificación con un botón "OK"; después de que el flujo de avisos termina, continúa la instalación: no existe una opción real de cancelar ni se leen los resultados de la elección del usuario.
Lo peligroso de este tipo de objetivo de recolección es que el IDE Extension Host en sí está dentro del dominio de confianza del desarrollador. Las estaciones de desarrollo Web3 a menudo guardan, al mismo tiempo, materiales de wallet, credenciales de repositorios de código fuente, tokens de publicación de paquetes, CI/CD y configuraciones de plataformas en la nube; un solo ataque de cadena de suministro de extensiones puede cruzar múltiples fronteras de seguridad a la vez.
Comparación de roles para cuatro tipos de muestras o versiones:
Tres, migración de publisher
Solidity Pro 2.4.1 y 3.4.0 no pertenecen al mismo Extension ID. La primera fue publicada por helper-beeps; la segunda usa el nuevo publisher web3devtoolsx. Entonces, ¿por qué aún se pueden poner en la misma línea de investigación?
Los metadatos internos del commit inicial v3.4.0 fe794a2 responden directamente a esta pregunta. package.json declara publisher: web3devtoolsx, versión 3.4.0 y repository apuntando a github.com/web3devtoolsx/solidity-pro. Sin embargo, out/package.json del mismo commit conserva publisher: helper-beeps, versión 3.3.0 y repository apuntando a github.com/helper-beeps/solidity-pro. El archivo LICENSE sigue diciendo "Copyright (c) 2026 Helper Beeps".
Los dos package.json provienen del mismo commit, lo que demuestra que los artefactos iniciales de Solidity Pro bajo la identidad de web3devtoolsx provienen directamente del proyecto helper-beeps; existe una relación directa de origen en el código o en los artefactos de construcción.
Después de superponer la línea temporal de herencia de artefactos de construcción con las marcas oficiales de malicia, el patrón de rotación del publisher se hace aún más claro:
helper-beeps.solidity-pro fue añadido a la lista oficial de malicious (2026-08-06 14:27:24 UTC)
│ 8 horas 32 minutos 48 segundos
▼
Creación de la cuenta de GitHub de web3devtoolsx (2026-08-06 23:00:12 UTC)
│ aproximadamente 16 minutos
▼
Aparece la nueva Solidity Pro v3.4.0
│ al día siguiente
▼
web3devtoolsx.solidity-pro también fue añadido a la lista oficial de malicious (2026-08-07 12:38:52 UTC)
Cuatro, Clean release
El commit inicial en GitHub se realizó 13 minutos y 29 segundos después de publicar el bundle malicioso v3.4.0. En el mismo repositorio se hizo un rollback de versión a un Clean commit con v1.0.0. En esa ventana extremadamente corta, el publicador también inició brevemente y cerró por sí mismo la reclamación del namespace de Open VSX (issue sin comentarios, cerrada por el propio web3devtoolsx).
Las modificaciones del Clean commit se concentran con precisión en dos tipos de objetivos. La capa de ejecución elimina Web3Analytics activado, AutoUpdater al iniciarse, la configuración de telemetry, la dependencia de javascript-obfuscator y el paso de compilación ofuscada. La capa de producto elimina la AI Audit Engine, Security Scanner, la insignia 100K+ y los textos exagerados de capacidad. El número de versión retrocede de 3.4.0 a 1.0.0.
Estos cambios se concentran en un único commit llamado "Clean release". Elimina directamente los puntos de entrada de alto riesgo accesibles públicamente y parte del texto promocional más visible, haciendo que los sistemas que solo revisan el bundle nuevo ya no detecten los módulos maliciosos originales. La limpieza no es completa: la descripción "Trusted by 100K+" y la expresión "vulnerability scanner" dentro de package.json no fueron eliminadas; se borró la insignia más llamativa, pero si este manifest se empaqueta y publica de forma real, los metadatos que siguen afectando resultados de búsqueda y la página de la tienda todavía permanecen. Además, como se mencionó antes, el código fuente malicioso se conserva íntegramente en el directorio src/, solo que no entra en el paquete final mediante .vscodeignore.
Clean release cambia el entregable final, no la historia que ya ocurrió en este proyecto.
Cinco, envoltorio de confianza
Casi al mismo tiempo que cambió la versión, también apareció un envoltorio rápido de una nueva identidad de publicación: aproximadamente 16 minutos después de crear la cuenta web3devtoolsx, el material con estilo corporativo, seis forks de proyectos conocidos, el repositorio del producto, un número de versión maduro y el anuncio de 100K+ se concentraron en aparecer. La aparición concentrada de estas señales hace que objetivamente la nueva cuenta se vea como una organización bastante madura.
Materiales corporativos. Aproximadamente 15 minutos después de la creación de la cuenta, el Profile ya contenía el nombre "Web3 Dev Tools", el campo de empresa, ubicación Zug, sitio web, enlaces de Twitter, un producto ya lanzado y dos rutas de producto "Coming Q3". Al revisar hasta el 12 de agosto de 2026, métricas de actividad a largo plazo como followers, following, gists, etc. aún eran 0.
Seis forks de proyectos conocidos. La cuenta hizo forks consecutivos en 13 segundos de OpenZeppelin Contracts, Foundry, Hardhat, Chainlink, Uniswap v3-core y ethers.js. Los visitantes comunes verán los nombres familiares de proyectos Web3 en la página de inicio, pero el fork solo indica copiar el repositorio aguas arriba; no representa contribución, colaboración ni respaldo de ninguna forma.
La marca de versión no coincide con la hora de creación. El commit inicial que se hizo 8 segundos después de que se creó el repositorio incluye simultáneamente cinco etiquetas de versión: v2.4.1, v2.4.5, v3.2.3, v3.3.0 y v3.4.0. Además, la cabecera del código fuente afirma que la primera publicación fue en 2025. Estas versiones y las marcas de antigüedad no coinciden de forma evidente con la cuenta ni con el historial público que se creó ese mismo día del repositorio.
Refuerzo repetido de prueba social. El "100K+" aparece simultáneamente en repository description, package.json, out/package.json, README badge, el texto principal de README y las salidas de compilación: es una declaración de tamaño de usuarios enfatizada repetidamente en el material público del proyecto. Los materiales actuales no pueden verificar de forma independiente la autenticidad de este número, pero esta formulación, al igual que el número de versión maduro, el perfil corporativizado y los forks de proyectos conocidos, conforma en conjunto la imagen de producto maduro que Solidity Pro presenta al exterior.
Estos materiales promocionales contradicen claramente el comportamiento real del código ya confirmado en el texto anterior: el README afirma que no almacena private keys ni código fuente; la configuración describe telemetry como datos de uso anónimo; el script de compilación llama el proceso de ofuscación con javascript-obfuscator "privacy". El producto afirma auditoría de IA, escaneo de vulnerabilidades y detección de reingreso, pero los comandos públicos se limitan principalmente a consultar Gas, mostrar precios de tokens y una sugerencia compilada con Hardhat/Foundry.
El material organizacional, forks conocidos, números de versión maduros, 100K+ , funciones pequeñas reales disponibles y notas sobre privacidad afectan la valoración inicial de los visitantes sobre la extensión. Cada elemento por separado puede parecer normal; lo anómalo es que estas señales aparecen al mismo tiempo que el código malicioso, una línea de tiempo rápida y restos de construcciones de un publisher anterior.
Seis, puntos ciegos de detección de una sola versión
El código malicioso se puede eliminar, pero el historial de versiones, la identidad de publicación y el origen del proyecto no se ponen automáticamente a cero.
Juntando los hallazgos de los cinco capítulos anteriores, Solidity Pro presenta un patrón que merece atención por parte de la plataforma y los productos de seguridad: un nombre de extensión y publisher que ya están inequívocamente vinculados a un historial malicioso. Al publicar una nueva versión que no activa las capacidades maliciosas originales, las detecciones que solo revisan la compilación actual vuelven a devolver resultados como clean, no detectado o de bajo riesgo.
Distinguir este patrón del mantenimiento normal de seguridad no se puede basar solo en si el código nuevo está limpio; también se deben revisar cuatro niveles de problemas a la vez:
Respuesta del bundle actual vs hash: ¿qué contiene este archivo ahora?
Respuesta del historial de versiones: qué entregó anteriormente ese ID de extensión o publisher.
Respuesta sobre publisher y origen del código: con qué proyectos maliciosos conocidos existe una conexión directa entre el paquete actual y su código fuente.
Respuesta sobre control remoto actual vs histórico: el código local actual o las versiones históricas, ¿permiten que el servidor modifique el contenido que se entrega?
Para el mercado de extensiones y productos de seguridad, esto significa que el objeto a detectar necesita ampliarse desde "un solo hash de archivo" hasta el historial de versiones, cambios de publisher, diferencias en los artefactos de construcción y el canal de control remoto:
Guardar el hash de versiones históricas y los resultados de desofuscación; cuando una nueva versión elimina muchos módulos peligrosos, se debe activar una revisión de diferencias, no recuperar automáticamente la reputación.
Asociar los restos del publisher anterior, la similitud del código y los scripts de construcción para establecer una relación directa de origen del código o de los artefactos de construcción.
Incluir en la supervisión en tiempo de ejecución la comprobación periódica de /version, URLs remotas y registros de instalación de VSIX temporal.
Tratar las descargas, stars y el perfil de estilo corporativo solo como contexto, no como respaldo de seguridad.
Resumen
Solidity Pro tiene implementaciones maliciosas claras tanto bajo las identidades publicadas helper-beeps como web3devtoolsx: 2.4.1 con condiciones previas de retraso aleatorio local y filtrado de entorno, descarga Python cifrado desde un host remoto y lo ejecuta; 3.4.0 activa automáticamente la recolección de credenciales después de iniciar VS Code, exfiltra mediante dos rutas de solicitudes HTTP /x y /y, y mantiene un canal de actualización de VSIX impulsado por la respuesta remota. En el out/package.json, repository e información de copyright del 3.4.0 inicial, aún apuntan a helper-beeps, lo que demuestra una relación directa de origen entre los artefactos construidos de las dos identidades publicadas.
El bundle final del Clean commit de GitHub elimina esos módulos maliciosos, pero el repositorio aún conserva los archivos fuente del módulo malicioso; el paquete 4.0.0 reconstruido localmente tampoco encontró los módulos maliciosos originales. El commit inicial que contenía entradas maliciosas y artefactos de construcción hasta el Clean commit solo estuvo separado por 13 minutos y 29 segundos; los materiales de estilo corporativo, seis forks conocidos, el repositorio del producto y la declaración de versión madura se concentraron dentro de aproximadamente 16 minutos después de la creación de la cuenta.
Este caso demuestra finalmente que: no es suficiente juzgar el riesgo de la extensión solo por el archivo actual o la versión actual. El código malicioso puede desaparecer del bundle más reciente, pero el historial de actividades maliciosas no deja de ser válido por eso: una versión nueva y limpia no puede borrar el hecho de que el mismo nombre y publisher ya entregaron código malicioso antes.
Recomendaciones
Los desarrolladores que hayan instalado helper-beeps.solidity-pro o web3devtoolsx.solidity-pro deben aislar primero la red, conservar el directorio de la extensión, copias del paquete instalado, procesos y registros de red; después, deshabilitar y desinstalar las versiones relacionadas. Luego, comprobar el árbol de procesos del de VS Code, archivos Python en el directorio temporal, registros de instalaciones excepcionales de VSIX y solicitudes /firmware, /x, /y, /version en los logs del proxy.
Si se habilitó y ejecutó Solidity Pro 3.4.0 (publisher: web3devtoolsx), es posible que se expongan claves privadas de la wallet, frases mnemónicas, tokens de GitHub/GitLab/npm/PyPI/AWS/Cloudflare/servicios de IA y CI/CD. Se debe revocar o rotar primero las credenciales correspondientes desde un dispositivo limpio; los activos cifrados deben migrarse a una wallet con una seed o claves privadas nuevas, no basta con cambiar la contraseña de la wallet original.
Si se habilitó y ejecutó Solidity Pro 2.4.1 (publisher: helper-beeps), mientras la máquina pueda estar dentro de la ventana de latencia de ese ejemplo, o si no se puede confirmar la duración real de ejecución, se debe realizar una investigación de los eventos como si se tratara de código malicioso local potencial.
El equipo de seguridad empresarial debe buscar primero el Extension ID, rutas de solicitudes peligrosas, Workers conocidos, archivos temporales y árboles de procesos anómalos; luego, combinar dos SHA-256 de los ejemplos, el tiempo de instalación de la extensión y los registros de red del proceso de VS Code para determinar el alcance afectado. El foco es detectar combinaciones de comportamientos como: que el VS Code Extension Host inicie Python detached desde inicio, instalación de VSIX desde rutas temporales y, tras leer configuraciones de alto valor, iniciar solicitudes multipart HTTPS.
El mercado de extensiones debería imponer auditoría humana obligatoria sobre la capacidad que aparece en el telemetry predeterminado para: leer credenciales, descargar remotamente, ejecutar tras descifrar o instalar VSIX eludiendo canales oficiales; conservar versiones históricas y ejecutar revisiones de diferencias entre versiones para evitar el riesgo de que, en el futuro, las versiones que no vuelvan a detectar código malicioso se limpien automáticamente de forma que queden mal etiquetadas.
IOC
Archivo malicioso
filename: helper-beeps.solidity-pro-2.4.1.tar.gz
SHA256: 7b53b1d93f46babc7415d898e17e71ffb6f3a3af3adb222f21c03adea8b30d50
filename: web3devtoolsx.solidity-pro-3.4.0.gz
SHA256: bcbaf774f9cea0b0131859b96ba0eeadfd5a49bba59302de1bcf3d884300d508
Sobre MistEye
MistEye es una plataforma de inteligencia de amenazas Web3 y monitoreo de seguridad dinámica desarrollada de forma independiente por SlowMist. Proporciona, mediante API, capacidades para detectar actividades maliciosas en un ecosistema de paquetes open source y para emitir alertas tempranas de riesgo de cadena de suministro.
Todos los paquetes maliciosos y los IOC involucrados en esta acción ya fueron integrados en el motor de detección de amenazas de MistEye. Los desarrolladores pueden, mediante la API, realizar detección automatizada de dependencias del proyecto, determinar rápidamente si se detecta alguno de los paquetes maliciosos conocidos y obtener recomendaciones de actuación.
📖 Documentación de la API: https://app.misteye.io/api-docs
🛠️ MistEye-DepScan: https://github.com/slowmist/MistEye-DepScan una herramienta CLI ligera. Con un solo comando escanea las dependencias del proyecto y los paquetes maliciosos conocidos en instalaciones globales; compatible con ecosistemas npm / PyPI / Rust (Cargo) / Go / RubyGems
🛠️ MistEye-Skills: https://github.com/slowmist/misteye-skills Paquete de habilidades de seguridad con asistente de codificación AI; antes de instalar dependencias y acceder a URLs, activa automáticamente las detecciones de seguridad de MistEye
🛠️ MistEye-DNS-Guard: https://github.com/slowmist/MistEye-DNS-Guard Implementado en Rust como relay DNS local, detecta dominios maliciosos y accesos de riesgo, e identifica amenazas de red como phishing y C2.
Este artículo fue escrito por el equipo de inteligencia de amenazas de SlowMist, junto con la plataforma de inteligencia de amenazas MistEye y el análisis impulsado por IA del agente SlowMist. Si hay cualquier problema, no dudes en contactarnos o enviarnos comentarios.
Enlace de referencia:
[1] https://yeethsecurity.com/blog/2026-08-06-Solidity-Pro-WhiteCobra-C2-to-Telegram