ConnectWise Suspends Cloud Backup After Credential Breach

One stolen API secret, belonging to a backup tool most customers never think about, has knocked out three ConnectWise cloud services and forced hundreds of Microsoft 365 tenants into emergency log review. ConnectWise confirmed unauthorized access to its Cloud Backup environment on October 17 and has since suspended Cloud Backup, SaaS Security and Cloud Management, with no timeline for restoration. Huntress has confirmed unauthorized sign-ins across 162 tenants, and Microsoft says the attackers "likely abused permissions previously granted by customers to the application, including highly elevated permissions like Directory.ReadWrite.All."

Nobody exploited a zero-day here. Nobody chained memory corruption bugs. An attacker walked through a door the customers themselves propped open — a door ConnectWise built, and one that doesn't even creak when it swings, because application-based authentication produces no MFA prompt and, in the wrong place, no trail at all. This is the least glamorous kind of incident I ever worked, and the kind that keeps me employed.

Days 0–2: the password sprays that didn't fit

The timeline, as reconstructed by The Record from Huntress telemetry, starts on October 13 and 14, when Huntress responders saw password spray attacks against four law firms. On its own, that's Tuesday. Password sprays against law firms are background radiation.

Day 2, October 15, is where it gets interesting. Around 50 systems monitored by Huntress saw attackers use ConnectWise's Cloud Management apps to assign themselves directory or administrative roles. That same morning, the Cloud Backup application authenticated from the IP address 144.172.64[.]128 between 06:13 and 08:34 UTC — a hosting provider's address, not the Azure private IP space the application normally speaks from, according to CSO Online. The events were sitting in Microsoft's sign-in logs. Detectable, in principle, the moment they happened: a service principal calling home from an address it had never used before.

The mechanism was boring in the way that matters. The compromised credential is an API secret tied to the Cloud Backup application in ConnectWise's own tenant. It lets the app obtain Microsoft Graph access tokens in customer tenants without any user signing in — no password, no MFA challenge. The secret lived in the vendor's environment, which means nothing any individual customer did, or failed to do, caused this. It also means customers couldn't have prevented it. What they could have done is notice it.

Five minutes to Global Admin

In one Huntress partner tenant, the attack chain ran its full course. A second ConnectWise application — Cloud Management for Microsoft Teams, application ID 24205314-2b89-4e07-a2a4-579e898a5640 — assigned itself the Global Administrator role, then added new credentials to two other applications in that tenant, one of them a single-tenant Huntress application unique to that partner. The whole sequence took about five minutes, according to Huntress, which says it hasn't established whether the separate stages were run by the same operator.

That five-minute sequence is the part of the incident worth memorising, because it's the textbook escalation path for delegated OAuth access. Initial access: the stolen vendor credential. Persistence: new credentials added to other applications, each one independent of the original vendor key. Privilege escalation: self-assignment of Global Admin via an application that customers themselves had consented to directory permissions. Huntress laid out why this compounds: an application that can assign directory roles can add credentials to other apps, create new ones, reset passwords and authentication methods, and change Conditional Access policies. "Each of those steps gives the attacker another way back in that does not depend on the original vendor credential, which is why rotating the vendor credential is necessary, but not enough," the firm wrote.

Huntress's practical warning, carried by The Register, is the single most consequential line in this incident: disabling the M365 apps, including the abused ConnectWise apps, will not remove credentials that were already added — defenders must review the credentials on all of their M365 applications. Containment at the vendor's end revokes the front-door key. It does nothing about copies the attacker already cut.

Days 3–6: containment, silence, and the second wave

ConnectWise first acknowledged "attempts of unauthorized access" on Friday, October 16, and confirmed access the following day. On October 17 it disabled seven application identities, then revoked certificates used for affected application connections across all users — cutting its own access through those connections and invalidating every shared credential previously used for Cloud Backup. The service interruption covers Cloud Backup (the former SkyKick product) plus the integrated SaaS Security and Cloud Management platforms. As of 16:00 UTC on October 18, customers still couldn't back up data, access archives, or restore, The Register reported. Jason Ferguson, ConnectWise's VP of security operations, wrote on Reddit that existing archives "remain encrypted, isolated, and preserved, with no evidence of unauthorized access."

Huntress's count stood at 162 tenants with unauthorized sign-ins as of 19:00 UTC on October 16. The firm also observed a second wave of largely unsuccessful attacks aimed at tenants "in the policy, national security, trade, and critical mineral sectors." Those attempts mostly failed for an instructive reason: the targeted tenants didn't use ConnectWise products, so the abused service principal wasn't present. Meanwhile, ConnectWise's October 19 advisory update added two more IP addresses — 144.172.64[.]99 and 144.172.64[.]60 — identified through downstream monitoring, and stated the company has seen no successful threat activity since containment. It still has no restoration timeline, has not said how many customers were affected, and declined to discuss attribution.

Two things sit in the unknown column, and honesty requires keeping them there. How the credential was compromised in the first place has not been disclosed. And whether backup data itself was touched is unproven — ConnectWise's spokesperson says there is no indication the archives were compromised, which is not the same as evidence of absence. Huntress's own caveat matters here: an attacker using these credentials can reach places where no trail of evidence will be left.

The visibility gap nobody priced in

ConnectWise has been blunt about the structural problem: it has no visibility into partner and customer environments and cannot determine whether any given tenant was breached. That's architecturally proper — it's a platform provider, and its MSP clients own the end-customer relationship. It's also the whole risk model in one sentence. The vendor held a credential that could touch every consenting tenant, but only the tenants can see what it touched. Detection responsibility sat with the party that had the least information about the compromise and, in many cases, the least logging maturity.

For MSPs the arithmetic is worse, as Huntress noted: a foothold in one customer can become access to all of them, which is the concentration risk this market runs on. ConnectWise has been here before — a nation-state attack on its remote monitoring software hit customers last year, and criminals have previously exploited vulnerabilities in its products to deploy ransomware. The pattern isn't that ConnectWise is uniquely careless. It's that MSP tooling is, by design, a privileged artery into thousands of downstream networks, and the industry's default consent grant — broad, durable, app-only — treats that artery as plumbing rather than attack surface.

What the logs could have told you

When could this have been caught? Three points stand out. First, 06:13 UTC on October 15: the first authentication from an IP outside the application's normal Azure range. An alerting rule on service-principal sign-ins from unfamiliar addresses would have fired before the first role assignment. Second, the moment Cloud Management for Teams granted itself Global Administrator — a directory-role assignment event, logged, and about as anomalous as audit events get. Third, the credential additions to the two other applications: five minutes of activity, each step in the audit log, each one a pager-worthy event if anyone was watching those logs for that app.

• Alert on service-principal authentications from IPs outside known vendor ranges — the 144.172.64.x addresses were the earliest public signal.
• Alert on any application assigning itself directory roles, full stop. Backup software never needs to make itself Global Admin at 6 a.m.
• Treat OAuth consent grants as standing credentials: inventory them, scope them down, and re-review them on a schedule, not after an incident.
• Remember that revoking the vendor connection closes the front door; credentials already added to other apps stay valid until you remove them yourself.

I've run the post-incident version of this review more times than I care to count, and the finding is always the same: the tenant had the logs, nobody had the alerts, and the application had more privilege than the task justified. ConnectWise's containment looks competent. But the containment was the vendor's job; the audit is yours. Pull your sign-in logs for October 13 onward, enumerate every credential on every enterprise application, and answer the question this incident is actually asking: which third-party apps in your tenant could do this, and would you know within five minutes if they did?