A trusted backup tool just became an entry point into hundreds of company inboxes. On October 17, 2026, ConnectWise shut off customer access to its Cloud Backup service, formerly known as SkyKick Backup, after confirming that hackers had hijacked the application’s own identity inside Microsoft 365 and used it to sign in to customer tenants without ever touching a password or multi-factor prompt. By the time the company pulled the plug, researchers had already tracked unauthorized sign-ins across 173 separate Microsoft 365 environments.
The incident lands in the middle of an already brutal month for enterprise security teams. Microsoft’s October Patch Tuesday cleared a record 1,413 vulnerabilities, Palo Alto Networks pushed emergency PAN-OS fixes, and NCC Group counted 83 active ransomware groups in a single month, the busiest stretch of 2026 so far. The ConnectWise breach stands out from that pile not because of its scale, but because of its mechanism: attackers never logged in as a person. They logged in as the software itself.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Happened: Inside the ConnectWise Cloud Backup Breach
ConnectWise Cloud Backup is a Microsoft 365 backup and restore product sold through managed service providers (MSPs) to small and midsize businesses. To do its job, the application needs standing permission inside a customer’s Microsoft 365 tenant, granted once through Microsoft Entra ID and then trusted indefinitely unless someone revokes it. That standing trust is exactly what attackers exploited.
According to incident responder Huntress, a Microsoft 365 API credential belonging to the Cloud Backup application was compromised, and the threat actor began using it to pull Microsoft Graph access tokens from customer tenants starting on or around October 14. By October 15, researchers observed sign-ins from a hosting-provider IP address, 144.172.64[.]128, a strong signal that the login traffic had nothing to do with legitimate ConnectWise infrastructure.
ConnectWise has not disclosed how the underlying credential, described in reporting as an API secret or client credential, was stolen in the first place. What is confirmed is the blast radius once that single secret ended up in the wrong hands: because the application had been pre-authorized in every tenant where a customer had ever installed it, the attacker could reach them all using the same stolen key.
Timeline: Four Days From First Sign-In to Lockdown
The public timeline, pieced together from ConnectWise’s own advisories and independent researchers, shows a slow-building incident that escalated fast once outside responders got involved.
| Date (Oct 2026) | Event | Source |
|---|---|---|
| Oct 14 | Compromised credential begins pulling Microsoft Graph tokens across customer tenants | Huntress |
| Oct 15 | Cloud Backup application identity signs in to M365 tenants from a hosting-provider IP address | Huntress |
| Oct 16, 19:00 UTC | Confirmed unauthorized sign-ins reach 162 tenants; responders advise disabling the app | Huntress |
| Oct 17, 07:00 UTC | ConnectWise disables seven application identities tied to the incident | ConnectWise |
| Oct 17, 13:00 EDT | ConnectWise revokes certificates and invalidates shared Cloud Backup credentials | ConnectWise |
| Oct 17 | Confirmed tenant count rises to 173; ConnectWise shuts off Cloud Backup access entirely | The Hacker News / BleepingComputer |
| Oct 18 | Investigation and remediation ongoing; Cloud Backup access remains disabled | ConnectWise |
That 72-hour gap between the first confirmed sign-ins and ConnectWise’s full lockdown is the part MSPs are most likely to scrutinize once the dust settles. Backups and restores for every Cloud Backup customer were paused for days, not because customer data was necessarily touched, but because ConnectWise could not rule it out quickly enough to leave the service running.
How a Single Vendor Credential Reached 173 Tenants
The Application ID at the Center of the Breach
Researchers at Huntress identified the specific Microsoft Entra application tied to the intrusion: ConnectWise Cloud Backup, registered under application ID 506e08f9-6e9a-4da4-942b-a099a03644ae. A related application, ConnectWise Cloud Management for Microsoft Teams (ID 24205314-2b89-4e07-a2a4-579e898a5640), was also flagged, along with other ConnectWise apps tied to Exchange Online, SharePoint Online, and Partner Center.
Depending on what permissions a customer had granted at setup, the compromised application could potentially reach Exchange Online mailboxes, Teams messages, SharePoint document libraries, OneDrive files, and core Microsoft Graph directory data. One incident report, cited by The Hacker News, described a related Teams-management application being used in at least one tenant to assign Global Administrator privileges and plant new client secrets, an escalation path that would hand an attacker durable control well beyond the original backup function.
App-Only Tokens vs. User Logins
The detail that security teams keep returning to is this: the attacker never authenticated as a human. They authenticated as the service principal itself, using an app-only OAuth flow backed by a client credential and, in some observed activity, a certificate-based client assertion. That distinction matters because most enterprise security stacks are built to watch user behavior. Multi-factor authentication, Conditional Access policies tied to device compliance, and risk-based sign-in scoring are all designed around the assumption that a human is logging in somewhere. None of that applies to a service principal using its own credentials.
Analysis from Inforcer put it plainly: the attacker signed in as the app itself, so user MFA and Conditional Access never came into play. For MSPs who built their security posture around locking down employee accounts, that is an uncomfortable gap to discover mid-incident.
ConnectWise’s Response: Seven Applications, Revoked Certificates
What ConnectWise Has Confirmed
In its public advisory, ConnectWise said it identified unauthorized access to application identities within the Cloud Backup environment and moved through a sequence of containment steps: disabling seven application identities at 07:00 UTC on October 17, revoking certificates used for affected application connections, invalidating shared Cloud Backup credentials, and finally shutting off Cloud Backup application access for partners and customers as a precaution. The company said it had no evidence that backup archives themselves had been accessed.
What Remains Unknown
ConnectWise also acknowledged a harder limit: its investigation could not determine whether individual live Microsoft 365 tenants experienced unauthorized activity beyond the confirmed sign-ins. That is an important distinction for any customer reading the advisory. Confirmed sign-ins prove the attacker reached a tenant. They do not, by themselves, prove that mailboxes were read, files were exfiltrated, or anything was changed. As of October 18, ConnectWise’s Cloud Backup service remained disabled, with backups and restores paused company-wide and no public restoration date confirmed.
The Numbers Behind the Breach
- 173 Microsoft 365 partner and customer tenants confirmed with unauthorized sign-ins as of October 17, up from 162 tenants a day earlier
- Seven ConnectWise application identities disabled in the October 17 containment action
- At least one hosting-provider IP address, 144.172.64[.]128, used for the malicious sign-ins
- Zero confirmed instances of backup archive data being accessed, according to ConnectWise’s current investigation
- An unknown but potentially larger pool of exposed tenants, since the credential worked anywhere the app had ever been consented, including dormant installs no longer in active use
That last point is the one keeping incident responders busy. A tenant count is not the same as a customer count. One MSP can manage dozens of tenants, and some of the 173 confirmed tenants may belong to organizations that stopped actively using Cloud Backup long ago but never revoked its access. Huntress has pushed organizations to check their Entra ID sign-in logs regardless of whether they believe they are still using the product.
Checking Your Own Tenant: What Security Teams Are Running
Responders have published a consistent set of log review steps. The most common starting point is pulling service principal sign-in logs scoped to the Cloud Backup application ID and cross-referencing them against the known malicious IP range.
Entra ID portal path:
Monitoring > Sign-in logs > Service principal sign-ins
Filter: Application ID = 506e08f9-6e9a-4da4-942b-a099a03644ae
Also check:
Application ID = 24205314-2b89-4e07-a2a4-579e898a5640 (Cloud Management - MS Teams)
Flag any sign-in from:
IP range around 144.172.64.0/24
Then review audit logs for:
- Newly added client secrets or certificates
- New Global Administrator role assignments
- Modified application permission grantsOrganizations that find no matching sign-ins are not necessarily clear. Security teams are advising a full review of dormant application consents, not just the two flagged IDs, since the same underlying weakness (long-lived, tenant-wide trust granted to a vendor app) applies to every SaaS integration a business has ever approved and forgotten about.
2026’s MSP Supply-Chain Pattern: ConnectWise Isn’t Alone
This is not an isolated event. October 2026 has been a brutal month for the software that enterprises trust to manage their infrastructure rather than run their business logic. Ivanti disclosed an exploited authentication-bypass flaw in its Connect Secure VPN appliances, tracked as CVE-2026-104935 with a CVSS score of 8.6, prompting CISA to urge immediate patching. BeyondTrust separately confirmed a remote support zero-day rated CVSS 9.3. Palo Alto Networks pushed emergency PAN-OS fixes the same week. None of those three involved an OAuth application identity the way ConnectWise’s incident did, but all four point to the same underlying trend: attackers are increasingly targeting the tools that sit between a vendor and thousands of customer environments, because one successful compromise there outperforms breaching customers one at a time.
| Incident | Attack Vector | Severity / Scale | Status as of Oct 18, 2026 |
|---|---|---|---|
| ConnectWise Cloud Backup | Compromised vendor app credential, app-only OAuth tokens | 173 confirmed M365 tenants | Service disabled, under investigation |
| Ivanti Connect Secure | Unauthenticated RCE via auth-bypass chain (CVE-2026-104935) | CVSS 8.6, active exploitation | Partial patch issued Oct 13; CISA advisory active |
| BeyondTrust Remote Support | Zero-day flaw, attributed to China-linked actors | CVSS 9.3 | Patched, post-incident review ongoing |
| Palo Alto PAN-OS | High-severity software flaw | Not independently rated in this dataset | Emergency patch released |
What separates the ConnectWise case from the others in this table is the absence of a software vulnerability to patch. There is no CVE here, no code flaw a vendor can simply fix with an update. The problem is architectural: once a customer grants a vendor application standing access to Microsoft 365, that trust persists until someone actively revokes it, and a single stolen vendor credential can ride that trust into every tenant where it was ever granted.
From ScreenConnect to Cloud Backup: ConnectWise’s Security History
ConnectWise’s remote monitoring and management tools, including ScreenConnect, have drawn security scrutiny before, typically in the form of vulnerabilities in the remote-access software itself that gave attackers a route into endpoint devices. The Cloud Backup incident is a structurally different kind of failure. Instead of a flaw in an agent running on an endpoint, this is a compromised identity belonging to a cloud application with delegated access across Microsoft 365. The common thread across both failure modes is concentration risk: ConnectWise, like most MSP tool vendors, sits in a position of trust across a huge number of downstream customer environments, and a single point of failure on the vendor side can cascade outward to all of them simultaneously. Reporting on this incident does not establish a technical link between the Cloud Backup compromise and any earlier ConnectWise product issue; the connection is about the business model, not a shared vulnerability.
What Security Researchers Are Telling MSPs to Do Now
The guidance coming out of Huntress, Inforcer, and other responders converges on a short list of actions that go beyond simply waiting for ConnectWise’s all-clear:
- Disable the Cloud Backup application (ID 506e08f9-6e9a-4da4-942b-a099a03644ae) in every tenant where it is installed, even tenants that stopped actively using the service
- Disable the related ConnectWise Cloud Management â MS Teams application where it is not essential to daily operations
- Pull service principal sign-in logs for both application IDs and cross-check against the known malicious IP range
- Audit for newly created client secrets, certificates, directory-role changes, and Global Administrator grants made in the affected window
- Treat every dormant, unused vendor application consent as an active exposure rather than background noise, and remove access that is no longer needed
- Maintain a backup path that is independent of any single vendor’s identity, so disabling one compromised application does not strip away all recovery capability
- Rotate or revoke affected application secrets and certificates, and only re-consent to the application after validating exactly which permissions it is requesting
That last bullet point is the one most MSPs skip during normal operations. OAuth consent screens are rarely re-reviewed once a vendor application is approved, and businesses routinely carry years-old grants for tools they no longer actively manage. This incident is a concrete demonstration of why that habit is risky.
The Business Fallout for MSPs and Their Customers
ConnectWise is privately held, so there is no public stock price to track the market’s reaction the way there might be for a listed vendor. But the operational fallout is concrete and ongoing. Microsoft 365 backups were paused for every Cloud Backup customer the moment ConnectWise disabled the application, and restores were unavailable for the same window. For MSPs that rely on ConnectWise’s backup product as the only recovery path for client tenants, that is a direct service outage layered on top of a security incident, not a hypothetical risk.
There is also a reputational cost that is harder to quantify. MSPs sell themselves to small and midsize business clients largely on the premise that they manage security and backup so the client does not have to think about it. When the vendor behind that promise becomes the attack vector, MSPs are stuck explaining an incident they did not cause and could not have prevented through their own hardening. That dynamic is likely to show up in contract renewal conversations and vendor risk assessments well after ConnectWise fully restores the service.
Market Impact: Backup Trust in a Post-Breach World
Backup and disaster recovery vendors sell on a specific promise: when something goes wrong, their product is the thing that still works. An incident where the backup product itself becomes the compromise vector cuts directly against that pitch, and competitors in the Microsoft 365 backup space are likely to use this episode in their own sales conversations over the next several quarters. For ConnectWise, the near-term priority is less about the headline and more about rebuilding the credential and certificate chain that customers now have reason to distrust by default.
The broader market signal is about OAuth application governance generally. Microsoft 365’s app consent model was built for convenience: approve an app once, and it keeps working indefinitely. Security vendors that build tooling around continuously auditing third-party app grants, rather than treating consent as a one-time checkbox, are positioned to benefit from the renewed attention this incident is generating among MSPs and their customers.
Predictions: Where MSP Identity Security Goes From Here
- Expect ConnectWise to publish a full post-incident report once remediation finishes, including how the original credential was stolen and a rotation schedule for every Cloud Backup customer.
- Microsoft is likely to face pressure to make tenant-wide app consent easier to audit and expire automatically, rather than leaving it to individual tenant admins to notice and revoke stale grants.
- Other MSP-tool vendors with similar standing-access models will quietly accelerate credential rotation and secret management reviews over the next few months, whether or not they say so publicly.
- Cyber insurance underwriters covering MSPs and their downstream clients will start asking more specific questions about vendor OAuth app governance during renewal, not just endpoint and user-account controls.
- More incidents built around compromised service-principal credentials, rather than classic password theft or software CVEs, should be expected through 2027 as attackers adapt to the fact that MFA-focused defenses don’t cover app-only authentication.
Frequently Asked Questions
What is the ConnectWise Cloud Backup breach?
It is a security incident disclosed in October 2026 in which hackers compromised a Microsoft 365 API credential belonging to ConnectWise’s Cloud Backup application (formerly SkyKick Backup) and used it to sign in to customer tenants without needing a password or MFA, since the sign-ins were authenticated as the application itself rather than as a user.
How many organizations were affected?
Huntress confirmed unauthorized sign-ins across 173 Microsoft 365 partner and customer tenants as of October 17, 2026, up from 162 tenants confirmed a day earlier. The real number of affected organizations could differ from the tenant count, since one organization can manage multiple tenants.
Was my data stolen if I use ConnectWise Cloud Backup?
ConnectWise has said it has no evidence that backup archive data was accessed, but it has also said its investigation could not confirm whether every individual tenant experienced unauthorized activity beyond the sign-ins themselves. Affected organizations should review their own Entra ID sign-in and audit logs rather than assume either outcome.
Is Cloud Backup still down?
As of October 18, 2026, ConnectWise’s Cloud Backup application access remained disabled, with Microsoft 365 backups and restores paused while the company continues its investigation and remediation.
Why didn’t multi-factor authentication stop this attack?
The attacker authenticated as the Cloud Backup application’s service principal using app-only OAuth credentials, not as a human user. MFA and most Conditional Access policies are designed to protect user sign-ins, so they do not apply to this type of app-to-app authentication.
How is this different from the Ivanti or BeyondTrust incidents disclosed the same month?
The Ivanti and BeyondTrust incidents both involved exploitable software vulnerabilities with assigned CVEs that could be fixed with a vendor patch. The ConnectWise incident involved a compromised credential tied to a legitimate, pre-authorized application rather than a code flaw, so there is no patch that resolves it; the fix is credential rotation, certificate revocation, and tighter governance over application consent.
What should I do if my organization uses ConnectWise Cloud Backup?
Check Entra ID service principal sign-in logs for the Cloud Backup application ID, review audit logs for unexpected client secrets or administrator role grants, and keep an independent backup path available in case the service remains disabled longer than expected.
Does this affect only ConnectWise partners, or end customers too?
Both. Huntress’s confirmed tenant count explicitly includes partner and customer tenants, since MSP partners administer Cloud Backup on behalf of their own downstream clients, and the compromised credential worked across that entire chain.
