ConnectWise has suspended its Cloud Backup service, formerly SkyKick, after confirming unauthorized access to application identities used by the product, turning a routine SaaS trust relationship into a live Microsoft 365 incident for MSPs and their customers. In an Oct. 18 update to its Trust Center advisory, the company said it disabled seven application identities at 07:00 UTC on Oct. 17, revoked affected certificates, and invalidated shared credentials. Scheduled backups are not running, and access to affected backup archives and restoration capabilities remains unavailable while the investigation continues.
Why it matters goes beyond downtime. Huntress said the compromised Cloud Backup identity authenticated into customer Microsoft 365 tenants from 144.172.64.128, a hosting-provider address, and had confirmed unauthorized sign-ins in 162 tenants by 19:00 UTC on Oct. 16. Huntress later reported sign-in activity in almost 1,000 tenants from the same suspicious IP, with more than 300 successful sign-ins in that broader set. Those numbers describe authentication activity, not a confirmed count of tenants where data was read or stolen. But they do show the blast radius when a multi-tenant backup platform is already trusted inside customer environments.
The question customers are really asking is narrower and more useful: when a backup vendor’s identity is abused, what can you actually prove about your own tenant, and which controls still belong to the vendor, the MSP, and the tenant owner?
The compromise was in the control plane
This was not a separate malware outbreak inside hundreds of customer networks. MSPs and internal IT teams had already installed a legitimate ConnectWise application and granted it permission to operate inside Microsoft 365 tenants. Once an attacker obtained the vendor-side credential, the shared control plane did the rest: Microsoft Entra could still issue tokens in every tenant where that service principal was trusted.
The main Cloud Backup application ID Huntress identified is 506e08f9-6e9a-4da4-942b-a099a03644ae. A service like this normally holds broad access because it has to back up mailboxes, OneDrive, SharePoint, Teams, and directory data. Huntress said the abused credential was a client assertion stored in ConnectWise’s own tenant, meaning customer action did not create it.
That distinction matters because it defines responsibility. ConnectWise controls the credential, certificates, application code, and service operation. Customers and MSPs do not. But the trust relationship inside each tenant still belongs to the tenant owner. Huntress also reported abuse of other ConnectWise Cloud Management applications, including the Microsoft Teams application ID 24205314-2b89-4e07-a2a4-579e898a5640. In one tenant, that application assigned itself Global Administrator and added credentials to two other applications, including a Huntress application. That is the part of the story buyers often miss: shutting down the original app can stop fresh sign-ins, but it does not reverse privileges, credentials, or persistence that may already have been created.
What ConnectWise can shut down, and what it cannot see
ConnectWise said it identified unauthorized access on Oct. 14. By Oct. 17, it had revoked affected certificates, disabled the seven application identities, invalidated shared credentials, and suspended the Cloud Backup service. Those are the right vendor-side containment moves for a compromised application identity, and they should cut off new authentication through those specific paths.
But ConnectWise also said something equally important for customers: it cannot determine from its own environment whether a particular downstream tenant experienced unauthorized activity, because the service does not give ConnectWise visibility into those customer environments. The company added that hosted backup archives remain encrypted, isolated, and preserved, and that it has no evidence those archives were accessed. That addresses one fear, but not the central tenant question of whether Microsoft 365 data or directory state changed elsewhere.
For MSPs and tenant owners, the practical consequence is that vendor remediation is necessary but not sufficient. Immediate containment means disabling the named ConnectWise or SkyKick service principals rather than deleting them outright, so the tenant preserves objects and evidence for review, and preventing reauthorization until a clean recovery path exists. It also means preserving logs before retention windows roll over. Huntress has warned that removing or disabling the known app will not remove any credentials that may already have been added to other applications.
What a Microsoft 365 customer can actually prove
A tenant with solid logging can usually answer several concrete questions.
First: did the service principal sign in to our tenant during the relevant window? Review Entra service-principal sign-ins for application ID 506e08f9-6e9a-4da4-942b-a099a03644ae and search for 144.172.64.128. Second: did the app, or related ConnectWise applications, receive privileged roles or alter app credentials? Review enterprise applications, app registrations, and role assignments, especially anything tied to the Teams application Huntress flagged. Third: was there follow-on activity in mail, SharePoint, Teams, OneDrive, or directory services that lines up with the app’s access? Fourth: did new credentials appear on other applications, creating persistence outside the original service principal?
Those are the questions a customer can investigate. They are not the same as proving theft. A successful sign-in does not by itself show data was read or copied. A clean search result does not always prove safety if audit coverage is incomplete or retention is short. ConnectWise has not published a root cause, a full victim list, the exact Graph permissions used in the unauthorized sessions, or a restoration date. Huntress’s broader counts separate sign-in activity from confirmed successful authentication, and neither number is the same thing as confirmed downstream data access.
For many organizations, the most honest answer may be limited but still useful: we can show whether the trusted app entered our tenant, whether it changed roles or credentials, and whether it left obvious traces in core Microsoft 365 services. If those logs do not exist, certainty drops fast.
When the backup service is the continuity problem
This incident is unusually punishing because the defensive move is also the outage. The same shutdown that cuts off fresh abuse also halts scheduled backups and temporarily removes restore access. As BleepingComputer reported, Microsoft has confirmed malicious activity involving the service, reinforcing that this is a supply-chain identity event rather than isolated customer-side infections.
That leaves customers with two jobs at once: investigate possible tenant exposure and stand up an alternate export or backup path for critical Microsoft 365 data while Cloud Backup remains suspended. It also forces a business conversation that tends to be deferred until a crisis. ConnectWise owns service restoration and the vendor-side forensic story. MSPs and tenant owners still own consent hygiene, permissions, logging, and tenant response. Contracts may split notification, legal, and recovery costs in different ways.
The broader lesson is not just that encrypted archives matter less than many buyers assume in the first hours of a crisis. It is that the operational identity touching every customer tenant may be the real crown jewel. Least privilege, credential rotation, app-instance locks, consent review, and tested recovery are shared controls, not promises a customer can outsource.
By
By
By
By
By
By
