Supply chain attack compromete 127 paquetes NPM populares
Investigadores de seguridad descubren una campaña coordinada de compromiso de cadena de suministro que afecta a 127 paquetes NPM con más de 50 millones de descargas semanales combinadas. El malware exfiltraba credenciales de AWS y tokens de CI/CD.
El ataque
El equipo de seguridad de Socket.dev ha descubierto y divulgado esta semana una de las campañas de supply chain attack más sofisticadas dirigidas al ecosistema NPM hasta la fecha. Un actor de amenaza no identificado, con características técnicas consistentes con un grupo de estado-nación, comprometió las cuentas de mantenedores de 127 paquetes populares de Node.js y publicó versiones maliciosas que permanecieron activas entre 6 y 18 horas antes de ser detectadas.
Los paquetes afectados incluyen utilidades de desarrollo ampliamente utilizadas en pipelines de CI/CD, herramientas de testing, plugins de frameworks web y librerías de utilidades generales. Combinados, los paquetes comprometidos suman más de 50 millones de descargas semanales.
Método de compromiso
La investigación de Socket revela que los atacantes emplearon una combinación de credential stuffing y ataque de recuperación de cuenta. Los mantenedores de los paquetes objetivo no tenían habilitado 2FA en sus cuentas de NPM —una práctica aún demasiado común— lo que permitió a los atacantes tomar el control mediante credenciales filtradas en breaches previos.
Una vez con acceso a las cuentas, los atacantes publicaron versiones con patches de un solo dígito (ej: de 2.4.1 a 2.4.2) para minimizar la visibilidad del cambio. Las versiones maliciosas incluían el código original del paquete sin modificaciones funcionales, con el payload malicioso ofuscado insertado en la función de inicialización.
El payload malicioso
El malware insertado en los paquetes comprometidos implementaba varias capacidades:
Exfiltración de credenciales cloud: Al ejecutarse en entornos CI/CD como GitHub Actions, GitLab CI o Jenkins, el código buscaba automáticamente variables de entorno con nombres asociados a credenciales: `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `GOOGLE_APPLICATION_CREDENTIALS`, tokens de GitHub y GitLab, y claves de API de servicios populares.
Persistencia en entornos de desarrollo: En máquinas de desarrolladores que instalaran los paquetes localmente, el malware también buscaba y exfiltraba archivos de configuración de AWS (`~/.aws/credentials`), tokens de Git almacenados localmente y credenciales de Docker.
Beacon a infraestructura C2: Todas las credenciales capturadas se enviaban cifradas a una red de servidores C2 distribuidos a través de Tor y servicios de storage cloud legítimos como Amazon S3 y Cloudflare R2, dificultando la detección de red.
Alcance del impacto
NPM y sus socios de seguridad han podido determinar que aproximadamente 23.000 proyectos únicos instalaron al menos una de las versiones comprometidas durante la ventana de exposición. Dada la naturaleza de los proyectos afectados —principalmente herramientas de desarrollo y CI/CD— el impacto potencial va mucho más allá de los sistemas que instalaron el paquete directamente.
Varias organizaciones Fortune 500 han confirmado que sus pipelines de CI/CD instalaron paquetes comprometidos, y algunos ya han iniciado procesos de rotación de credenciales cloud y revisión de accesos no autorizados en sus cuentas de AWS y GCP.
Respuesta y lecciones aprendidas
NPM (propiedad de GitHub/Microsoft) ha publicado un comunicado confirmando la eliminación de todas las versiones maliciosas y la implementación de un bloqueo temporal de publicaciones en las cuentas comprometidas. La plataforma también ha anunciado que a partir del 1 de abril de 2026, los paquetes con más de 500.000 descargas semanales tendrán habilitado 2FA obligatorio para los mantenedores.
Acciones recomendadas para equipos de desarrollo:
- Auditar el historial de instalaciones en pipelines CI/CD de los últimos 7 días y comparar hashes de paquetes instalados contra la lista de versiones comprometidas publicada por Socket
- Rotar inmediatamente todas las credenciales cloud y tokens de API que hayan estado presentes como variables de entorno en los pipelines afectados
- Habilitar 2FA en todas las cuentas de NPM de mantenedores del equipo
- Implementar lockfiles (`package-lock.json`) con verificación de integridad (npm ci) en pipelines de producción
- Considerar el uso de herramientas de análisis de dependencias como Snyk, Socket o Dependabot con alertas en tiempo real para detección temprana de paquetes comprometidos
Este incidente refuerza la necesidad de tratar las dependencias de software de terceros como vectores de ataque potenciales, no como código de confianza implícita.
Recibe el mejor contenido tech cada mañana
Gratis · Sin spam · Cancela cuando quieras