Las consecuencias de Shai-Hulud 2 y qué se podría hacer de manera diferente

El gusano npm Shai-Hulud 2.0 es uno de esos incidentes a los que los equipos de AppSec harán referencia en sus análisis post mortem durante años.

Analicemos qué sucedió, quiénes se vieron afectados y cómo una plataforma SSCS como ScribeHub Podría haber ayudado a las organizaciones a prevenir o al menos limitar drásticamente el radio de la explosión.

1. ¿Qué es Shai-Hulud 2.0?

Shai-Hulud apareció por primera vez en septiembre de 2025 como un Gusano autorreplicante que ataca el ecosistema npm, comprometiendo cientos de paquetes de JavaScript y propagándose a través de credenciales robadas y republicación automática. 

Sólo un par de meses después, los investigadores comenzaron a ver una Ola de seguimiento mucho más agresiva y automatizada, ahora comúnmente conocido como “Shai-Hulud 2.0”, “Sha1-Hulud 2.0” o “La Segunda Venida”. 

Características principales de Shai-Hulud 2.0:

• Enfoque en la cadena de suministro. En lugar de atacar a una empresa, ataca paquetes npm confiables y, en variantes posteriores, incluso ecosistemas Java (Maven), envenenando los bloques de construcción utilizados en miles de proyectos.
• Gusano autopropagador. Una vez que compromete a un mantenedor, automáticamente crea una puerta trasera. todas de los paquetes de ese mantenedor y los vuelve a publicar, lo que permite una distribución exponencial a través de los gráficos de dependencia.
• Ladrón de información y de secretos. La carga útil recopila de forma agresiva variables de entorno, tokens de GitHub y npm, credenciales de la nube y secretos de CI/CD de las máquinas de los desarrolladores y las canalizaciones de compilación. 
• Interruptor de hombre muerto destructivo. Si el malware no puede llegar a su C2 o no logra propagarse, algunas variantes intentan borrar el directorio de inicio del usuario, convirtiendo una vulneración de la cadena de suministro en un incidente potencialmente destructivo.

2. Cómo funcionó el ataque: paso a paso

Distintos proveedores observaron herramientas y scripts ligeramente diferentes, pero la cadena de eliminación general se ve más o menos así:

2.1 Punto de apoyo inicial: cuentas de mantenedor comprometidas

Atacantes:

1. Cuentas de mantenimiento de npm/GitHub comprometidas utilizando tokens previamente robados, phishing, reutilización de contraseñas o MFA débil.
2. Usé esas cuentas para publicar versiones troyanizadas de paquetes legítimos – a menudo solo con una actualización a nivel de parche para que se integren a los patrones de actualización normales.

Debido a que los paquetes fueron firmados y publicados por los mantenedores legítimos, parecieron confiables para los consumidores posteriores.

2.2 Infección a través de la canalización de instalación de npm/CI

Las organizaciones retiraron estos paquetes:

• vía normal npm instalar en desarrollo local,
• o indirectamente en pipelines de CI / CD como parte de compilaciones automatizadas.

Los paquetes maliciosos generalmente se aprovechan scripts de ciclo de vida de npm (preinstalación, instalar, postinstalación) como vectores de ejecución, descargando y ejecutando una carga útil de segunda etapa como paquete.js, setup_bun.js, o archivos grandes ofuscados similares. 

2.3 Robo de credenciales y reconocimiento del entorno

Una vez en ejecución, la carga útil:

• Variables de entorno enumeradas y archivos de configuración locales.
• Cosechado credenciales en la nube, tokens de GitHub/GitLab, tokens de acceso npm, claves SSH y otros secretos.
• Herramientas de uso ocasional como Escaneo al estilo TruffleHog para buscar secretos en repositorios.

Estas credenciales fueron entonces exfiltrado a repositorios de GitHub controlados por el atacante u otra infraestructura C2, a menudo nombrada para integrarse (por ejemplo, repositorios “Shai-Hulud” poblados con volcados de entornos robados). 

2.4 Movimiento lateral a través de ecosistemas de desarrolladores

Usando los tokens robados, el malware:

• Se introdujeron puertas traseras en todos los paquetes npm propiedad de los mantenedores comprometidos, que inyectan los mismos scripts maliciosos y los republican.
• Plantados flujos de trabajo maliciosos de GitHub Actions y puertas traseras en repositorios de víctimas para persistencia y exfiltración continua durante ejecuciones de CI.
• En algunas variantes 2.0, se extendió más allá de npm a Repositorios Maven, demostrando un verdadero alcance de la cadena de suministro entre ecosistemas. 

Debido a que muchas bibliotecas populares ocupan una posición alta en los árboles de dependencia, un compromiso de solo unos pocos mantenedores se traduce en Decenas de miles de repositorios afectados río abajo.

3. Escala e impacto en las víctimas

Los distintos proveedores de seguridad informan cifras ligeramente diferentes, pero todos coinciden en una cosa: Shai-Hulud 2.0 es enorme.

• Los investigadores de seguridad estiman que más de 25,000 repositorios de GitHub y cientos a ~700 paquetes fueron impactados en las olas posteriores, algunas de las cuales aparecen en Más de una cuarta parte de los entornos de nube/código ellos escanearon
• Los analistas lo llaman Uno de los ataques a la cadena de suministro de NPM de más rápida propagación jamás visto, con una automatización que comprometió cientos de paquetes en cuestión de horas.
• Entre las víctimas de alto perfil se incluyen proyectos y paquetes de Zapier, Dominios ENS, PostHog, Postman, y otros, lo que significa que tanto los proveedores de SaaS como miles de sus clientes tenían exposición potencial.

3.1 Impacto técnico directo

Para las organizaciones que extrajeron un paquete troyanizado, las consecuencias típicas incluyeron:

• Exposición de secretos de CI/CD (claves de proveedor de nube, tokens de implementación, certificados de firma de código, etc.).
• Puertas traseras sigilosas en repositorios de GitHub y acciones CI, lo que permite a los atacantes ejecutar comandos arbitrarios en compilaciones futuras.
• Artefactos manipulados:la posibilidad de que los atacantes inserten lógica maliciosa en aplicaciones creadas sin que los desarrolladores se den cuenta.
• Para algunos desarrolladores desafortunados, un borrado destructivo de la $ HOME directorio cuando el respaldo del malware entró en acción.

3.2 Impacto empresarial

Desde una perspectiva empresarial, esto se traduce en:

• Eventos de respuesta a incidentes a gran escala:Los equipos de IR tuvieron que auditar cada proyecto que utilizaba paquetes afectados, rotar tokens y, a veces, congelar las implementaciones.
• Exposición regulatoria y contractual:Las industrias reguladas (finanzas, atención médica, proveedores gubernamentales) ahora enfrentan la posibilidad de que datos regulados o claves de acceso a sistemas críticos hayan sido exfiltrados a través de un paquete de terceros.
• Erosión de la confianza en el código abierto:Los líderes de seguridad e ingeniería se ven obligados a revisar su modelo de confianza para los registros públicos y considerar controles más estrictos en torno a la gestión de dependencias.

4. Donde las defensas tradicionales luchan

¿Por qué Shai-Hulud 2.0 atravesó tantas defensas?

1. Se trata de un abuso de confianza y no de una simple vulnerabilidad. Los paquetes eran “legítimos”: publicados bajo nombres de mantenedores reales, a menudo desde repositorios existentes.
2. El SCA/SAST estático no fue suficiente. Incluso si los equipos tuvieran SBOM y escáneres de vulnerabilidad, muchos de ellos no estaban buscando en el comportamiento indicadores como scripts de ciclo de vida sospechosos o exfiltración saliente durante las compilaciones.
3. Los secretos y la CI/CD eran el verdadero objetivo. Muchas organizaciones tienen controles y monitoreos más débiles para entornos CI/CD que para producción, lo que los convierte en objetivos perfectos.
4. Falta de procedencia de extremo a extremo. La mayoría de los equipos no pudieron responder fácilmente: “¿Exactamente qué compilaciones, artefactos e implementaciones involucraron un paquete troyanizado y cuáles están limpios?”

Ésta es precisamente la brecha que seguridad de la cadena de suministro de software (SSCS) plataformas como ScribeHub están diseñados para abordar.

 

5. Cómo ScribeHub SSCS podría ayudar a prevenir y mitigar ataques tipo Shai-Hulud

Mapearé las técnicas de Shai-Hulud 2.0 con las capacidades que normalmente implementarías con la plataforma ScribeHub de Scribe Security y las herramientas relacionadas (por ejemplo, la política como código de Valint).

5.1 Barandillas en la ingestión de dependencias

Problema en Shai-Hulud 2.0:
Las organizaciones consumieron paquetes npm actualizados automáticamente (a través de ^/~ rangos de versiones, Renovate/Dependabot o scripts CI) con poco escrutinio del comportamiento.

Con ScribeHub:

• Controles de dependencia basados ​​en políticas. Utilice las políticas de Valint para restringir qué registros y ámbitos se consideran "confiables", aplicar listas de permitidos para paquetes críticos y alertar cuando:
  • un nuevo mantenedor publica una versión,
  • Aparecen scripts de ciclo de vida inesperados,
  • o un paquete de repente adquiere un nuevo comportamiento de red/ejecución.
• Certificación de componentes de terceros. ScribeHub puede ingerir y verificar Certificaciones de procedencia y construcción para los paquetes donde estén disponibles (por ejemplo, metadatos estilo SLSA, Sigstore, in-toto), habilitando reglas como “solo consumimos dependencias en cuya procedencia de compilación confiamos”.

Esto no soluciona mágicamente el ecosistema npm, pero sí lo hace significativamente. eleva el nivel antes de que se permita una nueva versión en sus compilaciones.

5.2 Fortalecimiento del pipeline de CI/CD como un “activo de primera clase”

El principal valor de Shai-Hulud provenía de la explotación computadoras portátiles para desarrolladores y nodos CI/CD como bóvedas secretas.

Usando ScribeHub:

• Certificación de tubería para cada ejecución.
  Cada trabajo de CI produce una certificación firmada que describe:
  • qué repositorios y ramas se crearon,
  • ¿Qué dependencias e imágenes de contenedores se utilizaron?
  • qué scripts se ejecutaron (incluidos los ganchos del ciclo de vida),
  • y a qué secretos se accedió.
• Esos datos llegan a El lago de evidencia de ScribeHub, lo que le proporciona un historial a prueba de manipulaciones de "quién construyó qué, desde dónde, con qué insumos".
• Comprobaciones en tiempo de ejecución de políticas como código.
  Antes de que un artefacto de compilación pueda promoverse a la etapa de preparación/producción, un motor de políticas valida:
  • que sólo se utilizaron registros npm aprobados,
  • que no hay scripts de ciclo de vida prohibidos (rizo | golpe, ofuscado paquete.js, etc.) se ejecutan,
  • que el corredor no se estaba ejecutando como root y no montó rutas de host sensibles.

Si Shai-Hulud inyecta una cantidad adicional postinstalación script que exfiltra secretos, esas ejecuciones fallar la política y nunca llegan a producción.

5.3 Análisis rápido del radio de explosión

Una de las tareas más difíciles en una campaña como ésta es responder:

“¿Dónde exactamente usamos versiones troyanizadas del paquete X y qué tocaron?”

Con ScribeHub:

• Cada compilación, implementación y artefacto está asociado con certificaciones vinculadas criptográficamente: dependencias, detalles del entorno, SHA de confirmación, resúmenes de contenedores, etc.
• Cuando un nuevo aviso dice “versiones 4.8.1–4.8.5 de alguna biblioteca son parte de Shai-Hulud 2.0”, consulta a ScribeHub:
  
  
  “Muéstrame todas las compilaciones de los últimos 90 días que incluyeron esas versiones y qué implementaciones o imágenes produjeron”.
  
• A continuación, puede rotación secreta de objetivos y remediación precisamente donde importa, en lugar de rotar todo a ciegas (lo que puede ser poco realista desde el punto de vista operativo).

En otras palabras, ScribeHub convierte un pánico generalizado en un ecosistema. incidente acotado y auditable.

5.4 Protegiendo su propia paquetes que se conviertan en armas

Muchas organizaciones no solo consumen código abierto, sino que también... publicar Paquetes utilizados por clientes, socios o equipos internos. Si una cuenta de mantenedor de su organización se viera comprometida, podría convertirse en un vector de propagación involuntario, al igual que los mantenedores de Shai-Hulud.

ScribeHub puede ayudar de la siguiente manera:

• Exigir certificaciones firmadas de su CI antes de que un paquete pueda publicarse en npm o en un registro interno:
  • Las versiones del paquete que no estén acompañadas de las certificaciones esperadas se rechazan o se marcan.
• Monitorización continua de sus propios registros y repositorios:
  • Alertas cuando se publica un paquete desde un entorno de compilación desconocido o fuera de sus canales de CI aprobados.
  • Detección de nuevas acciones de GitHub o scripts npm que no estaban presentes en la última versión “confiable”.

Esto lo hace mucho más difícil para un atacante con un token robado introducir silenciosamente una versión maliciosa en su espacio de nombres.

5.5 Evidencia para reguladores, clientes y partes interesadas internas

Incidentes como Shai-Hulud 2.0 son cada vez más analizados por los reguladores y los grandes clientes, especialmente en sectores alineados con marcos como SSDF del NIST, PCI DSS 4, o requisitos de certificación de software del gobierno.

Porque ScribeHub mantiene un registro firmado y con marca de tiempo de la actividad SDLC, usted puede:

• Demuestre qué compilaciones y versiones no se vieron afectadas por dependencias troyanizadas.
• Proporcionar a los auditores evidencia concreta de:
  • políticas de dependencia,
  • aplicación del principio de privilegio mínimo en la CI,
  • y cronogramas de rotación secreta posteriores al incidente.

Esto transforma la conversación de “creemos que estamos bien” a “aquí está la cadena de custodia certificada de nuestro software”.

6. Conclusiones prácticas para líderes de seguridad

Resumiendo, así es como resumiría Shai-Hulud 2.0 y el papel que puede desempeñar una plataforma como ScribeHub:

1. Supongamos que el ecosistema está comprometido. Los registros públicos resultan demasiado atractivos como puntos únicos de fallo. Su modelo de seguridad debe tratar las dependencias externas como no confiables hasta que se demuestre lo contrario.
2. Pasar de “escanear y rezar” a “certificar y hacer cumplir”. El SCA clásico y el linting siguen siendo importantes, pero Shai-Hulud 2.0 muestra que también necesitamos:
   • fuerte procedencia,
   • construcciones atestiguadas,
   • y promoción de artefactos protegida por políticas.
3. Trate CI/CD como producción. El gusano atacaba secretos y tuberías porque suelen ser objetivos más fáciles que los entornos de ejecución reforzados.
4. Invierta en trazabilidad. Cuando se produzca el próximo compromiso que abarque a todo el ecosistema (y ocurrirá), su capacidad de responder “¿Dónde nos afectó esto?” en cuestión de horas en lugar de semanas será la diferencia entre un incidente controlado y una crisis a gran escala.

ScribeHub SSCS no hace que npm o el código abierto sean mágicamente seguros, pero le brinda la visibilidad, el control y la estructura probatoria necesaria para resistir ataques al estilo Shai-Hulud con mucho menos caos.

Si diseña su SDLC en torno a certificaciones firmadas continuas, políticas basadas en evidencia y una sólida higiene de CI/CD, el próximo “mayor ataque a la cadena de suministro de npm de la historia” se convierte en otro incidente a manejar, no en una amenaza existencial para su negocio.