Storm-0940 y ARTEX: la IA que convirtió una brecha en ConnectWise en 2.250 empresas

El titular es escueto y esconde lo importante: atacantes chinos comprometer a miles de empresas después de entrar en ConnectWise, el gigante de la gestión de TI. Microsoft atribuye la operación a Storm-0940, un actor alineado con el Estado chino activo desde 2021, y sostiene que usó ARTEX, un framework abierto de pruebas de intrusión con IA agéntica, para automatizar la fase final del ataque contra más de 2.250 tenants a 2.900 intentos de inicio de sesión por minuto. No hay ninguna técnica nueva en el guion.

Lo que cambia no es el procedimiento, sino el rendimiento. El abuso de aplicaciones OAuth, el password spraying y el movimiento lateral a través de Microsoft Graph son técnicas de manual, documentadas desde hace años y con herramientas de sobra conocidas. ARTEX no inventa una vía de entrada: convierte a un operador humano, que se cansa, duda y acaba durmiendo, en un proceso que no se cansa, no duda y no duerme.

La consecuencia ya está medida. En varios entornos, el tiempo que pasó desde que Storm-0940 identificó una organización objetivo hasta obtener acceso privilegiado en su infraestructura cloud fue de menos de tres horas. Tres horas es lo que se tarda en abrir un ticket, escalarlo a otra persona y conseguir las claves del gestor de secretos. La IA no simplificaba la reacción: la acortaba hasta anularla.

Qué es ARTEX y por qué cambia la ecuación

ARTEX es un framework de penetration testing de código abierto que puede usar cualquier modelo de IA. Por debajo es un sistema multiagente escrito en Go, con una interfaz en Next.js. Por encima, un conjunto de agentes de LLM que ejecutan una prueba de intrusión autónoma de principio a fin, desde el reconocimiento hasta la exfiltración de datos, con muy poca intervención humana.

Los agentes no trabajan a ciegas. Durante la prueba van acumulando en un grafo los activos descubiertos y las vulnerabilidades encontradas, de manera que cada agente posterior parte de lo que ya saben los anteriores. Esa es la diferencia relevante frente a un simple script: la exploración deja de ser una recorrida lineal, que es justo lo que hace que una operación se atasque en las mismas técnicas que el operador ya conoce, y pasa a ser una búsqueda capaz de ramificarse hacia direcciones no previstas.

La interfaz y la salida por defecto están en inglés, pero el framework puede cambiarse a coreano, mandarín, español o japonés. El detalle parece menor y no lo es: dice bastante sobre para quién se construyó la herramienta y sobre lo fácil que resulta desplegarla en operaciones con objetivos en cualquier zona horaria. Un ataque que no depende del huso horario del analista no descansa.

La cadena de seis días

La secuencia reconstruida por Microsoft merece leerse con calma, porque muestra cómo un ataque fracasado convive con otro exitoso dentro de la misma campaña. Son dos historias distintas ejecutadas en paralelo por el mismo actor.

Entre el 10 y el 14 de octubre, la infraestructura del atacante en 144.172.64[.]99 lanzó una campaña automatizada de password spraying entre tenants contra 327 cuentas de ocho organizaciones, con el objetivo de acceder a Microsoft 365 y Exchange Online. La telemetría de Microsoft capturó más de 151.000 eventos de inicio de sesión fallido, con un pico de 2.900 fallos por minuto el día 11 y más de 111.000 fallos concentrados en una sola jornada. Cuarenta y ocho cuentas recibieron más de mil fallos cada una.

Y aquí aparece la ironía que conviene retener: el 98 % de la actividad terminó en respuestas de bloqueo de cuenta por exceso de intentos, y el resultado neto de toda la campaña fue un cero absoluto. No se observó ni un solo inicio de sesión exitoso, ni emisión de tokens, ni llamada a Graph, ni cambio de directorio. Los atacantes dispararon contra todas las puertas y no entraron por ninguna. Esta fase no solo falló: falló haciendo muchísimo ruido.

El 15 de octubre empezaron a aparecer informes públicos sobre el compromiso de ConnectWise, con indicadores que coincidían exactamente con el rango 144.172.64.x del spraying anterior. El 16 de octubre, ConnectWise publicó su comunicado inicial. El actor había conseguido controlar las identidades de varias aplicaciones cloud del proveedor y había dejado de necesitar credenciales ajenas: a partir de ese momento la operación cambió de naturaleza.

La confianza heredada: por qué 2.250 empresas quedaron expuestas sin que nadie las atacara

La parte que más se parece a un problema de arquitectura y menos a una noticia de seguridad es la del mecanismo. ConnectWise no vende un antivirus: vende Cloud Backup, un servicio que se conecta al tenant del cliente para respaldar sus datos. Esa conexión exige credenciales de aplicación, unas credenciales que el cliente autorizó en su tenant porque el proveedor necesitaba operar dentro de su Microsoft 365.

Si robas esas credenciales no estás atacando a 2.250 clientes: estás usando 2.250 autorizaciones que ellos ya te habían concedido. El atacante se autentica en el entorno del cliente igual que lo haría la aplicación legítima, sin necesidad de un inicio de sesión interactivo y sin generar las alertas típicas de un acceso con contraseña. En la telemetría, el tráfico se parece al de siempre del proveedor. Nadie ha irrumpido en esas empresas: sus propios entornos de confianza se han usado como amplificador.

Este es el tipo de compromiso de cadena de suministro que no se arregla instalando parches. El elemento vulnerable no está en tu empresa, está en la relación entre tu empresa y tu proveedor, y esa relación estaba mediada por un permiso que concediste sin pensar en su fecha de caducidad.

Tres horas entre el objetivo y el acceso privilegiado

Microsoft insiste en un punto que suele recibir menos atención de la que merece: la velocidad no solo hace el ataque más eficiente, lo vuelve casi inabordable en la práctica. Una actividad automatizada hasta ese punto genera muchísimo tráfico y muchísimos registros de auditoría, así que las alertas sí saltan. El problema es otro: el tiempo que hay entre la alerta y la respuesta.

A 2.900 intentos por minuto, un equipo que detecta en una hora ya ha perdido el incidente. Y hay un detalle casi irónico en la fase que fracasó: a ese volumen, el propio bloqueo de cuentas por exceso de intentos actúa como un mitigador casi natural, porque el sistema de autenticación frena al atacante por su cuenta. En la fase que sí funcionó, en cambio, no hubo ruido que ocultar porque no hubo miles de intentos: hubo una aplicación legítima moviéndose con permisos legítimos.

La lección es incómoda para el tooling actual. Buena parte de la detección se sigue diseñando en torno a encontrar un ataque dentro de un umbral que un humano pueda consumir. Cuando la unidad de medida del atacante pasa a ser el minuto, defenderse deja de ser un problema de mejorar una regla y pasa a ser un problema de latencia. No basta con ver la alerta: hay que poder actuar sobre ella en minutos, y en muchos casos de forma automática.

La puerta de atrás que sobrevive a la contención

Hay un matiz en la lectura de Microsoft que es el más incómodo a medio plazo. Los agentes del actor no se quedaron en el inicio de sesión. En varios entornos pasaron de la autenticación a operaciones de directorio mediante Microsoft Graph: reconocimiento, cambios en credenciales de aplicaciones y modificaciones de identidades, grupos y roles privilegiados.

Ese último punto es el verdadero problema. Si el atacante modifica las credenciales de una aplicación dentro de tu tenant, esas credenciales modificadas se convierten en un mecanismo de persistencia. Y aunque después revokes la aplicación comprometida y devuelvas el proveedor a su estado original, esos cambios siguen ahí, porque no pertenecían al componente que acabas de revocar. La credencial nueva puede continuar viva bajo la misma aplicación, esperando a que alguien la vuelva a usar. Es una puerta de atrás que sobrevive a la respuesta.

Microsoft pide además respetar un matiz que los titulares no reflejan: la presencia de una aplicación afectada, o incluso de un inicio de sesión exitoso, no significa automáticamente que los datos se hayan leído o exfiltrado. La actividad se ha detectado en varios entornos, pero no hay confirmación de acceso a datos en todos los casos. Un titular que afirma que se filtraron los datos de 2.250 empresas va mucho más allá de lo que sostiene la investigación.

Qué hacer si tu proveedor está en la lista

Microsoft ha publicado una guía de contención bastante concreta. Su idea central es que la primera respuesta no debe ser borrar, sino preservar. Eliminar una aplicación empresarial sin más destruye justamente la configuración y las pruebas que necesitas para entender qué se hizo con ella.

• Mantén desactivadas las conexiones de las aplicaciones afectadas de ConnectWise hasta que el proveedor dé instrucciones formales de restauración.
• No borres las aplicaciones empresariales como primera medida. Conserva configuración y evidencia antes de hacer cambios irreversibles.
• Localiza las aplicaciones por su identificador, no por su nombre visible, y revisa todos los tenants donde estuvo instalada o autorizada alguna vez, aunque la integración ya no se use.
• Conserva los registros de inicio de sesión y auditoría de Microsoft Entra, los de Microsoft Purview y los del SIEM antes de que roten. No aplaces la contención urgente a la espera de una exportación.
• Revisa la actividad desde al menos el 15 de octubre y, si hay registros, amplía el análisis al 1 de octubre. Separa los inicios de sesión correctos de los fallidos e investiga las fuentes desconocidas en lugar de quedarte con las IP publicadas.
• En la auditoría de Entra, busca altas de credenciales de aplicaciones, aplicaciones o service principals nuevos, asignaciones de roles de aplicación y consentimientos, sobre todo asignaciones de roles privilegiados.
• En la auditoría de Microsoft 365, revisa accesos inusuales a correo y ficheros, descargas, reenvíos, reglas de buzón o de transporte y permisos de buzón delegados.
• Al final, verifica que la rotación de credenciales del proveedor y la remediación en el tenant hayan eliminado de verdad cualquier acceso no autorizado.

Lo que el caso deja sobre la mesa

La primera conclusión incomoda a quienes llevan años construyendo el mismo tipo de defensa. ARTEX no es un exploit ni una forma de saltarse una protección: es un orquestador. Toma técnicas que ya existían, muchas de ellas documentadas por los propios fabricantes, y las ejecuta con una velocidad y una consistencia que ningún equipo humano puede sostener. No hay una vulnerabilidad nueva que parchear. Hay un cambio en el coste de la transición hacia la victimización, y ese coste es el que hay que recalcular.

La segunda es que esto no es una novedad. El mismo framework se identificó este año atacando al sector financiero de Corea del Sur, incluyendo entidades con controles débiles y sin autenticación multifactor, y Microsoft ha detectado actores en varias regiones geográficas distintas utilizándolo. Lo ocurrido con ConnectWise fue probablemente la campaña más visible hasta ahora, no la primera.

La tercera toca la defensa. Durante meses el discurso dominante en seguridad con IA era el de los modelos que encuentran vulnerabilidades: ya conocemos los proyectos que localizan cientos de miles de fallos en código abierto o que auditan infraestructura a escala. Todo eso es cierto y es valioso. Este caso es el reverso exacto de esa moneda: la misma capacidad de automatizar y recorrer, aplicada al otro bando, con un detalle que conviene no minimizar, que no hace falta ningún modelo propietario. Basta con un framework abierto y unas credenciales robadas.

La hipótesis de confianza

Queda una idea más general, que va más allá de este incidente concreto. Cada permiso que concedemos a un tercero tiene un radio de alcance que casi nunca hemos dimensionado. Puede que estemos pensando en cuánto nos cuesta el servicio y, en realidad, lo que hemos autorizado es hasta dónde puede llegar ese proveedor si alguien le roba la llave. La brecha de ConnectWise no se resolvió reforzando la contraseña de ConnectWise: se resolvió, en parte, porque alguien estaba mirando y publicó la telemetría que permitió reconstruir lo ocurrido.