Mini Shai-Hulud: la campaña de suministro comprometido que roba tokens, despliega cargas maliciosas y reinfecta tus pipelines desde npm

Investigadores de varias firmas de seguridad han alertado sobre una campaña de suministro comprometido que apunta al ecosistema JavaScript de SAP, distribuida en paquetes npm legítimos pero versionados con un instalador malicioso. El ataque —autodenominado "mini Shai-Hulud" por el actor— utiliza un gancho de instalación (preinstall) para descargar y ejecutar un binario de Bun desde GitHub Releases y, a partir de ahí, cargar un cargador JavaScript que instala un exfiltrador de credenciales y un marco de propagación que se ejecuta en el entorno del desarrollador o en pipelines de CI/CD.

Lo notable de esta campaña no es solo la técnica de entrega sino su objetivo y alcance: robar tokens y secretos locales y en la nube (GitHub, npm, GitHub Actions, AWS, Azure, GCP y Kubernetes), cifrar los datos robados con AES-256-GCM y empaquetar la clave con RSA-4096 para que solo el atacante pueda descifrarlos, y luego publicar los artefactos exfiltrados en repositorios públicos creados en la cuenta de la víctima. Además, incorpora mecanismos de auto‑propagación que usan los tokens robados para inyectar workflows maliciosos en repositorios y publicar nuevas versiones en el registro npm, cerrando un ciclo de re‑compromiso que puede expandir el daño de forma exponencial.

Hay otra dimensión preocupante y relativamente novedosa: el uso de configuraciones de agentes de programación de IA y del propio editor como vectores de persistencia. El malware introduce archivos como ".claude/settings.json" para aprovechar hooks de sesión de Claude Code y archivos de VS Code con "runOn": "folderOpen", de modo que abrir el proyecto en estos entornos vuelve a ejecutar el código malicioso. Esta táctica transforma herramientas que agilizan el desarrollo en trampas que reinfectan a los equipos de trabajo y a nuevas máquinas que clonen el repositorio.

Las implicaciones prácticas son graves: un desarrollador puede comprometer sin saberlo no solo su máquina, sino también pipelines de CI/CD, repositorios y cuentas de servicios en la nube. Desde allí los atacantes pueden desplegar cargas, extraer datos sensibles, publicar paquetes contaminados que infecten a terceros y mantener acceso persistente a entornos corporativos. La incorporación de cifrado fuerte y claves RSA de 4096 bits también complica la respuesta forense sobre el contenido exfiltrado.

Para mitigar el riesgo inmediato, es clave actuar rápido y en orden. Primero, identifique y deje de usar las versiones comprometidas (por ejemplo, las versiones publicadas por los investigadores) y purgue las instalaciones locales y caches de npm en estaciones de trabajo y runners de CI. Examine los repositorios en busca de commits o archivos inesperados —por ejemplo, comprobando la presencia de ".claude/settings.json" y ".vscode/tasks.json"— y revise cualquier GitHub Actions workflow nuevo o modificaciones recientes. Revocar y rotar inmediatamente todos los tokens personales y de servicio expuestos, y rotar claves de acceso a la nube, es indispensable: las credenciales deben asumirse comprometidas hasta demostrar lo contrario. GitHub ofrece guías prácticas para la gestión de tokens y buenas prácticas que pueden ayudar en la contención: Documentación de tokens de GitHub.

En los pipelines y en la política de desarrollo conviene reforzar controles a medio plazo: habilitar el escaneo de secretos y la detección de dependencias en la plataforma de repositorios, exigir firmas de paquetes o usar registros privados con políticas de admisión, y adoptar la rotación automática de credenciales con principios de mínimo privilegio. Además, restringir la ejecución automática de scripts de instalación y auditar hooks como preinstall en package.json ayuda a reducir las superficies de ataque que explotan comportamientos por defecto de npm. Para comprender cómo los scripts npm pueden ser utilizados como vectores, la propia documentación de npm es un recurso útil: Scripts en npm.

Desde la perspectiva operativa, es recomendable reconstruir runners y entornos de build desde imágenes limpias, eliminar y regenerar claves y credenciales, y revisar logs de GitHub y de servicios en la nube para detectar actividad inusual (creación de repositorios, pushes automáticos, workflows nuevos con permisos elevados). Herramientas de seguridad de la cadena de suministro como scanners de dependencias, políticas de bloqueo de versiones y soluciones de observabilidad para repositorios pueden detectar y contener reintentos de publicación maliciosa.

Finalmente, el incidente subraya la necesidad de entender y controlar no solo las dependencias de librerías, sino también las configuraciones de los agentes de código y los editores que forman parte del flujo de trabajo. La industria debe considerar medidas técnicas que limiten la ejecución automática de código al abrir proyectos y exigir confirmaciones explícitas o sandboxes para integraciones con asistentes de IA. Para desarrolladores que quieran evaluar componentes ejecutables como Bun, conviene descargar binarios desde fuentes oficiales y verificadas (por ejemplo, el sitio oficial de Bun: Bun) y verificar firmas o checksums cuando estén disponibles.

Este tipo de campañas demuestra que la siguiente generación de ataques de la cadena de suministro ya no solo apunta a paquetes populares, sino a los atajos y automatizaciones que hacen más rápido el trabajo diario. La respuesta debe combinar contención inmediata, rotación de credenciales, limpieza de artefactos y una política de desarrollo que empodere la prevención y la resiliencia frente a la ejecución de código no verificado.