Los atacantes usaron la identidad de aplicación de ConnectWise Cloud Backup para entrar en inquilinos de Microsoft 365
Un atacante usó la identidad de ConnectWise Cloud Backup para entrar en al menos 162 inquilinos de Microsoft 365 sin MFA. El servicio se cerró el 17 de octubre.

En esta página
Puntos clave
- Un atacante usó la identidad de aplicación de ConnectWise Cloud Backup para obtener tokens de Microsoft Graph en inquilinos de Microsoft 365 de clientes entre las 06:13 y las 08:34 UTC del 15 de octubre de 2026.
- Huntress confirmó inicios de sesión no autorizados en al menos 162 inquilinos; un resumen posterior elevó la cifra a 173, y ambos números son mínimos y no recuentos finales.
- El MFA no aplicaba porque el acceso usó una entidad de servicio preautorizada, no un inicio de sesión de usuario, y esa aplicación ya tenía permisos amplios sobre correo, archivos y Teams.
- ConnectWise desactivó siete identidades de aplicación el 17 de octubre y mantuvo Cloud Backup fuera de línea; dijo que hasta ahora no tenía indicios de que los datos de copia de seguridad de los socios se hubieran visto comprometidos.
- ConnectWise advirtió de que los tokens ya emitidos pueden seguir siendo válidos hasta que caduquen, y de que las credenciales o permisos creados mediante identidades separadas necesitan una revisión aparte.
ConnectWise cerró su servicio Cloud Backup el 17 de octubre de 2026 después de que un atacante usara la identidad de aplicación del propio producto para entrar en inquilinos de Microsoft 365 de clientes y obtener tokens de Microsoft Graph. No intervino ninguna contraseña de usuario y no apareció ningún aviso de multifactor. Huntress informó primero de la actividad; SpecterOps y BleepingComputer publicaron sus versiones el 17 de octubre.
Lectura relacionada: Los atacantes colaron un backdoor por los propios servidores de actualización de AOMEI Backupper · El HEIF Heist de Hacktron: una biblioteca de imágenes sin parche abrió la puerta al monorepo de OpenAI.
Los inicios de sesión se produjeron entre las 06:13 y las 08:34 UTC del 15 de octubre, todos desde 144.172.64.128, una dirección de un proveedor de alojamiento. Saltaban de un inquilino a otro con pocos segundos de diferencia, un patrón que SpecterOps describe como compatible con un script que trabaja sobre una lista de objetivos. El 13 y el 14 de octubre la misma dirección había intentado inicios de sesión automatizados con identificadores de aplicaciones cliente de otras herramientas, usando el agente de usuario curl/7.88.1. Huntress y BleepingComputer registraron ese sondeo previo. La identidad de Cloud Backup no fue la primera que se probó. Dos días de intentos contra otras aplicaciones hacen que la ventana exitosa parezca el final de una búsqueda y no un acierto por suerte.
Huntress confirmó inicios de sesión no autorizados en al menos 162 inquilinos cuando BleepingComputer publicó su información. SpecterOps usa la misma cifra. Un resumen semanal posterior elevó el recuento a 173, lo que sugiere que seguía subiendo mientras salían los primeros informes. Cualquiera de las dos cifras debe tratarse como un mínimo.
La aplicación hizo el trabajo de una contraseña
Una entidad de servicio (service principal) es la forma en que el software inicia sesión en Microsoft Entra ID. Un administrador le concede permisos una vez y, a partir de ahí, presenta un secreto o un certificado. No hay una persona ante el teclado a la que plantear un desafío, así que el MFA no tiene sobre qué actuar. No es un fallo del MFA. Es otra vía de autenticación, y fue la que se usó aquí.
Cloud Backup tiene una de esas identidades en cada inquilino de cliente, con derechos lo bastante amplios para hacer su trabajo: leer buzones, archivos de OneDrive y SharePoint y chats de Teams, y copiarlos a otro sitio. Todyl, cuyo análisis cita BleepingComputer, dijo que la aplicación preautorizada podía leer y escribir correo y adjuntos, archivos y mensajes de chat. Un token robado heredaba todo eso.
El lado del cliente en ese acuerdo es una pantalla de consentimiento. Un administrador aprueba la aplicación una vez, y la credencial que demuestra la identidad de la aplicación se queda con el proveedor. El inquilino obtiene un servicio de copia de seguridad que funciona y renuncia al control directo de la llave.
Los permisos eran amplios por diseño. Cuánto de ese alcance usó el atacante es otra pregunta. Microsoft confirmó los intentos de autenticación maliciosos desde esa dirección el 15 de octubre y describió el incidente como un ataque de cadena de suministro activo. Su equipo de inteligencia de amenazas evaluó que el atacante probablemente abusó de permisos existentes, incluido Directory.ReadWrite.All, y observó reconocimiento de la API Graph e intentos de añadir credenciales.
Lo que Huntress encontró dentro de los inquilinos
Huntress miró más allá de los registros de inicio de sesión. Informó de que las entidades de servicio de ConnectWise Cloud Management que cubren Exchange Online, Teams y Microsoft Graph se asignaron roles de directorio en casi 50 de los inquilinos que supervisa. La mayoría de esos roles eran Exchange Administrator.
En un inquilino, el atacante alcanzó persistencia en unos cinco minutos. La aplicación Cloud Management – MS Teams se autoconcedió Global Administrator y luego añadió credenciales a una herramienta de gestión para MSP y a la propia aplicación de Huntress. Añadir una credencial a una aplicación existente da al intruso una vía de vuelta que sobrevive a un restablecimiento de contraseña, a una revocación de sesiones o a la caducidad del token que abrió la puerta.
La muestra de Todyl es distinta. Examinó nueve intrusiones y encontró solo actividad de inicio de sesión, sin pruebas de que el actor creara cuentas, cambiara contraseñas, añadiera permisos o estableciera persistencia a través de la aplicación de copia de seguridad en esas nueve. Ambas versiones pueden sostenerse. La gravedad varió según el inquilino, y también lo que hizo el intruso una vez dentro.
Siete identidades, un interruptor
ConnectWise anunció la interrupción del servicio a las 05:01 UTC del 17 de octubre. Su aviso decía que la empresa había identificado «acceso no autorizado a identidades de aplicación dentro del entorno de ConnectWise Cloud Backup» y había cortado el acceso de aplicaciones para socios y clientes. The Hacker News informó el 18 de octubre de que la suspensión había dejado fuera de servicio el producto de copia de seguridad mientras la empresa investigaba.
Ese mismo día desactivó siete identidades de aplicación:
- Cloud Backup:
506e08f9-6e9a-4da4-942b-a099a03644ae - Cloud Management:
2399d300-6fca-4e6a-a686-399fefe75b83 - Cloud Management – MS Teams:
24205314-2b89-4e07-a2a4-579e898a5640 - Cloud Management – Exchange Online:
b78f6a77-d4e5-46fb-87e5-d1648bd02519 - Cloud Management – MS Graph:
0de14c77-b9b0-4137-9360-34878a929827 - Cloud Management – Partner Center:
412dcf96-176d-4b3a-a1b0-4981ad66971e - Cloud Management – SharePoint Online:
b2b55f5b-7758-4719-8d8f-88ae172e6bdb
Esos identificadores son la parte práctica de la historia para cualquiera que revise registros. Un inicio de sesión de entidad de servicio que nombre uno de ellos, desde una dirección que el inquilino no reconoce, es el evento que hay que buscar. Una de las identidades de la lista cubre Partner Center, el portal que los socios de Microsoft usan para gestionar cuentas de clientes, así que la respuesta fue más allá del propio producto de copia de seguridad.
ConnectWise dijo que no tenía «indicios hasta la fecha de que los datos de copia de seguridad de los socios de Cloud Backup se hayan visto comprometidos». Los archivos existentes están cifrados y aislados, según la empresa, y serían accesibles una vez restaurado el servicio. Una actualización de las 01:00 UTC del 18 de octubre indicaba que Cloud Backup seguía caído, que las copias programadas no se ejecutaban y que los archivos y la capacidad de restauración no estaban disponibles. SaaS Security y Cloud Management estaban desconectados como precaución. ConnectWise añadió que el apagado no debía interpretarse como prueba de que el entorno de un socio o cliente se hubiera visto comprometido.
Lo que no arregla revocar una aplicación
Desactivar la identidad de una aplicación impide que se emitan tokens nuevos. No cancela los tokens que ya están en manos de alguien. ConnectWise dijo que los tokens de acceso emitidos antes podían seguir siendo utilizables hasta que caducaran o se invalidaran, y que las credenciales, permisos o accesos establecidos mediante identidades separadas necesitan su propia revisión. Todyl señaló lo mismo: revocar sesiones de usuario no termina con el acceso basado en aplicaciones.
La aplicación está apagada; el token puede que no
Una entidad de servicio desactivada no es una sesión cerrada. Los tokens emitidos antes del 17 de octubre pueden seguir siendo válidos hasta que caduquen, y cualquier credencial que el atacante haya añadido a otra aplicación queda por completo fuera del apagado de ConnectWise. Revise las credenciales añadidas a aplicaciones y las concesiones OAuth, y no se fíe solo de la página de estado del proveedor.
Las comprobaciones recomendadas por Microsoft incluyen los registros de inicio de sesión de entidades de servicio filtrados por el identificador de la aplicación Cloud Backup y por direcciones de origen inesperadas, y después por cambios en credenciales de aplicaciones, concesiones OAuth y actividad relacionada de Graph. Esa guía apunta a un hueco de visibilidad: la vista habitual de inicios de sesión de usuario no muestra este tráfico, porque no inició sesión ningún usuario.
Huntress recomienda desactivar las aplicaciones de ConnectWise implicadas y revisar las integraciones de Cloud Management. Los inquilinos que han usado el producto desde antes del cambio de marca pueden seguir viéndolo como «SkyKick Cloud Manager», un nombre antiguo en una pantalla de consentimiento que oculta un riesgo actual.
Los proveedores de servicios gestionados usan Cloud Backup, antes SkyKick Cloud Backup, para proteger los buzones, OneDrive, SharePoint y Teams de sus clientes. Eso es el producto funcionando como debe, y es la razón por la que una sola intrusión llegó a tantas organizaciones. Una identidad de proveedor, presente en muchos inquilinos, entrega a quien la robe una llave que abre todas las puertas a la vez. Un MSP no necesita ser descuidado para quedar expuesto; basta con ser cliente de la herramienta.
La misma lógica vale para cada integración que instala un MSP. Las herramientas de copia de seguridad, documentación, PSA y monitorización remota suelen pedir acceso amplio y de larga duración. Cada una es una entidad de servicio con una credencial en algún sitio. Pocas organizaciones pueden enumerarlas de memoria, y menos aún alertan sobre sus inicios de sesión.
Alguien tiene que listar las entidades de servicio de cada inquilino, asignar un responsable a cada una y poner sus inicios de sesión delante de una persona que note una dirección inusual. La identidad de una aplicación es una cuenta privilegiada, así que debería revisarse como tal.
Advertencias
Los recuentos no están cerrados. Huntress confirmó al menos 162 inquilinos; la cifra de 173 procede de un resumen posterior. Ambas son mínimos construidos a partir de lo que los investigadores pudieron ver, y ninguna es un recuento final. Se desconoce el alcance de cualquier robo de datos.
Ningún atacante ha sido identificado públicamente. Se desconoce el método de acceso inicial, y ConnectWise no ha dicho cómo se obtuvo la credencial del proveedor. Especular sobre cualquiera de las dos cosas es adivinar en esta fase.
La afirmación de ConnectWise de que no tiene indicios de compromiso de los datos de copia de seguridad es de la propia empresa, emitida mientras su investigación continúa. Ninguna parte externa la ha confirmado.
Lo que está realmente establecido
Un atacante usó la identidad de aplicación de ConnectWise para obtener tokens de Graph en inquilinos de Microsoft 365 el 15 de octubre. El MFA no aplicaba porque no inició sesión ningún usuario. ConnectWise desactivó siete identidades de aplicación el 17 de octubre y mantuvo Cloud Backup fuera de línea. Los recuentos de víctimas, la pérdida de datos y la atribución siguen abiertos.
«acceso no autorizado a identidades de aplicación dentro del entorno de ConnectWise Cloud Backup» — ConnectWise, aviso de confianza, 17 de octubre de 2026
Qué observar
El calendario de restauración es el primer punto abierto. ConnectWise no ha dado ninguno, y hasta que lo haga los socios operan sin copias programadas y sin acceso de restauración. Es un riesgo de negocio distinto de la intrusión, y crece con cada día que el servicio sigue caído.
El segundo es la divulgación. Microsoft ha confirmado los intentos de autenticación pero no un recuento propio de inquilinos. ConnectWise ha confirmado las identidades desactivadas y no el camino que llevó a ellas. Cualquiera de las dos empresas podría completar la secuencia, y ninguna lo ha hecho.
El tercero es lo que encuentran los socios cuando miran. Los tokens emitidos antes del apagado caducan según su propio calendario, y las credenciales añadidas a otras aplicaciones no aparecerán en un aviso de ConnectWise. Las organizaciones que respondan bien a esto serán las que ya tenían un inventario de sus entidades de servicio. El resto estará construyendo uno ahora.
Imagen de portada: centro de datos de Microsoft en Middenmeer, Países Bajos, por Hay Kranen, CC BY 4.0, vía Wikimedia Commons. La foto muestra infraestructura de nube de Microsoft, no una instalación de ConnectWise.
Etiquetas
Preguntas frecuentes
- ¿Cómo entraron los atacantes en los inquilinos de Microsoft 365 a través de ConnectWise?
- Usaron la identidad de la propia aplicación ConnectWise Cloud Backup, una entidad de servicio registrada en los inquilinos de los clientes, para obtener tokens de Microsoft Graph. Como el acceso venía de una aplicación preautorizada y no de un inicio de sesión de usuario, no intervino ninguna contraseña ni ningún aviso de multifactor.
- ¿Se eludió el MFA en el ataque a ConnectWise Cloud Backup?
- El MFA no aplicaba porque no inició sesión ningún usuario. El atacante se autenticó como aplicación, y las identidades de aplicación presentan un secreto o un certificado en lugar de un desafío al usuario, así que no se activó ningún aviso.
- ¿Cuántos inquilinos de Microsoft 365 se vieron afectados?
- Huntress confirmó inicios de sesión no autorizados en al menos 162 inquilinos cuando BleepingComputer publicó su información, y SpecterOps cita la misma cifra. Un resumen semanal posterior habló de 173. Ambas son mínimos basados en lo que los investigadores pudieron observar.
- ¿Qué deben revisar los clientes de ConnectWise Cloud Backup?
- Revisar los registros de inicio de sesión de entidades de servicio en busca de los siete identificadores de aplicación desactivados y de direcciones de origen inesperadas, y después comprobar las credenciales añadidas a aplicaciones y las concesiones OAuth. Los tokens emitidos antes del 17 de octubre pueden seguir siendo válidos hasta que caduquen, así que desactivar la aplicación no pone fin a la limpieza.








