IA, scripts, operador: dentro del ataque a ConnectWise

Agradecimientos: Un agradecimiento especial a Eric Stride y Andrea Hatcher por sus contribuciones a esta investigación y a este artículo.

Contexto

El 16 de octubre, Huntress informó por primera vez sobre el abuso de una credencial de ConnectWise Cloud Backup para acceder a inquilinos de Microsoft 365, y desde entonces hemos seguido investigando el comportamiento del actor de amenazas relacionado con este incidente.

Ahora estamos tirando de un hilo distinto: quién, o qué, estaba escribiendo durante la actividad no autorizada que observamos. Microsoft publicó sus propios hallazgos y atribuyó la actividad a un actor de amenazas que rastrea como Storm-0940, el cual, según indica, usó ARTEX, un framework de IA multiagente de código abierto, para abusar de las credenciales comprometidas de la aplicación de ConnectWise e iniciar sesión en los inquilinos de Microsoft 365 posteriores a velocidad de máquina. Nuestra telemetría concuerda con los hallazgos de Microsoft, pero no los confirma de forma independiente.  

En la actividad de los inquilinos que examinamos, observamos que las herramientas cambiaban en menos de un minuto entre ejecuciones y que aparecía un bucle de reintentos en la ejecución posterior a un fallo. Algunas acciones se probaron primero en un inquilino antes de ejecutarse en lotes, un patrón que vimos tres veces en dos herramientas distintas. 

En conjunto, estas observaciones forman nuestra hipótesis de trabajo: herramientas con scripts hicieron la mayor parte del trabajo pesado en este incidente, mientras que algo adaptaba las herramientas entre ejecuciones, con rapidez. Es muy posible que ese algo sea un agente. A continuación, damos detalles sobre lo que vimos y dejamos que el público saque sus propias conclusiones.

Qué podemos ver y qué no

Nuestra visión proviene de los registros de inicio de sesión de Entra y de los registros de auditoría de directorio en los inquilinos de Microsoft 365 que monitoreamos, además de los barridos a nivel de flota que realizamos durante la ventana del incidente. Esto nos da el momento, el orden y la forma de lo que el actor hizo que Entra registrara. Sin embargo, deja algunos vacíos importantes:

• Las lecturas de Microsoft Graph no quedan registradas en el registro de auditoría de Entra, y ninguna víctima que conozcamos tenía habilitado el registro de actividad de Graph, por lo que no podemos ver el alcance ni el método de ningún acceso a Graph en los registros disponibles para nosotros.

• Los eventos de auditoría exclusivos de aplicaciones no incluyen una dirección IP de origen, por lo que no podemos vincular parte de la actividad, como los cambios de credenciales, a una IP específica.

• No tenemos visibilidad de los sistemas propios del actor, por lo que no podemos ver las herramientas en sí, ni si algún proveedor de modelos estaba detrás de ellas.

Por último, no podemos afirmar si se usó IA para planificar la operación, elaborar listas de objetivos o escribir las herramientas.

Un día, tres modos de operación

La mayor parte de lo que podemos ver ocurrió el 15 de octubre, en poco menos de 14 horas. Al colocarla en una sola línea de tiempo, la actividad se divide en tres comportamientos distintos: 

• Bucles con scripts

• Trabajo manual de un operador (un "operador" es quien haya dirigido las herramientas, ya sea una persona, una automatización o un agente de IA)

• Un tramo en el que las herramientas siguieron funcionando después de que aquello a lo que apuntaban ya había desaparecido

Figura 1: Actividad del 15 de octubre en inquilinos monitoreados por Huntress, agrupada por comportamiento. "Dirigido por un operador" significa que una persona, o un modelo que actuaba en su nombre, estaba dirigiendo las herramientas entre ejecuciones.

Cómo se ven diferentes los scripts, las personas y los agentes de IA en los registros

Los registros que analiza Huntress documentan el comportamiento y nos ayudan a determinar qué ocurrió: qué tan rápido suceden las cosas, qué pasa después de que algo falla y cuánto varían las solicitudes. Los registros pueden mostrar distintos tipos de huellas según si el comportamiento proviene de un script, una persona o un agente LLM. A continuación, una tabla de posibles señales de comportamiento entre los tres, aunque estas son características generales y pueden presentar una superposición considerable.

Estas categorías son heurísticas de los analistas de Huntress para distinguir entre los tres, no un estándar de la industria. Un matiz complicado aquí es que no se trata de una determinación blanco o negro: ninguna fila por sí sola resuelve por completo qué hay principalmente detrás del ataque. Por ejemplo, un script puede llevar un temporizador de pausa y una lista de agentes de usuario, lo que podría hacer que su comportamiento en los registros parezca más humano de lo que realmente es. Un único ataque de rociado de contraseñas contra un solo inquilino puede a primera vista parecer obra de una persona, pero un ritmo fijo en el tiempo y una lista rotativa de agentes de usuario indicarían lo contrario. Al investigar estas señales, parte de lo que importa es la combinación y si el comportamiento cambia en respuesta a lo que acaba de ocurrir. Un script se repite; una persona o un agente se ajusta.

Dos límites se aplican a todo nuestro análisis a continuación: 

• Una persona que pega comandos de un chatbot en una terminal se ve como una persona en estos registros, porque el modelo nunca toca la API. 

• Los registros muestran quién ejecutó las herramientas, no quién las escribió; un modelo puede escribir un script fijo que se vea como cualquier otro script.

Lo que vimos 

Los bucles: scripts a gran escala

Los registros nos mostraron que el 15 de octubre, entre aproximadamente las 06:13 y las 08:46 UTC, la credencial se usó contra casi 1.000 inquilinos, uno tras otro, en orden ascendente de ID de inquilino. Eso es un bucle sobre una lista ordenada: una solicitud de token de autenticación por inquilino, con una separación de uno a seis minutos, con el mismo agente de usuario (Python-urllib/3.12) cada vez. Cuando el bucle se detuvo a mitad de la lista, parecía una lista agotada o un proceso interrumpido (y no una decisión deliberada de detenerse). 

Los registros también mostraron que nueve minutos antes, alrededor de las 06:04 UTC, cerca de 100 solicitudes de token de autenticación fallidas habían llegado en un lapso de 10 segundos contra los primeros 100 inquilinos de esa misma lista de 1.000 inquilinos. Cada solicitud falló de la misma manera, y nada cambió entre los intentos. Esta es la firma de un grupo de hilos (thread pool): un conjunto fijo de hilos de trabajo que toman inquilinos de una lista compartida y disparan solicitudes en paralelo, cada uno ciego a lo que reciben los demás. Nada en el bucle lee una respuesta antes de que salga la siguiente solicitud.

Luego, la misma herramienta de grupo de hilos se ejecutó una segunda vez contra 100 inquilinos, usando la clave de una aplicación diferente, a entre 13 y 21 intentos por segundo, y falló de la misma manera. Ambas ejecuciones usaron secretos de aplicación que pertenecen a un solo inquilino, el cual no puede autenticarse en ningún otro lugar, y la herramienta siguió disparando de todos modos. Quien la haya construido, o al menos la haya lanzado, no tomó en cuenta esa diferencia.

Esto es lo que eso nos dice y lo que no nos dice: 10 solicitudes por segundo es más rápido que cualquier cosa que lea cada respuesta antes de decidir su siguiente paso, ya sea una persona o un modelo trabajando paso a paso. Así que lo más probable es que esto fuera un solo script, ejecutado al menos dos veces. Esto no nos dice quién o qué escribió el script. Un modelo puede escribir un grupo de hilos con la misma facilidad que una persona, así que si bien esto descarta que un modelo hiciera cada llamada, no descarta que un modelo haya escrito la herramienta.

Prueba y error

El 15 de octubre, entre las 03:42 y las 03:57 UTC, los registros mostraron un patrón de prueba y error en la actividad no autorizada, con la herramienta cambiando en menos de un minuto entre ejecuciones. La actividad descrita en los registros parecía un intento de establecer acceso persistente agregando credenciales: 

1. Se agregó un secreto, se eliminó y se volvió a agregar. 

2. Se subió un certificado, pero falló porque la huella digital no coincidía. 

3. El operador volvió a recurrir a un secreto antes de otorgar, y luego quitar, el rol de Global Administrator dos veces. 

La misma secuencia se ejecutó en un segundo inquilino 47 segundos después, con ambas claves agregadas en una sola ejecución. 

Durante esa ventana, la herramienta cambió en respuesta a los resultados al menos tres veces. La ejecución posterior a la carga fallida del certificado agregó un bucle de reintento, la secuencia se repitió en un segundo inquilino con ambas claves en una sola ejecución, y cuando ese inquilino rechazó la eliminación del rol de Global Administrator, el actor otorgó un rol diferente a un principal hermano, y luego se eliminó el principal de servicio original.

Según esta actividad, es posible que la plantación de credenciales y la sondeo dirigido hayan sido guiados por un operador que se adaptaba entre ejecuciones. Sin embargo, no podemos determinar si ese operador era una persona, una automatización o un modelo de LLM.

Los objetivos elegidos a mano: piloto y luego lote 

Entre aproximadamente las 09:25 y las 12:35 UTC del 15 de octubre, un barrido tocó 17 inquilinos, con una solicitud de token de autenticación de Graph cada uno, en una secuencia ordenada a mano con espaciado irregular a lo largo de tres horas. Un segundo barrido a las 13:54 UTC ejecutó una sondeo fijo de seis recursos por inquilino, en orden clasificado, con cuatro segundos por inquilino. Parece que alguien eligió los objetivos, los revisó de uno en uno, y luego entregó la lista a un script. 

Dónde empezó a parecer un agente

Ninguna observación aislada aquí demuestra nada, y no vamos a pretender lo contrario. Pero varias de ellas apuntaban en la misma dirección, y cuanto más lo analizamos, más difícil fue explicarlas como una persona frente a un teclado o un script dejado corriendo solo.

Primero, está la brecha de 55 segundos entre reintentos que describimos antes. La carga del certificado que falló por una huella digital que no coincidía a las 03:48:24 UTC terminó esa ejecución sin reintento. La siguiente ejecución, 55 segundos después, sí reintentó el mismo error, a los 3,5 segundos y luego a los 7,1 segundos, hasta que funcionó, y llevó ese mismo reintento al segundo inquilino. 

Figura 2: Cómo cambió la herramienta

Entonces, ¿qué nos dice esto en realidad sobre lo que ocurría detrás de escena? O alguien editó el código en menos de un minuto, o una herramienta preparada tenía una opción de reintento que nadie había usado todavía. Un script abandonado no se reescribe solo entre ejecuciones. Es probable que una persona, una persona que transmite instrucciones a un modelo, o un agente, lo haya adaptado como operador. La velocidad del cambio es consistente con un bucle de agente: leer el fallo, reescribir la llamada, volver a ejecutarla.

La lógica de reintento es particularmente reveladora. Duplicar la espera entre intentos es manejo de errores defensivo de manual. Esto es algo que el código generado tiende a agregar sin que se le pida, y en este incidente apareció en una herramienta que no lo tenía apenas un minuto antes. La herramienta también era más elaborada de lo que requería el trabajo: la ráfaga de 100 inquilinos usó un grupo de subprocesos, cuando un simple bucle sobre la lista habría logrado el mismo resultado.

Otro patrón notable que describimos arriba: un operador probó una acción contra un inquilino primero, y luego la ejecutó en lote, una y otra vez. Vimos esto tres veces en dos conjuntos de herramientas. Eso apunta a los hábitos de un operador, no a una peculiaridad de un solo script. Microsoft describe que ARTEX construye un grafo de los activos que descubre y ejecuta rutas de vulneración en paralelo, lo cual tiene la misma forma: sondear, aprender y luego expandirse.

Finalmente, está la velocidad. Nuestra primera actividad de enumeración comenzó alrededor de las 01:05 UTC, y los cambios de credenciales en el primer inquilino se completaron para las 03:50 UTC, en línea con el informe de Microsoft de menos de tres horas desde la selección del objetivo hasta el acceso privilegiado en múltiples entornos. La velocidad por sí sola no distingue a un agente de un script bien preparado, pero es el tipo de compresión que Microsoft describe que logran los marcos de agentes. Algunas de las cadenas de user agent también parecen fijadas a mano en lugar de ser valores predeterminados de biblioteca. Una herramienta se identificó como python-requests/2.31, cuando la biblioteca envía python-requests/2.31.0 por defecto, y el 13 de octubre a una cadena de navegador le faltaba su segmento estándar "(KHTML, like Gecko)". Ambos casos concuerdan con un modelo que produce user agents de memoria, y ambos concuerdan con una persona que los copia de la documentación.

En conjunto, estos factores conforman nuestra hipótesis de trabajo: una herramienta con script hace el trabajo pesado en este incidente, con algo que la adapta entre ejecuciones, rápidamente. Ese algo bien podría ser un agente. La siguiente sección trata sobre qué tan seguros estamos, y dónde se acaba la evidencia.

Lo que la telemetría puede confirmar

Una hipótesis de trabajo solo vale la pena compartirla si sus límites son claros. Estos son los nuestros.

La mejor evidencia en contra de un agente totalmente autónomo es lo que ocurrió después de las 03:57 UTC. Se eliminó el principal de servicio de Teams, y durante los siguientes 22 minutos las solicitudes que lo usaban siguieron disparándose cada cuatro a ocho segundos. Se rechazaron todas las veces, y las solicitudes posteriores no cambiaron. Se esperaría que un agente que observa su propia salida se detuviera. Un marco multiagente podría mantener tareas de expansión desatendidas en ejecución mientras otros agentes continúan, lo cual podría explicar este comportamiento. Lo mismo podría explicarlo una persona que lanzó algunos bucles en segundo plano y se alejó. Sin embargo, no sabemos cuál de las dos ocurrió en esta situación.

Otra consideración: curl/7.88.1 es la versión con la que viene Debian 12, y la imagen oficial del contenedor python:3.12 está construida sobre Debian 12. Eso apunta a cómo posiblemente se empaquetó la herramienta, ya que el user agent no concuerda con las huellas externas del sistema.

El mayor vacío son los registros faltantes de solicitudes de Graph. Estos mostrarían la variedad de consultas, la diferencia más clara entre un script y un agente, y no sabemos de nadie que los haya recopilado.

Entonces, ¿qué tan seguros estamos? Tenemos alta confianza en que un operador, ya sea una persona o un modelo LLM, adaptó la herramienta entre ejecuciones. Solo con nuestra propia telemetría, ubicamos nuestra confianza en que un LLM estuvo involucrado en la herramienta de escalamiento en un nivel de bajo a medio. Tomando en cuenta la atribución de Microsoft, la ubicamos en un nivel de medio a alto. 

Lo que podría ayudar a resolverlo es evidencia que no tenemos: los registros de actividad de Graph de una víctima que los tenía habilitados, la herramienta en sí, o el tráfico de los sistemas del actor hacia la API de un proveedor de modelos.

Lo que dice Microsoft: Storm-0940 y ARTEX

En su informe del 21 de octubre, Microsoft atribuye el abuso de credenciales de ConnectWise a Storm-0940, un actor de amenazas que, según dicen, ha estado activo desde 2021. Microsoft afirma que el actor apunta a organizaciones de distintas industrias para robar datos, y que históricamente ha entrado mediante ataques de pulverización de contraseñas y aplicaciones expuestas a internet, y luego ha mantenido el acceso agregando credenciales a aplicaciones OAuth existentes de la cuenta.

Lo nuevo, según Microsoft, es la herramienta. Informan que, desde al menos septiembre de 2026, el actor usó ARTEX, un framework de código abierto en el que agentes impulsados por LLM ejecutan una prueba de penetración desde el reconocimiento hasta la exfiltración de datos con muy poca interacción humana, construyendo un grafo de los activos y debilidades que descubren en el camino. ARTEX puede usar cualquier modelo de IA, y Microsoft dice haber visto a otros actores usándolo en varias regiones.

¿Cómo conecta Microsoft eso con este incidente? El razonamiento que han compartido apunta a la infraestructura: atribuyen un gran ataque de pulverización de contraseñas desde 144.172.64[.]99 entre el 10 y el 14 de octubre a Storm-0940, y señalan que la misma IP, y el rango circundante, aparecen en el aviso de ConnectWise. El informe no describe cómo Microsoft identificó ARTEX, ni qué vincula el ataque anterior con Storm-0940. No hemos verificado ninguno de los dos de forma independiente.  Sin embargo, es posible que Microsoft sepa cómo identificar esta herramienta en particular, razón por la cual mencionaron su uso en esta campaña.

Cómo coinciden nuestros hallazgos con el informe de Microsoft

Nuestra telemetría coincide con el relato de Microsoft en varios aspectos.

• Vimos la misma infraestructura (144.172.64[.]128) y los mismos agentes de usuario (Python-urllib/3.12, curl/7.88.1), y la misma secuencia: credenciales de aplicación comprometidas, seguidas de actividad en Graph con adición de credenciales y cambios de roles con privilegios, incluyendo la aplicación de Teams asignándose a sí misma el rol de Administrador global.

• Nuestra telemetría también corrobora el ataque de pulverización de contraseñas que Microsoft atribuye a 144.172.64[.]99. 

• La escala es donde diferimos, por diseño. Microsoft cuenta más de 2.250 inquilinos, y nosotros solo vemos los inquilinos que protegemos, así que nuestras cifras son solo un subconjunto, no una contradicción. Vimos python-requests/2.34.2 desde 144.172.64[.]99 en el ataque de pulverización de contraseñas del 10 al 14 de octubre, pero no azure-toolkit/1.0, y no vimos cambios de identidad ni de grupos en los dos inquilinos donde tenemos registros de auditoría de directorio.

Por qué esto importa

Quienquiera, o lo que fuera, que estuviera detrás, esta operación no fue pulida. A lo largo de nuestra investigación vimos: 

• Secretos agregados, eliminados y agregados otra vez. 

• Un certificado que no se pudo subir. 

• Secretos de un inquilino rociados contra otros cien, donde nunca funcionarían. 

Sin embargo, como vimos en los dos inquilinos donde tenemos registros de auditoría, pasaron menos de tres horas desde la primera actividad de enumeración hasta los cambios de roles con privilegios, en línea con lo que Microsoft reporta en múltiples entornos, porque la credencial de aplicación robada hizo gran parte del trabajo.

Es torpe, pero funcionó. Si había un agente involucrado aquí, era uno temprano. Ya ejecutaba cosas en paralelo, nunca necesitaba un descanso, y dejó a los defensores unas cuantas horas. Herramientas como esta mejoran rápido: dejan de cometer los errores que vimos, y son baratas de apuntar contra cientos de inquilinos a la vez. Microsoft hace el mismo señalamiento: los agentes pueden trabajar las 24 horas e intentar múltiples rutas de brecha simultáneamente.

La visibilidad de los defensores también está en constante cambio. A nuestro juicio, las señales en las que nos basamos aquí (un reintento que apareció 55 segundos después de una falla, un ritmo fijo entre solicitudes, y cadenas de user agent personalizadas fuera del valor predeterminado de la librería) son lo primero que una mejor herramienta eliminará. El ritmo no será una señal confiable por mucho tiempo. Lo que sí se sostendrá es lo que hace la actividad, que es hacia donde apuntan las detecciones a continuación.

Qué pueden hacer los defensores

La velocidad es la mayor preocupación aquí. Esta actividad se mueve más rápido de lo que una persona puede triar. Esta es una guía de detección útil sin importar el actor:

• Alerta cuando un service principal se asigna a sí mismo el rol de Global Administrator o Privileged Role Administrator, se elimina a sí mismo, o cuando el principal de un proveedor otorga un rol a un principal hermano.

• Alerta sobre adiciones de credenciales a aplicaciones de alto privilegio desde fuentes inesperadas.

• Establece una línea base del user agent normal de cada aplicación de proveedor (kiota-dotnet para las aplicaciones de ConnectWise), los rangos de origen y el ritmo. La señal temprana más clara aquí fue una aplicación de proveedor comportándose de forma distinta a su línea base.

• Activa los registros de actividad de Microsoft Graph donde la licencia lo permita, y conserva las cadenas de user agent sin procesar y las marcas de tiempo en fracciones de segundo. El ritmo y el tiempo de reintento fueron nuestras señales más útiles, y la normalización destruye ambas.

• Vigila a través de los inquilinos, no solo dentro de uno. Un goteo en un solo inquilino puede ser parte de una campaña que corre a miles de intentos por minuto en todo el conjunto.

Actualizaremos esta publicación conforme ConnectWise, Microsoft y otros compartan más información.

Indicadores de compromiso (IOCs)

• Informe inicial de respuesta rápida de Huntress (16 de oct.): https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access

• Análisis de Microsoft (21 de oct.): https://www.microsoft.com/en-us/security/blog/2026/10/21/storm-0940-uses-artex-agentic-ai-connectwise-supply-chain-compromise