El ecosistema de código abierto ha vuelto a demostrar que su mayor fortaleza es también su mayor vulnerabilidad. Microsoft ha identificado un ataque activo de cadena de suministro dirigido al ecosistema de paquetes npm de @antv, una organización que mantiene librerías de visualización de datos utilizadas en miles de aplicaciones en todo el mundo.
Un actor malicioso comprometió la cuenta de un mantenedor de @antv y publicó versiones maliciosas de paquetes ampliamente utilizados, desencadenando un impacto en cascada que se propagó a través de cadenas de dependencias hacia librerías como echarts-for-react, que supera el millón de descargas semanales, expandiendo el radio de explosión hacia pipelines de CI/CD y cargas de trabajo en la nube.
El payload malicioso, un archivo JavaScript ofuscado de aproximadamente 499 KB, se ejecuta silenciosamente durante la instalación de npm y está diseñado específicamente para robar credenciales de entornos de GitHub Actions.
Sus capacidades incluyen robo de credenciales multiplataforma (GitHub, AWS, HashiCorp Vault, npm, Kubernetes, 1Password), extracción de memoria de procesos del GitHub Action Runner, escalada de privilegios, exfiltración de datos por doble canal y falsificación de procedencia SLSA.
Estas capacidades sugieren un esfuerzo deliberado por evadir el análisis y un enfoque claro en entornos de CI/CD.
La cadena de ataque: del mantenedor comprometido al robo masivo de credenciales
El ataque sigue un patrón meticulosamente orquestado. La organización @antv mantiene librerías de gráficos como G2 y G6, que están integradas en paneles de control y aplicaciones de todo el mundo. El ataque procede a través de varias etapas:
La primera es el compromiso de la cuenta del mantenedor y la publicación de versiones maliciosas de paquetes @antv. La segunda es la amplificación a través de dependencias downstream como echarts-for-react, size-sensor y otras.
La tercera es la ejecución automática del payload a través de un hook preinstall durante npm install. Y la cuarta es la cadena de ejecución: node → shell → bun → payload, instalando el runtime de Bun si no está presente.
La ofuscación: dos capas de protección para evadir el análisis
El payload reemplaza el index.js legítimo con un script ofuscado de una sola línea.
La primera capa de ofuscación consiste en 1.732 cadenas codificadas en Base64 en un array rotado, decodificadas a través de una función de búsqueda con la clave de barajado 0xa31de.
La segunda capa cifra cadenas críticas como el dominio de comando y control y los nombres de variables de entorno con un cifrado personalizado PBKDF2 y SHA-256, que se descifra en tiempo de ejecución.
El payload también incluye un mecanismo de puerta de enlace ambiental: se detiene inmediatamente si no se está ejecutando en GitHub Actions sobre Linux. Además, evita las ramas main, master, dependabot/, renovate/ y gh-pages al usar la exfiltración a través de la API de Git.
El robo de credenciales: seis plataformas en el punto de mira
El payload ataca secretos en seis plataformas diferentes. En GitHub, extrae el GITHUB_TOKEN, busca Personal Access Tokens (gh[op]) y tokens de instalación (ghs), valida a través de la API /user y enumera secretos de repositorios y organizaciones.
En AWS, consulta el Instance Metadata Service, el metadata de Elastic Container Service, lee archivos .aws/, recolecta variables de entorno y llama a SecretsManager en todas las regiones.
En HashiCorp Vault, busca más de 12 rutas de tokens y se conecta a un Vault local en 127.0.0.1:8200. En npm, valida tokens usando /-/whoami, intercambia tokens OpenID Connect por acceso de publicación y enumera paquetes. En Kubernetes, lee tokens de cuentas de servicio y enumera secretos de namespaces.
Y en 1Password, interactúa con la interfaz de línea de comandos e intenta extraer la contraseña maestra con bypass de autenticación de dos factores.
La extracción de memoria: eludiendo el enmascaramiento de secretos
El payload localiza el PID del GitHub Actions Runner.Worker usando escaneo de /proc, luego extrae secretos en tiempo de ejecución directamente de la memoria del proceso.
Esta actividad elude el enmascaramiento normal de secretos al leerlos directamente desde la memoria del proceso del runner, un método que los sistemas de seguridad tradicionales no detectan.
La escalada de privilegios y la exfiltración de doble canal
El payload inyecta una regla de sudoers a través de un bind mount, modificando /etc/hosts para la redirección de DNS. Para la exfiltración, utiliza un canal primario HTTPS hacia un dominio C2 cifrado en el puerto 443 con pre-verificación DNS y sonda de salud.
Como respaldo, utiliza la API de Git Data para crear blobs, trees o commits en repositorios de víctimas en ramas no protegidas. Y como canal terciario, crea repositorios públicos bajo cuentas de víctimas con la descripción invertida “niagA oG eW ereH :duluH-iahS”, de los cuales se han observado más de 2.200 hasta la fecha.
La propagación y la persistencia: de una cuenta a miles de proyectos
El payload enumera /user/repos y /user/orgs para propagarse a repositorios adicionales. Instala el runtime de Bun y ejecuta un payload de segunda etapa. Despliega un monitor de tokens para la captura continua de credenciales. Y falsifica atestaciones de procedencia SLSA a través de Sigstore para parecer legítimo.
El impacto: un radio de explosión que abarca miles de proyectos
El impacto directo es el compromiso de paquetes @antv con amplia adopción en el ecosistema. La amplificación a través de dependencias downstream afecta a miles de proyectos.
El riesgo en cascada incluye tokens npm robados que permiten el envenenamiento adicional de paquetes, tokens de GitHub robados que permiten la manipulación de repositorios y credenciales de AWS robadas que permiten el acceso a la nube. La falsificación de procedencia SLSA erosiona la confianza en los marcos de atestación de cadena de suministro.
La respuesta de GitHub: 640 paquetes eliminados y 61.274 tokens invalidados
Al tener conocimiento del ataque, GitHub actuó de inmediato para limitar el daño. Eliminó 640 paquetes maliciosos e invalidó 61.274 tokens de acceso granular de npm con permisos de escritura y bypass de 2FA, evitando que los tokens filtrados pudieran usarse en este o similares ataques.
GitHub también publicó avisos relevantes en la Base de Datos de Avisos de GitHub y alertó a la comunidad a través de alertas de Dependabot y npm audit. Continúa monitorizando paquetes adicionales afectados y eliminándolos según sea necesario.
¿Cómo protegerse: las recomendaciones de Microsoft?
Microsoft recomienda una serie de mitigaciones para reducir el impacto de esta amenaza.
La primera es revisar los árboles de dependencias en busca de uso directo o transitivo de paquetes @antv afectados.
La segunda es identificar sistemas que instalaron o construyeron versiones de paquetes afectadas durante la ventana de exposición sospechosa.
La tercera es fijar versiones conocidas como buenas y evitar actualizaciones automáticas de dependencias hasta que se complete la validación.
También se recomienda deshabilitar la ejecución de scripts pre y post-instalación asegurándose de ejecutar npm install con –ignore-scripts.
Rotar credenciales, tokens, tokens de acceso npm, secretos de CI/CD y credenciales de nube que puedan haber sido expuestos. Auditar las cuentas de GitHub organizacionales y personales en busca de repositorios públicos con la descripción “niagA oG eW ereH :duluH-iahS” u otros repositorios inesperados creados durante la ventana de exposición.
Auditar los registros de CI/CD en busca de conexiones de red salientes inesperadas, ejecución de scripts o actividad sospechosa en el ciclo de vida de paquetes. Revisar los lockfiles de npm, los registros de compilación y la procedencia de artefactos en busca de evidencia de versiones de paquetes comprometidas. Y habilitar la protección en la nube en Microsoft Defender Antivirus o protección antivirus equivalente.
La lección: la cadena de suministro es el eslabón más débil
El ataque Mini Shai Hulud es un recordatorio brutal de que la seguridad de la cadena de suministro de software es uno de los desafíos más críticos de nuestra era digital.
Un solo mantenedor comprometido puede desencadenar una reacción en cadena que afecta a miles de proyectos, desde startups hasta grandes corporaciones. La confianza que depositamos en el código abierto es también nuestra mayor vulnerabilidad.
La respuesta de GitHub fue rápida y contundente, pero el ataque ya se había propagado. La lección para los desarrolladores y las organizaciones es clara: la seguridad no puede ser una ocurrencia tardía.
Debe integrarse en cada etapa del ciclo de vida del desarrollo, desde la selección de dependencias hasta la configuración de los pipelines de CI/CD. La cadena de suministro es tan fuerte como su eslabón más débil, y en el mundo del código abierto, esos eslabones son incontables.
La era de confiar ciegamente en las dependencias ha terminado. La era de la verificación y la auditoría constante ha comenzado.
Descubre más desde CIBERED
Suscríbete y recibe las últimas entradas en tu correo electrónico.
