NAP Latino

Publicado el 24 de agosto de 2026 · Revisado el 24 de agosto de 2026

14 paquetes de npm escondían un backdoor para Linux con un "agente de IA" propio: así se instalaba solo con hacer `npm install`

Investigadores de TrendAI Research descubrieron 14 paquetes de npm disfrazados de utilidades de calendario y cálculo de rachas que instalaban en silencio RedC2 4.0, un backdoor para Linux con proxy SOCKS5, robo de llaves SSH y un componente de "agente de IA" que traduce instrucciones en lenguaje natural a acciones de post-explotación. No hacía falta ejecutar ningún script sospechoso: bastaba con importar el paquete en un proyecto Node.js corriendo en un servidor Linux.

Si administras un servidor Linux y corres aplicaciones Node.js, probablemente ejecutas npm install varias veces por semana sin pensarlo dos veces — es el gesto más rutinario del desarrollo web moderno. Investigadores de TrendAI Research acaban de documentar por qué ese gesto también puede ser el punto de entrada de un backdoor completo: encontraron 14 paquetes de npm que, disfrazados de simples utilidades de calendario y cálculo de rachas ("streak calculators", populares en apps de hábitos y productividad), instalaban en silencio un implante malicioso diseñado específicamente para tomar control de servidores Linux.

Cómo logra pasar desapercibido

Lo que hace especial a esta campaña no es el malware en sí, sino cómo evita las defensas que existen justamente para detectar este tipo de ataque. Desde hace años, npm y las herramientas de seguridad vigilan de cerca los "scripts de ciclo de vida" —los postinstall, preinstall y similares que un paquete puede ejecutar automáticamente al instalarse—, porque es el vector clásico de un ataque a la cadena de suministro. Estos 14 paquetes no usan ninguno de esos scripts. En su lugar, el código malicioso vive dentro del propio archivo de entrada del paquete (dist/index.mjs): en cuanto tu aplicación hace un simple import de la librería, una rutina se activa sola, localiza un binario que viene empaquetado junto al código, le cambia los permisos para hacerlo ejecutable, verifica su huella criptográfica (SHA-256) y lo lanza como proceso independiente. Ningún antivirus de dependencias que solo revise scripts de instalación lo va a detectar.

Ese binario es RedC2 4.0, y sus capacidades son las de una herramienta de post-explotación completa: puede convertir el servidor infectado en un proxy SOCKS5 con un simple comando, redirigir tráfico de un puerto a otro, abrir shells inversos hacia el atacante, y robar llaves SSH y credenciales guardadas en navegadores. Toda la comunicación con el servidor de mando y control —una IP fija en el puerto 8792— viaja cifrada con TLS, aunque sin validar el certificado, y el código interno usa ofuscación con XOR para dificultar el análisis. Para sobrevivir a un reinicio, se instala usando tareas cron programadas para @reboot, modificaciones al .bashrc, o servicios de systemd a nivel de usuario — varias rutas distintas, para que baste con que una sobreviva.

El detalle que más le preocupa a los investigadores: un "agente" que decide solo

Lo que distingue a esta versión de campañas anteriores de malware para Linux es un componente que los investigadores llaman "Red Agent": un módulo que traduce un objetivo escrito en lenguaje natural —por ejemplo, "buscar credenciales de base de datos en este servidor"— en una secuencia ordenada de acciones que el implante ejecuta por su cuenta. En la práctica, reduce el trabajo manual que antes le tomaba a un atacante humano decidir, paso a paso, qué hacer después de comprometer una máquina.

Qué revisar si administras servidores Node.js en Linux

TrendAI recomienda tres cosas concretas: revisar el árbol completo de dependencias del proyecto (no solo las directas, también las que arrastran esas dependencias), buscar archivos binarios ELF sospechosos dentro de las carpetas dist/ de los paquetes instalados, y monitorear si el servidor abre conexiones salientes hacia la IP y los puertos identificados en la investigación. También vale la pena revisar tareas cron, entradas de .bashrc y servicios de systemd que no reconozcas — son justo los lugares donde este tipo de implante se esconde para sobrevivir a un reinicio.

La lección de fondo no es dejar de usar npm, sino tratar cada npm install con el mismo criterio con el que revisarías un archivo ejecutable que te llega por correo: si el paquete es poco conocido y hace algo que se podría resolver con diez líneas propias, escribir esas diez líneas sigue siendo más seguro que confiar a ciegas en la cadena de dependencias de otro.

Conoce los planes de VPS de NAP Latino.