La credencial de una aplicación de backup permitió autenticación sin MFA en entornos de clientes desde el 15 de octubre — los tokens ya emitidos siguen activos hasta expirar
ConnectWise deshabilitó siete identidades de aplicación el 17 de octubre después de que una credencial vinculada a su plataforma Cloud Backup fuera utilizada para acceder sin autorización a entornos Microsoft 365 de clientes. La firma de seguridad Huntress identificó inicios de sesión sospechosos en 162 organizaciones a partir de las 19:00 UTC del 16 de octubre, todos originados desde direcciones IP externas al espacio privado de Azure que ConnectWise normalmente utiliza. La compañía suspendió Cloud Backup, SaaS Security y Cloud Management como medida de contención, pero advirtió que los tokens de acceso ya emitidos pueden seguir siendo válidos hasta su expiración natural.
Cómo una credencial de integración se convirtió en llave maestra de 162 tenants
La aplicación Cloud Backup de ConnectWise requiere permisos amplios para respaldar y restaurar datos de clientes en servicios de Microsoft 365 como Exchange Online, OneDrive, SharePoint y Teams. Esos permisos se gestionan mediante una credencial que reside en el entorno del proveedor — no en los tenants individuales de cada cliente — y que permite a la aplicación obtener tokens de Microsoft Graph sin que ningún usuario deba iniciar sesión ni completar autenticación multifactor.
Huntress registró que la aplicación Cloud Backup se autenticó desde la dirección IP 144.172.64.128 el 15 de octubre entre las 06:13 y 08:34 UTC. Esa dirección pertenece a un proveedor de hosting, no al rango de IP privadas de Azure desde el cual la aplicación normalmente se comunica. Los eventos de autenticación quedaron registrados en los logs de inicio de sesión de Microsoft. ConnectWise actualizó su aviso el 19 de octubre e incluyó dos direcciones IP adicionales — 144.172.64.99 y 144.172.64.60 — identificadas mediante monitoreo de seguridad posterior.
Escalada de privilegios en cinco minutos dentro de un tenant de partner
Huntress también identificó actividad relacionada con una segunda aplicación de ConnectWise, Cloud Management for Microsoft Teams, en un tenant de partner. Según la firma de seguridad, la aplicación se asignó a sí misma el rol de Administrador Global y agregó credenciales a otras dos aplicaciones — incluida una aplicación específica de Huntress en ese mismo partner — en un lapso de aproximadamente cinco minutos. Huntress no estableció si las distintas etapas de actividad fueron ejecutadas por el mismo operador.
Este tipo de escalada automática de privilegios es posible porque las aplicaciones con permisos delegados pueden modificar roles y asignaciones dentro del directorio de Azure Active Directory sin intervención humana visible en los registros de auditoría estándar. Algunas operaciones de lectura del directorio mediante Microsoft Graph no dejan rastro auditable, lo que limita la capacidad de los investigadores para reconstruir qué datos fueron consultados o extraídos.
Tokens activos y servicios suspendidos — la contención no es reversión
ConnectWise deshabilitó las siete identidades de aplicación y revocó certificados asociados a las conexiones afectadas. La compañía aclaró que esas acciones impiden nuevas autenticaciones a través de las conexiones deshabilitadas, pero no revierten automáticamente los cambios ya realizados dentro de los tenants de clientes. Los tokens de acceso emitidos previamente pueden seguir siendo utilizables hasta que expiren o sean invalidados de forma explícita.
La suspensión de servicios se extiende más allá de los respaldos. Con Cloud Backup fuera de línea, los respaldos programados, el acceso a archivos existentes y las capacidades de restauración permanecen inaccesibles. Las funciones de monitoreo y alertas de SaaS Security, junto con la gestión de usuarios y licencias de Cloud Management, también están deshabilitadas mientras continúa la remediación. ConnectWise confirmó que los archivos de respaldo existentes permanecen cifrados y aislados sin indicios de compromiso, pero no estableció un cronograma para restaurar los servicios.
Por qué México y Brasil quedan expuestos por su dependencia del mismo modelo de integración
ConnectWise es un proveedor ampliamente adoptado por empresas de servicios gestionados en América Latina, especialmente en México y Brasil, donde muchas organizaciones delegan la gestión de su infraestructura Microsoft 365 en partners que utilizan estas mismas herramientas de backup y administración cloud. El modelo de credencial compartida — una sola identidad de aplicación con permisos amplios sobre múltiples tenants de clientes — es estándar en la industria de MSP (proveedores de servicios gestionados), pero concentra el riesgo en un único punto de falla.
Si bien ConnectWise no reportó actividad específica en tenants de la región, la arquitectura de autenticación comprometida es la misma que utilizan los partners locales. Huntress advirtió que su investigación no confirmó robo de datos, pero tampoco pudo descartarlo: en el único tenant cuyos logs de auditoría examinó en detalle, no encontró registros de acceso a correo o archivos, aunque algunas operaciones de lectura del directorio mediante Microsoft Graph no generan trazas auditables. Esa limitación técnica aplica igual en cualquier geografía.
Nuestro análisis
Este incidente expone una tensión estructural en el modelo de integración cloud entre proveedores de servicios gestionados y plataformas SaaS. ConnectWise necesita permisos amplios para cumplir su función — respaldar y restaurar datos en múltiples servicios de Microsoft 365 — pero esos mismos permisos, concentrados en una credencial de aplicación que no requiere autenticación de usuario ni MFA, se convierten en un vector de compromiso lateral masivo cuando esa credencial es expuesta. La escalada de privilegios observada en un tenant de partner — donde una aplicación se asignó el rol de Administrador Global en cinco minutos — muestra que el problema no es solo de acceso inicial, sino de capacidad de persistencia y movimiento lateral automatizado dentro de entornos ya comprometidos.
La respuesta de ConnectWise — deshabilitar identidades y suspender servicios — es una contención necesaria pero incompleta. Los tokens ya emitidos siguen activos hasta expirar, y los cambios realizados en los tenants de clientes (roles asignados, credenciales agregadas, políticas modificadas) no se revierten automáticamente. Eso traslada la carga de verificación y limpieza a cada administrador de tenant afectado, que debe revisar manualmente logs de inicio de sesión, roles de directorio, consentimientos de aplicación y mecanismos de persistencia como reglas de reenvío de correo. Microsoft no respondió inmediatamente a solicitudes de comentario, lo que deja sin aclarar si la plataforma implementará invalidación forzada de tokens o auditorías asistidas para los tenants impactados. ¿Qué pasaría si el próximo compromiso de credencial de integración ocurre en un proveedor con permisos similares pero sin la capacidad de detección temprana que Huntress demostró en este caso?