Esto es lo que realmente sucedió, paso a paso: El 18 de mayo, los actores de amenazas comprometieron la cuenta de publicación de Nrwl (la empresa detrás de Nx Console) en el mercado de VS Code. Entre las 12:36 y las 12:47 UTC de ese día, subieron la versión 18.3.4 de Nx Console con código malicioso al mercado utilizando las credenciales legítimas del editor. La versión comprometida fue firmada criptográficamente con el certificado de editor válido de Nrwl, por lo que la verificación integrada de VS Code la aceptó sin advertencia. Cuando cualquier instancia de VS Code de un desarrollador buscó actualizaciones de extensiones durante esa ventana de 11 minutos (o cuando instalaron manualmente Nx Console durante ese período), descargaron directamente la versión envenenada desde el mercado oficial de Microsoft. La extensión no fue hackeada en el sentido de que alguien modificara archivos en un servidor, se publicó por la puerta principal utilizando credenciales de editor robadas. ¿Cómo obtuvieron los atacantes las credenciales de publicación del mercado de Nrwl en primer lugar? Esa es la parte que a la mayoría de la cobertura le falta. La publicación en el mercado de VS Code requiere ya sea un Token de Acceso Personal (PAT) de Azure DevOps o credenciales OAuth vinculadas a una cuenta de Microsoft. Esas credenciales casi con seguridad se obtuvieron de un compromiso anterior de cadena de suministro, posiblemente de una ola anterior de la misma campaña. Esto crea un patrón de falla en cascada: comprometer una herramienta de desarrollador para robar credenciales, usar esas credenciales para publicar versiones maliciosas de otra herramienta de desarrollador, usar esa herramienta para robar más credenciales, repetir. Cada iteración aumenta el acceso del atacante a las cuentas de editor en todo el ecosistema. El compromiso de Nx Console no fue el paciente cero, ya estaba profundamente en la cadena. Una vez que la extensión envenenada se instaló en la máquina de un desarrollador (incluido el empleado de GitHub en el centro de esta historia), ejecutó inmediatamente código que escaneó toda la máquina en busca de credenciales. Las extensiones de VS Code están escritas en JavaScript y TypeScript, y se ejecutan dentro de Node.js, el mismo entorno de ejecución de JavaScript que impulsa a VS Code. Cuando instalas una extensión, VS Code carga su código JavaScript directamente en el espacio del proceso del editor con acceso completo a las APIs de Node.js. El código malicioso en Nx Console 18.3.4 utilizó las APIs del sistema de archivos de Node.js (específicamente fs.readFile, fs.readdir y funciones de recorrido de rutas) para escanear recursivamente el directorio de inicio del usuario y ubicaciones comunes de almacenamiento de credenciales. Buscó archivos que coincidieran con patrones como .npmrc, .aws/credentials, .kube/config, .ssh/, .gitconfig, .netrc y archivos de configuración para 1Password CLI, HashiCorp Vault y Claude Code. La extensión también llamó a las APIs del proceso hijo de Node.js (child_process.exec y child_process.spawn) para ejecutar comandos del sistema que descargan variables de entorno, consultan el llavero del sistema en macOS (utilizando la herramienta de línea de comandos de seguridad) y extraen credenciales del Administrador de Credenciales de Windows (usando cmdkey). Todo esto sucede en puro JavaScript que se ejecuta con los mismos privilegios que el usuario que lanzó VS Code. No hay sandboxing, no hay mensajes de permisos, no hay aislamiento a nivel del sistema operativo. Las extensiones de VS Code son código de confianza por diseño. Las credenciales obtenidas fueron luego exfiltradas usando el módulo https incorporado de Node.js para enviar los datos mediante POST a dominios controlados por el atacante. El código malicioso ofuscó el punto final de exfiltración utilizando codificación base64 y concatenación de cadenas para evadir el análisis estático, pero una vez que la extensión se ejecutó, hizo solicitudes HTTPS directas para enviar cargas útiles JSON comprimidas que contenían todas las credenciales que encontró. El package.json de la extensión declaró eventos de activación que la hacían ejecutarse inmediatamente al inicio de VS Code (utilizando el evento de activación "*", que se activa en cualquier apertura de espacio de trabajo), lo que significa que los desarrolladores no necesitaban invocar explícitamente las funciones de Nx Console para que se ejecutara el código malicioso. Solo tener VS Code funcionando con la extensión instalada era suficiente. La carga útil de JavaScript también inyectó hooks en las propias APIs de almacenamiento de credenciales de VS Code (usando las APIs vscode.authentication y vscode.workspace) para interceptar cualquier credencial a la que el usuario accediera durante su sesión de trabajo, incluidos los tokens OAuth de GitHub que VS Code utiliza para su propia integración de Git. A partir de ahí, el atacante utilizó esas credenciales robadas para instalar una segunda extensión envenenada en la misma máquina del empleado (GitHub aún no ha revelado cuál fue esta extensión). Esa segunda extensión exfiltró aproximadamente 3,800 repositorios internos de GitHub durante las siguientes horas o días. Para el 20 de mayo, el grupo de amenazas TeamPCP estaba anunciando los repositorios robados para su venta en un foro de piratería por $50,000 en adelante, horas antes de que GitHub confirmara públicamente la brecha. Los repositorios internos no son datos de clientes, son algo peor para la seguridad de la infraestructura. Estos repositorios contienen scripts de implementación, credenciales de preparación, esquemas de API internos y configuraciones de infraestructura. El acceso al código fuente a ese nivel da a los atacantes un plano de cómo los sistemas de GitHub se conectan, autentican y fallan. Cada secreto que llega a un comprador acorta la fase de reconocimiento para cualquier ataque que ese comprador ya estaba planeando. El cofundador de Binance, CZ, advirtió inmediatamente a cualquiera con repositorios privados que contengan secretos en texto claro que rotara todo. Mike Riemer, CTO de Ivanti, me dijo que la red honeypot de Azure ahora muestra vulnerabilidades conocidas explotadas en menos de 90 segundos, y las credenciales robadas colapsan la línea de tiempo aún más. La brecha de GitHub no llegó en un vacío. El 19 de mayo, Endor Labs detectó 42 paquetes npm maliciosos (Socket's tracking más amplio encontró 639 versiones maliciosas en 323 paquetes) publicados dentro del ecosistema de visualización de datos @antv de Alibaba, que ve aproximadamente 16 millones de descargas semanales. Esta ola introdujo falsificación de procedencia: el gusano Mini Shai-Hulud ahora llama a Fulcio y Rekor en tiempo de ejecución para generar certificados de firma válidos de Sigstore para cada paquete que propaga. Las herramientas de procedencia muestran una insignia verde. La cadena de construcción pertenece al atacante. Peyton Kennedy, investigador de seguridad sénior en Endor Labs, me dijo que "TanStack tenía la configuración correcta sobre el papel: publicación de confianza OIDC, procedencia firmada, 2FA en cada cuenta de mantenedor. El ataque funcionó de todos modos". También el 19 de mayo, actores de amenaza comprometieron el flujo de trabajo de acciones de GitHub actions-cool/issues-helper redirigiendo cada etiqueta existente a un commit impostor que contiene código malicioso que exfiltra credenciales de pipelines CI/CD (Integración Continua/Despliegue Continuo). El dominio de exfiltración coincidió con la ola Mini Shai-Hulud de @antv, uniendo los clústeres. Horas después, Wiz detectó que TeamPCP había comprometido durabletask, el cliente oficial de Python de Microsoft para el marco de ejecución de flujos de trabajo Durable Task. Tres versiones maliciosas fueron publicadas en PyPI (Índice de Paquetes de Python) dentro de una ventana de 35 minutos usando una cuenta de GitHub comprometida en una operación previa de TeamPCP. La carga útil roba credenciales de AWS (Servicios Web de Amazon), Azure, GCP (Plataforma de Google Cloud), Kubernetes y más de 90 configuraciones de herramientas de desarrollo, luego se propaga lateralmente a través de la infraestructura en la nube. El paquete promedia más de 400,000 descargas mensuales. Todo el patrón se repite: comprometer una herramienta popular, exfiltrar credenciales de cada máquina que la ejecuta, usar esas credenciales para comprometer la siguiente herramienta. TeamPCP está construyendo una base de datos de credenciales que abarca todo el ecosistema de desarrolladores y están vendiendo acceso a cualquiera que pague.