Campaña de npm instala RedC2 4.0 al importar paquetes maliciosos

Investigadores en ciberseguridad han hallado una campaña de paquetes maliciosos en el ecosistema npm que, a primera vista, proporcionan utilidades de calendario y cálculo pero en realidad sirven como vehículo para instalar un implante Linux de control remoto llamado RedC2 4.0 (con su beacon Linux RedShell). El hallazgo fue difundido públicamente por el equipo de investigación de Trend Micro y confirma que la ejecución del malware ocurre simplemente al importar el paquete en una cadena de dependencias, incluso de forma transitiva.

Hechos confirmados: Trend Micro reportó que una docena de paquetes publicados en npm contienen un binario empaquetado (con nombres como math-core.bin, calc.bin o calc-mapping.bin ubicados en dist/ o dist/internal/) que es marcado como ejecutable y lanzado en segundo plano cuando el módulo se carga. Los paquetes identificados incluyen, entre otros, streak-metrics-math@1.0.0, kit-map-vim@1.0.0, streak-map-cache@1.0.0 y una lista completa informada por la investigación. El archivo de entrada que actúa como cargador troiano es dist/index.mjs: basta con que cualquier módulo en la cadena de dependencias importe ese paquete para que el implante se ejecute, sin necesidad de hooks de instalación ni llamadas explícitas a funciones exportadas.

Técnicamente, el mecanismo descrito es simple y eficaz en entornos JavaScript/Node: el módulo expone funcionalidades legítimas (por ejemplo, funciones de fechas o métricas) pero en su inicialización realiza operaciones sobre el binario incluido —cambia permisos (chmod), lo lanza con spawn como proceso desasociado y termina su propia ejecución—. Así el paquete sigue cumpliendo su promesa funcional y pasa desapercibido en revisiones superficiales, mientras establece una conexión saliente a un servidor de mando y control (C2) para recibir órdenes.

Sobre la carga útil: el binario desplegado es la variante Linux del framework RedC2 en su versión 4.0, que incorpora el beacon RedShell. Según la descripción técnica difundida, la implant ofrece control remoto interactivo (/bin/sh), exfiltración de datos (incluyendo claves SSH y credenciales de navegadores), ejecución en memoria de ELF y shellcode, proxy SOCKS5 y funcionalidades de pivoting y tunneling entre hosts. RedC2 incluye además componentes para Windows y macOS con capacidades similares; la versión para Windows añade evación de control de cuentas (UAC bypass), técnicas para interferir con antivirus y movimiento lateral más avanzado.

Un aspecto que preocupa especialmente a los investigadores es la integración de una capa asistida por modelos de lenguaje: Red Agent, un componente LLM que transforma instrucciones en lenguaje natural en secuencias de comandos y comandos del beacon. Trend Micro y el investigador Aliakbar Zahravi han señalado que esa abstracción reduce la pericia técnica necesaria para operar el C2, facilitando intrusiones complejas a operadores con menos experiencia.

¿A quién afecta esto? Confirmado: cualquier proyecto que dependa directa o indirectamente de los paquetes listados y que ejecute código en entornos Linux —especialmente servidores, contenedores y pipelines de integración continua que instalan dependencias automáticamente— corre riesgo de ejecutar la implant. El vector es peligroso porque un simple "import" o "require" en una dependencia transitiva activa el binario. Por tanto, no solo usuarios que instalen a mano los paquetes maliciosos están en riesgo; repositorios, imágenes base y entornos de producción que actualicen o reconstruyan dependencias sin filtrado también pueden verse comprometidos.

Consecuencias prácticas: en sistemas comprometidos, los operadores pueden obtener shells interactivos, robar credenciales, desplegar cargas adicionales, mover lateralmente y establecer persistencia. A nivel de cadena de suministro, el vector permite que el malware se propague hacia proyectos legítimos que incluyan estas dependencias en su árbol. Además, la presencia de un asistente AI integrado puede acelerar operaciones a escala y hacer más difícil detectar patrones de actividad humana frente a automatizada.

Lo confirmado vs. lo estimado: está confirmado que los paquetes ejecutan un binario RedShell y que RedC2 4.0 se ha promocionado públicamente; también se ha documentado la lista de paquetes afectados. Es una estimación, aunque plausiblemente fundada, que estas publicaciones representen una campaña intencional de distribución de malware mediante paquetes npm. La atribución a actores o vinculaciones con ataques previos delictivos se mantiene como sospecha en informes relacionados sobre otras campañas de la cadena de suministro, pero no se han presentado pruebas públicas concluyentes que permitan atribuirlo de forma definitiva.

Medidas concretas e inmediatas que deben tomar desarrolladores y administradores:

1) Identificar exposición inmediata. En repositorios y servidores, busque la presencia de las librerías concretas y de los nombres de binarios reportados. Ejemplos de búsquedas útiles: listar dependencias con npm ls streak-metrics-math o escanear node_modules por patrones como "math-core.bin" o "dist/index.mjs" (por ejemplo, grep -R "math-core.bin" node_modules/). Revise los locks (package-lock.json / yarn.lock) para versiones citadas.

2) Contener y eliminar. Si detecta presencia de los paquetes o de binarios sospechosos, aísle la máquina de la red, preserve imágenes y logs para análisis forense y elimine los paquetes de los entornos afectados. Reemplace artefactos reconstruyendo imágenes desde fuentes limpias y verificadas en entornos aislados.

3) Revisar y endurecer pipelines. Evite instalaciones automáticas sin revisión en entornos productivos. Configure políticas de bloqueo/allowlist en registries internos, utilice verificación de integridad (hashes), habilite 2FA para cuentas de publicación y restrinja privilegios de CI para la publicación de paquetes. Implemente escaneo de dependencias con herramientas como Snyk, Dependabot o Sonatype y valide artefactos antes de promover a producción.

4) Monitorizar e intentar detección. Bloquee comunicaciones salientes sospechosas en firewalls (especialmente a servidores C2) y monitorice procesos hijos inesperados que ejecuten binarios desde dist/ en node_modules. Actualice reglas EDR/AV para detectar RedShell/RedC2 y patterns de ejecución de binarios empaquetados.

5) Rota credenciales y privilegios. Tras una posible intrusión, considere la rotación de claves y credenciales (APIs, SSH), y revise usuarios y accesos. Evalúe la necesidad de reconstruir sistemas comprometidos en lugar de limpiarlos en caliente.

Recomendaciones estratégicas a mediano plazo: utilice registries privados y firmas de paquetes para entornos críticos; adopte enfoques reproducibles para builds (bloqueo de versiones y SLSA o firmas) y aplique controles de confianza a los mantenedores de paquetes. La comunidad de seguridad también necesita mejorar la detección de binarios empaquetados en módulos que se prometen como librerías puramente JavaScript.

Contexto adicional: esta intrusión encaja en una tendencia mayor de ataques a la cadena de suministro de software (en distintos ecosistemas como npm y crates.io). En meses recientes se han documentado incidentes donde paquetes legítimos fueron comprometidos para insertar código malicioso que se ejecuta durante compilaciones o instalaciones automáticas. Para referencia general sobre riesgos y buenas prácticas en cadena de suministro, consulte proyectos de la industria como OWASP Software Supply Chain (https://owasp.org/www-project-supply-chain-security/) y documentación oficial de npm (https://www.npmjs.com/). El informe original del análisis técnico fue publicado por Trend Micro; su página de investigación ofrece detalles adicionales y actualizaciones (https://www.trendmicro.com/en_us/research.html).

En resumen: la amenaza demuestra que los paquetes aparentemente inocuos pueden portar implantes potentes y que la ejecución automática —incluso por importaciones transitivas— facilita compromisos a gran escala. La respuesta eficaz exige detección proactiva en repositorios y pipelines, bloqueo de dependencias no verificadas y procedimientos claros para contener y recuperar sistemas afectados.