ConnectWise suspendió su servicio Cloud Backup después de que atacantes desconocidos obtuvieran acceso no autorizado a sus identidades de aplicación y las usaran para entrar en tenants de Microsoft 365.
La empresa indicó que detectó el problema el 14 de octubre de 2026 mediante su monitorización de seguridad e inició una investigación. Según la cuenta de ConnectWise recogida por The Hacker News, desactivó siete identidades de aplicación y revocó los certificados que respaldaban las conexiones afectadas a las 07:00 UTC del 17 de octubre.
Otro informe indica que ConnectWise anunció la interrupción de Cloud Backup a las 05:01 UTC del 17 de octubre. Estas horas corresponden, respectivamente, a la acción de mitigación informada y al anuncio del servicio, y no deben tratarse como una única marca temporal.
El cierre impide nuevas autenticaciones a través de las conexiones afectadas, pero no elimina las credenciales, los permisos ni otros mecanismos de persistencia que los atacantes puedan haber creado ya dentro de los tenants de los clientes.
Servicios de copia de seguridad y gestión desconectados
Cloud Backup, antes SkyKick Cloud Backup, ofrece copia de seguridad y recuperación para Microsoft 365 y Google Workspace. ConnectWise también desconectó temporalmente SaaS Security y Cloud Management mientras revisa el incidente.
Las copias de seguridad programadas no se están ejecutando, y los clientes no pueden usar actualmente los archivos de copia afectados ni las funciones de restauración. ConnectWise indica que los archivos existentes siguen cifrados, aislados y conservados. La empresa no ha informado de ninguna evidencia de que se haya accedido a las copias almacenadas ni a los datos de copia de los socios, ni de que hayan sido comprometidos.
ConnectWise indicó que las credenciales compartidas de Cloud Backup implicadas en el incidente ya no son válidas. Sin embargo, los tokens de acceso emitidos antes de la revocación pueden seguir siendo utilizables hasta que caduquen o se invaliden por separado. Desactivar la conexión original tampoco neutraliza las credenciales ni los permisos creados a través de otras identidades de aplicación.
La empresa enumeró estas siete identidades desactivadas:
| Nombre de la aplicación | ID de aplicación (cliente) |
|---|---|
| ConnectWise Cloud Backup | 506e08f9-6e9a-4da4-942b-a099a03644ae |
| ConnectWise Cloud Management | 2399d300-6fca-4e6a-a686-399fefe75b83 |
| ConnectWise Cloud Management - MS Teams | 24205314-2b89-4e07-a2a4-579e898a5640 |
| ConnectWise Cloud Management - Exchange Online | b78f6a77-d4e5-46fb-87e5-d1648bd02519 |
| ConnectWise Cloud Management - MS Graph | 0de14c77-b9b0-4137-9360-34878a929827 |
| ConnectWise Cloud Management - Partner Center | 412dcf96-176d-4b3a-a1b0-4981ad66971e |
| ConnectWise Cloud Management - SharePoint Online | b2b55f5b-7758-4719-8d8f-88ae172e6bdb |
En tenants antiguos, algunas aplicaciones de Cloud Management pueden aparecer con el nombre SkyKick Cloud Manager.
ConnectWise no ha determinado si una vulnerabilidad en alguno de sus productos contribuyó al compromiso. El mecanismo por el que quedaron expuestas las credenciales de aplicación sigue bajo investigación.
Las credenciales de aplicación eludieron la autenticación de usuario
El ataque no requirió la contraseña de ningún usuario de Microsoft 365. Los investigadores afirmaron que el actor se autenticó como la aplicación de copia de seguridad presentando su secreto ante Microsoft Entra ID y solicitando tokens con permisos que los clientes ya habían concedido.
Como se trataba de una autenticación basada en aplicación y no de un inicio de sesión interactivo de usuario, el MFA de usuario no se aplicaba. Revocar las sesiones de usuario no bastaría, por sí solo, para cortar el acceso de la aplicación.
Esos permisos existentes eran amplios. Todyl indicó que la aplicación podía técnicamente leer y escribir correos y adjuntos, archivos de OneDrive y SharePoint, y chats de Teams. Eso describe lo que permitía la autorización, no una prueba de que se hubiera accedido a todos esos tipos de datos.
Los permisos de gestión más amplios también crearon vías para la persistencia. Huntress observó que entidades de servicio (service principals) asociadas a ConnectWise Cloud Management se asignaban roles de directorio a sí mismas en casi 50 tenants monitorizados, siendo lo más habitual el rol Exchange Administrator. En un tenant, la entidad de servicio Cloud Management - MS Teams se asignó a sí misma el rol Global Administrator y añadió credenciales a una aplicación de gestión de un MSP y a la propia aplicación de Huntress. Huntress afirmó que la secuencia duró unos cinco minutos.
Microsoft, según BleepingComputer, calificó la operación como un ataque activo a la cadena de suministro y consideró probable que el actor hubiera abusado de permisos existentes, incluido Directory.ReadWrite.All. Según se informa, Microsoft observó una puerta trasera tras una autenticación exitosa de una entidad de servicio, seguida de reconocimiento de Microsoft Graph e intentos de añadir credenciales.
La actividad de inicio de sesión y el compromiso confirmado son medidas distintas
Huntress encontró actividad de inicio de sesión desde la dirección IP del atacante en casi 1.000 tenants de Entra. De esos inicios de sesión, 300 tuvieron éxito, pero una autenticación exitosa no siempre daba acceso al tenant: en algunos casos, no estaba presente la entidad de servicio requerida.
En el propio entorno de Huntress, los investigadores identificaron al menos 162 tenants comprometidos. Esa cifra es distinta de los casi 1.000 tenants con actividad de inicio de sesión y de los 300 inicios de sesión exitosos.
Otros hallazgos se refieren a muestras más reducidas:
- Todyl examinó nueve tenants y solo encontró actividad de inicio de sesión. No identificó creación de cuentas, cambios de permisos o contraseñas, ni persistencia a través de la aplicación de copia de seguridad en esos tenants.
- Huntress confirmó el abuso de la aplicación de Teams en un tenant.
- Casi 50 tenants monitorizados por Huntress mostraron autoasignación de roles de directorio con entidades de servicio de ConnectWise Cloud Management.
- Una segunda oleada dirigida seleccionó 16 tenants de los sectores de políticas públicas, seguridad nacional, comercio y minerales críticos, aunque Huntress afirmó que esos intentos fracasaron.
Huntress vinculó los intentos automatizados con curl/7.88.1 con el 13 y el 14 de octubre de 2026. ConnectWise detectó el problema más amplio el 14 de octubre.
El 15 de octubre, Huntress registró el último inicio de sesión malicioso desde la dirección original a las 08:45 UTC. Un barrido posterior dirigido a tokens de Graph asociados a la aplicación SkyKick se ejecutó entre las 09:25:04 y las 12:35:50 UTC. Un segundo barrido, aparentemente manual, contra los mismos 16 tenants se produjo entre las 13:54:39 y las 14:20:24 UTC, dirigido a Exchange Online, SharePoint Online, Teams, Azure Resource Manager, Entra y las API de Office 365 Management.
Huntress afirmó no haber identificado nueva actividad maliciosa después del 15 de octubre. ConnectWise afirmó asimismo que no había observado actividad exitosa en los entornos que monitoriza desde la aplicación de sus medidas, aunque advirtió que no puede observar directamente los entornos de los clientes finales.
Indicadores y comprobaciones en los tenants
El principal indicador de red es:
- Dirección IP:
144.172.64[.]128
Los user agents asociados a la actividad incluyen:
python-urllib/3.12python-requests/2.31python-requests/2.34.2curl/7.88.1
Los socios de ConnectWise deben revisar tanto sus propios entornos de Microsoft 365 como cada tenant de cliente gestionado, incluidas las conexiones SkyKick inactivas. Las comprobaciones recomendadas incluyen:
- Busque en los inicios de sesión de entidades de servicio de Entra los siete ID de aplicación y direcciones de origen inesperadas, en particular
144.172.64[.]128. - Revise los inicios de sesión de todas las identidades desde el 13 de octubre de 2026 en adelante.
- Conserve los registros de inicio de sesión y de auditoría antes de que las acciones de contención alteren las pruebas disponibles.
- Inspeccione las credenciales, secretos y certificados de aplicaciones por si hay adiciones no autorizadas realizadas desde el 13 de octubre.
- Revise las concesiones de consentimiento OAuth, los roles de directorio, los propietarios de aplicaciones, las relaciones de confianza de federación y los cambios recientes de políticas.
- Busque credenciales añadidas recientemente en otras aplicaciones de confianza, no solo en la identidad original de ConnectWise.
- Compruebe en Exchange si hay reenvíos no autorizados, reglas de bandeja de entrada o de transporte, y accesos delegados a buzones.
- Revise otras integraciones de Cloud Management e investigue las identidades modificadas o usadas durante la actividad sospechosa.
Huntress también recomienda restringir quién tiene Application Administrator y Cloud Application Administrator, usar políticas de gestión de aplicaciones para limitar los secretos de cliente y la duración de las credenciales, y aplicar Acceso condicional para identidades de carga de trabajo cuando lo permitan las licencias. Microsoft Entra ID Protection también puede identificar entidades de servicio de riesgo.
Estos controles no sustituyen la revisión de credenciales. La revocación de ConnectWise detiene la nueva autenticación a través de las conexiones afectadas, pero cada tenant debe determinar si el atacante creó una vía independiente que sobreviva a la eliminación de la credencial original.
