Un ataque masivo roba credenciales a desarrolladores usando librerías de confianza

Un ataque masivo roba credenciales a desarrolladores usando librerías de confianza

Una campaña de ciberataque llamada Shai-Hulud ha comprometido cientos de paquetes de software en los dos repositorios más usados por programadores de todo el mundo: npm (para JavaScript) y PyPI (para Python). Lo grave no es solo la cantidad de código afectado, sino que los paquetes maliciosos llevaban firmas digitales válidas y pasaban todos los controles de seguridad automáticos. Para los sistemas de protección, parecían 100 % legítimos.

¿Qué son npm y PyPI y por qué importan?

Imagina que npm y PyPI son como supermercados de ingredientes para cocinar software. Los desarrolladores no escriben todo desde cero; van a estos repositorios, cogen librerías ya hechas (por ejemplo, una que gestiona fechas o una que conecta con una base de datos) y las añaden a sus proyectos. Cada vez que alguien descarga una de esas librerías, confía en que es segura porque viene de la «tienda oficial».

El ataque Shai-Hulud ha envenenado las estanterías de esa tienda. Los atacantes colaron versiones falsas de librerías muy populares —como las de TanStack (usada en miles de webs modernas), Mistral AI (herramientas de inteligencia artificial), Bitwarden CLI (gestor de contraseñas) e incluso paquetes oficiales de SAP—. Según las firmas de seguridad Endor Labs y Socket, hay entre 160 y 416 paquetes comprometidos.

Cómo lograron que el código malicioso pareciera legítimo

El truco principal fue robar credenciales de identidad digital (tokens OIDC) que los propios desarrolladores usan para publicar actualizaciones de forma automática. Es como si un ladrón consiguiera el uniforme, la llave y el badge de un repartidor de confianza: puede entrar en el almacén, cambiar productos por versiones envenenadas y nadie se da cuenta porque «es el repartidor de siempre».

Además, explotaron tres fallos en cadena en los flujos de trabajo de GitHub Actions (el sistema que compila y publica código automáticamente):

• Configuraciones inseguras que permitían ejecutar código ajeno en el proyecto principal.
• Envenenamiento de la caché compartida, colando dependencias falsas.
• Robo de los tokens de identidad desde la memoria del servidor de compilación.

El resultado: los paquetes maliciosos llevaban atestados SLSA Nivel 3, el estándar más alto de «este código se ha construido en el sitio oficial y no ha sido manipulado». Los controles automáticos daban el visto bueno.

Qué busca el malware una vez dentro

El objetivo no es romper el ordenador, sino espiar y robar secretos. El código malicioso escanea el entorno del desarrollador y extrae:

• Tokens de GitHub y claves de publicación en npm.
• Credenciales de Amazon Web Services, Kubernetes y HashiCorp Vault.
• Configuraciones de herramientas de IA como Claude Code y tareas de VS Code.

Para pasar desapercibido, el malware envía lo robado a través de la red Session Messenger, que parece tráfico de mensajería cifrada legítima. Además, se instala en «ganchos» de Claude Code y en tareas automáticas de VS Code: desinstalar el paquete no limpia la infección.

Hay un detalle escalofriante: en entornos que parecen estar en Israel o Irán, el malware tiene una probabilidad de 1 entre 6 de ejecutar un borrado total del disco (rm -rf /). Esto sugiere una motivación geopolítica además del robo de credenciales.

Qué deben hacer los equipos de desarrollo ya

Los expertos recomiendan pasos inmediatos:

1. Auditoría de versiones: revisar los archivos de bloqueo (package-lock.json, yarn.lock, pnpm-lock.yaml, poetry.lock) en busca de actualizaciones recientes inesperadas de los proyectos afectados.
2. Rotar todas las credenciales: si se descargó una versión comprometida, asumir que todos los secretos de esa máquina o servidor de CI/CD están expuestos. Cambiar tokens de GitHub, npm, AWS, claves SSH, etc.
3. Limpiar persistencia: revisar directorios de configuración de los IDE (VS Code, JetBrains) y de herramientas de IA (Claude Code) porque el malware sobrevive a la desinstalación.
4. Forzar instalaciones estrictas: usar solo npm ci, pnpm install --frozen-lockfile o pip install --require-hashes para evitar actualizaciones silenciosas.
5. Bloquear infraestructura de mando: cortar en el firewall o DNS los dominios api.masscan.cloud, git-tanstack.com y *.getsession.org.

La lección: la firma digital ya no basta

Este ataque demuestra que una firma válida no garantiza que el código sea seguro. Los atacantes han aprendido a robar la identidad de los publicadores legítimos y a usar la infraestructura oficial contra sí misma. La defensa debe añadir una capa de análisis de comportamiento en el momento de la instalación: ¿este paquete intenta leer claves SSH? ¿Se conecta a servidores extraños? Solo así se detecta lo que la firma oculta.

Mientras tanto, cualquier persona que use software —que hoy en día es todo el mundo— debe saber que la cadena de suministro del código es un objetivo prioritario para los ciberdelincuentes. La seguridad de las aplicaciones que usamos cada día empieza en la «despensa» donde los programadores compran sus ingredientes.