ConnectWise shuts off Cloud Backup access after credential abuse reaches Microsoft 365 tenants

October 17 shutdown adds operational disruption

ConnectWise announced at 05:01 UTC on October 17 that it was shutting off Cloud Backup application access, interrupting backups until further notice. The updated advisory acknowledged unauthorized access to application identities, following an initial investigation notice published at 17:47 UTC on October 16. The development affects customers using ConnectWise Cloud Backup, formerly SkyKick, with Microsoft 365, and managed service providers responsible for those integrations. [1][4]

Huntress observed the Cloud Backup identity obtaining Microsoft Graph tokens from 144.172.64[.]128 between 06:13 and 08:34 UTC on October 15. By its October 16, 19:00 UTC cutoff, it had confirmed unauthorized sign-ins in 162 tenants. The Hacker News subsequently reported 173, attributing that figure to Huntress. The defensible summary is at least 162 confirmed, with 173 subsequently reported: the published primary account does not reconcile the figures, and neither measures affected people or records. [2][3]

An approved application can carry access across customers

The exposure concerns an application identity rather than an ordinary employee account. Administrators approve a backup application's permissions to customer resources. Someone authenticating as that application can inherit its existing access, potentially reaching email, SharePoint and Teams data. Human-user multifactor authentication does not protect this app-only authentication flow. The incident notices do not identify a CVE or vulnerable-version patch matrix, and this should not be treated as a newly discovered Microsoft 365 software flaw. [1][4]

Managed service providers can deploy the integration across multiple customers, increasing the reach of a supplier credential compromise. But an installed application establishes potential exposure, not a confirmed intrusion. Coalition's account distinguishes precautionary customer identification and outreach from proof of compromise. The practical inference is that providers must check permissions and activity separately in each managed tenant rather than classify every installation as breached. [4]

Separate observations corroborate activity, not the final count

The evidence comes from sources with different visibility. ConnectWise provides the vendor acknowledgment and shutdown decision; Huntress supplies time-stamped authentication findings. Guardz reports its own observation of connection attempts and its operational response. That is separate primary evidence of suspicious activity, but it does not independently validate the reported 173-tenant total or establish widespread data theft. [1][2][6]

The Hacker News is a separate publisher, but its tenant count and underlying incident claims are attributed to investigators and the vendor. Its report therefore should not be counted as a second independent measurement. Coalition adds a firsthand response account and an explanation of the access model, rather than another verified victim total. Together, the sources support the incident's reality while leaving its ultimate scope unsettled. [3][4]

Additional credential changes broaden the investigation

Huntress also described a Cloud Management–MS Teams application granting itself Global Administrator and adding credentials to a partner-specific Huntress application. This concerns an application inside that partner's tenant, not evidence of a breach of Huntress's entire platform. The response implication is broader than rotating or disabling the originally abused Cloud Backup credential: investigators must look for other application credentials and privilege changes. [5][6]

The relationship between these events remains unresolved. Huntress has not conclusively linked the earlier privilege and credential changes to the operator behind the later public-IP authentications. Other role changes across approximately 50 tenants may reflect vendor automation, pending confirmation. A private Azure IPv6 address associated with the secondary activity is not attribution evidence on its own: Huntress says legitimate ConnectWise and unrelated customer traffic also appear from that range. [2][5]

Unauthorized sign-ins do not establish data theft

Unauthorized authentication is established, but widespread exfiltration is not. Huntress found no visible mail or file access in the tenant audit it examined closely. It also cautioned that logging gaps prevent interpreting that absence as proof that nothing was taken. That finding cannot establish the outcome for every affected tenant. [2]

ConnectWise says it has no indicators that partner backup data was compromised and that existing archives were unaffected by the interruption. That assurance addresses stored backups. The inference from the vendor statement and the application-permission model is narrower than a general all-clear: unaffected archives do not resolve whether the abused identity accessed live information in customers' Microsoft 365 environments. [1][4]

Disable implicated identities and preserve tenant evidence

Guardz recommends disabling, rather than initially deleting, the relevant enterprise applications until ConnectWise confirms credential remediation. The application IDs are 506e08f9-6e9a-4da4-942b-a099a03644ae for Cloud Backup and 24205314-2b89-4e07-a2a4-579e898a5640 for Cloud Management–MS Teams. Microsoft documents that setting “Enabled for users to sign-in?” to No disables the tenant-local service principal and prevents new token issuance. This is containment, not evidence that cleanup is complete. [6][7]

ConnectWise directs administrators to Service principal sign-ins, filtering by the Cloud Backup application ID and investigating 144.172.64[.]128 and unexpected origins. The default user-sign-in view misses this evidence. Guardz recommends exporting sign-in and audit logs from October 13 onward, checking unauthorized directory roles, new application credentials and permission changes, and examining Microsoft Graph activity logs where available. [6][8]

Customers should not assume other controls close the gap. Microsoft's workload-identity Conditional Access does not cover third-party multitenant SaaS applications, so it is not a customer-side fix for this integration. Token lifetimes also vary: the common 60–90-minute default is not a universal guarantee that access ends within 90 minutes. Investigators therefore need to assess remaining access paths rather than stop at disablement. [6][7][9]

Watch restoration, credential remediation and revised scope

ConnectWise's status page lists Cloud Backup as affected across all regions and says archives will be accessible once services return. It provides no restoration time. Organizations should assess the consequences of missed backup runs and unavailable restoration access alongside their security investigation. Existing archives being unaffected does not mean backup and recovery operations remain available during the shutdown. [1][8]

The next material developments are a restoration schedule, confirmation of credential remediation, a reconciled tenant count and stronger evidence about access to customer content. Investigators also need to determine whether the privilege changes and public-IP authentications share an operator. Until those questions are answered, service recovery, credential containment and tenant-level investigation remain separate measures of progress. [1][2][3][5][6][8]