ConnectWise informó que detectó actividad el 14 de octubre y confirmó actividad maliciosa el día 15. A las 07:00 UTC del 17 de octubre deshabilitó siete identidades de aplicación vinculadas a Cloud Backup, anteriormente SkyKick, y suspendió Cloud Backup, SaaS Security y Cloud Management mientras investiga y remedia el incidente.

Qué está confirmado

Según el aviso oficial, un actor no autorizado obtuvo acceso a credenciales asociadas con identidades de aplicación de Cloud Backup. Esas identidades contaban con autorización previa en tenants de Microsoft 365 administrados por socios y clientes. Al deshabilitarlas, ConnectWise bloqueó nuevas autenticaciones a través de esas rutas.

La empresa afirma que los archivos de respaldo existentes permanecen cifrados y aislados, y que no encontró evidencia de acceso a esos archivos. Sin embargo, durante la suspensión no se ejecutan respaldos programados y el acceso o restauración de archivos archivados puede no estar disponible.

La escala observada: casi 1.000 tenants con actividad

Huntress informó que identificó casi 1.000 tenants de Microsoft Entra con actividad de inicio de sesión desde una dirección IP vinculada al atacante y más de 300 autenticaciones exitosas. La compañía advierte que algunos eventos exitosos pueden producirse incluso cuando el service principal correspondiente no está presente, por lo que esas cifras no equivalen automáticamente a 300 compromisos confirmados.

En cerca de 50 tenants monitorizados, las aplicaciones afectadas tenían roles de directorio asignados, principalmente Exchange Administrator. En un caso, Huntress observó que el actor agregó Global Administrator y creó secretos de cliente en otras aplicaciones. Esa conducta importa porque puede establecer rutas de persistencia que sobrevivan al bloqueo de la integración original.

Por qué este incidente trasciende a ConnectWise

El modelo MSP multiplica la eficiencia operativa, pero también el radio de impacto. Una aplicación central puede gestionar correo, Teams, SharePoint, identidades y respaldos para muchas empresas. Si su credencial se compromete, el atacante hereda una ruta autorizada que puede parecer tráfico normal y que no depende de vulnerar cada cliente por separado.

Este caso también demuestra que MFA para usuarios humanos no basta. Los service principals y las identidades de carga de trabajo requieren inventario, mínimo privilegio, credenciales de corta duración, alertas por cambios de rol y revisión continua de consentimiento. Una integración olvidada puede conservar permisos mucho después de que cambie su necesidad empresarial.

Lo que todavía no se sabe

ConnectWise no ha establecido públicamente cómo quedaron expuestas originalmente las credenciales y continúa investigando. Tampoco puede determinar desde su plataforma si cada tenant posterior fue comprometido. Esa respuesta depende de los registros y cambios observados dentro de cada entorno de cliente.

Por eso es incorrecto presentar todas las autenticaciones como intrusiones confirmadas o afirmar que todos los datos de Microsoft 365 fueron extraídos. La evidencia pública sí justifica una investigación urgente: existió una ruta de acceso válida, hubo actividad a escala y se observaron acciones de privilegio y persistencia en al menos algunos entornos monitorizados.

Recomendaciones para MSP y organizaciones afectadas

1. Usar la lista oficial actualizada. Comparar los identificadores de aplicación publicados por ConnectWise con los service principals presentes en el tenant y no depender de listas copiadas de terceros.
2. Preservar evidencia antes de limpiar. Exportar registros de inicio de sesión, auditoría, consentimiento, Exchange, Teams, SharePoint y Microsoft Graph dentro de la retención disponible.
3. Revocar sesiones y credenciales. Deshabilitar las aplicaciones indicadas, revocar tokens, rotar secretos o certificados y revisar credenciales federadas relacionadas.
4. Buscar persistencia. Examinar nuevos propietarios de aplicaciones, secretos agregados, service principals creados, permisos OAuth, asignaciones de roles y cambios en políticas.
5. Revisar privilegios efectivos. Confirmar qué roles y permisos tenía cada identidad en cada tenant; una autenticación exitosa sin permisos no tiene el mismo impacto que Exchange Administrator o Global Administrator.
6. Investigar el uso de servicios. Correlacionar la actividad con Exchange Online, Teams, SharePoint y Graph para distinguir autenticación, acceso y posible extracción.
7. Extender la búsqueda. Si el actor añadió credenciales a otras aplicaciones, bloquear solo los IDs de ConnectWise no es suficiente.
8. Evaluar a cada cliente por separado. Un MSP debe comunicar hallazgos y exposición tenant por tenant, sin convertir la ausencia de evidencia central en garantía de seguridad.
9. Controlar la continuidad de respaldos. Verificar qué ventanas quedaron sin copia, priorizar cargas críticas y validar integridad antes de reanudar restauraciones.
10. Reducir confianza permanente. Aplicar mínimo privilegio, revisiones de consentimiento, credenciales de corta duración y alertas ante nuevos secretos o roles privilegiados.

Conclusión

La cadena de suministro de la nube no siempre se rompe mediante una vulnerabilidad de software. También puede fallar cuando una identidad confiable se convierte en el atacante. El incidente de ConnectWise obliga a mirar más allá del proveedor: cada tenant debe demostrar, con sus propios registros, si la ruta fue usada, qué permisos existían y si quedaron mecanismos de persistencia.

La respuesta correcta no es asumir compromiso masivo ni confiar en que deshabilitar siete aplicaciones resolvió todo. Es separar autenticación de acceso, preservar evidencia y reconstruir la confianza identidad por identidad.

ConnectWise said it detected activity on October 14 and confirmed malicious activity on October 15. At 07:00 UTC on October 17, it disabled seven application identities associated with Cloud Backup, formerly SkyKick, and suspended Cloud Backup, SaaS Security and Cloud Management while investigating and remediating the incident.

What is confirmed

According to the official advisory, an unauthorized actor gained access to credentials associated with Cloud Backup application identities. Those identities had been previously authorized in Microsoft 365 tenants managed by partners and customers. Disabling them blocked new authentication through those routes.

The company says existing backup archives remain encrypted and isolated, with no evidence that the archives were accessed. During the suspension, however, scheduled backups are not running and access to or restoration of archived files may be unavailable.

Observed scale: activity across almost 1,000 tenants

Huntress said it identified almost 1,000 Microsoft Entra tenants with sign-in activity from an attacker-linked IP address and more than 300 successful authentications. The company cautions that successful events can sometimes occur even when the corresponding service principal is absent, so these numbers do not automatically equal 300 confirmed compromises.

Across roughly 50 monitored tenants, affected applications had directory roles assigned, most often Exchange Administrator. In one tenant, Huntress observed the actor adding Global Administrator and creating client secrets in other applications. That behavior matters because it can establish persistence paths that survive the original integration being blocked.

Why this incident reaches beyond ConnectWise

The MSP model multiplies operational efficiency, but also the blast radius. A central application may manage email, Teams, SharePoint, identity and backups for many companies. If its credential is compromised, an attacker inherits an authorized route that can resemble normal traffic and does not require breaching every customer separately.

The case also shows why MFA for human users is not enough. Service principals and workload identities need inventory, least privilege, short-lived credentials, alerts for role changes and continuous consent review. A forgotten integration can retain access long after its business need has changed.

What remains unknown

ConnectWise has not publicly established how the credentials were originally exposed and its investigation continues. It also cannot determine from its platform whether every downstream tenant was compromised. That answer depends on logs and changes recorded inside each customer environment.

It would therefore be inaccurate to present every authentication as a confirmed intrusion or claim that all Microsoft 365 data was extracted. The public evidence does justify urgent investigation: a valid access route existed, activity occurred at scale, and privilege and persistence actions were observed in at least some monitored environments.

Recommendations for MSPs and affected organizations

1. Use the current official list. Compare the application identifiers published by ConnectWise with service principals in the tenant; do not rely on copied third-party lists.
2. Preserve evidence before cleanup. Export sign-in, audit, consent, Exchange, Teams, SharePoint and Microsoft Graph logs within the available retention window.
3. Revoke sessions and credentials. Disable the indicated applications, revoke tokens, rotate secrets or certificates and review related federated credentials.
4. Hunt for persistence. Examine new application owners, added secrets, created service principals, OAuth grants, role assignments and policy changes.
5. Review effective privileges. Establish which roles and permissions each identity held in every tenant; successful authentication without permissions differs materially from Exchange or Global Administrator access.
6. Investigate service usage. Correlate activity across Exchange Online, Teams, SharePoint and Graph to distinguish authentication, access and possible extraction.
7. Expand the hunt. If the actor added credentials to other applications, blocking only the ConnectWise IDs is insufficient.
8. Assess every customer separately. MSPs should communicate findings and exposure tenant by tenant, without treating the absence of central evidence as proof of safety.
9. Manage backup continuity. Identify missed backup windows, prioritize critical workloads and validate integrity before restoring normal operations.
10. Reduce standing trust. Enforce least privilege, consent reviews, short-lived credentials and alerts for new secrets or privileged roles.

Conclusion

The cloud supply chain does not always fail through a software vulnerability. It can also fail when a trusted identity becomes the attacker. The ConnectWise incident requires organizations to look beyond the vendor: each tenant must prove from its own logs whether the route was used, which permissions existed and whether persistence remains.

The right response is neither to assume mass compromise nor to trust that disabling seven applications solved everything. It is to separate authentication from access, preserve evidence and rebuild trust identity by identity.