**Campaña Shai-Hulud II en NPM: 400.000 secretos expuestos y 30.000 repositorios comprometidos**
—
### 1. Introducción
Durante la última semana, el ecosistema de desarrollo Node.js ha sido sacudido por una nueva y sofisticada campaña de ataques de la familia Shai-Hulud que ha comprometido la integridad del registro NPM. Los atacantes lograron infiltrar cientos de paquetes maliciosos en NPM, extrayendo aproximadamente 400.000 secretos sensibles (tokens, claves API, credenciales) y publicando los datos exfiltrados en más de 30.000 repositorios de GitHub. Este incidente pone de manifiesto la fragilidad de la cadena de suministro software y la necesidad de robustecer los mecanismos de seguridad en los entornos DevOps.
—
### 2. Contexto del Incidente
La campaña Shai-Hulud no es nueva, pero esta segunda oleada ha demostrado una capacidad de propagación y automatización sin precedentes. El ataque se produce en un contexto de creciente dependencia de paquetes de código abierto, donde la confianza en los repositorios públicos como NPM es fundamental para los equipos de desarrollo y los sistemas en producción. Según datos de NPM Inc., el registro alberga más de 2 millones de paquetes y gestiona más de 20.000 millones de descargas semanales, lo que convierte cualquier brecha de seguridad en un asunto crítico para toda la industria.
El vector de ataque consiste en la publicación de paquetes NPM aparentemente legítimos pero que contienen payloads diseñados para recolectar secretos presentes en los entornos donde se instalan. Posteriormente, estos secretos son exfiltrados y publicados de forma automatizada en repositorios de GitHub controlados por los atacantes, a modo de “dump” público.
—
### 3. Detalles Técnicos
#### CVEs y Paquetes Afectados
Aunque no se ha asignado un CVE específico al ataque Shai-Hulud II, la vulnerabilidad explotada es la confianza ciega en la procedencia y el contenido de los paquetes NPM. De acuerdo con los análisis realizados por varios equipos de threat intel, los paquetes maliciosos incluían scripts postinstall en JavaScript y Node.js que exploraban el entorno local (`process.env`) y buscaban patrones de autenticación (AWS_ACCESS_KEY, GCP_CREDENTIALS, SSH_PRIVATE_KEY, etc.).
#### Vectores de Ataque y TTPs
Los atacantes utilizaron técnicas de *typosquatting* y *dependency confusion*, publicando paquetes con nombres similares a librerías populares o internas de grandes organizaciones. El payload recogía variables de entorno y archivos de configuración presentes en el sistema antes de volcarlos a endpoints externos y, posteriormente, automatizaba la publicación de los secretos robados en 30.000 repositorios GitHub creados ad hoc.
La operación muestra una clara alineación con las técnicas MITRE ATT&CK:
– **T1195 – Supply Chain Compromise**
– **T1074 – Data Staged**
– **T1041 – Exfiltration Over C2 Channel**
– **T1087 – Account Discovery**
#### Indicadores de Compromiso (IoC)
– Nombres de paquetes NPM sospechosos con errores tipográficos leves.
– Presencia de scripts postinstall no documentados.
– Conexiones salientes hacia dominios y direcciones IP asociadas a infraestructura atacante.
– Aparición de secretos corporativos en repositorios GitHub no autorizados.
—
### 4. Impacto y Riesgos
La exposición de 400.000 secretos supone un riesgo crítico para la seguridad operacional de organizaciones de todos los tamaños. Las credenciales comprometidas pueden facilitar desde escaladas de privilegios hasta despliegues de ransomware, movimientos laterales y ataques directos a servicios cloud (AWS, Azure, GCP). El hecho de que los secretos se hayan publicado en GitHub multiplica el impacto potencial, ya que cualquier actor malicioso puede acceder a ellos.
Se estima que cientos de proyectos empresariales han sido afectados, incluyendo sistemas de CI/CD, pipelines de despliegue y aplicaciones productivas. La potencial brecha de datos puede acarrear sanciones regulatorias bajo GDPR y la inminente NIS2, así como daños reputacionales y pérdidas económicas significativas.
—
### 5. Medidas de Mitigación y Recomendaciones
– **Revisión inmediata de dependencias:** Auditar todos los paquetes NPM instalados y eliminar cualquier paquete sospechoso o no verificado.
– **Rotación de secretos:** Cambiar de forma urgente todas las credenciales, tokens y claves que pudieran haberse visto comprometidos.
– **Implementación de herramientas SCA (Software Composition Analysis):** Soluciones como Snyk, Sonatype Nexus o GitHub Dependabot resultan críticas para detectar paquetes maliciosos.
– **Refuerzo de políticas CI/CD:** Restringir la ejecución de scripts postinstall y limitar los permisos de los entornos de build.
– **Monitorización de actividad anómala:** Revisar logs de acceso a sistemas cloud, pipelines y repositorios en busca de comportamientos inusuales.
—
### 6. Opinión de Expertos
Analistas de ciberseguridad y responsables de Red Team coinciden en que este ataque representa un salto cualitativo en la automatización y escala del abuso de la cadena de suministro. “El volumen de secretos expuestos y la sofisticación del proceso de exfiltración muestran que el vector de paquetes maliciosos en NPM es actualmente uno de los mayores riesgos para la seguridad de las empresas tecnológicas”, señala David Barroso, CEO de CounterCraft.
—
### 7. Implicaciones para Empresas y Usuarios
Para las empresas, la campaña Shai-Hulud II pone de relieve la urgencia de adoptar una postura Zero Trust en el consumo de software de terceros. Los usuarios y desarrolladores deben extremar la vigilancia sobre las dependencias y reforzar las políticas de gestión de secretos. Además, la publicación masiva de credenciales en GitHub expone a las organizaciones a ataques de fuerza bruta, secuestro de cuentas y acceso no autorizado a datos sensibles.
—
### 8. Conclusiones
El segundo ataque Shai-Hulud en NPM constituye uno de los incidentes más graves de supply chain registrados en el ecosistema Node.js, con una afectación sin precedentes tanto en volumen de datos expuestos como en la superficie de ataque generada. La automatización del proceso y el uso de plataformas públicas como GitHub para la exfiltración refuerzan la necesidad de adoptar controles avanzados, revisar de forma continua las dependencias y aplicar el principio de mínimo privilegio en entornos DevOps.
(Fuente: www.bleepingcomputer.com)
