Agentes de IA y credenciales robadas de ConnectWise, usados para sondear más de 2.250 tenants de Microsoft 365
Un actor de amenazas alineado con un Estado ha combinado un framework de agentes de IA con credenciales robadas de aplicaciones ConnectWise para intentar acceder a más de 2.250 tenants de Microsoft 365. La campaña no dependió de una vulnerabilidad nueva de Microsoft. Se apoyó en permisos que los clientes ya habían concedido a aplicaciones ConnectWise en las que confiaban.
Qué ocurrió
Microsoft atribuye la actividad a Storm-0940, un grupo que rastrea como alineado con los intereses del Estado chino, e indica que los operadores usaron un framework de penetration testing multiagente llamado ARTEX para acelerar el reconocimiento, los intentos de autenticación y la persistencia dentro de los tenants en la nube. ARTEX está diseñado para encadenar tareas desde el descubrimiento inicial hasta la exfiltración de datos, manteniendo un mapa conectado de los activos y debilidades que va encontrando.
El punto de entrada fue la identidad de aplicación. En lugar de iniciar sesión como usuarios, los atacantes se autenticaron como aplicaciones ConnectWise con credenciales obtenidas en una fase anterior de la campaña. Como los inicios de sesión procedían de un principal de aplicación, no hubo introducción interactiva de contraseña ni aviso de autenticación multifactor que una persona pudiera rechazar. El sistema de autenticación de Microsoft no fue vulnerado. Se usó exactamente como fue diseñado, con las llaves de otro.
Fases anteriores de la misma campaña ya habían producido inicios de sesión no autorizados en 173 tenants de socios y clientes tras el compromiso de credenciales de backup de ConnectWise. La cifra de 2.250 cuenta tenants atacados, no tenants vulnerados.
Automatización a velocidad de máquina
La mayor parte de la actividad se concentró en una ventana de menos de 14 horas el 15 de octubre. Un solo barrido recorrió casi 1.000 tenants en orden ascendente de identificador. Ráfagas separadas lanzaron unas 100 solicitudes de token fallidas en diez segundos, lo que apunta a workers paralelos ejecutándose sin detenerse a evaluar cada respuesta.
La evidencia más reveladora es cómo las herramientas se adaptaron entre ejecuciones. Tras fallar una carga de certificado porque su huella digital no coincidía, una nueva ejecución arrancó 55 segundos después con lógica de reintento añadida. Reintentó a los 3,5 y 7,1 segundos aproximadamente, luego trasladó la secuencia corregida a otro tenant y añadió ambas claves en una sola pasada. Cuando un intento de eliminación fue denegado, la herramienta recurrió a conceder el rol Privileged Role Administrator a un principal hermano y borró el principal de servicio original minutos después.
Dentro de los tenants se añadieron, eliminaron y restauraron secretos, junto con cambios en roles privilegiados. En un caso, una identidad de aplicación de Teams se asignó a sí misma Global Administrator, una ilustración clara de cómo el acceso de una aplicación de confianza puede convertirse en control administrativo.
No todo pareció inteligente. Tras borrarse un principal de servicio de Teams, las solicitudes siguieron llegando cada cuatro a ocho segundos durante otros 22 minutos, un comportamiento más propio de scripts desatendidos o tareas de fondo que de un operador reaccionando a la retroalimentación. Solo por el comportamiento, la confianza en que hubo un agente de IA en el circuito es de baja a media. Sube a media o alta únicamente al incorporar la atribución de Microsoft, y conviene mantener esa cautela: la evidencia describe actividad maliciosa de aplicaciones y herramientas de ataque, no una familia de malware recién identificada.
Por qué importa
Tres cosas hacen que esta campaña resulte incómoda para los defensores.
- Las identidades de aplicación eluden los controles pensados para personas. La MFA, los avisos de acceso condicional y las alertas centradas en el usuario sirven de poco cuando el actor es una aplicación registrada legítimamente con credenciales válidas.
- La visibilidad es escasa. Los registros de auditoría de Entra no capturan las lecturas de Microsoft Graph, y ninguna de las víctimas conocidas tenía activado el registro de actividad de Graph. Un inicio de sesión exitoso no permite saber, por tanto, qué se leyó o se sustrajo. La propia Microsoft separa tres categorías: tenants atacados, inicios de sesión exitosos y acceso confirmado a datos.
- Las cifras se malinterpretan con facilidad. Una fase anterior de password spray de la campaña registró más de 151.000 inicios de sesión fallidos contra 327 cuentas de ocho organizaciones, con un pico de 2.900 fallos por minuto. Ese ritmo pertenece al spray, no a un recuento de inicios de sesión exitosos en ConnectWise.
Qué hacer
- Alerte sobre aplicaciones que se otorgan poder a sí mismas. Cualquier principal de servicio que se asigne Global Administrator o Privileged Role Administrator, o que añada credenciales inesperadas, merece una revisión inmediata.
- Establezca una línea base para las identidades de proveedores. Conozca qué hacen normalmente sus aplicaciones de ConnectWise y de otros terceros, y trate como incidentes las desviaciones en IP de origen, user agent o cadencia de solicitudes.
- Cace entre tenants, no dentro de uno solo. Una actividad que parece menor en un único entorno se convierte en una campaña evidente al correlacionarla entre clientes o departamentos.
- Siga la guía de contención de Microsoft. Mantenga deshabilitadas las conexiones afectadas hasta que se publique la guía oficial de restauración, preserve la evidencia antes de borrar aplicaciones y revise credenciales, permisos y asignaciones de roles. Eliminar la vía de acceso original puede dejar credenciales plantadas en otro lugar.
- Active el registro de actividad de Microsoft Graph donde su licenciamiento lo permita e investigue la actividad de buzones y archivos junto con los cambios de identidad.
Indicadores de compromiso
Los indicadores están desactivados con [.]. Reactívelos solo dentro de herramientas controladas, como su SIEM o su plataforma de inteligencia de amenazas.
| Tipo | Indicador | Contexto |
|---|---|---|
| IP | 144.172.64[.]128 | Inicios de sesión de aplicaciones y actividad Graph |
| IP | 144.172.64[.]99 | Password spraying entre tenants, 10–14 de octubre |
| IP | 194.165.16[.]21 | Posible vínculo a través de un user agent reutilizado |
| IP | 144.172.64[.]60 | Señalado tanto por ConnectWise como por Microsoft |
| User agent | Python-urllib/3.12 | Herramientas de enumeración y escalada |
| User agent | curl/7.88.1 | Coherente con herramientas en contenedores |
| User agent | python-requests/2.31 y 2.31.0 | Barridos dirigidos |
| User agent | python-requests/2.34.2 | Telemetría de password spray |
| User agent | azure-toolkit/1.0 | Listado por Microsoft, no visto en la telemetría de víctimas |
Sea cual sea el grado real de participación de la IA, la lección defensiva no cambia: la confianza que concede a aplicaciones de terceros forma parte de su superficie de ataque. Nuestros servicios de penetration testing cubren la capa de identidad de Microsoft 365, incluidos los registros de aplicaciones, los permisos de principales de servicio y los consentimientos otorgados, para que el acceso sobreprivilegiado de proveedores se detecte y elimine antes de que unas llaves robadas a otro lo conviertan en control administrativo.
