ConnectWise Disables Seven App Identities as Breach Scope Grows to Nearly 1,000 Tenants
ConnectWise has disabled seven application identities tied to its Cloud Backup service (formerly SkyKick) as new findings show the breach disclosed earlier this week reached a far wider set of Microsoft 365 tenants than first reported. This is an update to CosmicBytez Labs' October 17 coverage of the campaign, which at the time confirmed 173 affected tenants. Huntress has since revised that figure sharply upward: nearly 1,000 Entra tenants showed sign-in activity from the compromised application credentials, with roughly 300 resulting in successful authentication.
What's New
| Attribute | Value |
|---|---|
| Application identities disabled | 7 (listed below) |
| Disabling action taken | October 17, 2026, 07:00 UTC |
| Revised scope | ~1,000 Entra tenants with sign-in activity; ~300 successful sign-ins |
| Original discovery | October 14, 2026, via ConnectWise internal monitoring |
| Last observed malicious activity | October 15, 2026, 14:20 UTC |
| Secondary targeted wave | October 15, 2026 — 16 tenants in policy, national security, trade, and critical-minerals sectors |
| Backup status | Scheduled backups and restoration remain suspended |
| Vendor position | No evidence backup archives were accessed; archives remain encrypted and isolated |
Seven Identities Taken Offline
ConnectWise's statement names the specific application connections it disabled on October 17 at 07:00 UTC:
- Cloud Backup
- Cloud Management (primary)
- Cloud Management – MS Teams
- Cloud Management – Exchange Online
- Cloud Management – MS Graph
- Cloud Management – Partner Center
- Cloud Management – SharePoint Online
The company was explicit about what this action does and doesn't accomplish: "Disabling the affected connections prevents new authentication through those connections; it does not reverse changes previously made inside a tenant." In other words, any persistence the attackers already planted — new credentials on other privileged apps, mailbox rules, or directory changes made during the window of access — survives the identity shutdown and requires separate tenant-by-tenant remediation.
ConnectWise also addressed the fate of customer backup data directly, stating that existing archives remain encrypted, isolated, and preserved, and that the company has found no evidence they were breached or accessed by the attackers. Scheduled backups and restoration capability, however, remain unavailable while the Cloud Backup identity stays disabled.
A Much Larger Blast Radius
The October 17 article reported 173 confirmed tenants based on early Huntress and Todyl telemetry. Huntress has since widened that picture considerably: sign-in activity tied to the compromised application credentials touched nearly 1,000 Entra tenants, of which about 300 resulted in a successful authentication. The gap between "touched" and "successful" is consistent with the automated, list-driven sweep Huntress described in its original analysis — the actor worked through a pre-compiled set of tenant GUIDs, and not every attempt landed.
More notably, Huntress identified a second, more deliberate wave of activity on October 15 that targeted just 16 tenants — a sharp narrowing from the broad sweep, and one aimed specifically at organizations in policy, national security, trade, and critical-minerals sectors. That shift from indiscriminate scanning to a short list of sensitive-sector targets suggests the operators triaged their initial access and moved to deliberately exploit footholds in tenants of elevated intelligence value.
Impact Assessment
| Impact Area | Description |
|---|---|
| Scope | Revised from 173 to roughly 1,000 touched / 300 breached Entra tenants — a nearly six-fold increase in confirmed exposure |
| Targeting | A secondary, narrowly-targeted wave against 16 tenants in sensitive sectors indicates selective follow-on exploitation, not just opportunistic access |
| Backup Availability | MSPs and their customers relying on ConnectWise Cloud Backup have no scheduled backups or restore capability until service is restored |
| Residual Persistence | Disabling the seven identities stops new logins through those connections but does not undo any changes or secondary credentials attackers already planted inside affected tenants |
Recommendations
For MSPs and customers using ConnectWise Cloud Backup
- Do not assume disabled identities equal remediation. Audit each affected tenant for new application credentials, mailbox rules, OAuth grants, and Global Admin role assignments created during the October 14–15 window.
- Review Microsoft Graph sign-in and audit logs for activity originating from ConnectWise application service principals, particularly any Global Admin escalation events.
- Treat any tenant in the policy, national security, trade, or critical-minerals sectors as higher priority for deep-dive incident response given the documented secondary targeting wave.
- Plan for extended backup unavailability and validate alternate backup coverage while Cloud Backup remains suspended.
For security teams generally
- Re-run detection queries against the full revised scope — organizations cleared during the initial 173-tenant disclosure should re-check their tenants against the expanded ~1,000-tenant figure.
- Audit third-party MSP application permissions across your own Microsoft 365 tenant; a single compromised backup-vendor credential bridged into nearly a thousand downstream organizations here.
Key Takeaways
- ConnectWise disabled seven Cloud Backup and Cloud Management application identities on October 17, 2026, in response to the credential-theft campaign first reported October 15.
- The confirmed scope grew from 173 to nearly 1,000 Entra tenants touched, with ~300 successful sign-ins.
- A secondary, targeted wave on October 15 hit just 16 tenants in policy, national security, trade, and critical-minerals sectors — signaling deliberate follow-on exploitation.
- Disabling the identities stops new authentication but does not reverse changes already made inside breached tenants.
- ConnectWise reports no evidence that backup archives themselves were accessed, though scheduled backups and restoration remain suspended.