Microsoft atribuye a Storm-0940 el ataque con IA a ConnectWise

Microsoft atribuye a Storm-0940, un grupo alineado con el Estado chino, el ataque a la cadena de suministro de ConnectWise Cloud Backup que desde el 15 de octubre abre tenants de Microsoft 365 con las credenciales de las aplicaciones del fabricante. Según el informe publicado el 21 de octubre de 2026, el grupo utilizó ARTEX, un framework de pentesting con agentes de IA, para intentar iniciar sesión en más de 2.250 tenants a un ritmo de 2.900 intentos por minuto.

Microsoft señala a Storm-0940 como autor del ataque a ConnectWise

Esta noticia continúa las dos que publicamos sobre la credencial robada de ConnectWise Cloud Backup y sobre la desactivación de las siete identidades de aplicación. Hasta ahora nadie había puesto nombre al atacante. Huntress, ConnectWise y la propia Microsoft hablaban de un actor desconocido con infraestructura en RouterHosting. El 21 de octubre, Microsoft Threat Intelligence y Microsoft Security Research publicaron el informe que cierra esa incógnita. El responsable es Storm-0940, un grupo que Microsoft sigue desde 2021, sin alias conocidos en el sector, y que ya describió el 31 de octubre de 2024 por sus campañas de password spraying desde routers domésticos comprometidos.

La atribución llega con un dato que cambia la escala del incidente. Microsoft afirma que Storm-0940 «used the agentic AI penetration testing framework ARTEX to automate attacks» (usó el framework de pentesting con IA agéntica ARTEX para automatizar ataques) desde septiembre de 2026 contra cientos de organizaciones de sectores como aeroespacial y defensa, automoción, química, energía, servicios financieros, administraciones públicas, despachos de abogados, fabricación, medios, ejército, semiconductores, software y think tanks. En varios de esos ataques el grupo obtuvo acceso privilegiado a la nube de la víctima, y en más de un caso tardó menos de tres horas desde que eligió el objetivo. Microsoft Threat Intelligence lo anunció también en X el mismo día.

En paralelo, Igor Tsyganskiy, vicepresidente ejecutivo de Microsoft según recoge CyberScoop, escribió en LinkedIn que «Since early October, a wave of AI-driven cyberattacks has been ongoing» (desde principios de octubre hay en marcha una oleada de ciberataques impulsados por IA) y que el de ConnectWise es uno de muchos. ConnectWise no ha respondido públicamente a la atribución, según el mismo medio. El fabricante sí anunció el 21 de octubre a las 14:35 UTC en su página de estado que «We have begun restoring services in controlled phases» (hemos empezado a restaurar los servicios por fases controladas), con la advertencia de que el inicio de la restauración no significa que todas las funciones estén disponibles. Desde el 22 de octubre publica dos actualizaciones diarias.

La infografía con la que Microsoft abre su informe resume las cifras de la campaña: más de 2.250 tenants alcanzados con inicios de sesión de solo aplicación, 327 cuentas de ocho organizaciones sometidas a password spraying, más de 151.000 inicios de sesión fallidos, 2.900 intentos por minuto y más de 200 inicios de sesión en menos de cuatro minutos con cuatro credenciales de aplicación. Esa última cifra no cuadra del todo con el resto del documento, que solo enumera tres identificadores de aplicación, y Microsoft no aclara cuál es la cuarta.

El diagrama ordena las fechas que dan Microsoft, CrowdStrike, Zscaler y ConnectWise hasta la atribución, y representa la secuencia del incidente y no el funcionamiento interno de ARTEX, que ninguna de las fuentes ha publicado con detalle.

• Septiembre de 2026: Storm-0940 empieza a usar ARTEX contra cientos de organizaciones, según Microsoft.
• 7 de octubre: CrowdStrike publica su informe sobre el uso de ARTEX contra la banca surcoreana.
• 10 a 14 de octubre: password spraying desde 144.172.64.99 contra 327 cuentas de ocho organizaciones.
• 14 de octubre: Zscaler describe la arquitectura de ARTEX y cifra en 67.000 las personas afectadas en Corea del Sur.
• 15 de octubre: los agentes se autentican con las identidades de aplicación de ConnectWise en tenants de clientes.
• 16 de octubre: ConnectWise publica su primer aviso.
• 17 de octubre, 07:00 UTC: ConnectWise desactiva las siete identidades de aplicación y suspende Cloud Backup.
• 19 de octubre: ConnectWise completa el reinicio de todas las cuentas y credenciales del entorno de Cloud Backup.
• 21 de octubre, 14:35 UTC: comienza la restauración por fases.
• 21 de octubre: Microsoft atribuye el ataque a Storm-0940 y describe el uso de ARTEX.

Cómo ARTEX automatizó el abuso de las aplicaciones de ConnectWise

ARTEX es, según la descripción de Microsoft, un sistema multiagente basado en modelos de lenguaje, escrito en Go y con una interfaz web en Next.js que arranca en inglés y se puede cambiar a coreano, mandarín, español o japonés. Sus agentes ejecutan un pentest autónomo desde el reconocimiento hasta la exfiltración con muy poca intervención humana, acumulan los activos y las vulnerabilidades descubiertas en un grafo y admiten cualquier modelo como motor. Es lo que las plataformas de simulación de brechas y ataques hacen de forma controlada, pero sin reglas de alcance ni consentimiento de la víctima. Microsoft Threat Intelligence afirma haber identificado actores de varias regiones geográficas que lo usan.

La herramienta ya tenía historial. CrowdStrike publicó el 7 de octubre que un actor sin nombre la había empleado entre finales de septiembre y principios de octubre contra varias entidades financieras surcoreanas. Lo descubrió por unos directorios abiertos en una IP de Hong Kong que exponían historiales de sesión de Claude Code y ficheros de configuración de ARTEX, con la instancia de la herramienta alojada en 38.244.50.120. Esa instancia usaba DeepSeek v4.1-flash como modelo principal y GLM-5.3 y Grok 4.6 como apoyo, y CrowdStrike valora con confianza moderada que el operador habla chino y busca dinero, sin vincularlo a ningún grupo conocido. Zscaler ThreatLabz cifró el 14 de octubre en unas 67.000 personas los datos exfiltrados y explicó la arquitectura: «ARTEX uses an orchestration layer, known as a harness, to coordinate its models and agents» (ARTEX usa una capa de orquestación, llamada harness, para coordinar sus modelos y agentes). Un planificador divide el encargo en tareas, los agentes de trabajo ejecutan herramientas y guardan hallazgos, y una lista de bloqueo por defecto excluye administraciones y universidades, pero no bancos. Tras la publicación, su desarrollador, con el alias Autumn-27 en GitHub, cerró el código.

El diagrama de Zscaler ThreatLabz resume las cuatro fases que ARTEX encadenó contra la banca surcoreana: reconocimiento autónomo de aplicaciones web y backends de apps móviles, explotación por parte de los agentes, exfiltración de nombres, teléfonos, ingresos y límites de crédito, y planificación de la venta en Telegram. En el caso de ConnectWise, Microsoft describe las dos primeras fases aplicadas a identidades en la nube en lugar de a aplicaciones web. La secuencia que reconstruye su telemetría es esta.

1. Del 10 al 14 de octubre, la IP 144.172.64.99 lanzó password spraying automatizado contra 327 cuentas de ocho organizaciones para entrar en Microsoft 365 y Exchange Online. Microsoft registró más de 151.000 inicios de sesión fallidos, con un pico de 2.900 por minuto el 11 de octubre y más de 111.000 concentrados en un solo día. 48 cuentas recibieron más de 1.000 intentos y los bloqueos supusieron casi el 98 % de la actividad. No hubo ninguna autenticación con éxito, ningún token emitido ni ninguna llamada a Graph.
2. El 15 de octubre aparecieron los primeros informes públicos del compromiso de ConnectWise con indicadores en el mismo rango 144.172.64.x. El aviso del fabricante del 16 de octubre añadió después una IP que coincide exactamente con la 144.172.64.99 del password spraying.
3. Con las identidades de varias aplicaciones de ConnectWise en su poder, los agentes de IA se autenticaron desde el mismo rango en los tenants de los clientes, aprovechando los permisos que esas aplicaciones ya tenían concedidos. No hizo falta ningún inicio de sesión interactivo de usuario, por lo que el MFA no intervino.
4. En parte de esos entornos los agentes pasaron de la autenticación a Microsoft Graph y al directorio: reconocimiento, modificación de credenciales de aplicación para persistir y cambios en identidades, grupos y roles privilegiados. Microsoft avisa de que esos cambios «can remain active as a backdoor even after the original compromised application is mediated» (pueden seguir activos como puerta trasera incluso después de remediar la aplicación comprometida original).

Las cifras de Microsoft y las de Huntress no miden lo mismo. Microsoft cuenta más de 2.250 tenants con intentos de inicio de sesión de solo aplicación en toda su nube, mientras que Huntress, en su actualización del 19 de octubre, dice haber revisado más de 10.000 tenants con aplicaciones de ConnectWise entre sus clientes y haber confirmado acciones posteriores al compromiso en dos de ellos, con el último inicio de sesión correcto con la credencial robada a las 08:44 UTC del 15 de octubre. Huntress atribuye la 144.172.64.99 al password spraying del 10 al 14 de octubre y la 144.172.64.60 a unos pocos inicios de sesión fallidos del 18 de octubre, y añade una cuarta dirección, 144.172.94.243, con spraying continuo contra muchas organizaciones que Microsoft no recoge en su informe. Esa diferencia en el recuento no es una contradicción, es el reflejo de dos telemetrías distintas, y la cifra real de tenants tocados sigue sin publicarse. Estos son los indicadores que publica Microsoft.

Microsoft encuadra la actividad en MITRE ATT&CK como escaneo activo (T1595), cuentas válidas en la nube (T1078.004), compromiso de la cadena de suministro (T1195), roles adicionales en la nube (T1098.003, incluida la autoasignación de Global Administrator desde una de las aplicaciones de Cloud Management), credenciales adicionales en la nube (T1098.001), robo de tokens de acceso de aplicación (T1528), descubrimiento de cuentas en la nube (T1087.004) y descubrimiento de infraestructura en la nube (T1580). Son las mismas técnicas que Huntress ya había señalado, con el matiz de que ahora el reconocimiento y el descubrimiento los hace un agente. Para quien gestiona identidades y accesos en la nube, eso significa que la actividad llega en ráfagas de segundos y no en horas.

Microsoft propone para la caza avanzada de Defender XDR esta consulta, que une los inicios de sesión de entidad de servicio y la actividad de la API de Graph de las tres aplicaciones desde el 13 de octubre y los cruza con las IP del informe. Quitar el filtro de IP amplía la búsqueda a toda la actividad de esas aplicaciones.

let Apps = dynamic([
    "506e08f9-6e9a-4da4-942b-a099a03644ae",
    "24205314-2b89-4e07-a2a4-579e898a5640",
    "0de14c77-b9b0-4137-9360-34878a929827"
]);
let IPs = dynamic(["144.172.64.60", "144.172.64.99", "144.172.64.128"]);
union kind=outer
    (EntraIdSpnSignInEvents
     | extend EventType = "Sign-in"),
    (GraphAPIAuditEvents
     | extend EventType = "Graph API", IPAddress = IpAddress)
| where Timestamp >= datetime(2026-10-13)
| where ApplicationId in (Apps)
| where IPAddress in (IPs) // Comment out for broader hunting
| project-away IpAddress
| order by Timestamp asc

Para quien tiene Microsoft Sentinel y los registros de actividad de Graph activados, Microsoft publica esta otra consulta, que devuelve cada petición a Graph de las aplicaciones afectadas con su método, URI, código de respuesta y ámbitos. Una coincidencia con las IP del informe es actividad del atacante, y una petición de solo lectura al directorio desde una IP desconocida merece la misma atención.

let IPIndicators = dynamic([
    "144.172.64.60",
    "144.172.64.99",
    "144.172.64.128"
]);
let ConnectWiseApps = dynamic([
    "506e08f9-6e9a-4da4-942b-a099a03644ae", // ConnectWise Cloud Backup
    "24205314-2b89-4e07-a2a4-579e898a5640", // ConnectWise - MS Teams
    "0de14c77-b9b0-4137-9360-34878a929827" // ConnectWise - MS Graph
]);
MicrosoftGraphActivityLogs
| where TimeGenerated >= datetime(2026-10-13)
| where AppId in (ConnectWiseApps)
| where IPAddress in (IPIndicators) // Comment out to review all Graph activity from these applications
| project
    TimeGenerated,
    AppId,
    IPAddress,
    RequestMethod,
    RequestUri,
    ResponseStatusCode,
    Scopes,
    ClientRequestId,
    OperationId,
    RequestId
| order by TimeGenerated asc

Defender XDR genera para esta campaña alertas con los títulos Unusual Microsoft Graph activity associated with Compromised ConnectWise Application, Application self-assigned Global Administrator role, Suspicious sign-in from verified nation-state threat actor infrastructure y Malicious sign-in from known threat actor IP address. Defender for Cloud Apps añade otras siete, entre ellas la adición sospechosa de asignaciones de rol a una entidad de servicio y el acceso a correo por una aplicación OAuth tras una asignación de rol.

Tenants de Microsoft 365 y sectores en el punto de mira de Storm-0940

Afecta a cualquier tenant de Microsoft 365 donde alguna de las aplicaciones de ConnectWise o del antiguo SkyKick esté o haya estado consentida, incluidos los que conservan integraciones sin uso. Microsoft pide buscar por identificador de aplicación y no por nombre visible, porque en tenants antiguos aparecen como SkyKick Cloud Manager. El fabricante insiste en que la presencia de la aplicación o incluso una autenticación con éxito del atacante no demuestra que se accediera a datos, y en que hay que mirar lo que pasó después de cada inicio de sesión.

La campaña de ARTEX es más amplia que ConnectWise. Microsoft habla de cientos de organizaciones atacadas desde septiembre en los catorce sectores que enumera su informe, con la energía, las finanzas y la defensa entre ellos. En su informe de 2024, Microsoft situaba los objetivos de Storm-0940 en Norteamérica y Europa, con think tanks, organismos públicos, ONG, despachos de abogados y la base industrial de defensa a la cabeza, de modo que las organizaciones españolas de esos sectores encajan en el perfil del grupo aunque no usen ConnectWise.

En el momento de escribir esta noticia, el 22 de octubre de 2026, no hay recuento de tenants afectados por países y ni INCIBE-CERT ni CCN-CERT han publicado aviso propio sobre el incidente ni sobre ARTEX. En España el impacto directo sigue recayendo en el canal MSP que gestiona Microsoft 365 para pymes y administraciones con Cloud Backup o Cloud Management, y en sus clientes, que llevan desde el 17 de octubre sin copias nuevas.

Qué revisar en Entra y Microsoft 365 tras la atribución

Microsoft publica una lista de acciones inmediatas que coincide con la de ConnectWise y la amplía. Por orden de urgencia, es esta.

1. Mantén desactivadas las conexiones de las aplicaciones de ConnectWise en todos los tenants hasta que el fabricante publique las instrucciones formales de reactivación. La restauración por fases empezó el 21 de octubre y ConnectWise avisa de que no todas las funciones vuelven a la vez.
2. No borres las aplicaciones empresariales como primera respuesta. Conserva la configuración y las pruebas antes de cualquier cambio irreversible, porque borrar elimina el consentimiento y parte del rastro.
3. Inventaría los tres identificadores de aplicación del informe en cada tenant y anota el Object ID local de la entidad de servicio. Revisa todos los tenants donde las aplicaciones estén o hayan estado instaladas, aunque la integración ya no se use.
4. Conserva los registros de inicio de sesión y auditoría de Entra, la auditoría de Purview, los datos del SIEM y los registros de actividad de Graph que ya tuvieras. Revisa desde el 15 de octubre como mínimo y, si la retención lo permite, extiende la revisión de inicios de sesión de entidad de servicio hasta el 1 de octubre.
5. Revisa por separado los inicios de sesión correctos y fallidos de las entidades de servicio. Investiga orígenes desconocidos fuera de la infraestructura del fabricante y no te limites a las IP publicadas. Para el 15 y el 16 de octubre, incluye las tres direcciones de VPN del rango 187.15.x.
6. Busca en la auditoría de Entra adiciones de credenciales a aplicaciones o entidades de servicio, aplicaciones, entidades y propietarios nuevos, asignaciones de roles de aplicación y concesiones de consentimiento, asignaciones de roles privilegiados y cambios en usuarios, grupos, métodos de autenticación o acceso condicional. Ante un hallazgo confirmado, revoca permisos y rota credenciales.
7. Busca en la auditoría de Microsoft 365 reconocimiento desde IP inusuales (listados de directorio, permisos y aprobaciones), accesos anómalos a correo y archivos, descargas, reenvíos, reglas de bandeja de entrada y de transporte y permisos delegados sobre buzones.
8. Con las pruebas a salvo, que un responsable autorizado elimine las credenciales, concesiones, propietarios, asignaciones e identidades no autorizadas, y comprueba que la rotación de credenciales del fabricante y la limpieza del tenant han cerrado todos los accesos.
9. Aplica mínimo privilegio a los permisos y consentimientos de las aplicaciones multitenant y vigila las adiciones de credenciales, las asignaciones de privilegios y la actividad anómala de solo aplicación, en especial en las aplicaciones con permisos elevados, como manda un modelo Zero Trust aplicado a identidades de carga de trabajo.
10. Notifica la actividad sospechosa a ConnectWise en SecurityPartnerSupport@ConnectWise.com y, en España, a INCIBE-CERT si eres empresa y al CCN-CERT si eres administración pública. Si hay datos personales afectados, prepara la notificación a la AEPD en el plazo de 72 horas.

Lo que la atribución a Storm-0940 cambia para los MSP

Para quien gestiona tenants de terceros, la atribución cambia el modelo de amenaza. Hasta el 21 de octubre el incidente podía leerse como un robo de credencial oportunista. Lo que describe Microsoft es un grupo estatal que lleva años añadiendo credenciales a aplicaciones OAuth ajenas para mantener acceso al correo, y que ahora dispone de agentes que lo hacen en segundos y en miles de tenants a la vez. La frase sobre las puertas traseras que sobreviven a la remediación de la aplicación original es, a nuestro juicio, el aviso más serio del informe: la rotación de credenciales de ConnectWise cierra la puerta del fabricante, pero cada secreto plantado en otra aplicación o cada rol añadido a una identidad sigue abierto hasta que alguien lo encuentre en su propio tenant. Es la misma lección que dejó el backdoor servido por las actualizaciones de AOMEI Backupper, con la diferencia de que aquí la persistencia vive en el directorio y no en un ejecutable.

Hay cosas que el informe no dice. Microsoft no explica cómo salió la credencial de Cloud Backup del entorno de ConnectWise ni si ARTEX participó en ese robo o solo en el abuso posterior. Tampoco da el número de tenants donde la actividad fue más allá de la autenticación, y ConnectWise sigue sin aclarar si una vulnerabilidad de producto contribuyó al compromiso. La atribución es una valoración de Microsoft, que usa el verbo assesses, y ninguna agencia gubernamental la ha respaldado por ahora. Hay una coincidencia que nos parece relevante aunque ninguna fuente la señale: el password spraying del 13 y el 14 de octubre que Huntress vio contra cuatro bufetes de abogados encaja con el perfil de objetivos que Microsoft atribuía a Storm-0940 en 2024, donde los despachos figuraban junto a los think tanks y la base industrial de defensa.

El gráfico que Microsoft publicó en octubre de 2024 muestra el estilo anterior de Storm-0940. En torno al 80 % de las veces, la red CovertNetwork-1658 de routers domésticos comprometidos hacía un único intento por cuenta y día, precisamente para no disparar los umbrales de bloqueo. La campaña de octubre de 2026 es lo contrario: 2.900 intentos por minuto, 111.000 fallos en un día y un 98 % de bloqueos. Al grupo ha dejado de importarle el ruido, porque el agente consigue el acceso antes de que el SOC procese la alerta. Para el defensor la señal ya no es sutil, pero la ventana para actuar se ha reducido a minutos, y eso obliga a automatizar la respuesta (deshabilitar la entidad de servicio o revocar la credencial en cuanto se dispara la alerta) y a tratar las aplicaciones multitenant como el activo de nivel cero que son. El debate sobre la IA en ciberseguridad ha dejado de ser teórico: ARTEX es software libre reconvertido en arma en menos de tres meses, y cabe esperar que aparezcan derivados y herramientas parecidas aunque su autor haya cerrado el código.

Preguntas frecuentes sobre Storm-0940, ARTEX y ConnectWise

¿Qué es ARTEX y sigue disponible?

Es un framework de pentesting autónomo desarrollado en China y publicado en GitHub por un autor con el alias Autumn-27. Está escrito en Go, tiene una interfaz web en Next.js y encadena agentes basados en modelos de lenguaje que reconocen, explotan y exfiltran sin apenas intervención humana. El autor cerró el código tras la publicación de CrowdStrike, pero las copias descargadas antes y los derivados en inglés y coreano siguen circulando, y Microsoft ya ve a actores de varias regiones usándolo.

¿Qué cambia para mi empresa que el atacante sea Storm-0940?

Cambia la hipótesis de trabajo. Un grupo estatal con historial de persistencia en aplicaciones OAuth no busca un rescate rápido, busca quedarse. Si tu tenant tuvo la aplicación de ConnectWise consentida, revisa roles, credenciales de aplicación y propietarios añadidos desde el 13 de octubre aunque ya hayas deshabilitado la entidad de servicio. Si trabajas en defensa, energía, administración pública o en un despacho de abogados, entras en el perfil de objetivos del grupo aunque no uses ConnectWise.

¿Cuándo vuelve a funcionar ConnectWise Cloud Backup?

ConnectWise empezó la restauración por fases el 21 de octubre a las 14:35 UTC y calcula varios días. Cada paso pasa una validación de seguridad y las instrucciones de reconexión se publicarán por fases. Hasta recibirlas, las aplicaciones deben seguir desactivadas y las copias siguen paradas, aunque el fabricante asegura que los archivos existentes siguen cifrados, aislados y conservados.

¿Cómo distingo el tráfico legítimo de ConnectWise del de Storm-0940?

El tráfico legítimo de las aplicaciones sale de direcciones IPv6 de Azure y usa el agente kiota-dotnet del SDK de Microsoft Graph. El del atacante llega desde 144.172.64.128, 144.172.64.99 o 144.172.64.60, desde las tres IP de VPN del 15 y el 16 de octubre, y con agentes Python-urllib/3.12, python-requests, curl/7.88.1 o azure-toolkit/1.0. Cualquier inicio de sesión de entidad de servicio de esas aplicaciones desde una IP pública de un proveedor de hosting es sospechoso, y entender por qué merece el mismo trato que una cuenta de administrador es el punto de partida de cualquier gestión de identidad y acceso en la nube que quiera sobrevivir a esta campaña.