Introducción
La dependencia de identidades de aplicación compartidas en arquitecturas multi-tenant sigue siendo un vector de ataque de alto impacto para los proveedores de servicios gestionados (MSP) y sus clientes. Cuando un proveedor centralizado como ConnectWise pierde el control de sus credenciales de aplicación, el impacto no se limita a su infraestructura, sino que se propaga horizontalmente hacia todos los tenants de Microsoft 365 que confían en esas identidades. El incidente reportado el 17 de octubre de 2026 demuestra cómo la rotación insuficiente de secretos y la falta de restricciones granulares en Azure Active Directory (ahora Microsoft Entra ID) permiten a los atacantes operar con la legitimidad de la aplicación, eludiendo controles de seguridad convencionales centrados en usuarios humanos.
Para los equipos de DevOps y seguridad, este evento subraya la necesidad de auditar no solo los accesos de usuario, sino también las identidades de servicio y sus permisos delegados. La capacidad de un atacante para autenticarse como una aplicación de respaldo legítima y expandir su alcance dentro del tenant, incluyendo la creación de nuevos secretos, convierte una exposición de credenciales en una brecha persistente y difícil de erradicar si no se revisan manualmente los registros de auditoría de Entra ID.
Qué ocurrió
ConnectWise identificó actividad anómala el 14 de octubre de 2026 mediante su monitoreo de seguridad interno. Como respuesta, el proveedor deshabilitó siete identidades de aplicación críticas el 17 de octubre a las 07:00 UTC y suspendió la función Cloud Backup para todos los usuarios. Esta medida incluyó la revocación de los certificados utilizados para las conexiones afectadas, invalidando las credenciales compartidas utilizadas para la autenticación de la aplicación.
Los atacantes obtuvieron acceso no autorizado a estas identidades y las utilizaron para comprometer tenants de Microsoft 365. Según la investigación de Huntress, la actividad maliciosa principal ocurrió el 15 de octubre, con intentos automatizados y manuales dirigidos contra APIs de Exchange Online, SharePoint, Teams y Azure Resource Manager. Aunque ConnectWise no ha confirmado una vulnerabilidad de producto específica como causa raíz, el mecanismo de exposición de credenciales sigue bajo análisis. La empresa enfatizó que, aunque los backups existentes permanecen cifrados y aislados, la capacidad de restauración y el acceso a los archivos están actualmente interrumpidos.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
El riesgo principal para la infraestructura de clientes no radica en la pérdida de los datos de respaldo, sino en la integridad del tenant de Microsoft 365. Al comprometer la identidad de la aplicación, los atacantes pueden solicitar tokens de acceso a Microsoft Entra ID basándose en los permisos preexistentes de la aplicación. Esto permite el acceso a buzones de correo, documentos de SharePoint y mensajes de Teams sin necesidad de robar contraseñas individuales.
Más crítico aún es la capacidad de escalada de privilegios. Los atacantes pueden modificar los permisos de la aplicación comprometida, añadirse al rol de Administrador Global, o crear nuevas aplicaciones con secretos propios para mantener la persistencia. Esto significa que revocar la credencial original de ConnectWise no garantiza la expulsión del atacante, quien puede haber plantado «puertas traseras» dentro del registro de aplicaciones del tenant. Para los equipos de seguridad, esto transforma el incidente de un problema de backup a una investigación forense completa de la configuración de identidad y autorización en Azure AD y Microsoft 365.
Detalles técnicos
La técnica de ataque se centra en el abuso de secretos de cliente (client secrets) para identidades de servicio en Azure AD. Los atacantes utilizaron la IP 144.172.64[.]128 para realizar autenticaciones. Huntress identificó casi 1,000 tenants con intentos de inicio de sesión desde esta dirección, de los cuales 300 fueron exitosos en términos de autenticación, aunque no todos resultaron en acceso efectivo a los datos debido a la ausencia de service principals adecuados en algunos casos.
El vector de ataque explotó la confianza implícita del tenant en las aplicaciones de ConnectWise. Al autenticarse con el secreto robado, el atacante obtenía un token JWT válido para la API de Microsoft Graph. Los logs muestran barridos dirigidos contra las APIs de Exchange Online, SharePoint Online, Teams, Azure Resource Manager, Entra y las API de administración de Office 365. La capacidad de modificar aplicaciones registradas (App Registrations) permitió a los atacantes añadir nuevos secretos, lo que asegura la persistencia incluso si el secreto original es revocado.
Es relevante notar que, aunque el resumen menciona «rust» como tecnología relevante, no hay evidencia técnica en el informe de incidente de que Rust haya sido el vector de ataque o el lenguaje de la herramienta explotada. La mención probable se relaciona con el ecosistema de herramientas de seguridad de próxima generación o binarios específicos utilizados por los atacantes para ofuscar su actividad, pero el núcleo del incidente es la gestión de identidades en Azure.
Los permisos comprometidos incluían alcance para Exchange, SharePoint y Teams, lo que implica acceso a datos sensibles corporativos. La falta de políticas de Conditional Access para identidades de carga de trabajo (workload identities) permitió que las autenticaciones desde una IP externa no identificada fueran aceptadas sin factores adicionales.
Qué deberían hacer los administradores y equipos técnicos
Los administradores de Microsoft 365 y Azure AD deben actuar inmediatamente para detectar y remediar la persistencia del atacante. No basta con confiar en que ConnectWise haya revocado sus credenciales; es necesario auditar el propio tenant.
Para mitigar futuros riesgos, adopte el principio de mínimo privilegio en las asignaciones de permisos de las aplicaciones de terceros. Evite otorgar permisos Application (de nivel cliente) cuando Delegated (de nivel usuario) es suficiente, y limite quién puede asignar roles de Cloud Application Administrator.
Conclusión
El incidente de ConnectWise ilustra la fragilidad inherente a las arquitecturas que dependen de secretos compartidos para la identidad de aplicaciones en la nube. La suspensión de Cloud Backup es una medida reactiva necesaria, pero la verdadera seguridad reside en la proactividad de los clientes para monitorizar sus propios tenants. La capacidad de los atacantes para establecer persistencia mediante la creación de nuevos secretos dentro de Azure AD exige una revisión manual de las aplicaciones registradas y una implementación estricta de controles de acceso condicional para identidades de máquina. La confianza en el proveedor no elimina la responsabilidad del cliente de verificar la integridad de su entorno de identidad.
Fuentes
https://thehackernews.com/2026/10/connectwise-suspends-cloud-backup-after.html
https://therecord.media/