Un nuevo hallazgo en ciberseguridad alerta sobre el riesgo de la cadena de suministro de software en JavaScript. Investigadores identificaron paquetes npm troyanizados que se presentan como herramientas legítimas de calendario y seguimiento de rachas, pero en realidad están diseñados para desplegar un implante malicioso en Linux. El objetivo final es habilitar control remoto mediante una infraestructura C2 (command and control) descrita como RedC2 4.0, con funciones asistidas por IA para automatizar tareas posteriores a la intrusión.
Lo relevante no es solo que el código sea malicioso, sino cómo se activa. Estos paquetes ofrecen la funcionalidad prometida, lo que puede reducir sospechas, y aun así ejecutan un payload al cargarse el módulo, sin necesidad de “ganchos” de instalación ni llamadas a funciones exportadas.
Qué son los paquetes npm troyanizados
Los investigadores detectaron varios nombres de paquetes que imitan utilidades conocidas: métricas, mapas, cálculos y cachés para rachas y fechas. En su superficie, el comportamiento parece coherente con la descripción de producto. Sin embargo, debajo de esa apariencia existe un mecanismo de carga que termina entregando un implante para Linux.
Entre los paquetes señalados se encuentran, por ejemplo, streak-metrics-math, streak-map-cache, streak-calc-metrics y streak-math-abz, además de combinaciones similares orientadas a “mapas” y “cálculos”. Muchos de ellos comparten la misma estructura interna, aunque el nombre del archivo del binario incrustado cambia según el paquete.
Cómo se ejecuta el payload sin instalar “hooks”
El punto técnico clave del informe es el modo de activación. Cuando el módulo se carga, el código localiza el binario incluido, lo marca como ejecutable y lo inicia como un proceso en segundo plano separado (detached). Esto ocurre de forma automática durante la carga del módulo, no como parte de una fase visible de instalación.
Según lo descrito por Trend Micro en su línea empresarial (TrendAI), no se requiere una función de instalación específica. Basta con que exista una importación en cualquier punto del grafo de dependencias: incluso si la importación es transitiva (es decir, indirecta), el payload puede llegar a ejecutarse en el entorno del usuario.
Además, el archivo de entrada del paquete que ejecuta la lógica maliciosa es dist/index.mjs. Su papel funciona como un cargador troyano: reexporta los helpers de fecha y, al mismo tiempo, lanza el implante incluido inmediatamente al cargar el módulo.
RedC2 4.0: el implante Linux y su papel como C2
El binario incrustado en cada paquete esconde la misma finalidad: introducir el beacon Linux asociado con RedC2 4.0. Los investigadores señalan que el binario puede residir directamente en dist/ o dentro de dist/internal/, pero su contenido guarda la conexión con RedShell, el componente Linux de RedC2 4.0.
En términos operativos, el beacon se comunica con un servidor remoto —en Windows o Linux— para apoyar actividades posteriores a la intrusión en la máquina comprometida. Es decir, el paquete troyanizado no solo entrega malware: habilita una capa de control remoto que permite coordinar acciones desde un operador externo.
Qué promete RedC2 4.0 en foros
RedC2 4.0 fue promocionado en foros de cibercrimen como un kit multiplataforma (Windows, macOS y Linux). En esas descripciones, se presenta como un marco C2 “construido para evadir” defensas, y se señala que incluye capacidades de vigilancia, robo de credenciales, carga de payloads y operaciones masivas.
Los hallazgos también contextualizan que el desarrollo no es reciente: se vendieron versiones anteriores (por ejemplo, 2.0 en agosto de 2025 y 3.0 a inicios de enero de 2026). En la narrativa del informe, la versión 4.0 incorpora el beacon Linux.
Funciones de C2: más allá de la simple puerta trasera
La infraestructura de mando y control de RedC2 se describe como rica en funciones. Entre ellas figuran acceso al terminal, transferencia de archivos, entrega escalonada de payloads, recopilación de datos, operación con múltiples beacons y visualización de red.
También se mencionan capacidades como tunneling host a host y ejecución en memoria de formatos como BOFs (Beacon Object Files), ensamblados .NET y shellcode. En conjunto, esto apunta a un diseño orientado a facilitar el trabajo del operador sin depender únicamente de binarios externos en disco.
Qué hace el beacon en Linux
Una vez desplegado el beacon en Linux, proporciona una shell interactiva mediante /bin/sh. Desde ahí expone comandos específicos para reconocimiento del sistema, operaciones de archivos y recolección de información.
El informe detalla que puede recopilar datos sensibles, incluyendo llaves SSH y credenciales asociadas a navegadores. Además, contempla mecanismos para persistencia y ejecución en memoria de binarios ELF. Para el movimiento dentro de redes, también se describe soporte para un proxy SOCKS5 y pivoting de red.
En cuanto a la comunicación, el beacon reúne información básica del sistema, envía un mensaje de “check-in” al servidor C2 para registrarse y, después, entra en un bucle de procesamiento: recibe instrucciones, las ejecuta con /bin/sh y devuelve los resultados.
Diferencias con los componentes de Windows y macOS
El informe indica que las variantes para Windows y macOS abarcan funciones similares: operaciones de archivos, reconocimiento del host y de la red, enumeración de usuarios y recolección de datos. No obstante, la variante de Windows incorpora características adicionales que no aparecen en la de macOS, como bypass de UAC, manipulación o interferencia con antivirus/endpoint detection, ejecución en memoria y movimiento lateral.
En otras palabras, aunque el objetivo general se mantiene, el arsenal se adapta al sistema comprometido.
IA para simplificar el trabajo del operador
Uno de los elementos que destaca del caso es la capa asociada a IA. En la descripción pública del actor responsable, se presenta un componente llamado Red Agent, descrito como un sistema apoyado por un modelo grande de lenguaje (LLM) que permite transformar instrucciones naturales en comandos ejecutables dentro del framework.
De acuerdo con el informe, el operador interactúa con una interfaz orientada a intención en lenguaje natural. El sistema traduce esas solicitudes en secuencias de comandos útiles para el C2, haciendo más accesible la ejecución de intrusiones complejas y de múltiples etapas, incluso para personas con menos experiencia.
Esto amplía el impacto del ataque: no solo se entrega un implante, sino que se reduce la barrera para orquestar acciones posteriores, como reconocimiento de red o extracción de credenciales.
Por qué este caso preocupa: cadena de suministro y “barrera de entrada”
El núcleo del problema está en la distribución. Los paquetes npm troyanizados aparecen como software funcional y útil, lo cual puede hacer que pase desapercibido en procesos de instalación que no validen orígenes o firmas de dependencias. Al ejecutarse en el momento de cargar el módulo, se vuelve especialmente difícil detectar el comportamiento desde el simple “instalado correcto”.
Además, el uso de un framework C2 con capacidades modernas sugiere un enfoque de atacante más profesional. La combinación entre entrega desde npm, ejecución automática y automatización asistida por IA incrementa la probabilidad de que el ataque escale.
Relación con otros incidentes de supply chain
El informe también menciona un antecedente cercano: un ataque coordinado a tres crates legítimos de Rust (arrayref, internment y append-only-vec) que fueron comprometidos mediante una dependencia maliciosa en forma de proc-macro. Allí, el código malicioso se ejecutaba durante el proceso de construcción (cargo build) y también estaba orientado a operaciones en sistemas reales, como perfilado del dispositivo, recopilación de navegadores basados en Chromium, persistencia y comunicación con infraestructura controlada por atacantes.
Se sugiere que existe solapamiento de infraestructura con campañas previas vinculadas a actores norcoreanos relacionados con Mastra y Axios, según la evidencia referida en el informe. El objetivo de incluir esta comparación es contextualizar que la cadena de suministro sigue siendo un vector persistente y en evolución.
Recomendaciones prácticas para equipos y desarrolladores
Ante incidentes como este, la mejor defensa suele ser prevenir la ejecución de dependencias no confiables y aumentar la visibilidad. Algunas acciones concretas que ayudan:
- Revisar el árbol de dependencias para detectar imports indirectos que puedan activar comportamiento inesperado.
- Verificar procedencia de paquetes y mantener políticas de confianza (por ejemplo, limitar fuentes y usar registros/feeds internos).
- Aplicar escaneo de dependencias en el pipeline CI/CD, incluyendo análisis de comportamiento cuando sea posible.
- Monitorear ejecuciones inusuales durante la carga o ejecución de módulos (procesos en segundo plano, binarios extraídos desde dist/, etc.).
- Practicar respuesta ante incidentes con pautas claras para aislar hosts y revisar indicadores en endpoints.
Estas medidas no eliminan por completo el riesgo, pero reducen significativamente la probabilidad de que un paquete malicioso pase sin ser detectado.
Conclusión
El caso de RedC2 4.0 demuestra cómo los paquetes npm troyanizados pueden combinar apariencia legítima, ejecución automática y entrega de un C2 con capacidades avanzadas, incluyendo componentes asistidos por IA. Para organizaciones y desarrolladores, el aprendizaje es directo: no basta con que una dependencia “funcione”. Es imprescindible evaluar su comportamiento, su integridad y su contexto dentro del grafo de dependencias.
Si usas npm en proyectos en producción, fortalece tus controles de cadena de suministro ahora: revisa dependencias, escanea con regularidad y crea una estrategia de monitoreo que detecte señales tempranas antes de que el C2 establezca control persistente.
Fuente: https://thehackernews.com/2026/08/14-trojanized-npm-packages-drop-redc2.html
