El bucle de reconocimiento: qué haría falta para que el agente conduzca la caza por sí mismo
La pregunta
¿Qué configuración permitiría a un agente autónomo conducir por sí mismo la caza de credenciales, en lugar de ser usado como herramienta mientras otra cosa marca el rumbo?
La tesis
El paso demostrado es un malware que orquesta CLI de IA de confianza. El paso condicional imagina un agente que recibe su lista de objetivos a través del contenido que lee durante un trabajo legítimo. Cada capacidad que el segundo paso necesita ya existe en los entornos de desarrollo empresariales. Lo que separa a los dos es dónde están las credenciales respecto al alcance del agente, y cuán accesibles resultan sus instrucciones desde una entrada no confiable.
Contenido
Registro de afirmaciones
Hecho verificado
- Versiones maliciosas del paquete del sistema de compilación Nx se publicaron en npm a partir del 26 de agosto de 2025, en torno a las 22:32 UTC, y permanecieron disponibles algo más de cinco horas, durante las cuales miles de desarrolladores pueden haberse visto expuestos. [stepsec]
- El malware recolectó claves SSH, tokens de npm y ficheros .gitconfig, y StepSecurity describe el incidente como el primer caso documentado de malware que utiliza herramientas CLI de IA, incluidas Claude, Gemini y Amazon Q, como armas para el reconocimiento y la exfiltración de datos. [stepsec]
- Los mantenedores de Nx publicaron un aviso de seguridad que confirma el compromiso y afirma que la cuenta de npm de un mantenedor quedó comprometida a causa de una fuga de token. [advisory]
- Una segunda oleada el 28 de agosto de 2025 usó las credenciales filtradas para hacer públicos repositorios privados de la organización y bifurcarlos. [stepsec]
Lectura técnica
- Las CLI de IA aportaron la parte de la caza más difícil de automatizar con scripts: localizar credenciales dentro de entornos de desarrollo heterogéneos. Su lectura del sistema de ficheros es una función del producto, y el malware la usó tal como estaba prevista, sobre un objetivo que eligió él mismo.
Hipótesis
- Un agente que lee contenido no confiable durante un trabajo ordinario podría recibir una lista de objetivos a través de ese contenido y conducir después la misma caza sin un motor externo. Esta es una construcción condicional. Ningún caso así está documentado en este incidente.
Abierto
- El registro publicado no determina cuántas de las credenciales recolectadas se usaron realmente para accesos posteriores, ni informa de si el descubrimiento asistido por agente superó a las partes automatizadas del ataque.
El estado de partida
Tomemos una organización de ingeniería de tamaño corriente y costumbres corrientes. Los desarrolladores instalan un asistente de IA para programar como herramienta de línea de comandos. La herramienta se ejecuta con la identidad del propio desarrollador, lee el árbol de trabajo y puede ejecutar comandos de shell, porque eso es lo que la hace útil. Los runners de integración continua ejecutan pasos de compilación a partir de dependencias instaladas, y esos runners tienen credenciales para que las canalizaciones puedan publicar artefactos y comentar en pull requests.
Añadamos ahora el suceso demostrado. El 26 de agosto de 2025, versiones maliciosas del paquete del
sistema de compilación Nx llegaron a npm y permanecieron disponibles algo más de cinco horas.
[1] Instalar una de ellas ejecutaba una carga útil que recolectaba claves SSH, tokens de npm
y ficheros .gitconfig, y esa carga útil además invocaba los asistentes de IA instalados en la
máquina, usándolos para buscar credenciales en el sistema de ficheros y para enviar lo que
encontraba a repositorios controlados por el atacante. [1] Los mantenedores de Nx
confirmaron el compromiso y lo rastrearon hasta un token de npm filtrado perteneciente a una cuenta
de mantenedor. [2] Una segunda oleada, dos días después, usó las credenciales recolectadas
para hacer públicos repositorios privados de la organización. [1]
Ese incidente es el cimiento. Todo lo que sigue se construye sobre él y va etiquetado como construcción.
1. Capacidades que exige el escenario y dónde se demuestra cada una
| Capacidad | Estado |
|---|---|
| Ejecutar código de un paquete público durante la instalación | Demostrado en el incidente |
| Recolectar credenciales de un entorno de desarrollo | Demostrado en el incidente |
| Invocar sin interacción un asistente de IA instalado | Demostrado en el incidente |
| Localizar credenciales dentro de un sistema de ficheros heterogéneo | Demostrado en el incidente |
| Exfiltrar hacia infraestructura controlada por el atacante mediante protocolos corrientes | Demostrado en el incidente |
| Que un agente reciba una lista de objetivos a través del contenido que lee durante el trabajo normal | Hipótesis, con resultados publicados de inyección de prompt como evidencia de apoyo |
Cinco de las seis capacidades están documentadas como ya ejercidas en el mundo real. La sexta se sitúa entre dos literaturas que rara vez se encuentran: la inyección de prompt, donde el canal de entrega está bien estudiado, y el robo de credenciales en la cadena de suministro, donde el objetivo está bien comprendido. El paso condicional las combina.
2. Condiciones de acceso y permiso
El escenario necesita que cinco condiciones se cumplan a la vez. Un token de larga vida con alcance sobre repositorios o registros debe estar en un fichero que el agente puede leer, sin pedir consentimiento en cada ejecución. El agente debe ejecutarse como la persona, de modo que cualquier acción suya herede la autoridad de esa persona y quede en su rastro de auditoría. Debe leer ficheros, incidencias, dependencias, documentación o salida de herramientas sobre las que un tercero pueda influir. El entorno debe permitir conexiones salientes a puntos finales arbitrarios, incluidos sitios de pegado y hosts públicos de repositorios. Y algo debe ejecutar el agente sin nadie presente: un paso de compilación, un hook, una tarea programada, un vigilante. Quita cualquiera de estas y el escenario condicional pierde su motor. Ese es el sentido de dejarlo por escrito.
3. El mecanismo causal
En el escenario condicional, un fragmento de contenido que el agente encuentra durante el trabajo rutinario contiene una instrucción. El agente lo procesa igual que procesa cualquier texto recuperado, y la instrucción lo envía a buscar material con forma de credencial: ficheros de entorno, almacenes de claves, configuración de nube, cadenas de conexión en repositorios cercanos. Al descubrimiento le sigue la recolección, y a la recolección la transmisión a un punto final que la instrucción nombraba.
Poco importa lo ingeniosa que sea la instrucción. Lo que importa es dónde reside la capacidad. El incidente demostrado mostró que un asistente que lee el sistema de ficheros es un motor de búsqueda de credenciales eficaz en entornos que nadie ha catalogado. Combina esa capacidad de búsqueda con un canal de entrega para la lista de objetivos, y el atacante ya no tiene que escribir código de reconocimiento para cada entorno, que es la parte más cara de una campaña de cadena de suministro.
4. Puntos de fallo, ordenados por lo barato que resulta corregirlos
Los puntos de fallo merecen atención en el orden de lo que cuesta cerrarlos. Un token que caduca en quince minutos conserva poco valor en un host que ya ha sido comprometido. Un agente con identidad propia, que sostiene sus propias atribuciones con alcance limitado, deja un rastro de auditoría limpio y niega al adversario el alcance de la persona. Un agente al que se concede el árbol de trabajo en lugar del directorio personal encuentra menos ficheros de credenciales. Un runner que solo puede alcanzar tres hosts no puede publicar en un repositorio que el atacante haya elegido. Un asistente que exige una sesión interactiva no puede ser conducido por un hook posterior a la instalación.
5. Prevención y contención
Los controles que este atlas ya incluye encajan en los puntos de fallo con una pulcritud poco habitual. Mantener la autorización del agente fuera del propio agente hace que las llamadas a herramientas y las operaciones privilegiadas las medie una parte que el agente no puede suplantar. Tratar las acciones ejecutadas por el agente como de alto impacto y condicionarlas a una decisión humana rompe el bucle en el momento de la recolección. Registrar y limitar qué herramientas de IA pueden ejecutarse en las imágenes de desarrollo y de runners reduce la superficie de búsqueda instalada, y validar y registrar las entradas y salidas del agente convierte una conversación no observada con contenido no confiable en un registro revisable. Cada uno de esos controles está catalogado, con su propio alcance y sus límites, en las fichas de control enlazadas al pie de esta pieza. Credenciales de corta vida emitidas para las cargas de trabajo, en lugar de tokens guardados junto al código, eliminan el premio.
La contención merece una reflexión aparte, porque el incidente demostrado comprimió la ventana de respuesta hasta hacerla incómoda. El paquete malicioso estuvo activo unas cinco horas, y el abuso posterior de las credenciales empezó dos días después. [1] Las organizaciones que no pueden responder en horas a la pregunta «qué paquetes se instalaron en esta ventana, en qué host y qué credenciales había allí» no pueden contener en absoluto esta clase de suceso.
6. Incertidumbres
El registro publicado establece el mecanismo, y deja varias cantidades sin medir. Cuántas de las credenciales recolectadas produjeron accesos posteriores no está establecido públicamente. Si la búsqueda asistida por el asistente superó a los componentes automatizados no se ha informado, y la lectura honesta es que los asistentes ampliaron la búsqueda allí donde automatizarla resultaba incómodo, más que sustituirla. Cuánto tiempo siguieron siendo válidas las credenciales en la práctica depende de una higiene que varía según la organización, que es justo la variable que determina el radio de daño.
7. Evidencia que limita la plausibilidad
Dos límites mantienen honesto este escenario.
El primero es la forma del abuso demostrado. El malware puso la conducción, el objetivo y el canal de exfiltración, y los asistentes pusieron la lectura de ficheros. Un escenario en el que el agente genera sus propios objetivos a partir de un fragmento de contenido no confiable es una construcción distinta, y su plausibilidad se apoya en resultados de inyección de prompt, más que en este incidente.
El segundo es la dificultad de la búsqueda autodirigida. Un agente que debe decidir cuáles de diez mil ficheros parecen credenciales se enfrenta a un problema sin límites, y las tasas de error en tareas autónomas de varios pasos siguen siendo altas. El escenario condicional se vuelve realista en entornos donde las credenciales están en lugares predecibles, lo que describe a la mayoría de las organizaciones y a ninguna de las cuidadosas.
El veredicto de Atlas
Un malware comprometió un paquete de compilación muy usado y utilizó los asistentes de IA para programar instalados para localizar y exfiltrar credenciales de desarrolladores a escala, en una ventana de unas cinco horas.
- La lectura que nos parece más sólida
- Lo nuevo aquí es el reparto del trabajo. El malware puso el objetivo y la infraestructura, y los asistentes pusieron la capacidad de lectura de ficheros que un script habría tenido que escribir desde cero para cada entorno que encontrase.
- Qué se malinterpreta casi siempre
- La cobertura lo presentó como agentes de IA que se vuelven contra sus usuarios. Los agentes fueron invocados como herramientas por un proceso externo, y su comportamiento se derivó del acceso que ya tenían.
- Por qué importa para la seguridad, la ciencia o la filosofía
- Cada estación de trabajo de desarrollador y cada runner de CI con un agente instalado y credenciales en el entorno ha añadido una capacidad de búsqueda de propósito general a todo lo demás que se ejecuta allí, incluido código que llegó hace cinco minutos en una actualización de dependencia.
- Evidencia que cambiaría esta conclusión
- Una configuración que separe la identidad del agente de la identidad humana, y que niegue las credenciales del entorno durante la instalación de paquetes, haría fracasar el paso demostrado. La ausencia de tales fallos en entornos auditados es en sí misma una evidencia comprobable.
Fuentes
- [1] StepSecurity, 's1ngularity: Popular Nx Build System Package Compromised with Data-Stealing Malware'
El informe que documentó el abuso de las CLI de IA y la segunda oleada, y la fuente de casi todo el detalle técnico de esta pieza.
- [2] GitHub Security Advisory GHSA-cxm3-wv7p-598c (Nx compromise)
Aviso de los mantenedores que confirma el compromiso y la cuenta de npm que hay detrás. Publicado en la base de datos de avisos del registro de npm.
-
Identificador seguido por el fabricante para el paquete manipulado, que conviene conservar para consultas de activos.