- Los paquetes npm maliciosos colortoolsv2 y mimelib2 obtuvieron URL C2 de un contrato inteligente de Ethereum para evadir la detección.
- La indirección en cadena permite a los operadores rotar puntos finales sin volver a publicar paquetes; colortoolsv2 se eliminó el 7 de julio antes de un pivote a mimelib2.
- Un impulso coordinado de GitHub utilizó repositorios de bots comerciales falsos, estrellas infladas y confirmaciones programadas para enmascarar las dependencias maliciosas.
- Los IoC incluyen versiones de paquetes, hashes SHA1 y el contrato 0x1f171a1b07c108eae05a5bccbe86922d66227e2b, además de orientación para defensores.
Los actores de amenazas han recurrido a un truco novedoso: enrutar la infraestructura maliciosa a través de un Contrato inteligente de Ethereum para ocultar indicadores de comando y control (C2) Utilizado por paquetes npm. Según ReversingLabs, dos paquetes (colortoolsv2 y mimelib2) accedieron discretamente a la cadena de bloques para recuperar las URL de las cargas útiles de la segunda etapa, evadiendo así las comprobaciones rutinarias que buscan dominios codificados.
En lugar de explotar un error en Ethereum, el esquema aprovecha la red como una Capa de indirección pública y resilienteDespués de que colortoolsv2 fuera bloqueado en npm el 7 de julio, los operadores cambiaron rápidamente a mimelib2 con una lógica casi idéntica, y continuaron haciendo referencia al mismo contrato en cadena para el siguiente paso.
De la instalación de npm a la búsqueda en cadena: cómo funcionó el desvío
Dentro de colortoolsv2, un cargador mínimo (index.js) actuó como un despachador que invocó un comando externo y obtuvo su objetivo de un contrato inteligente En lugar de un script local o una configuración estática, Etherscan muestra el contrato en 0x1f171a1b07c108eae05a5bccbe86922d66227e2b, cuyas funciones de lectura devolvieron una URL utilizada para acceder al servicio C2.
Este indicador en cadena complicó el bloqueo: los defensores no podían simplemente confiar en encontrar o poner en la lista negra un dominio codificado en el paquete porque El punto final activo residía detrás de un contrato que los operadores controlabanLos destinos rotativos solo requerían actualizar el almacenamiento del contrato, no volver a publicar el artefacto npm, y todo el tráfico de blockchain resultante se mezclaba como legítimo.
Una vez ejecutado durante la instalación o el tiempo de ejecución, el cargador recuperó un second-stage component (SHA1 021d0eef8f457eb2a9f9fb2260dd2e39ff009a21), que gestionaba la actividad posterior. Imitando el comportamiento de colortoolsv2, mimelib2 reutilizó el mismo contrato para el mismo propósito con rutas de código prácticamente idénticas.
ReversingLabs describió el enfoque como inusual en el ecosistema npm: Las URL maliciosas se alojaron a través del estado de un contrato inteligente, no en los servicios web tradicionales que suelen verse en campañas de cadena de suministro anteriores (por ejemplo, almacenamiento en la nube o gists).
Humo y espejos de GitHub: repositorios falsos de bots comerciales como tapadera
Los paquetes npm no aparecieron de forma aislada. Los operadores crearon una red de proyectos de GitHub presentados como herramientas para el comercio de criptomonedas.repositorios como solana-trading-bot-v2—y luego los conectó a las dependencias maliciosas. Para un observador casual, estos repositorios parecían estar "vivos", con miles de confirmaciones, múltiples mantenedores, estrellas y observadores.
Una mirada más de cerca reveló que gran parte de la actividad estaba programada y era superficial, incluyendo la rotación repetitiva de archivos de licencia y Cuentas recién creadas con contenido escaso (Algunos creados alrededor del 10 de julio con archivos README tan mínimos como "Hola"). Los nombres de usuario que aparecieron en los historiales de commits, como slunfuedrac, cnaovalles y pasttimerles, aparecieron repetidamente en los proyectos en fase.
Las confirmaciones mostraron exactamente dónde se integraron los paquetes en el código base.agregando colortoolsv2 y posterior mimelib2 como dependencias En bot.ts y las importaciones correspondientes que aparecen en src/index.ts. La prueba social fabricada hizo que la inserción de la dependencia fuera mucho menos obvia durante una revisión superficial.
En efecto, la fachada de GitHub amplificó las señales de confianza mientras que la El verdadero punto de decisión para el siguiente movimiento del malware residía en EthereumAl separar la ingeniería social (GitHub) del control (contrato inteligente), los operadores hicieron que la campaña fuera más difícil de detectar e interrumpir.
Indicadores de cumplimiento y medidas concretas para los defensores
ReversingLabs publicó un inventario detallado de los artefactos vinculados a esta actividad, junto con la referencia clave en cadena que impulsó la segunda etapa. Los siguientes elementos se pueden utilizar para cazar, bloquear y validar exposiciones en canales de compilación y estaciones de trabajo de desarrolladores:
- npm packages: colortoolsv2 1.0.0 (SHA1 678c20775ff86b014ae8d9869ce5c41ee06b6215), 1.0.1 (1bb7b23f45ed80bce33a6b6e6bc4f99750d5a34b), 1.0.2 (db86351f938a55756061e9b1f4469ff2699e9e27)
- npm packages: mimelib2 1.0.0 (bda31e9022f5994385c26bd8a451acf0cd0b36da), 1.0.1 (c5488b605cf3e9e9ef35da407ea848cf0326fdea)
- Second stage: SHA1 021d0eef8f457eb2a9f9fb2260dd2e39ff009a21
- Contrato inteligente utilizado para la indirección C2: 0x1f171a1b07c108eae05a5bccbe86922d66227e2b
Contexto adicional de la fase de desmontaje: colortoolsv2 se eliminó de npm el 7 de julio, después de lo cual los operadores cambiaron a mimelib2 con la misma referencia en cadena y un comportamiento de cargador casi idéntico.
Las acciones recomendadas para los equipos de ingeniería y seguridad incluyen: Búsquedas de banderas en cadena realizadas por scripts de instalación; bloquear o advertir sobre la ejecución de child_process en los ganchos del ciclo de vida del paquete; denegar la salida de la red durante la instalación de npm en CI; aplicar listas de permitidos para registros y mantenedores; bloquear versiones transitivas; y monitorear solicitudes vinculadas a la dirección del contrato anterior.
En términos más generales, trate las métricas de popularidad del repositorio como señales que no son de seguridad. La confianza debe derivar del código, los artefactos y los indicadores de red., no el número de estrellas, el volumen de confirmaciones ni la presencia de muchos "mantenedores". La verificación independiente (análisis estático, ejecución en un entorno aislado y comprobaciones de procedencia basadas en SBOM) sigue siendo esencial.
Lo que destaca en esta campaña no es una falla en Ethereum, npm o GitHub individualmente, sino la forma en que la infraestructura pública puede integrarse en una cadena de distribución sigilosa. Trasladar el descubrimiento de C2 a un contrato inteligente y blanquear la credibilidad a través de GitHubLos actores desvirtuaron la detección tradicional. La cuidadosa higiene de la dependencia y los controles estratificados son el contrapeso.
