Una campaña de cadena de suministro en npm utiliza paquetes que imitan utilidades de PostCSS para ejecutar código durante la instalación y descargar un RAT orientado a Windows. El riesgo aumenta en equipos de desarrollo y en CI/CD, donde la instalación de dependencias puede exponer credenciales y tokens.
Una nueva campaña de cadena de suministro ha puesto el foco en npm con paquetes maliciosos que se camuflan como utilidades relacionadas con PostCSS y activan su carga durante un gesto tan cotidiano como un npm install. El gancho no está en un exploit sofisticado, sino en una práctica habitual del ecosistema: los scripts de ciclo de vida, como postinstall, que pueden ejecutarse automáticamente al instalar dependencias.
El patrón encaja con ataques recientes contra repositorios de paquetes: el código se dispara en el momento de la instalación, contacta con una infraestructura de mando y control (C2) y baja una segunda fase adaptada al sistema operativo. En este caso, el objetivo principal se concentra en Windows, donde la cadena de infección suele apoyarse en PowerShell para descargar componentes, lanzar la carga útil y preparar mecanismos de persistencia. El resultado es un troyano de acceso remoto (RAT), una herramienta que permite al atacante controlar el equipo, ejecutar comandos y moverse por el sistema con discreción.
El impacto no se limita al portátil del desarrollador. Los entornos de CI/CD también quedan en la diana porque instalan dependencias de forma desatendida y suelen manejar tokens, credenciales de despliegue y accesos a servicios internos. Un único paquete contaminado en el árbol de dependencias puede convertir un pipeline en un punto de entrada, con capacidad para escalar el incidente hacia repositorios, artefactos de compilación o infraestructura.
Los análisis describen además rutinas pensadas para complicar el trabajo posterior: tras ejecutarse, algunos paquetes eliminan o sustituyen metadatos y señales visibles para pasar más desapercibidos en node_modules. Aun así, la campaña deja rastros aprovechables para caza proactiva, como dominios, IPs, rutas de descarga y ficheros temporales asociados al descargador y a la carga final.
La respuesta defensiva pasa por medidas poco glamurosas, pero eficaces. Conviene inventariar dependencias y revisar el árbol en busca de nombres que imiten librerías populares o incorporaciones recientes sin justificación técnica. También ayuda fijar versiones exactas en package.json y evitar rangos con ^ o ~, que abren la puerta a actualizaciones automáticas no revisadas. Cuando el proyecto lo permita, se puede desactivar la ejecución de scripts durante la instalación con opciones como ignore-scripts, y reforzar dependencias transitivas con overrides.
En paralelo, las organizaciones deberían revisar logs de estaciones y pipelines para detectar instalaciones sospechosas, controlar el tráfico saliente hacia infraestructura asociada a campañas de npm, y, si existe la sospecha de ejecución, aislar equipos y rotar secretos. En ataques de este tipo, el coste real suele llegar después: cuando el atacante ya ha tenido tiempo de leer tokens, moverse por la red y persistir donde menos se mira.
Más información
- The Hacker News – Google Attributes Axios npm Supply Chain Attack to North Korean Group UNC1069 : https://thehackernews.com/2026/04/google-attributes-axios-npm-supply.html
- Microsoft Security Blog – Mitigating the Axios npm supply chain compromise : https://www.microsoft.com/en-us/security/blog/2026/04/01/mitigating-the-axios-npm-supply-chain-compromise/
- ReversingLabs – Malicious npm packages use fake install logs to load RAT : https://www.reversinglabs.com/blog/npm-fake-install-logs-rat
Deja una respuesta