npm-incident-response

English | Português

Escáner independiente para el incidente de la cadena de suministro de keyv/cacheable ("Shai-Hulud: Here We Go Again", 4 ago 2026) — 440+ paquetes npm comprometidos por un gusano autopropagante que roba credenciales de nube/CI e instala persistencia con un interruptor de hombre muerto.

Detecta, en minutos y sin instalar nada:

• Paquetes comprometidos en package-lock.json, npm-shrinkwrap.json, yarn.lock (v1 y Berry), pnpm-lock.yaml y bun.lock — incluidas las dependencias transitivas, con la cadena completa (p. ej. eslint → file-entry-cache → flat-cache → [email protected]);
• Payloads instalados en node_modules (nombre + hash SHA-256 de los artefactos conocidos);
• Variantes que aún no están en las listas de IOCs (heurística: scripts de ciclo de vida sospechosos, archivos con los nombres del gusano) — siempre marcadas como SUSPECT, nunca confirmadas sin un hash;
• Implantes de persistencia en el host: LaunchAgent (macOS), servicio de usuario de systemd + linger (Linux), hooks en .claude/settings.json y .vscode/tasks.json, artefactos temporales (bun-dl-*);
• El interruptor de hombre muerto: el implante monitoriza un token de GitHub y ejecuta un comando remoto cuando la revocación devuelve 4xx. Rotar las credenciales antes de limpiar el host dispara la trampa — el informe te lo advierte, y el orden de respuesta más abajo evita el error.

Comprender el ataque

1. La cuenta de mantenedor de las familias keyv/cacheable fue comprometida; el atacante publicó nuevas versiones con un hook "preinstall": "node setup.mjs" — código que se ejecuta antes de que el paquete se instale, con los privilegios de quien haya ejecutado npm install.
2. setup.mjs descarga el runtime de Bun desde GitHub y ejecuta el payload dentro de él — evasión contra herramientas que solo monitorizan procesos node.
3. Math_Symbol.js (~728 KB, ofuscado) roba credenciales: metadatos de instancia de AWS, claves de AWS/GCP/Azure, tokens de Vault, cuentas de servicio de Kubernetes, secretos de GitHub Actions, tokens de npm, además de un barrido regex genérico en busca de claves privadas y bearer tokens en el disco.
4. Es un gusano: con el token de npm robado, inyecta el mismo hook en otros paquetes que esa identidad puede publicar, recalcula los hashes de integridad y vuelve a publicar. Así pasó de ~10 a cientos de paquetes.
5. Exfiltra sin un C2 fijo (repositorios de GitHub creados sobre la marcha, DNS) y deja una trampa detrás — ver más abajo.

Los dos vectores (el segundo es más sutil)

• Vector A — instalación: cualquiera que haya ejecutado npm install/npm ci con los scripts de ciclo de vida habilitados desde 2026-08-04 09:35 UTC. Con --ignore-scripts, el hook no se ejecutó.
• Vector B — clonación: el repositorio fuente recibió hooks de autoarranque en .claude/settings.json (SessionStart) y .vscode/tasks.json (folderOpen) que ejecutan el cargador cuando se abre la carpeta clonada — sin npm install, sin instalar nada. Esto incluye a quienes clonaron el repositorio para investigar el incidente y a agentes de codificación de IA que abrieron el directorio — uno de los primeros casos públicos de hooks de agentes de IA (.claude/) usados como vector de cadena de suministro.

La trampa (interruptor de hombre muerto)

El implante instala un "watcher" (gh-token-monitor) mantenido vivo por un LaunchAgent (macOS) o un servicio de usuario de systemd + loginctl enable-linger (Linux). Cada 60 segundos valida el token de GitHub robado contra la API. Mientras el token funcione, no pasa nada. Cuando la respuesta se vuelve 4xx — es decir, el momento en que revocas el token — ejecuta, vía eval, el contenido de ~/.config/gh-token-monitor/handler: un comando arbitrario definido remotamente por el atacante. El análisis público no sabe qué contiene — podría ser destrucción de datos, reimplantación, ransomware o nada. El riesgo no es evaluable; por eso el orden de respuesta es absoluto.

Tres propiedades que cambian la respuesta:

• Aislar la red es seguro: sin conectividad no hay respuesta HTTP, por lo que no hay 4xx — la trampa no se dispara y la exfiltración se detiene. Aísla primero, no apagues (la memoria volátil es evidencia).
• Es de un solo disparo y se autolimpia después de dispararse — el comportamiento queda sin explicación, sin artefactos que investigar.
• TTL de ~24 h: el watcher se autodestruye después de un día. La ausencia de artefactos no prueba que la máquina estuviera limpia — el escáner advierte de esto en el modo host.

Por qué las defensas habituales suelen pasarlo por alto

• "La firma era válida" — [email protected] se publicó con una atestación SLSA en regla. La procedencia da fe de la integridad de la compilación, no de la fuente: el workflow legítimo compiló código ya troyanizado.
• "El diff de código no cambió" — correcto: la librería en sí no fue modificada. La malicia está en package.json (el hook preinstall) y en dos archivos nuevos añadidos al paquete (setup.mjs, Math_Symbol.js).
• "No usamos keyv" — sí lo usas, indirectamente: la cadena más común es eslint → file-entry-cache → flat-cache → keyv. Por eso el escáner muestra la cadena en cada hallazgo.
• "Nadie ejecutó npm install" — insuficiente: ver Vector B.

Qué es el script de este repositorio

scan.mjs tiene las siguientes propiedades — importantes para cualquiera que responda a un incidente de cadena de suministro:

• Un solo archivo, ~880 líneas legibles, cero dependencias. Sin npm install. Audita todo scan.mjs en 15 minutos antes de ejecutarlo.
• Cero egreso. Ningún dato sale de tu máquina. Sin telemetría, sin "enviar el resultado para análisis". La única operación de red es --update (descargar un manifiesto de IOCs nuevo), explícita y opcional.
• Solo lectura. El escáner no modifica, elimina ni ejecuta nada de lo que encuentra.
• Funciona sin conexión. docker run --network=none o una máquina aislada: solo copia scan.mjs + iocs.json.

Cómo usarlo en tu empresa

Requisito: Node.js ≥ 18 (cualquier máquina con npm ya lo tiene). Descarga los dos archivos — scan.mjs + iocs.json — y listo: sin instalación.

Aviso: si clonaste este repositorio completo, la carpeta fixtures/ contiene IOCs inertes usados en las pruebas (nombres y versiones reales, contenido ficticio — sin malware). El escáner la omite automáticamente y lo advierte en la salida; los hallazgos de allí solo aparecen si la escaneas a propósito.

Hay dos modos de ejecución que responden a preguntas distintas, y eso es lo que decide dónde ejecutarlo:

• El modo repo lee lockfiles y node_modules — y los lockfiles viven en git, por lo que se puede centralizar: una persona escanea todos los repositorios de la empresa.
• El modo host busca el implante (watcher, LaunchAgent/systemd, hooks de IDE), que vive en la máquina donde se ejecutó el código — eso no está en git y no se puede centralizar.

Paso 1 — AppSec escanea todos los repositorios (una persona, una máquina)

node scan.mjs repo /folder/with/all/the/repos --json=result.json --html=report.html

Responde "qué proyectos están expuestos" en minutos, sin involucrar a nadie. Acepta múltiples rutas; recorre subdirectorios (incluidos monorepos y workspaces).

Paso 2 — quienes trabajaron en los proyectos afectados escanean su propia máquina

Para cada proyecto con un hallazgo, identifica quién lo tocó desde 2026-08-04 09:35 UTC (git log, registros de CI). Esas personas ejecutan, en su máquina:

node scan.mjs        # current directory + host, in ~30 seconds