Microsoft: agentes de IA detrás del hackeo a ConnectWise

Microsoft señala a Storm-0940: el ataque a ConnectWise se ejecutó con agentes de IA

2.900 intentos de inicio de sesión por minuto. Esa es la cifra que Microsoft publicó el 21 de octubre al atribuir el ataque a la cadena de suministro de ConnectWise a Storm-0940, un grupo alineado con el Estado chino que lleva activo desde 2021. Para un founder, el dato que importa no es el nombre del grupo: es que la operación la ejecutaron agentes de IA que no se cansan, no duermen y prueban varias rutas de intrusión al mismo tiempo.

Según el blog de seguridad de Microsoft, Storm-0940 usó ARTEX, un framework de pentesting autónomo de código abierto, para automatizar ataques contra cientos de organizaciones en todo el mundo desde septiembre de 2026. En varios casos, el tiempo entre seleccionar un objetivo y obtener acceso privilegiado fue menos de tres horas.

ARTEX: qué es el framework que automatizó el ataque

ARTEX es un sistema multiagente basado en modelos de lenguaje, escrito en Go con frontend en Next.js, que puede conectarse a cualquier modelo de IA. Su función declarada es correr un pentest autónomo desde el reconocimiento hasta la exfiltración de datos con poca interacción humana, según la descripción de Microsoft. La interfaz viene en inglés por defecto, pero se puede cambiar a coreano, mandarín, español o japonés.

El detalle incómodo es que la herramienta es legítima: sirve para que un equipo de seguridad pruebe sus propios sistemas. En manos de un atacante, convierte lo que antes exigía horas de trabajo manual en un proceso que corre solo.

Microsoft aclara que identificó actores de amenaza de varias regiones usando ARTEX, no solo a Storm-0940. El framework ya había aparecido antes: The Record reportó que se lo vinculó a ataques contra instituciones financieras de Corea del Sur y Japón. El desarrollador, el ingeniero chino Li Puhua (usuario Autumn-27 en GitHub), publicó el 8 de octubre un comunicado en el que reconoce el mal uso y anuncia que ARTEX dejará de actualizarse y pasará a código cerrado.

Los números que deberían preocupar a cualquier CTO

La secuencia que reconstruyó Microsoft es lo más útil del reporte, porque muestra cómo se ve un ataque automatizado en los logs:

• Entre el 10 y el 14 de octubre, la infraestructura de Storm-0940 lanzó un password spraying automatizado contra 327 cuentas de ocho organizaciones, con más de 151.000 intentos fallidos de inicio de sesión.
• El pico fue el 11 de octubre: 2.900 fallos por minuto y más de 111.000 en un solo día. Cuarenta y ocho cuentas recibieron más de 1.000 intentos fallidos cada una.
• El 15 de octubre aparecieron los primeros reportes públicos del compromiso de ConnectWise, con indicadores que coincidían con el mismo rango de IP del ataque anterior.
• Ya dentro de la cadena de suministro, los agentes intentaron autenticarse en más de 2.250 tenants de Microsoft 365 usando credenciales robadas de aplicaciones de ConnectWise.

La firma de seguridad Huntress, que monitorea sistemas de clientes, había confirmado brechas en 162 tenants al 16 de octubre y después identificó cerca de 1.000 tenants con intentos de inicio de sesión, de los cuales más de 300 mostraron intentos exitosos, según The Next Web. ConnectWise deshabilitó siete identidades de aplicación el 17 de octubre, sacó Cloud Backup de línea y empezó a restaurar el servicio por etapas el 21 de octubre, con un proceso que la compañía espera que tome varios días.

Microsoft fue explícito en un punto: el incidente no se originó en una vulnerabilidad de sus propios sistemas.

Por qué el vector es la cadena de suministro y no tu firewall

ConnectWise Cloud Backup, antes conocido como SkyKick, respalda datos de Microsoft 365 de los clientes de proveedores de servicios de TI. Para hacerlo, se apoya en aplicaciones con permisos amplios sobre las cuentas de esos clientes. Ahí está el punto débil: si comprometes la identidad de la aplicación, heredas la confianza que esa aplicación ya tenía dentro de cada tenant.

Microsoft observó que los agentes no se detuvieron en la autenticación. En varios entornos avanzaron hacia Microsoft Graph y operaciones de directorio: reconocimiento, modificación de credenciales de aplicación para establecer persistencia y cambios en identidades, grupos y roles privilegiados. Es decir, dejaron puertas que pueden seguir abiertas incluso después de cerrar la aplicación comprometida.

Ese es el cambio de fondo. Un atacante humano necesita tiempo, y el tiempo genera ruido y alertas. Un agente que corre a velocidad de máquina genera muchísimo más ruido, pero en una ventana tan corta que el equipo de seguridad no alcanza a reaccionar de forma coordinada.

¿Qué significa esto para tu startup?

Si tu startup usa Microsoft 365 o Google Workspace, o si vendes un SaaS que se integra con ellos vía OAuth, esta noticia te toca directamente. Estas son las acciones concretas que recomienda Microsoft y que puedes ejecutar esta semana:

• Inventaria todas las aplicaciones de terceros con permisos elevados en tu tenant, incluso las que ya no usas. Busca por ID de aplicación, no por nombre visible: las integraciones viejas y olvidadas son las que nadie revisa.
• Revisa los inicios de sesión de service principals desde al menos el 15 de octubre y, si tienes los registros, extiéndelo al 1 de octubre. Míralos por separado de los inicios de sesión de usuarios: son los que suelen pasar desapercibidos.
• No borres las aplicaciones empresariales como primera reacción. Preserva la configuración y la evidencia antes de hacer cambios irreversibles; si borras, pierdes la capacidad de investigar qué pasó.
• Aplica mínimo privilegio a los permisos multi-tenant y monitorea la creación de credenciales nuevas, las asignaciones de roles y la actividad anómala de aplicaciones.
• Mantén deshabilitadas las conexiones de ConnectWise hasta que la compañía publique instrucciones formales de restauración, y rota credenciales después de cualquier remediación.

Para los que venden software B2B hay una lección de producto: si tu app pide permisos amplios sobre los datos de tus clientes, tu superficie de riesgo es la de ellos. Vale la pena preguntarse si realmente necesitas ese scope o si puedes pedir menos.

El debate que viene: ¿quién responde cuando ataca un agente?

El caso de ARTEX abre una discusión que el ecosistema todavía no resolvió. CrowdStrike vinculó los ataques a instituciones financieras surcoreanas a un individuo con motivación económica en China, que según su análisis combinó ARTEX con Claude Code de Anthropic, de acuerdo con el reporte recogido por Crypto Briefing. Anthropic no se había pronunciado públicamente al momento de ese reporte.

Del lado de Microsoft, Igor Tsyganskiy, vicepresidente ejecutivo de la compañía, escribió en LinkedIn que desde principios de octubre hay en curso una ola de ciberataques impulsados por IA y que el de ConnectWise es solo uno de muchos. La compañía lanzó además un panel de seguridad para IA que busca dar visibilidad sobre qué agentes y aplicaciones de IA operan dentro de una organización.

La pregunta de fondo es incómoda para cualquiera que construya con modelos: si un agente autónomo ejecuta una acción dañina, ¿la responsabilidad es de quien lo construyó, de quien lo desplegó o de quien no lo contuvo? El desarrollador de ARTEX ya eligió su respuesta al cerrar el código.

Conclusión

El ataque a ConnectWise no es una historia sobre un grupo chino ni sobre una herramienta puntual. Es un caso de cadena de suministro a escala documentado con agentes de IA haciendo el trabajo pesado, y eso cambia el cálculo de riesgo para cualquier empresa conectada a la nube.

La buena noticia es que las defensas que funcionan siguen siendo las mismas de siempre: inventario de accesos, mínimo privilegio, revisión de logs y rotación de credenciales. La mala es que ahora hay que ejecutarlas más rápido, porque el otro lado ya no trabaja en horario de oficina.

Fuentes

• The Record (fuente original)
• Microsoft Security Blog
• CyberScoop
• The Next Web
• Crypto Briefing