Del paquete nx comprometido a control administrativo en la nube en 72 horas

En agosto de 2025 una brecha en la cadena de suministro de software volvió a demostrar que el eslabón más débil puede estar en el flujo de trabajo del desarrollador. Una versión comprometida del paquete nx publicada en npm incluyó un script de postinstalación malicioso que terminó siendo la puerta de entrada para un ataque que escaló en la nube hasta convertirse en control administrativo total en menos de tres días.

El mecanismo inicial no fue sofisticado en su concepto: la explotación de un flujo de trabajo de GitHub Actions basado en pull_request_target, una clase de ataque que la comunidad conoce como Pwn Request. Investigaciones sobre este tipo de abusos y cómo afectan a repositorios y workflows se pueden consultar en análisis técnicos como los de Praetorian, Endor Labs y SonarSource. Ese tipo de flujo permite que un actor con acceso a una solicitud de extracción consiga privilegios elevados y extraiga secretos que luego se reutilizan para comprometer entornos más sensibles.

En este caso, el paquete troceado incluía un ladrón de credenciales en JavaScript bautizado QUIETVAULT, cuya detección puede consultarse en fuentes de análisis de malware como VirusTotal. El código buscaba variables de entorno, metadatos del sistema y tokens valiosos —entre ellos tokens personales de GitHub (PAT)— y subía la información recopilada a un repositorio público. El vector de ejecución fue, paradójicamente, una actualización disparada por una extensión de desarrollo (Nx Console) cuando un empleado abrió su editor y permitió que el postinstall se ejecutara en su máquina.

Con los tokens en mano, el grupo identificado por Google como UNC6426 inició maniobras de reconocimiento dentro del entorno GitHub de la víctima y utilizó una herramienta legítima de extracción de secretos llamada Nord Stream para localizar credenciales adicionales, incluyendo las de una cuenta de servicio de GitHub. A partir de ahí, el atacante aprovechó la relación de confianza entre GitHub Actions y Amazon Web Services (la integración OIDC) para solicitar tokens temporales de AWS STS y acceder a roles con capacidad de desplegar infraestructura.

El problema clave en la nube fue la permisividad de un rol ligado a GitHub Actions que permitía operaciones de CloudFormation con facultades para crear identidades y adjuntar políticas. Con esa ventana, los agresores desplegaron una pila cuyo único objetivo era crear una nueva identidad con la política de AdministratorAccess adjunta. Según el análisis publicado por Google en su Cloud Threat Horizons Report H1 2026, este encadenamiento permitió pasar de un token robado a permisos administrativos completos en AWS en menos de 72 horas.

Con el control administrativo absoluto, los atacantes hicieron lo que cualquier operador malicioso con ese nivel podría: enumeraron y exfiltraron objetos de buckets S3, terminaron instancias de producción en EC2 y RDS y desencriptaron claves de aplicaciones que protegían otros activos. En una fase final de humillación operativa, coincidieron cambios en el ecosistema de desarrollo: renombraron repositorios internos y los hicieron públicos, dejando evidencia del compromiso y ampliando el daño reputacional y operativo.

Hay una capa adicional relevante en este incidente: la intervención de agentes de inteligencia artificial como herramienta operativa. El ladrón QUIETVAULT, además de recoger secretos, aprovechó un asistente LLM presente en los endpoints para localizar credenciales y datos con instrucciones en lenguaje natural, lo que evidencia una nueva modalidad de abuso de la cadena de suministro donde la ejecución de acciones maliciosas se expresa como prompts y no como callbacks codificados. Firmas especializadas, como Socket, han alertado sobre cómo los asistentes integrados en el flujo del desarrollador amplían el perímetro de ataque y complican la detección tradicional.

Las recomendaciones técnicas que emergen de la investigación apuntan a medidas tanto en la fase de desarrollo como en la gestión de identidades y accesos en la nube. Es crítico limitar scripts de postinstalación o ejecutar paquetes en entornos aislados, aplicar estrictamente el principio de menor privilegio en cuentas y roles que interactúan con CI/CD, y evitar privilegios permanentes para tareas que no los requieren, como la creación de roles administrativos. También conviene emplear PATs más granulares y de corta vigencia, vigilar patrones inusuales en la actividad de IAM y fortalecer la supervisión para detectar indicios de agentes de IA actuando sobre sistemas de desarrollo.

Más allá de las medidas puntuales, el caso ilustra una lección estructural: las cadenas de suministro modernas son un vector multiplicador. Un paquete popular con una actualización maliciosa puede transformar un exploit local en una intrusión a gran escala si las relaciones de confianza entre herramientas (editores, extensiones, registries, pipelines y nubes) no están correctamente acotadas. Las organizaciones deben replantearse no solo las políticas de seguridad en la nube, sino cómo se integran y confían las herramientas de desarrollo en entornos distribuidos.

Para quienes deseen profundizar en los detalles técnicos y mitigaciones, los informes y análisis citados ofrecen guías y contexto adicional: el informe de Google sobre amenazas en la nube citadas arriba, los ensayos técnicos sobre Pwn Request de Praetorian y SonarSource, y trabajos sobre ejecución de agentes AI y riesgos en extensiones por parte de Socket. La vigilancia en ambos frentes —cadena de suministro y control de identidades en la nube— es hoy una prioridad operativa y de gobernanza para cualquier organización que dependa de software de terceros y pipelines automatizados.