Storm-0940 y ARTEX: Microsoft atribuye a un grupo alineado con China el ataque a ConnectWise

Microsoft atribuyó el 21 de octubre de 2026 el ataque a ConnectWise Cloud Backup a Storm-0940, un grupo alineado con el Estado chino. En su análisis, la empresa afirma que el grupo usó ARTEX, un marco de pruebas de penetración de código abierto que funciona con agentes de IA, para intentar iniciar sesión en más de 2.250 inquilinos de Microsoft 365. En varios casos pasó del primer intento al acceso privilegiado en menos de tres horas.

Es la pieza que faltaba en el incidente que analizamos el 19 de octubre, cuando nadie había atribuido aún el ataque. La atribución identifica al actor y la herramienta, y la vía de entrada sigue siendo la misma. El atacante se hizo con las identidades de aplicación de un proveedor que sus clientes habían autorizado con permisos amplios, y la IA, según Microsoft, aceleró tanto la difusión de contraseñas previa como el abuso posterior de esas identidades.

¿Qué ha atribuido Microsoft a Storm-0940?

Microsoft "evalúa que Storm-0940 fue responsable" del compromiso de la cadena de suministro de ConnectWise, sin indicar un nivel de confianza. Según The Record, el vínculo se apoya en parte en las direcciones IP que publicó ConnectWise, que coincidían con las de la investigación de Microsoft.

Storm-0940 es un grupo APT activo desde 2021, sin otros nombres conocidos en el sector. Microsoft lo describe como un actor que entra por difusión de contraseñas (password spraying) y por aplicaciones expuestas a Internet, y que se mantiene añadiendo credenciales a aplicaciones OAuth existentes para leer correo y datos a través de Microsoft Graph. En un perfil de octubre de 2024, Microsoft situaba sus objetivos en Norteamérica y Europa, entre laboratorios de ideas, administraciones, ONG, despachos de abogados y la industria de defensa.

La campaña de 2026 apunta a aeroespacial y defensa, automoción, química, energía, servicios financieros, administraciones, despachos, industria, medios, sector militar, semiconductores, software, tecnología, laboratorios de ideas y organizaciones sin ánimo de lucro. Microsoft no precisa países. El consejero delegado de ConnectWise, Manny Rivelo, afirmó en un comunicado recogido por Reuters que "parece que un grupo alineado con el Estado chino fue responsable". La embajada china respondió que su país se opone a los ataques informáticos y a las "difamaciones" con el pretexto de la ciberseguridad.

¿Cómo se desarrolló el ataque?

Microsoft sitúa el inicio del uso de ARTEX por Storm-0940 en septiembre de 2026. Entre el 10 y el 14 de octubre, desde la dirección 144.172.64[.]99, el grupo lanzó una difusión de contraseñas contra 327 cuentas de ocho organizaciones, con más de 151.000 intentos fallidos y un pico de 2.900 fallos por minuto el día 11. Microsoft no observó ningún acceso con éxito en esa fase.

El 15 de octubre el atacante pasó a usar las identidades de varias aplicaciones de ConnectWise, desde el mismo rango de direcciones. Sophos describe un barrido de unos 96 minutos desde un único servidor, que recorrió los inquilinos en orden ascendente de identificador e incluyó a antiguos clientes del servicio de copias. Microsoft cuenta más de 2.250 inquilinos con intentos de inicio de sesión y, en su infografía, más de 200 inicios de sesión en menos de cuatro minutos con cuatro credenciales de aplicación.

En algunos inquilinos hubo reconocimiento a través de Graph, cambios en las credenciales de aplicaciones para mantener el acceso y modificaciones de identidades, grupos y roles privilegiados, entre ellas la autoasignación del rol de Administrador global por una aplicación de gestión de ConnectWise. Microsoft advierte de que esos cambios "pueden seguir activos como puerta trasera". En Azure, según la tabla de detecciones de Microsoft, el atacante enumeró recursos y leyó secretos de forma masiva en varios almacenes Azure Key Vault.

ConnectWise desactivó las siete identidades de aplicación el 17 de octubre, completó el 19 un restablecimiento de todas las cuentas y credenciales y, según su página de estado, restaura los servicios por fases desde el 21. La empresa sigue sin explicar cómo obtuvo el atacante el control de esas identidades.

¿A qué se refiere cada cifra que circula?

Las cifras publicadas miden cosas distintas, y algunos titulares han convertido los intentos en empresas comprometidas. La tabla resume qué significa cada una según su fuente.

Microsoft afirma que la mayoría de los intentos fracasó, pero que el grupo logró persistencia privilegiada en la nube en "muchas organizaciones", sin dar una cifra. También precisa que incluso una autenticación con éxito "no indica necesariamente un acceso no autorizado a datos".

¿Qué es ARTEX y qué papel tuvo la IA?

ARTEX es un marco de pruebas de penetración multiagente, con el núcleo escrito en Go, que admite distintos modelos de IA y encadena el reconocimiento, la explotación y la exfiltración. Según Wiz, se publicó en GitHub en julio de 2026 y superaba las 12.000 bifurcaciones cuando su autor lo cerró. El 8 de octubre, antes de la atribución, el desarrollador anunció que dejaba de actualizarlo y lo convertía en código cerrado por el mal uso, aunque varias bifurcaciones con licencia AGPL siguen activas en GitHub.

Storm-0940 no es el único actor que lo ha usado. Zscaler y Recorded Future documentaron este mes campañas de actores probablemente de habla china y con motivación económica contra entidades financieras surcoreanas. En un análisis posterior de una campaña más amplia, Zscaler encontró ARTEX configurado para usar un modelo de DeepSeek a través de una pasarela compatible con OpenAI, aunque precisa que eso no confirma qué modelo respondía. Microsoft afirma haber visto actores de varias regiones con esta herramienta.

Que se usara IA en la fase de ConnectWise es una afirmación de Microsoft que la empresa no respalda con artefactos publicados, y los únicos indicios públicos son la velocidad y la escala de la actividad. Los agentes de usuario observados (Python-urllib/3.12, python-requests/2.31.0, curl/7.88.1) son genéricos. Jon Semon, de Huntress, dijo a Cybersecurity Dive que su "hipótesis de trabajo" es que los ataques los ejecutó un agente de IA con herramientas automatizadas y alguna intervención humana.

Sophos, que no menciona la IA, describe un script que recorría una lista de inquilinos. Según SC World, Anthony Pillitiere, cofundador de Horizon3, sostiene que lo que permitió entrar fue un secreto de proveedor mal protegido con acceso a miles de inquilinos. Esa lectura encaja con el patrón que describimos al hablar de los agentes de IA autónomos con modelos de DeepSeek, en el que la IA acorta el tiempo entre una credencial robada y el control de un entorno y permite repetir la operación en miles de inquilinos a la vez.

¿En qué cambia el caso respecto al 19 de octubre?

La atribución añade el actor, la herramienta y el uso de ARTEX desde septiembre. Microsoft publica además tres direcciones de VPN (187.15.88[.]186, 187.15.90[.]217 y 187.15.89[.]186) y el agente de usuario azure-toolkit/1.0, y describe la lectura masiva de secretos en Azure Key Vault, que no figuraba en nuestro análisis del 19 de octubre. Las direcciones del rango 144.172.64.x coinciden con las que publicaron Huntress y ConnectWise.

El cambio práctico más importante es el de Key Vault. Si la aplicación de ConnectWise tenía acceso a almacenes de secretos, las claves, certificados y cadenas de conexión que guardaban deben tratarse como expuestos, aunque el inquilino no muestre otros cambios.

¿Qué deben revisar las organizaciones con aplicaciones de ConnectWise?

Microsoft publica una lista de mitigaciones y consultas de búsqueda para Defender XDR y Microsoft Sentinel, con la prioridad de conservar las pruebas antes de limpiar. La lista siguiente las resume e incorpora una recomendación nuestra sobre Key Vault.

• Las conexiones de ConnectWise deben seguir desactivadas hasta que el fabricante envíe instrucciones de restauración, y las aplicaciones empresariales no deben borrarse antes de conservar las pruebas.
• El inventario debe hacerse por identificador de aplicación y no por nombre visible, con el identificador de objeto de cada entidad de servicio en cada inquilino.
• Los registros de inicio de sesión y auditoría de Entra ID, Purview, el SIEM y Graph deben conservarse antes de que caduquen. La revisión abarca, como mínimo, desde el 15 de octubre, y desde el 1 de octubre para los inicios de sesión de entidades de servicio.
• La auditoría cubre credenciales añadidas, aplicaciones y propietarios nuevos, asignaciones de roles de aplicación y consentimientos, roles privilegiados, cambios en el acceso condicional, acceso a correo y ficheros, reglas de reenvío y de transporte y permisos delegados.
• Ante actividad sospechosa, Microsoft pide revocar permisos y rotar credenciales. En nuestra opinión eso incluye los secretos de los almacenes Azure Key Vault a los que pudo llegar la aplicación, y las lecturas masivas pueden buscarse con la tabla CloudKeyVaultEvents.
• La corrección del fabricante y la del inquilino deben verificarse por separado, porque desactivar la aplicación no revierte los cambios hechos dentro del entorno.

Las detecciones de Defender incluyen nombres como "Application self-assigned Global Administrator role" o "Suspicious addition of application role assignments by service principal to itself". Las consultas de Microsoft combinan EntraIdSpnSignInEvents y GraphAPIAuditEvents desde el 13 de octubre, y la empresa advierte de que un resultado vacío no demuestra que no hubiera acceso. Una revisión de seguridad de Microsoft 365 o un servicio de respuesta a incidentes pueden encargarse de esa investigación si el equipo interno no tiene capacidad.

En la edición gratuita de Entra ID los registros de inicio de sesión y de auditoría se conservan siete días, frente a los 30 de las licencias P1 y P2, y esa retención puede decidir el resultado. Para una organización sujeta al RGPD o a NIS2, el plazo de notificación de 72 horas y, si el incidente es significativo, la alerta temprana en 24 horas pueden empezar a correr antes de que los registros permitan responder qué pasó.

¿Cómo afecta a la defensa frente a ataques con agentes de IA?

Cuando el paso de una credencial robada al acceso privilegiado se mide en horas, los controles que dependen de una revisión manual al día siguiente llegan tarde. La protección de las identidades no humanas se convierte en la primera línea, porque una aplicación con consentimiento en miles de inquilinos no pasa por la autenticación multifactor ni por el acceso condicional para usuarios.

Shane Barney, CISO de Keeper Security, dijo a SC World que "los agentes autónomos prosperan en entornos donde las identidades no humanas están mal gobernadas". Las medidas que describimos en la guía sobre identidades no humanas y claves de API (inventario de consentimientos, permisos mínimos, límites a los secretos de larga duración) se aplican aquí sin cambios, dentro de un programa de seguridad de identidades no humanas.

Las alertas de Defender sobre autoasignación de roles y las búsquedas de lecturas masivas de Key Vault solo sirven si alguien, o una regla automática, actúa en minutos. Ese es el trabajo de un SOC gestionado con capacidad de contención fuera de horario, y la inteligencia de amenazas permite incorporar los indicadores de Microsoft, Huntress y Wiz el mismo día que se publican.

Para la gestión del riesgo de terceros, el caso confirma que el proveedor con una aplicación multiinquilino es un ataque a la cadena de suministro en potencia. ConnectWise planteó una idea parecida en su actualización del 21 de octubre, recogida por Infosecurity Magazine, al decir que los MSP "son objetivos en sí mismos" y además una vía hacia cada cliente al que dan servicio.

¿Cuáles son las incógnitas pendientes?

A 24 de octubre de 2026, ni ConnectWise ni Microsoft han explicado cómo obtuvo el atacante el control de las identidades de aplicación. Microsoft no ha publicado cuántas organizaciones sufrieron cambios persistentes ni si hubo robo de datos, y no ha mostrado artefactos que vinculen ARTEX con la fase de ConnectWise más allá del ritmo de la actividad.

Tampoco consta un aviso específico de CISA, del NCSC británico, del CCN-CERT, de INCIBE o de ENISA, y nadie ha nombrado víctimas en España. Ninguna de las fuentes consultadas relaciona a Storm-0940 con los grupos con motivación económica que usaron ARTEX contra bancos surcoreanos.

Un proveedor con acceso consentido a miles de entornos perdió el control de sus identidades de aplicación, y un actor estatal aprovechó esa ventana con herramientas que, según Microsoft, le permitieron llegar al acceso privilegiado en menos de tres horas en varios casos.

Fuentes y atribución: este análisis se basa en el informe de Microsoft Threat Intelligence del 21 de octubre de 2026, en la página de estado de ConnectWise y en los análisis de Huntress, Sophos, Wiz, Zscaler y Recorded Future. También recoge la cobertura de Reuters, The Record, Cybersecurity Dive, Infosecurity Magazine y SC World, con la información disponible a 24 de octubre de 2026. La atribución a Storm-0940 y el uso de IA son afirmaciones de Microsoft. La mención de ConnectWise no implica más fallos de los que la empresa ha comunicado.

Aviso: las mitigaciones y las consultas citadas son orientativas y deben adaptarse a cada entorno y probarse antes de aplicarlas en producción. Las consultas completas y los indicadores actualizados están en el informe de Microsoft.