Cuando los agentes de IA parecen atacantes: lo que nos muestra la telemetría de comportamiento

Los agentes de código con IA (Claude Code, Cursor, Codex y otros basados en paquetes de habilidades como GStack) están apareciendo en los entornos de los clientes. Escriben código, instalan dependencias, automatizan tareas del navegador y solucionan fallos probando enfoques alternativos. Desde la perspectiva de un motor de comportamiento de endpoints, parte de esa actividad es indistinguible de la actividad típica que se observa en las redes de los clientes o, en algunos casos, de las acciones que podría llevar a cabo un adversario activo.

En este blog analizamos datos de telemetría reales del motor de comportamiento CIXA de Sophos en Windows para mostrar dónde y por qué los agentes de IA activan reglas de detección. La intención no es calificar esta actividad de maliciosa, sino demostrar que las protecciones de comportamiento existentes funcionan exactamente como las diseñamos, e ilustrar los retos de ingeniería de detección que nos esperan a medida que se acelera la adopción de la IA agencial.

Resumen de la telemetría

El siguiente gráfico muestra la distribución de los aciertos de reglas de bloqueo durante un periodo de siete días en junio de 2026, desglosados por táctica MITRE ATT&CK y medidos por número de máquinas únicas. Predominan las tácticas relacionadas con el «Acceso a credenciales» y la «Ejecución» (respectivamente, la novena y la cuarta categoría de tácticas en la matriz ATT&CK). Fíjate en la presencia de una categoría que no pertenece a ATT&CK y que llamamos «Disrupt».

Figura 1: activaciones de reglas de bloqueo (por táctica de MITRE) tras los agentes de IA, medidas por número de máquinas únicas

La categoría «Disrupt» —que no forma parte de las categorías oficiales de ATT&CK, pero es un útil cajón de sastre que vamos a explicar a continuación— representa las reglas de AAP (Adaptive Attack Protection), es decir, dispositivos en los que la AAP se activó y bloqueó la actividad asociada a los agentes de IA. Todas las detecciones de AAP que analizamos tenían que ver con ejecutables de baja reputación que los agentes intentaban ejecutar. Ninguno parecía malicioso, pero todos tenían puntuaciones de reputación global bajas en la telemetría de SophosLabs.

Si pasamos a las detecciones silenciosas (sin bloqueo) de las reglas, obtenemos una visión más amplia de la actividad que realizan los agentes de IA y que el motor de comportamiento considera que merece la pena rastrear y agrupar.

Figura 2: detecciones silenciosas de reglas (por táctica MITRE) tras los agentes de IA, medidas por número de máquinas únicas

La distribución de las reglas silenciosas está más dispersa, con las categorías de evasión y C2 a la cabeza. Esto refleja que los agentes realizan llamadas de red, generan procesos hijos y utilizan patrones de línea de comandos que se solapan con las técnicas de los atacantes.

Acceso a credenciales

Volviendo a las dos categorías más grandes de ATT&CK que vimos en nuestro conjunto de datos de reglas de bloqueo, las reglas de «Acceso a credenciales» representan la mayor parte de las detecciones. El desglose de las reglas específicas se muestra en la Figura 3.

Figura 3: reglas de bloqueo de acceso a credenciales tras los agentes de IA, medidas por número de máquinas únicas

Creds_3b es la responsable de la mayor parte de estos resultados positivos. Esta regla se activa ante la señal HMPA CookieGuard, que identifica procesos que usan la API de protección de datos (DPAPI) para descifrar las credenciales del navegador.

GStack /browse y Creds_3b

GStack es un paquete de habilidades para agentes de IA muy extendido. Una de sus habilidades integradas, /browse, conecta el agente a un daemon de Chromium para automatizar el navegador. La telemetría de Creds_3b muestra que esta cadena de habilidades usa PowerShell para descifrar datos confidenciales del navegador. El ejemplo de la figura 4 muestra cómo Claude Code invoca GStack /browse.

Figura 4: árbol de actividad que muestra la cadena de habilidades de GStack /browse, desde bash pasando por browse.exe y node.exe, hasta llegar a PowerShell

La línea de comandos de PowerShell confirma lo que detectó la regla:

powershell -NoProfile -Command "Add-Type -AssemblyName System.Security; 
  $stdin = [Console]::In.ReadToEnd().Trim(); 
  $bytes = [System.Convert]::FromBase64String($stdin); 
  $dec = [System.Security.Cryptography.ProtectedData]::Unprotect($bytes, 
    $null, [System.Security.Cryptography.DataProtectionScope]::CurrentUser); 
  Write-Output ([System.Convert]::ToBase64String($dec))" 

En este contexto, es casi seguro que se trata de algo inofensivo: el agente está automatizando una sesión del navegador. Pero que PowerShell descifre las credenciales del navegador a través de DPAPI es precisamente lo que Creds_3b está diseñado para bloquear, y la regla se activa correctamente.

Acceso a credenciales en Python (Creds_6a, Creds_2d)

Varias detecciones de acceso a credenciales involucraban procesos de Python. En el ejemplo que se muestra en la figura 5, Claude ejecuta una serie de comandos taskkill.exe para cerrar procesos del navegador por PID y, a continuación, ejecuta un script de Python que accede a los almacenes de credenciales del navegador.

Figura 5: Claude cerrando procesos del navegador antes de ejecutar un script de Python (decrypt_wp_pass.py) que accede a los datos del navegador (haz clic para ampliar la imagen)

El árbol de actividad también muestra un comando que Claude genera para extraer las credenciales almacenadas en el Administrador de credenciales de Windows:

"C:\Windows\system32\cmdkey.exe" /list

¿Es esto malicioso? Por sí solo, bastaría para que un analista de MDR te llamara. La línea de comandos de claude.exe incluye un indicador que merece la pena destacar:

--dangerously-skip-permissions 

La documentación de Claude, como muestra la figura 6, es muy clara sobre los riesgos de este indicador.

Figura 6: advertencia de la documentación de Claude Code sobre el indicador --dangerously-skip-permissions

Ofuscación de la línea de comandos

Apareció una serie de activaciones de Exec_16a en la telemetría. Se trata de una regla antigua, añadida hace más de cinco años. En un principio se creó para detectar PowerShell malicioso que utilizara una técnica específica de formateo de cadenas como ofuscación leve.

Cinco años después, los agentes de IA están generando código PowerShell con patrones de formateo similares en sus líneas de comando. Ya hemos reforzado la regla para reducir los falsos positivos procedentes de esta fuente.

Ingreso: descarga y ejecución

Los agentes de IA son solucionadores de problemas persistentes. Cuando un comando falla, prueban alternativas, pasando por diferentes herramientas y técnicas hasta que algo funciona. Esta es una capacidad útil para un asistente de programación. También refleja cómo se comportan los atacantes que se ponen manos a la obra con el teclado una vez que tienen acceso.

Un ejemplo de telemetría lo ilustró claramente. El agente de IA (OpenAI Codex) intentó descargar y ejecutar un instalador de Python. Empezó con certutil.exe (Lateral_1b lo bloqueó) y luego pasó a bitsadmin.exe (Exec_5a lo bloqueó).

El destino de la descarga era legítimo: python.org. Sin embargo, «certutil -urlcache» y «bitsadmin /transfer» son métodos de descarga típicos de LOLBin. El agente los utilizó por iniciativa propia y, cuando bloqueamos uno, cambió a otro. Ese comportamiento de cambio de estrategia es exactamente lo que distingue a un adversario activo de un script tonto, y ahora es algo que los agentes de IA benignos hacen habitualmente.

Persistencia

Escribir en la carpeta de inicio fuera del contexto de un instalador de confianza y con buena reputación es una señal de alarma.

No es un comportamiento que esperarías de un agente de programación.

El ejemplo siguiente muestra a Cursor utilizando un script de PowerShell para escribir un archivo VBScript en la carpeta de inicio de Windows. La regla Persist_2a bloqueó la acción. El nombre del archivo del script sugiere que está relacionado con una aplicación llamada «EZConvert», pero sin el contenido del script no podemos confirmar la intención.

Línea de comandos de PowerShell:

powershell.exe -ExecutionPolicy Bypass -File C:\Users\<username>\AppData\Local\Temp\ps-script-6a6de53c-7d17-4e73-9538-00a77b8b2a2d.ps1 

Script en proceso de escritura:

C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\Launch-EZConvert-ConsoleOnly.vbs 

Conclusión

Los agentes de programación con IA han cambiado lo que se considera «normal» en la telemetría de los clientes. Las reglas que antes se activaban casi exclusivamente ante actividades maliciosas ahora se activan ante comportamientos benignos de los agentes. El cambio aún no es muy grande, pero la tendencia es clara.

Algunas de estas actividades son realmente sospechosas, independientemente de quién las haya iniciado. Que PowerShell descifre credenciales del navegador, extraiga entradas del gestor de credenciales, escriba en carpetas de inicio o pruebe distintos métodos de descarga de LOLBin… son cosas que los defensores señalan por una buena razón. El hecho de que las haya hecho un agente de IA no las convierte en seguras.

La ingeniería de detección tendrá que adaptarse. Tendremos que ajustar algunas reglas para tener en cuenta las firmas de agentes que sabemos que son fiables. Otras deberían seguir activándose, porque la actividad que detectan es arriesgada, tanto si la ha iniciado un humano como un agente. Los ejemplos prácticos anteriores son un punto de partida para esa clasificación.

La cuestión más amplia para los clientes que implementan agentes de IA tiene que ver con las políticas y el control. ¿Qué se le debería permitir hacer a un agente en un endpoint? ¿Qué límites debemos imponer? La telemetría de comportamiento que mostramos aquí ofrece un conjunto de datos inicial muy útil para desarrollar esas políticas. No se trata de una instantánea de seis meses de telemetría con conclusiones definitivas. Es un primer análisis, un breve resumen de datos, en el que ya podemos ver algunas cosas interesantes, y también reconocer que deberemos seguir supervisando, evaluando y ajustando.