Ataque de Shai-Hulud a la cadena de suministro de NPM: una nueva generación de amenazas auto-replicantes

La anatomía del gusano Shai-Hulud

El ataque Shai-Hulud no es un simple asunto de fuerza bruta. Opera a través de un proceso de varias etapas, que comienza con una carga maliciosa que se inyecta meticulosamente en paquetes populares de npm. Los atacantes inocularon con el malware a un número significativo de paquetes, probablemente usando tokens de npm que fueron robados previamente del ataque s1ngularity/Nx. La prueba de esto proviene de los metadatos de los usuarios en los archivos de los 49 paquetes iniciales, que llevaban la característica huella digital de una distribución de Kali Linux—una herramienta a menudo utilizada por profesionales de la seguridad y actores de amenazas, no por desarrolladores comunes.

En esencia, el malware es un archivo JavaScript sofisticado y minimizado llamado bundle.js, que suele tener un tamaño de más de 3 MB. Este archivo no es un simple script; es un motor modular de varias etapas que utiliza chunks de Webpack para organizar sus diversas funciones. Se ejecuta automáticamente después de la instalación de un paquete comprometido, generalmente a través de un script postinstall secuestrado e incrustado en el archivo package.json del paquete. Los atacantes descargaban el archivo tarball de un paquete, inyectaban su script malicioso, volvían a empaquetar el archivo y lo republicaban como una nueva versión. Este proceso es tan sutil que los usuarios pueden instalar fácilmente una versión comprometida sin notar nada extraño.

Script postinstall añadido a package.json. (Fuente de la imagen.)

Una vez ejecutado en la máquina de la víctima, el diseño modular del malware entra en acción. Las funcionalidades principales de la carga útil incluyen:

• Reconocimiento del sistema y de credenciales: El malware primero realiza un reconocimiento del sistema anfitrión y recopila un perfil, incluyendo el sistema operativo y la arquitectura. Luego procede a vaciar todo el process.env, capturando una amplia gama de variables de entorno sensibles como GITHUB_TOKEN, NPM_TOKEN, AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY.

• Recolección de credenciales de la nube: Shai-Hulud se dirige específicamente a las credenciales de los principales proveedores de servicios en la nube. Utilizando sus propios SDK (kits de desarrollo de software) en la nube y wrappers de API incrustados, intenta enumerar y acceder a los secretos de servicios como AWS Secrets Manager y Google Cloud Platform (GCP) Secret Manager. Incluso puede sondear puntos finales de metadatos de la nube para capturar credenciales IAM (gestión de identidades y accesos) efímeras, que pueden conceder privilegios aún mayores. El malware está diseñado para fallar silenciosamente en los errores de permisos, lo que hace que su actividad sea aún más difícil de detectar.

• Escaneo de secretos del sistema de archivos: Para maximizar su botín, el malware reutiliza herramientas de código abierto como TruffleHog, una herramienta legítima de escaneo de secretos. Inicia un proceso para escanear todo el sistema de archivos en busca de secretos de alta entropía y archivos sensibles, como ~/.aws/credentials u otros archivos de configuración que puedan contener credenciales codificadas. Este escaneo agresivo amplía el alcance del robo de datos mucho más allá de las variables de entorno.

Es importante destacar que se observó que el malware fue generado por IA en algunas variantes, lo que sugiere que los atacantes podrían haber utilizado herramientas como Claude, Gemini o Q para ayudar a escribir el código malicioso. El diseño también asume un entorno de ejecución Linux o macOS, ya que aparentemente incluye una comprobación para omitir deliberadamente los sistemas Windows.

Persistencia, exfiltración y la propagación incesante del ataque

El verdadero peligro del ataque Shai-Hulud reside en su capacidad no solo para robar datos, sino también para replicarse y establecer persistencia. Después de recolectar credenciales, el gusano las utiliza inmediatamente para propagarse aún más y asegurar un acceso continuo.

Exfiltración de datos a través de GitHub y Webhooks

Los datos robados no se envían a un solo lugar; los atacantes utilizaron una estrategia de exfiltración doble:

• Repositorios públicos de GitHub: El malware utiliza un token de acceso personal (PAT) de GitHub robado para crear un nuevo repositorio público bajo la cuenta de la víctima. Este repositorio se llama típicamente Shai-Hulud y contiene una copia de los secretos cosechados, a menudo dentro de un archivo llamado data.json. Luego, los datos se codifican doblemente con Base64 para que sean menos legibles para los observadores casuales. Este método es particularmente eficaz, ya que se mezcla con la actividad normal de los desarrolladores y elude muchos controles de seguridad tradicionales. Los investigadores de seguridad observaron cientos de estos repositorios apareciendo en GitHub, lo que demuestra la escala y la naturaleza continua del ataque.

• Puntos finales de Webhook: El malware también intenta exfiltrar datos a un punto final de webhook codificado, específicamente hxxps://webhook[.]site/bb8ca5f6-4175-45d2-b042-fc9ebb8170b7. Sin embargo, debido al gran volumen de actividad, la plataforma de webhook finalmente desactivó la cuenta, lo que hizo que este método no fuera funcional. A pesar de esto, los secretos seguían expuestos en los registros del flujo de trabajo en GitHub, lo que proporcionó una nueva vía para que los atacantes accedieran a datos sensibles.

El mecanismo de autopropagación

Con un token de npm válido a la mano, el malware se convierte en un verdadero gusano. Aprovecha la función NpmModule.updatePackage para consultar el registro de npm en busca de otros paquetes propiedad del mantenedor comprometido. Y puede recuperar hasta 20 paquetes a la vez. El gusano crea y publica automáticamente nuevas versiones maliciosas de cada uno de estos paquetes. Esto se hace inyectando el script malicioso bundle.js y agregando un comando postinstall al archivo package.json. Este proceso automatizado crea un efecto en cascada, donde cada paquete infectado sirve como un nuevo vector de distribución, infectando nuevos anfitriones y robando sus credenciales para repetir el ciclo. Este "compromiso en cascada" convierte una sola brecha exitosa en una amenaza exponencial que se propaga a la velocidad de los pipelines de CI/CD.

Estableciendo persistencia

Más allá del robo de datos inmediato, el malware trabaja para establecer una persistencia a largo plazo. Utiliza un PAT de GitHub robado para empujar un nuevo flujo de trabajo de GitHub Actions, a menudo llamado shai-hulud-workflow.yml, en todos los repositorios accesibles. Este flujo de trabajo está diseñado para activarse en los eventos de empuje y exfiltrar más secretos del propio pipeline de CI/CD utilizando la expresión ${{ toJSON(secrets) }}.

Además, el gusano exhibe otro comportamiento malicioso, que recuerda al ataque s1ngularity: la "migración" de repositorios privados. El malware utiliza un script para clonar repositorios privados y volver a publicarlos como repositorios públicos bajo un usuario controlado por el atacante. Estos nuevos repositorios públicos se nombran con un sufijo -migration y la descripción "Shai-Hulud Migration". Esta táctica es probablemente un intento de obtener acceso a secretos que están codificados en el código fuente o simplemente de robar código propietario. El malware crea el repositorio como privado e inmediatamente cambia su visibilidad a pública, dejando dos eventos observables en los registros de auditoría de GitHub: un CreateEvent seguido de un PublicEvent. Una búsqueda de estos repositorios en GitHub arrojó cerca de 700 resultados, lo que indica la escala masiva de esta faceta particular del ataque.

El vínculo con el ataque s1ngularity/Nx: una trilogía peligrosa

El ataque Shai-Hulud está profundamente entrelazado con el ataque a la cadena de suministro s1ngularity, que se dirigió al ampliamente usado paquete del sistema de construcción Nx, a finales de agosto de 2025. Comprender el ataque s1ngularity proporciona un contexto crucial para Shai-Hulud.

En el ataque s1ngularity, los actores de la amenaza comprometieron el repositorio nrwl/nx al explotar un flujo de trabajo de GitHub Actions defectuoso. El flujo de trabajo, que estaba destinado a validar solicitudes de pull, se ejecutó con permisos elevados y era vulnerable a la inyección de código a través de títulos de solicitudes de pull no saneados. Esto permitió a los atacantes ejecutar comandos arbitrarios, exfiltrar el token de npm del equipo a un webhook y publicar versiones maliciosas del paquete Nx.

El malware s1ngularity también era una carga útil de recopilación de datos, pero tenía sus propias características únicas:

• Carga útil del malware: Utilizó un archivo malicioso telemetry.js activado por un script postinstall. La carga útil se dirigió específicamente a los sistemas Linux y macOS y buscó archivos sensibles, incluyendo monederos de criptomonedas, claves SSH y archivos .env.

• Reconocimiento impulsado por IA: El malware aprovechó notablemente las herramientas de línea de comandos de IA como Claude, Gemini y Q, pidiéndoles con indicadores peligrosos (--dangerously-skip-permissions, --yolo) que ayudaran en el reconocimiento y robaran el contenido del sistema de archivos. Este fue un enfoque novedoso en ese momento.

• Exfiltración: Los datos robados fueron codificados doble y triplemente con Base64 y subidos a repositorios de víctimas controlados por el atacante, de acceso público, llamados s1ngularity-repository.

• Persistencia: El malware intentó lograr persistencia y un efecto de denegación de servicio agregando sudo shutdown -h 0 a los archivos ~/.bashrc y ~/.zshrc del usuario.

• Exposición de repositorios: Una segunda fase del ataque s1ngularity implicó el uso de los tokens de GitHub robados para convertir los repositorios privados en públicos y renombrarlos a un patrón como s1ngularity-repository-#5letters#. Más de 5.500 repositorios privados de más de 400 usuarios se vieron afectados.

La superposición funcional entre las dos campañas es significativa. Ambos ataques:

• Se dirigieron a paquetes populares de código abierto con millones de descargas semanales.

• Se centraron en la recopilación de variables de entorno e información secreta.

• Aprovecharon las cuentas de GitHub propiedad del usuario para la exfiltración de datos.

• Expusieron repositorios privados haciéndolos públicos.

Sin embargo, Shai-Hulud representa una escalada. Como señaló un investigador de seguridad, los atacantes detrás de Shai-Hulud probablemente habían estado sentados sobre las credenciales robadas del ataque s1ngularity, esperando el momento oportuno para lanzar una nueva campaña, más automatizada. El hecho de que Shai-Hulud incluya un mecanismo de autopropagación —que no estaba presente en s1ngularity— es lo que lo convierte en una amenaza mucho más peligrosa. La naturaleza consistente y refinada de estos ataques demuestra que los actores de la amenaza están aprendiendo y adaptándose, utilizando cada compromiso exitoso como un plan para el siguiente. Las llaves del reino se han filtrado, y como el mismo investigador lo expresó acertadamente, esto podría ser solo el comienzo de una trilogía.

El alcance del ataque: paquetes, usuarios y el ecosistema en general

El ataque Shai-Hulud afectó a una amplia gama de paquetes y desarrolladores, desde mantenedores de alto perfil hasta estudiantes y líderes técnicos. El gran número de paquetes involucrados, junto con la naturaleza de autopropagación del gusano, creó una superficie de ataque masiva que es difícil de cuantificar completamente.

Algunos de los paquetes más populares afectados incluyeron:

• @ctrl/tinycolor (con más de 2,2 millones de descargas semanales)

• ngx-bootstrap (con más de 309 mil descargas semanales)

• ng2-file-upload (con más de 94 mil descargas semanales)

El ataque también comprometió múltiples paquetes pertenecientes a la cuenta de npm @crowdstrike, publicados por crowdstrike-publisher. Esto demuestra que el gusano no se limitó a desarrolladores individuales, sino que también pudo infectar paquetes propiedad de importantes proveedores de seguridad.

La lista de paquetes comprometidos y sus versiones es extensa. Para ayudar a los desarrolladores y organizaciones a identificar si se vieron afectados, hemos compilado una tabla completa de todos los paquetes afectados conocidos y las versiones maliciosas que se publicaron.

El impacto de este ataque es significativo. Más allá del robo inmediato de secretos, el cual puede llevar al robo de datos, criptominería o la eliminación de entornos de producción, la naturaleza de autopropagación del ataque deja un rastro de cuentas comprometidas y código fuente potencialmente expuesto. Una compañía de seguridad analizó los datos filtrados y encontró un total de 278 secretos, con 90 recolectados de sistemas locales y 188 de flujos de trabajo maliciosos. Los secretos más filtrados fueron tokens de GitHub, tokens de npm y claves de AWS, lo que pone de relieve los objetivos principales de la campaña.

Qué pueden hacer los desarrolladores y las organizaciones: algunas recomendaciones

El ataque Shai-Hulud es una llamada de atención para todo el ecosistema de código abierto. El incidente demuestra que el riesgo de la cadena de suministro de software ya no se trata solo de vulnerabilidades en el código, sino también de identidades comprometidas y automatización de confianza. Dado que el malware se propaga a la velocidad de CI/CD, dejando muy poco tiempo para la detección y la remediación, una defensa fuerte y proactiva es crucial.

Aquí hay recomendaciones prácticas para mitigar el riesgo de este ataque y amenazas similares:

Contención y remediación inmediatas

• Eliminar paquetes maliciosos: En primer lugar, audita las dependencias de tu proyecto y elimina o reduce la versión de cualquier paquete afectado. Puedes utilizar herramientas como npm audit para identificar versiones vulnerables. Después de eliminar los paquetes, borra tu caché ejecutando npm cache clean --force y luego reinstala una versión limpia y probada.

• Asumir el compromiso y rotar credenciales: Cualquier máquina o runner de CI que haya instalado un paquete afectado debe considerarse totalmente comprometido. Debes revocar y regenerar inmediatamente todas las credenciales potencialmente expuestas, incluyendo tokens de npm, PATs de GitHub, claves SSH y todas las claves de API en la nube.

• Auditar las cuentas y los registros de GitHub: Revisa tu cuenta de GitHub en busca de cualquier actividad sospechosa. Busca:

  • Repositorios públicos recién creados llamados "Shai-Hulud".

  • Repositorios privados que de repente se hicieron públicos y tienen la descripción "Shai-Hulud Migration" con un sufijo -migration.

  • Nuevas ramas llamadas "shai-hulud".

  • Commits inesperados o modificaciones a los archivos de flujo de trabajo de GitHub Actions, buscando específicamente shai-hulud.yml o shai-hulud-workflow.yml.

Fortalecimiento de la seguridad a largo plazo

• Hacer cumplir una autenticación fuerte: Exige el uso de autenticación de múltiples factores (MFA) en todas las plataformas de desarrollador críticas, incluyendo GitHub y npm. Cuando sea posible, usa claves de seguridad de hardware para el más alto nivel de protección.

• Implementar el principio de menor privilegio: Limita el alcance de tus tokens. Usa tokens de corta duración y con un alcance limitado que tengan solo los permisos que necesitan para su tarea específica. Por ejemplo, un token utilizado para CI/CD no debería tener amplios derechos administrativos o de publicación si no es estrictamente necesario.

• Fortalecer los pipelines de CI/CD: Trata tus entornos de construcción como objetivos potenciales. Usa runners efímeros que se destruyen después de cada construcción para evitar que el malware establezca persistencia. Restringe las conexiones de red salientes de tus pipelines de construcción solo a los dominios necesarios.

• Fijar dependencias y monitorear anomalías: En lugar de permitir actualizaciones automáticas o flotantes (^ o ~), fija todas las dependencias a una versión específica y probada en tu archivo package.json o package-lock.json. Esto evita que una construcción automatizada extraiga sin saberlo una versión recién comprometida. Monitorea continuamente los registros en busca de eventos inusuales de npm publish o procesos secundarios inesperados, lo que podría indicar que se está ejecutando un script malicioso.

• Usar soluciones de seguridad avanzadas: El aumento de estos ataques sofisticados, que explotan identidades y automatización de confianza, exige un nuevo enfoque de la seguridad. Las soluciones que ofrecen análisis de composición de software (SCA) y la lista de materiales de software (SBOM) pueden ayudarte a rastrear y gestionar continuamente tus dependencias, identificar paquetes vulnerables y bloquear los maliciosos. Estas herramientas te ayudan a ver lo que hay en tu software y a detener los cambios arriesgados antes de que entren en tu pipeline. En Fluid Attacks, nuestra completa solución Hacking Continuo incluye AST automatizado y PTaaS, y también proporcionamos SCA, incluyendo SBOM, para ayudar a las empresas a rastrear y gestionar continuamente sus dependencias, identificar vulnerabilidades y proteger de forma proactiva su cadena de suministro de software. Te invitamos a iniciar nuestra prueba gratuita de 21 días ahora mismo.

Los clientes de Fluid Attacks pueden determinar rápidamente si sus aplicaciones están expuestas a estos paquetes vulnerables. Solo tienen que ir a la sección Inventory y filtrar la tabla de Packages por nombre de componente:

Conclusión: un punto de inflexión para la seguridad de la cadena de suministro

El ataque Shai-Hulud es un momento decisivo para la seguridad de la cadena de suministro de software. Significa un cambio de compromisos aislados y puntuales a amenazas automatizadas, escalables y que se autopropagan. Esta nueva generación de ataques, que aprovecha las credenciales robadas para alimentar una propagación viral, deja a las organizaciones con poco o ningún margen para una detección y remediación lentas.

Este incidente con paquetes de npm, al igual que el ataque de vaciar billeteras que lo precedió, subraya una verdad crítica: Todo nuestro ecosistema digital depende de la seguridad de la cadena de suministro de código abierto. La rápida respuesta de los investigadores de seguridad y de la comunidad de desarrolladores en este caso es un testimonio del espíritu de colaboración que sustenta el software de código abierto. Sin embargo, también subraya la necesidad urgente de que las organizaciones vayan más allá de los modelos de seguridad tradicionales y adopten un enfoque proactivo y continuo para proteger su cadena de suministro de software. Al implementar prácticas de seguridad robustas, aprovechar herramientas modernas y mantenerse vigilantes, podemos enfrentar colectivamente este desafío creciente y proteger nuestro futuro digital compartido.