Los paquetes npm maliciosos ocultaron rutas de carga útil dentro de los contratos inteligentes de Ethereum.

Actualización definitiva: 09/04/2025
  • Dos paquetes npm, colortoolsv2 y mimelib2, consultaron los contratos inteligentes de Ethereum para obtener las URL de C2 en busca de malware de segunda etapa.
  • Los atacantes ejecutaron una campaña organizada utilizando repositorios de bots comerciales de GitHub falsos para atraer a los desarrolladores.
  • La técnica se mezcla con el tráfico legítimo de blockchain, lo que complica la detección y la eliminación.
  • ReversingLabs compartió IoC, incluidos hashes de paquetes y una dirección de contrato utilizada para servir URL.

Contratos inteligentes de Ethereum npm

Los investigadores han detallado un esquema de cadena de suministro en el registro npm en el que se consultaron dos bibliotecas de JavaScript Contratos inteligentes de Ethereum para descubrir ubicaciones de descarga de malware posterior. La táctica, observada en julio de 2025 y ahora eliminada de npm, muestra cómo las cadenas de bloques públicas pueden usarse indebidamente como una capa de indirección para mantener... infraestructura de comando y control (C2) fuera de vista.

En lugar de incrustar URL fijas, el código malicioso las extrajo en tiempo de ejecución de un contrato en Ethereum, haciendo que la actividad pareciera consultas normales en cadena. Ese cambio hacia el uso de... “libreta de direcciones” descentralizada La entrega de carga útil ilustra cómo los actores de amenazas se están adaptando para evadir el escaneo convencional y las listas de bloqueo simplistas.

Lo que se subió a npm

Según ReversingLabs, los paquetes denominados herramientas de color v2 y mimelib2 se publicaron en julio de 2025 y posteriormente se eliminaron. Cada uno actuó como un pequeño cargador: una vez que el paquete estaba instalado o importado, ejecutó un código que llegó a un contrato de Ethereum, leyó un valor y luego obtuvo un componente de la siguiente etapa de la URL devuelta.

Si bien las bibliotecas npm no ofuscaron profundamente el comportamiento de su cargador, la credibilidad se generó en otras partes: los proyectos de GitHub vinculados adoptaron nombres y patrones de actividad familiares para parecer legítimos, lo que hizo más fácil para los desarrolladores aceptar la dependencia de un vistazo.

Cómo funcionó el cambio hacia los contratos inteligentes

Las ubicaciones de la carga útil no estaban codificadas. En su lugar, el cargador consultó un contrato en 0x1f171a1b07c108eae05a5bccbe86922d66227e2b, utilizando funciones de lectura que devolvían una cadena interpretada como URL para la segunda etapa. Al alojar el puntero en la cadena, los atacantes ganaron resiliencia: es público, consultable y actualizable sin impulsar nuevas versiones de npm ni mantener un único servidor propenso a caídas.

Dado que las búsquedas en blockchain se asemejan a herramientas y análisis criptográficos inofensivos, esas solicitudes pueden integrarse en los flujos de trabajo normales de los desarrolladores. El enfoque evoca ideas anteriores como EtherHiding, pero aquí se integró directamente en ejecución del paquete npm, convirtiendo una instalación rutinaria en una ruta para una entrega por etapas.

Un impulso más amplio de GitHub para fomentar la adopción

Los paquetes npm se referenciaron en una red de repositorios de GitHub posicionados como utilidades para el comercio de criptomonedas. Algunos ejemplos incluyen bot de comercio solana v2, bot de Ethereum Mev v2, robot de arbitraje y robot de comercio hiperlíquidoLa actividad en torno a estos repositorios (estrellas, bifurcaciones, observadores y confirmaciones frecuentes) se diseñó para proyectar legitimidad e impulso.

ReversingLabs vincula esta amplificación a un clúster de distribución como servicio conocido como Red fantasma de observadores de estrellas, donde las cuentas coordinadas inflan las señales de popularidad e introducen dependencias maliciosas en los proyectos. La cuenta de GitHub asociada a un repositorio principal se eliminó posteriormente, pero los historiales de confirmaciones mostraron cómo... importaciones maliciosas Se incorporaron al código a lo largo del tiempo.

Cronología y rotación de paquetes

Colortoolsv2 apareció primero y se bloqueó en npm aproximadamente 7 Julio 2025Poco después, los actores cambiaron a un reemplazo casi idéntico llamado mimelib2, preservando la misma búsqueda de contrato inteligente para la URL de la segunda etapa. Este intercambio rápido subraya un patrón familiar en los incidentes de la cadena de suministro: una vez que se detecta un artefacto, un... paquete similar Cumple rápidamente su función.

Indicadores de compromiso (IoC)

ReversingLabs reportó los siguientes indicadores que se relacionan con la campaña. Las organizaciones pueden usarlos para impulsar... detección y caza esfuerzos:

  • Paquetes y versiones de npm:
    • colortoolsv2 1.0.0 (SHA1 678c20775ff86b014ae8d9869ce5c41ee06b6215)
    • colortoolsv2 1.0.1 (SHA1 1bb7b23f45ed80bce33a6b6e6bc4f99750d5a34b)
    • colortoolsv2 1.0.2 (SHA1 db86351f938a55756061e9b1f4469ff2699e9e27)
    • mimelib2 1.0.0 (SHA1 bda31e9022f5994385c26bd8a451acf0cd0b36da)
    • mimelib2 1.0.1 (SHA1 c5488b605cf3e9e9ef35da407ea848cf0326fdea)
  • Archivo de segunda etapa: SHA1 021d0eef8f457eb2a9f9fb2260dd2e39ff009a21
  • Ethereum contract: 0x1f171a1b07c108eae05a5bccbe86922d66227e2b

Por qué este método complica la defensa

Al subcontratar la decisión de “adónde ir a continuación” a una contrato inteligenteLos atacantes desacoplan la lógica del malware de un único endpoint. Si se bloquea una URL, el valor del contrato puede actualizarse y el mismo paquete npm resolverá una nueva ubicación sin cambios. Ese dinamismo debilita indicadores estáticos y eleva el nivel de los derribos.

Además, muchos entornos de desarrollo ya interactúan con endpoints web3, por lo que las llamadas EVM podrían no ser inherentemente sospechosas. La línea entre el tráfico legítimo de blockchain y... balizamiento malicioso se desdibuja y desafía tanto las estrategias de monitoreo de red como las de detección de puntos finales.

Pasos prácticos para desarrolladores de npm y web3

Los equipos deben combinar el análisis del código, el mantenimiento y la red antes de implementar una dependencia. Más allá del número de descargas y las estrellas, examinen historial del mantenedor, la edad del repositorio, la calidad de las confirmaciones, la cadencia de lanzamiento y si el paquete llega inesperadamente a contratos en cadena o hosts desconocidos.

  • Inspeccione los ganchos de instalación y postinstalación, así como los puntos de entrada. llamadas de red o ejecución de procesos secundarios.
  • Bloquear o alertar sobre consultas RPC de EVM inesperadas desde CI/CD o canalizaciones de compilación; establecer la línea base a la que deben acceder sus herramientas y negar el resto.
  • Fije versiones, utilice archivos de bloqueo y refleje paquetes examinados en un registro interno para reducir la exposición a intercambios de paquetes.
  • Adoptar certificaciones de artefactos y verificación de firmas (por ejemplo, procedencia SLSA) para que la integridad de la dependencia sea verificado en la compilación.
  • Escanee continuamente los gráficos de dependencia para detectar IoC recientemente revelados y anomalías cambios de mantenedor.

Para los repositorios que se vieron afectados por la campaña, revise las confirmaciones recientes para la introducción de colortoolsv2 o mimelib2, restaure las claves y los tokens utilizados durante las compilaciones comprometidas y considere volver a crear imágenes de los sistemas que ejecutaron los paquetes afectados para eliminar cualquier error. artefactos de segunda etapa.

El episodio destaca cómo una plataforma conocida, npm, puede aprovecharse junto con Ethereum para enmascarar el rastro entre una dependencia y su host de carga útil. Con los datos en cadena como un indicador resistente, los defensores se ven obligados a correlacionar Comportamiento del paquete, señales de GitHub y lecturas de blockchain para detectar lo que las comprobaciones estáticas simples pasan por alto.

Artículos Relacionados: