Artículo
Storm0940: IA y ciberseguridad
Microsoft publicó el 21 de octubre de 2026 su investigación sobre Storm-0940 y ARTEX. Evalúa la responsabilidad del actor en el compromiso de una aplicación multiinquilino de ConnectWise. Reporta intentos de inicio de sesión en más de 2250 tenants (directorios de identidad), no 2250 compromisos confirmados.
Describe ARTEX como agentes basados en modelos de lenguaje para automatizar pruebas de seguridad. Atribuye al actor su uso para acelerar operaciones existentes; no presenta una medición causal aislada del efecto de la IA.
Esta lectura separa hechos atribuidos, definiciones técnicas y un ejercicio inventado. Su objetivo es formular preguntas precisas sin diagnosticar organizaciones ni convertir una posibilidad en un resultado.
Del proveedor a una identidad dentro de la empresa
La documentación de Entra distingue el objeto global de aplicación, en su directorio de origen, del service principal que la representa localmente en cada organización usuaria. Esa representación define permisos y recursos accesibles. El identificador global y el local cumplen funciones diferentes.
Por ello, reconocer una aplicación del proveedor no basta para describir su alcance en una empresa concreta: hace falta relacionar la representación local con sus permisos.
App-only no significa «en nombre de un usuario»
Según la documentación de permisos, el acceso delegado actúa por un usuario conectado y exige autorización de cliente y usuario. App-only emplea la identidad de la aplicación sin usuario conectado, con permisos de aplicación o app roles, no scopes delegados. Otros mecanismos de autorización pueden coexistir.
Identidad y permiso responden preguntas distintas: quién actúa y qué tiene autorizado. No describen por sí solos el resultado observado.
Un caso ficticio: una aplicación de respaldo en Laurel
Imaginemos que Comercial Laurel contrata una aplicación de respaldo a un proveedor ficticio. Para este ejercicio inventamos también sus documentos y registros; no describen ConnectWise, Entra ni capacidades comprobadas de un producto. La necesidad empresarial es conservar una copia de determinados documentos de trabajo, con un alcance que el expediente del caso identifica expresamente.
La ficha ficticia relaciona una aplicación global del proveedor con una representación local en Laurel y enumera los recursos y permisos atribuidos a esta última.
El supuesto elegido es app-only: actúa la identidad de la aplicación. No debe explicarse como acceso delegado por una persona conectada.
El equipo recibe después un registro ficticio que sólo informa de una autenticación de esa identidad a las 02:10. Una autenticación exitosa no demuestra por sí sola lectura de documentos ni extracción de datos. Para avanzar en el ejercicio, proponemos pedir evidencia distinta para cada pregunta, en vez de ampliar el significado de ese único registro.
| Observación del caso | Qué permite sostener | Límite de esa evidencia |
|---|---|---|
| Referencias global y local | Relacionan ambos objetos. | Relación declarada, no verificada. |
| Registro de autenticación de las 02:10 | Qué evento consigna ese registro inventado. | No contiene una operación sobre un documento. |
| Segundo registro hipotético: solicitud de copia del documento D7 | Que el expediente incorpora una solicitud concreta, con objeto y hora. | La palabra «solicitud» no dice cómo terminó. |
| Resultado hipotético vinculado a esa solicitud: denegada | Que ese resultado declarado fue una denegación. | No describe otras solicitudes ni resuelve el estado de todos los documentos. |
La última fila cambia la conclusión del ejemplo: el expediente describe una solicitud denegada, no una copia completada. Si faltara ese resultado, quedaría pendiente. Tampoco correspondería extender una denegación a toda la actividad. Son límites del escenario construido, no afirmaciones sobre formatos de registro disponibles ni sobre cómo opera un servicio real.
Para sostener acceso a D7 faltaría evidencia vinculada de su entrega o lectura efectiva. Tampoco demostraría, por extensión, extracción de otros documentos.
Qué comunicó ConnectWise sobre la recuperación
En su actualización de Cloud Backup del 23 de octubre, a las 01:11 UTC, ConnectWise describió restauración en curso. Preveía completar pruebas y validación de seguridad al terminar el fin de semana; sólo si resultaban satisfactorias devolvería capacidades por fases. Anticipaba acceso para restaurar copias a comienzos de la semana siguiente y reinscripción después. Era una previsión condicionada, no disponibilidad restablecida.
Declaró archivos de respaldo cifrados, aislados y preservados sin indicios de compromiso, y mantuvo la necesidad de revisar los entornos de cada cliente. Su aviso de las 06:12 UTC sobre un arreglo de ConnectWise Home no demuestra la restauración de Cloud Backup.
No hemos probado restauraciones, investigado víctimas ni observado el estado de una organización. La explicación propone un criterio de lectura; una situación real exige evidencia de sus responsables.
Preguntas frecuentes
¿App-only carece de identidad porque nadie inició sesión?
No: utiliza la identidad de la aplicación. No equivale a actuar de forma delegada por un usuario conectado.
¿El arreglo de Home confirma que Cloud Backup volvió?
No. Son referencias a servicios distintos; el anuncio de Cloud Backup conservaba condiciones pendientes.
¿El mismo nombre del proveedor implica el mismo alcance local?
No. La representación y los permisos locales deben distinguirse de la aplicación global.
Como contexto relacionado, puedes leer el análisis de AISI y las prácticas de seguridad. Trata una declaración distinta; no es una auditoría de este incidente.
