Campaña ChainDrop expone tensorlake en npm; versión 0.5.144 retirada

Un paquete de npm llamado tensorlake, un SDK en TypeScript orientado a aplicaciones y servicios de Tensorlake, fue comprometido en una campaña de cadena de suministro vinculada a la familia de ataques conocida como ChainDrop / Shai‑Hulud. La versión maliciosa identificada —0.5.144— fue retirada del registro de npm después de que análisis independientes rastrearan en su contenido un gancho de preinstalación y múltiples artefactos destinados a robar credenciales, exfiltrar secretos, mantener persistencia y ejecutar código remoto.

Los componentes investigados muestran que, durante la instalación, el paquete ejecutaba un preinstall hook que invocaba el archivo package/lib/setup.mjs. Ese arranque cargaba un “loader” ofuscado que ejecutaba, sobre el runtime Bun, el payload principal (package/lib/Math_Symbol.js). El comportamiento técnico documentado incluye recolección de credenciales desde ficheros locales y entornos de CI, extracción desde Kubernetes y HashiCorp Vault, instalación del binario HackBrowserData para robar datos de navegadores, exfiltración de información cifrada y mecanismos de persistencia que permiten al atacante conservar acceso incluso si la dependencia es eliminada.

Entre los tipos de secretos confirmados como objetivo por los análisis están tokens de npm y GitHub, credenciales y secretos de AWS, tokens y credenciales de Vault, credenciales de Kubernetes, claves SSH, archivos .env, carteras de criptomonedas y datos de aplicaciones de mensajería. También se identificaron referencias a ficheros de configuración asociados a agentes de IA y servicios de asistentes —por ejemplo, archivos relacionados con Claude y otras plataformas—, lo que sugiere que el actor buscaba información útil para explotar infraestructura de IA o agentes de automatización.

El vector de propagación detectado combina dos capacidades peligrosas: por un lado, el gusano enumera paquetes asociados a la identidad del publicador de la víctima, genera una prueba de procedencia (Sigstore provenance) y vuelve a publicar versiones comprometidas para infectar otras víctimas; por otro, planta flujos de trabajo de GitHub Actions falsos (cadenas semejantes a Copilot/Dependabot) y escribe ficheros como .claude/settings.json y .vscode/tasks.json en repos que puede alcanzar, de modo que la carga maliciosa se reactive cuando un desarrollador abra el proyecto en ciertas herramientas. También se documentó el uso de un contrato Ethereum para resolver un endpoint de comando y control (C2) y el uso de repositorios públicos en GitHub como mecanismo de fallback para alojar datos robados.

Factos confirmados: la versión 0.5.144 del paquete fue publicada y después retirada del registro de npm; el paquete contenía un preinstall hook que activaba archivos ofuscados y un payload basado en Bun; el malware buscaba y exfiltraba una amplia gama de secretos, dejaba binarios conocidos (HackBrowserData) y plantaba artefactos en repositorios; hubo commits maliciosos al repositorio tensorlakeai/tensorlake y la primera modificación reportada fue el 7 de octubre de 2026, según análisis publicados por terceros. Estas conclusiones provienen de informes técnicos publicados por equipos de respuesta que analizaron el release y los artefactos en el repositorio.

Incógnitas y estimaciones: la escala exacta de la infección (número de instalaciones afectadas o organizaciones comprometidas) no ha sido publicada de forma exhaustiva; tampoco está confirmado públicamente el alcance de credenciales efectivamente explotadas o si el atacante logró comprometer cuentas de alto impacto en empresas concretas. El uso del monitor “hostage token” que ejecuta código con Invoke‑Expression cuando se revoca un token ha sido observado en oleadas previas y se considera una táctica de alto riesgo; sin embargo, el impacto destructivo real de esa rutina en esta campaña, si llegó a ejecutarse, permanece sujeto a investigación forense en hosts afectados.

¿A quién afecta esto? Principalmente a desarrolladores y organizaciones que hayan instalado la versión 0.5.144 del paquete tensorlake —directa o transitivamente— en entornos de desarrollo, CI/CD, contenedores o imágenes base. El vector es especialmente crítico en pipelines automatizados y entornos con secretos montados en el contexto de ejecución (por ejemplo, runners de CI con tokens con permisos, contenedores con credenciales de nube o agentes de IA con claves almacenadas). También están en riesgo quienes publican paquetes npm con la misma identidad de maintainer, porque el gusano intenta reutilizar esas credenciales para propagar versiones maliciosas.

Consecuencias prácticas: la exposición de un token de CI o de una clave de AWS puede derivar en exfiltración de datos, despliegues no autorizados, gasto fraudulento en la nube, usurpación de cuentas de repositorio y pivoteo lateral dentro de redes corporativas. La persistencia a nivel de repositorio y de flujos de trabajo significa que la mera eliminación de la dependencia no garantiza la erradicación del actor si éste ha dejado artefactos en el código o ha sesgado la cadena de distribución de paquetes.

Medidas concretas e inmediatas que debería tomar quien haya instalado la versión comprometida: primero, identificar si su entorno contiene la versión 0.5.144 revisando package.json, package-lock.json, yarn.lock, pnpm-lock.yaml y ejecutando comandos de inspección en proyectos y build servers (por ejemplo, npm ls tensorlake o grep recurriendo a los ficheros de lock). Si aparece la versión maliciosa, eliminarla inmediatamente y aislar hosts donde se instaló la dependencia.

Segundo, rotar todas las credenciales potencialmente expuestas: revocar y reemitir tokens de npm y GitHub, claves y roles de AWS, credenciales de Vault, cuentas de servicio de Kubernetes y cualquier clave SSH que pueda haber residido en esos entornos. No limitase a rotarlas una sola vez: cada secret que pudiera haber sido accesible al proceso infectado debe considerarse comprometido y reemplazado.

Tercero, realizar búsquedas forenses: buscar archivos y procesos que coincidan con package/lib/setup.mjs o package/lib/Math_Symbol.js, detectar binarios HackBrowserData, revisar cron, servicios y tareas programadas, y auditar los repositorios y GitHub Actions en busca de workflows no autorizados o commits sospechosos (incluyendo los ficheros .claude/settings.json y .vscode/tasks.json). Aislar y preservar evidencia antes de limpiar para permitir investigación posterior.

Cuarto, higienizar imágenes y runners: reconstruir contenedores e imágenes desde orígenes de confianza, no reutilizar artefactos binarios que hayan estado en entornos comprometidos y regenerar credenciales asociadas a runners y agentes. En pipelines, evitar montar secretos en texto plano en contenedores y preferir mecanismos temporales y rotativos (por ejemplo, credenciales de corta duración o mecanismos de OIDC donde sea posible).

Por último, a nivel organizacional, ejecutar escaneo de dependencias a través de la flota de repositorios y máquinas, activar detección de comportamiento anómalo saliente (conexiones a dominios sospechosos como iseekaigogo[.]com), y fortalecer controles de publicación de paquetes (revisiones humanas en releases, restricción de permisos de publicación y uso de firmas de artefactos verificables). Para entender mejor las garantías de procedencia y mitigación de abuso en firmas, consultar documentación de Sigstore: https://sigstore.dev. Para comprobar la existencia y estado del paquete afectado y su historial en el registro, ver la página de npm: https://www.npmjs.com/package/tensorlake y el repositorio asociado en GitHub: https://github.com/tensorlakeai/tensorlake.

Esta intrusión es una nueva iteración de la tendencia observada desde agosto de 2026 por la que actores atacan la cadena de suministro de JavaScript y, ahora, extienden el foco hacia infraestructuras de IA y agentes automatizados. La lección operacional es clara: la simple presencia de una dependencia en node_modules puede ser un vector de compromiso cuando esa dependencia ejecuta código en hooks de instalación o en pipelines con permisos extensos. Revisar políticas de publicación, minimizar privilegios en tokens de CI y configurar detección de secretos en repositorios son medidas que reducen considerablemente el riesgo de que un incidente similar escale dentro de una organización.