Los ciberdelincuentes están utilizando redes de blockchain públicas como una capa de comando y control (C2) para malware de cadena de suministro. Este método les permite cambiar su infraestructura sin modificar el código malicioso en los sistemas infectados, facilitando la redirección del robo de datos hacia nuevos servidores y haciendo que las listas de bloqueo de dominios tradicionales sean menos efectivas.

Los actores de amenazas están convirtiendo cada vez más las redes públicas de blockchain en una capa de comando y control (C2) para el malware de la cadena de suministro de software, lo que les ayuda a rotar la infraestructura sin cambiar el código malicioso que ya se está ejecutando en los sistemas de los desarrolladores.

Este método ofrece a los criminales una forma resistente de dirigir los paquetes infectados hacia nuevos servidores de robo de datos, haciendo que las listas de bloqueo de dominios tradicionales sean menos efectivas. El riesgo es especialmente grave para las organizaciones centradas en la nube.

Los paquetes de código abierto envenenados pueden ejecutarse dentro de los portátiles de los desarrolladores y en los flujos de trabajo de CI/CD, donde pueden acceder a tokens de identidad temporales de la nube, secretos de despliegue, claves de cuentas de servicio, credenciales de GitHub y otros datos de alto valor.

Una investigación reciente sobre el gusano npm ChainDrop mostró cómo las rutas de publicación confiables comprometidas pueden convertir las actualizaciones de dependencias ordinarias y la configuración de los proyectos en una ruta para el robo de credenciales.

Analistas de Unit 42 identificaron el malware ChainDrop como un gusano npm de autopropagación que infectó más de 400 paquetes.

Los investigadores descubrieron que recolectaba credenciales de la nube, tokens de npm y GitHub, claves SSH, tokens de Kubernetes, archivos de estado de Terraform, tokens de Vault y secretos almacenados en entornos de desarrollo.

También buscó en la memoria de los procesos ejecutores de GitHub Actions tokens de OpenID Connect (OIDC) de corta duración y secretos del ejecutor.

Utilizan Web3 y C2 de Blockchain

En una operación de malware normal, los atacantes codifican un dominio o una dirección IP directamente en el malware. Eso crea un objetivo claro para los defensores: los equipos de seguridad pueden bloquear la dirección, los registradores pueden suspender el dominio y las plataformas de paquetes pueden escanear el código en busca de ello.

El C2 de blockchain cambia ese modelo. En lugar de contener una dirección de C2 fija, el malware consulta un contrato inteligente o una transacción de blockchain y recupera el destino actual en tiempo de ejecución.

ChainDrop utilizó este enfoque a través de un contrato inteligente de Ethereum. Unit 42 señaló que el gusano consultaba el contrato para obtener la dirección utilizada para el robo de datos, y luego trasladó su C2 de npm-cache[.]com a awqhnjewqjkl[.]icu mediante una sola transacción de Ethereum.

El cambio no requirió que los atacantes vuelvan a publicar los paquetes ni que enviaran una nueva versión del malware a las víctimas. Esta técnica se conoce comúnmente como EtherHiding.

Esto no significa que la blockchain en sí sea maliciosa; más bien, los criminales abusan de su diseño público y descentralizado como una agenda de direcciones, un almacén de carga útil o un servicio de entrega anónima.

Un informe anterior sobre la entrega de malware EtherHiding describió cómo los contratos inteligentes pueden devolver cargas útiles de JavaScript codificadas y permitir que los operadores cambien el contenido de entrega sin modificar un sitio web comprometido.

ChainDrop apunta a los flujos de trabajo de desarrollo

La infección de ChainDrop comienza con un paquete npm alterado que contiene un comando preinstall. Ese comando lanza setup.mjs, que descarga el entorno de ejecución JavaScript Bun legítimo si no está presente y lo utiliza para ejecutar una carga útil ofuscada. Bun no fue comprometido; los actores de amenazas simplemente utilizaron el entorno de ejecución legítimo para ejecutar su código.

Una vez activo, el malware revisa archivos locales, variables de entorno y servicios de metadatos de la nube en busca de credenciales. También analiza los procesos de construcción en ejecución, un detalle importante porque los sistemas de CI/CD suelen utilizar credenciales temporales que no permanecen en el disco.

Esos tokens aún pueden dar a los atacantes una ruta directa a las API de la nube, entornos de despliegue o sistemas de código fuente mientras sean válidos.

ChainDrop también estableció persistencia a través de herramientas de desarrollo. Escribió una tarea de VS Code que puede ejecutarse cuando se abre una carpeta y añadió un hook de SessionStart de Claude Code.

Eso significa que tú, como desarrollador, podrías activar el malware simplemente abriendo un proyecto o iniciando una sesión de codificación con IA. El mismo riesgo aparece en la exposición de la configuración de herramientas de desarrollo reportada en la campaña más amplia de ChainDrop, donde archivos de proyecto locales confiables se convirtieron en una ruta de ejecución.

Una segunda campaña, rastreada como PolinRider, muestra que este modelo está yendo más allá de npm. Los investigadores vincularon la campaña con actividades alineadas con Corea del Norte y encontraron cargadores maliciosos en npm, Packagist, módulos de Go y extensiones de Chrome.

Los cargadores utilizaron blockchain y servicios RPC públicos conectados a TRON, Aptos y BNB Smart Chain para obtener cargas útiles posteriores cifradas.

La campaña ocultó su código en archivos que parecían normales para muchos desarrolladores, incluyendo vite.config.js, archivos de fuentes .woff2 falsos y .vscode/tasks.json.

Este enfoque es relevante porque muchas herramientas de escaneo de dependencias se centran en los manifiestos de paquetes y los lockfiles, no en la configuración del editor, la automatización del espacio de trabajo o la configuración del repositorio.

La campaña anterior de cargadores de JavaScript ocultos también mostró cómo PolinRider utilizó tales archivos para entregar las cargas útiles DEV#POPPER y OmniStealer.

Para quienes defienden los sistemas, el tráfico de blockchain desde los ejecutores de construcción y los endpoints de desarrolladores debe tratarse como una señal significativa cuando la organización no tiene una necesidad comercial de Web3.

Deberías revisar los scripts del ciclo de vida de los paquetes, inspeccionar los archivos de configuración del repositorio, aislar los ejecutores de CI, restringir las conexiones salientes de los sistemas de construcción y rotar cada credencial accesible desde un host afectado.

Fuentes:
https://cybersecuritynews.com/hackers-use-web3/