Vendor Access · Supply Chain

ConnectWise Suspends Cloud Backup After Attackers Compromise Microsoft 365 Tenants

October 19, 2026 · 7 min read

A single compromised application credential at ConnectWise gave attackers authenticated access to Microsoft 365 tenants belonging to managed service providers and their clients, all without triggering MFA on a single account. The attacker moved between tenants in seconds, scripted and systematic, hitting at least 162 confirmed tenants and leaving traces in activity logs across nearly 1,000 more. ConnectWise suspended its Cloud Backup service on October 17, 2026 to contain the damage, taking backups, archives, and restoration capability offline in the process. For anyone relying on that service to meet a recovery time objective, the suspension itself became an incident worth explaining to clients.

What actually happened

ConnectWise Cloud Backup, which the company acquired when it purchased SkyKick in September 2024, uses registered application identities in Microsoft Entra ID to authenticate into customer tenants. These application registrations hold delegated permissions to Microsoft Graph, Exchange Online, SharePoint, Teams, and other services, and they authenticate with a credential (a client secret or a client assertion certificate) rather than through a user login flow. That distinction matters because user-facing MFA controls simply do not apply to this authentication path. An attacker who holds the application credential signs in as the app and gets tokens the same way the legitimate service would.

According to Huntress, who published their first analysis on October 16, 2026 at 17:47 UTC, scripted sign-in attempts from hosting-provider IP address 144.172.64.128 began on October 13 and 14, 2026. Activity peaked in the window between 06:13 and 08:34 UTC on October 15, with the attacker moving from tenant to tenant with only seconds between each attempt. An MSP who reported the activity on r/msp noted that a dormant SkyKick service principal had self-assigned the Exchange Administrator role in their tenant at 02:04 UTC on October 15, roughly 40 hours before ConnectWise issued any public advisory.

The scope of the affected application identities went beyond backup. Huntress assessed with high confidence that the threat actor abused ConnectWise Cloud Management apps for Exchange Online, Microsoft Teams, and SharePoint Online, in addition to the Cloud Backup, MS Graph, and Partner Center applications. In one Huntress partner tenant, the ConnectWise Cloud Management Teams application (App ID 24205314-2b89-4e07-a2a4-579e898a5640) self-assigned Global Administrator rights and added new credentials to two other applications inside that tenant. An app granting itself tenant-wide admin access and then planting additional credentials is about as bad an outcome as an attacker can achieve inside a Microsoft 365 environment.

ConnectWise says it identified the issue on October 14, 2026 and began incident response. On October 17, 2026 at 07:00 UTC, it disabled seven application identities, including App ID 506e08f9-6e9a-4da4-942b-a099a03644ae (Cloud Backup) and App ID b78f6a77-d4e5-46fb-87e5-d1648bd02519 (Cloud Management, Exchange Online). Revoking the application identities stopped further abuse of those specific credentials, but ConnectWise's own advisory acknowledged that disabling the applications does not reverse changes previously made inside a tenant and that previously issued access tokens may remain valid until they expire. On October 18, ConnectWise published a technical investigation and remediation guide advising partners to review sign-in logs from October 13, 2026 through the current date, filtering for the attacker IP. As of October 18, 2026, no CVE identifier had been assigned, no specific threat actor group had been attributed, and ConnectWise had not announced a service restoration date.

"Existing backup archives remain encrypted, isolated, and preserved, with no evidence they were breached or accessed by attackers." — ConnectWise Trust Center, October 18, 2026

Why this should matter to you even if you don’t run ConnectWise Cloud Backup (SkyKick)

If your organization uses any SaaS platform that authenticates into Microsoft 365 through registered application identities, this incident is directly relevant to your environment. Backup tools, PSA platforms, RMM products, email security gateways, compliance scanners, and a long list of productivity add-ins all use this model. Every one of those integrations represents an application credential living somewhere in the vendor's infrastructure, with permissions granted inside your tenant. You have limited visibility into how the vendor stores that credential, how they rotate it, and who inside their organization can access it.

The core problem this incident illustrates is that MFA, conditional access policies, and identity protection alerts are all designed around human sign-in flows. Application credential abuse routes around those controls entirely. From Microsoft's perspective, the sign-in from 144.172.64.128 looked like the legitimate ConnectWise Cloud Backup application authenticating normally, because it was using a valid credential. Detection depends on behavioral signals, anomalous IP addresses, unusual permission changes, and out-of-hours activity, rather than the authentication controls most security teams consider their primary line of defense.

The scale of the tenant exposure is also worth considering. At least 162 tenants had confirmed unauthorized sign-ins. A later count found sign-in activity from the attacker's IP in almost 1,000 tenants, with an intermediate count exceeding 300. That amplification effect, one compromised vendor credential affecting hundreds of downstream customer environments, is exactly the supply chain risk that security teams have been discussing in the abstract for years. This incident makes it concrete.

The service suspension added a second layer of operational risk. ConnectWise took Cloud Backup, SaaS Security, and Cloud Management offline while completing its review. Any organization relying on ConnectWise Cloud Backup for Microsoft 365 data protection lost access to scheduled backups, backup archives, and restoration capabilities during that window. If a data loss or ransomware event had occurred in a customer tenant during the suspension, that customer would have had no path to recovery through that tool. Depending on backup architecture, they may have had no recovery path at all.

The control that would have blunted it

The control category here is vendor access management, specifically the governance of third-party application registrations inside your Microsoft Entra ID tenant. Most organizations have approved dozens of these registrations over time, often without a systematic review of what permissions each one holds, whether those permissions are still appropriate, or whether the vendor still actively uses the integration. The ConnectWise incident is a reasonable forcing function to run that audit now if you have not done it recently.

The practical starting point is an inventory. In Entra ID, enterprise applications and app registrations can be enumerated through the portal or through Microsoft Graph. For each third-party application, you want to know what permissions it holds (delegated versus application permissions matter here, since application permissions like Mail.ReadWrite at the application level are broader than most people realize), what it has been granted access to in your tenant, and when it last authenticated. A registered application that has not authenticated in six months probably does not need to remain active.

Beyond inventory, the control that would have limited the blast radius in this specific incident is restricting application permissions to the minimum required scope and applying Conditional Access policies where the authentication path supports it. Microsoft's workload identity Conditional Access policies can restrict which IP ranges or geographic locations an application identity is permitted to authenticate from, which would have made the 144.172.64.128 sign-ins at least detectable and potentially blockable at the policy layer. This capability requires Entra ID P2 licensing, which is a real cost consideration, but it is one of the few authentication controls that applies to app-to-app flows rather than only to user sign-ins.

Monitoring is the other side of this. Entra ID sign-in logs for non-interactive sign-ins (the log category that covers application authentications) are often not included in default SIEM ingestion because the volume is high and the signal-to-noise ratio is low during normal operations. This incident is a good argument for at least ingesting application sign-in logs and alerting on permission changes, specifically AppRoleAssignment.ReadWrite.All grants, new credential additions to existing applications, and role assignments made by application principals rather than human administrators. The SkyKick service principal self-assigning Exchange Administrator is exactly the kind of event that should produce an alert at any organization with a mature detection posture.

Cyber insurers have been asking about third-party vendor access controls with increasing consistency over the past two years. Questions around MFA, privileged access management, and vendor risk assessments are now standard on most applications. What this incident surfaces is that application-level integrations are a gap in the MFA story that most organizations have not fully addressed in their policy submissions or their actual controls. Documenting your application permission governance process, your Entra ID app review cadence, and your non-interactive sign-in monitoring coverage puts you in a materially stronger position both operationally and at renewal time.

If you want to understand how your current vendor access controls map to what cyber insurers expect, the Strondex Cyber Insurance Readiness assessment covers third-party application access governance as part of its evaluation framework.