Atacantes usaron identidades comprometidas para acceder a entornos Microsoft 365 de clientes sin necesidad de robar contraseñas individuales
ConnectWise descubrió el 14 de octubre acceso no autorizado a siete identidades de aplicación que su servicio Cloud Backup utilizaba para operar dentro de entornos Microsoft 365 de clientes. Tres días después, el 17 de octubre, la compañía deshabilitó las identidades comprometidas y suspendió por completo Cloud Backup (anteriormente conocido como SkyKick), junto con sus servicios SaaS Security y Cloud Management. La investigación sigue en curso, con apoyo de una firma externa de respuesta a incidentes, y ConnectWise todavía no ha explicado cómo los atacantes obtuvieron las credenciales originales.
El vector de ataque no dependió de phishing masivo ni de comprometer contraseñas de usuarios finales. Las aplicaciones de ConnectWise ya tenían permisos delegados para acceder a datos de clientes en Microsoft 365 — buzones de correo, documentos de SharePoint, mensajes de Teams, información de directorio — como parte de su operación normal de backup y gestión. Al robar las credenciales de esas aplicaciones, los atacantes pudieron solicitar tokens de acceso directamente a Microsoft Entra ID haciéndose pasar por las propias herramientas de ConnectWise, sin necesidad de tocar ninguna cuenta de usuario individual.
Por qué deshabilitar las conexiones comprometidas no borra lo que ya pasó
ConnectWise aclaró que revocar las identidades afectadas impide nuevas autenticaciones a través de esas conexiones, pero no revierte cambios que los atacantes hayan realizado previamente dentro de los entornos de clientes. Cualquier modificación ejecutada antes del 17 de octubre permanece intacta hasta que cada organización afectada la identifique y remedie manualmente.
El problema de persistencia es estructural. Un atacante que logró acceso inicial mediante una credencial de aplicación robada puede agregar su propio secreto de cliente a otra aplicación de confianza ya registrada en el tenant, o crear una aplicación completamente nueva con permisos propios. Ambas rutas le otorgan una segunda llave que sigue funcionando incluso después de que ConnectWise revoque la credencial original comprometida. Investigadores de Huntress documentaron que si una aplicación tiene capacidad de asignar roles de directorio — como observaron en al menos un tenant — puede elevarse a sí misma como Administrador Global, y desde ese rol puede agregar credenciales a otras aplicaciones, crear nuevas aplicaciones con permisos arbitrarios, resetear contraseñas y métodos de autenticación de usuarios, y modificar políticas de acceso condicional.
Dos oleadas de ataques con objetivos distintos
Huntress identificó inicios de sesión maliciosos desde la dirección IP 144.172.64.128 hasta el 15 de octubre alrededor de las 14:20 UTC. Esa misma tarde se registró una segunda ola de ataques dirigida específicamente a 16 inquilinos en los sectores de política, seguridad nacional, comercio y minerales críticos. Esta segunda oleada fue manual — no automatizada — y golpeó en rápida sucesión las API de Exchange Online, SharePoint Online, Teams, Azure Resource Manager, Entra y Office 365 Management. Los 16 intentos de la segunda ola fallaron, pero el hecho de que fueran dirigidos manualmente a sectores sensibles revela intención de reconocimiento o espionaje más allá de un ataque oportunista masivo.
De aproximadamente mil tenants de Microsoft Entra que registraron actividad de inicio de sesión desde la IP sospechosa, alrededor de 300 inicios de sesión fueron exitosos. Sin embargo, un inicio de sesión exitoso no siempre otorgó acceso efectivo al tenant: en algunos casos los atacantes no pudieron avanzar porque faltaba el service principal requerido, resultado de la configuración particular del tenant y no de una medida de seguridad implementada deliberadamente.
Qué implica la suspensión del servicio para clientes que dependen de esos backups
ConnectWise afirmó que los archivos de backup en Cloud Backup permanecen cifrados, aislados y preservados, sin evidencia de que los atacantes hayan accedido o comprometido esos archivos. Pero mientras el servicio permanece suspendido, los backups programados no se ejecutan y los clientes no pueden restaurar sus datos. Esto genera un riesgo operacional concreto para organizaciones que dependen del servicio para recuperar sistemas e información en caso de incidente.
La recomendación de Huntress para cualquier usuario de ConnectWise Cloud Backup o Cloud Management es revisar tanto el propio tenant de Microsoft 365 como cada tenant de cliente gestionado, incluyendo aquellos con conexiones SkyKick inactivas. La búsqueda debe enfocarse en actividad de inicio de sesión desde la IP 144.172.64.128 a partir del 13 de octubre. Antes de ejecutar cualquier paso de contención, es crítico preservar los logs de inicio de sesión y auditoría disponibles, porque las acciones de remediación pueden sobrescribir la evidencia necesaria para entender qué ocurrió realmente dentro de cada entorno.
Para América Latina, donde proveedores de servicios gestionados dependen crecientemente de plataformas como ConnectWise para operar infraestructuras de clientes en sectores regulados — banca, energía, gobierno — este incidente expone la fragilidad del modelo de confianza delegada en aplicaciones de terceros con permisos amplios sobre entornos Microsoft 365. Aunque ConnectWise no ha reportado clientes afectados específicamente en la región, cualquier MSP (proveedor de servicios gestionados) latinoamericano que utilice Cloud Backup o SkyKick enfrenta ahora la misma tarea de auditoría forense que sus pares en otras geografías, con la complejidad adicional de que muchos carecen de capacidad interna de respuesta a incidentes para ejecutar esa revisión sin apoyo externo.
Nuestro análisis
Este caso confirma un patrón que ya habíamos visto en incidentes previos de cadena de suministro de software: el punto de falla no está en las credenciales de usuarios finales sino en las identidades de aplicación con permisos delegados amplios. A diferencia de un ataque de phishing tradicional, donde cada cuenta comprometida requiere un vector de ataque individual, robar una credencial de aplicación de un proveedor de servicios otorga acceso simultáneo a cientos o miles de entornos de clientes. La arquitectura de permisos delegados en Microsoft Entra ID asume que las aplicaciones de terceros protegen sus propias credenciales con el mismo rigor que Microsoft protege las suyas — una suposición que este incidente vuelve a cuestionar.
Lo que todavía no sabemos es cómo los atacantes obtuvieron las siete identidades de aplicación comprometidas. ConnectWise no ha divulgado si fue mediante acceso a sistemas internos, ingeniería social contra empleados con acceso a esas credenciales, o exfiltración desde repositorios de código o configuración. Tampoco está claro si los atacantes tenían conocimiento previo de qué permisos tenían esas identidades antes de robarlas, o si fue un descubrimiento posterior. La segunda oleada manual contra sectores específicos sugiere que al menos parte del ataque fue dirigido, no oportunista. ¿Qué pasaría si el mismo patrón se repite en otros proveedores de backup y gestión que operan con el mismo modelo de permisos delegados, pero sin la capacidad de detección interna que permitió a ConnectWise identificar el acceso no autorizado en tres días?