Compromised ConnectWise credential reached 173 Microsoft 365 tenants
ConnectWise disabled Cloud Backup access after a compromised credential reached 173 Microsoft 365 tenants, with administrators urged to inspect service-principal logs.
ConnectWise has shut off Cloud Backup application access after identifying unauthorised access to application identities, interrupting backup services for partners and their clients while the company investigates.1
The incident matters because ConnectWise Cloud Backup, formerly known as SkyKick Backup, is granted broad Microsoft 365 permissions when installed. Depending on the consent granted by a tenant, that can include access to mailboxes, OneDrive and SharePoint files, Teams data and directory information.2
What happened
Huntress says it observed unauthorised sign-ins in 173 partner and customer tenants using a compromised ConnectWise Cloud Backup credential. The activity obtained Microsoft Graph tokens from the suspicious IP address 144.172.64.128 on 15 October, between 06:13 and 08:34 UTC, with the actor moving through tenants in sorted GUID order.3
The researchers also identified activity beyond simple token use. In at least one tenant, a separate ConnectWise application allegedly assigned itself the Global Administrator role and added credentials to other trusted applications. That could create further routes into privileged services, although the precise impact depends on each tenant's permissions and audit trail.3
ConnectWise's own advisory says it has found no evidence that Cloud Backup partner backup data was compromised. It has nevertheless disabled application access as a protective measure, meaning automated backup services are interrupted until further notice. Existing cloud backup archives should remain accessible once service is restored, according to the company.1
What affected organisations should check
ConnectWise directs administrators to the Microsoft Entra Admin Center's Monitoring area, then the Service principal sign-ins tab. The default User sign-ins view will not show the relevant activity. Administrators should filter for application ID 506e08f9-6e9a-4da4-942b-a099a03644ae and investigate sign-ins from outside expected Microsoft or Azure ranges, particularly 144.172.64.128.1
Huntress separately recommends disabling the application rather than deleting it, checking unified audit logs for unusual mail access, file downloads or directory changes between 14 and 16 October, and waiting for ConnectWise to confirm that the compromised credential has been rotated before re-enabling it.2
Our opinion
This is exactly the sort of incident where "no evidence of data theft" should not be mistaken for "nothing happened". A vendor identity with wide, pre-consented access turns one credential compromise into a multi-tenant problem, so disabling the application and checking service-principal logs is the sensible response even where an organisation has not yet confirmed abuse. ConnectWise's shutdown is disruptive, but it is preferable to leaving a trusted identity active while the investigation continues.
For UK and European organisations, the operational question is twofold: investigate the technical indicators now, and document the interruption and any potential data-access exposure for the relevant security, legal and continuity teams. The eventual answer will depend on tenant-level logs, not on the absence of a public claim that backup archives were copied.