The ConnectWise Cloud Backup breach forced the company to shut off its service and disable seven of its application identities after a stolen credential let attackers sign into 173 Microsoft 365 tenants. ConnectWise took the step on Saturday, October 17, and its cleanup is still ongoing. For US managed service providers and small businesses that use the tool to back up Microsoft 365 mail and files, the practical result is simple: scheduled backups have stopped and restores are unavailable for now.
USA 24 previously reported the 173-tenant count. This follow-up covers the shutdown, the cleanup steps and what remains unverified. According to Huntress's account, relayed by Tech Insider, attackers began pulling Microsoft Graph access tokens from customer tenants on or around October 14. They used a Microsoft 365 API credential belonging to the Cloud Backup application, formerly SkyKick Backup.
Researchers say the credential was then used to authenticate across 173 tenants on October 15. Decryption Digest reports that Huntress first went public on October 16, and that the confirmed count rose from 162 to 173 within 24 hours.
How one stolen credential reached 173 tenants
The credential did not sit in customer environments. It lived in ConnectWise's own tenant, so customer-side multifactor authentication and conditional access could not block it, according to researchers cited by Forkast. That detail changes the defensive picture. Customers could have hardened every login and still been exposed.
Cloud Backup depends on standing permission inside customer tenants. That permission is granted once through Microsoft Entra ID and then trusted until someone revokes it, and Tech Insider says that standing trust is what made the attack effective [5].
This is a supply-chain attack. One attacker-controlled credential reached many downstream customers at once, rather than breaching each company one by one [2][3].
One write-up reports a 2.5-hour window on October 15, from 06:13 to 08:34 UTC, in which the unauthorized access read mail, OneDrive, SharePoint and Teams data [3]. That timing is a single-source detail. USA 24 could not corroborate it elsewhere, so treat it with caution.
What ConnectWise shut down on October 17
ConnectWise said it disabled seven of its application identities and suspended Cloud Backup by revoking the certificates used for affected application connections across all users, as The Hacker News reported. The company said it took that action on October 17 at 07:00 UTC. It also took SaaS Security and Cloud Management offline temporarily while it reviews the incident.
| Item | Status, per ConnectWise |
|---|---|
| Cloud Backup | Suspended by revoking certificates for affected connections |
| Seven application identities | Disabled |
| SaaS Security and Cloud Management | Temporarily offline |
| Scheduled backups | Not running |
| Restore functions and affected archives | Access unavailable |
| Existing backup archives | Encrypted, with no evidence of a breach |
All items in the table come from ConnectWise's statements as reported by The Hacker News.
Two company statements deserve close reading. ConnectWise said the shutdown "does not reverse changes previously made inside a tenant." It also stated that "The affected shared Cloud Backup credentials are no longer valid." Neither statement came with a named spokesperson.
Which US businesses are most exposed
US managed service providers and their small and midsize business clients face the most exposure, because Cloud Backup received broad Microsoft 365 access inside customer tenants [5]. The 173 figure is not a ceiling. Any US organization that uses the tool could be affected, including those whose tenant is not on the count.
The count may also be low. One source notes that a single MSP tenant can represent dozens of client organizations, which means the true number of affected companies could be higher [3]. Three ConnectWise application IDs with delegated Microsoft 365 permissions are cited as affected: Cloud Backup, Cloud Management and Cloud Management – MS Teams [3].
How to check your Microsoft 365 tenant for ConnectWise access
Work through these steps in order. They draw on the reporting above and do not replace instructions from Microsoft or ConnectWise.
- Review Microsoft Entra ID service principal sign-in logs for the ConnectWise applications, and revoke their access [3].
- Disable, but do not delete, the ConnectWise Cloud Backup and Cloud Management – MS Teams service principals, according to guidance reported by Time News [4].
- Search for unauthorized credentials, permissions or access created through separate identities. ConnectWise says those need their own review and remediation [1].
- Check applications in the tenant for recently added credentials. One commentator, as reported by InfoSec Today, notes that an attacker who added credentials could keep access even after the service is shut off [6].
- Look for privilege escalation. In at least one partner tenant, a separate ConnectWise application was found raising its own permissions to Global Administrator [4].
- Assume previously issued access tokens may still work until they expire. Do not treat the revocation as a complete fix [1].
- Plan for a backup gap. Scheduled backups are not running and restores are unavailable at the moment [1].
What remains unverified about the ConnectWise breach
The most important open question is who is behind the intrusion. None of the sources reviewed names a threat actor, and ConnectWise refers only to unknown threat actors [1].
The root cause is also disputed. Forkast says the credential was a client assertion in ConnectWise's own tenant [2]. A separate outlet, PRSOL:CC, claims attackers compromised ConnectWise's internal key management enclaves and harvested signing certificates. The same outlet says ConnectWise retained Mandiant for forensic triage [7]. USA 24 could not verify either claim, and no second source has confirmed them.
Persistence is open too. Whether attackers planted new credentials, permissions or rogue admin accounts in victim tenants is not confirmed, even though a Global Administrator escalation in at least one tenant is reported [4]. ConnectWise has not said when Cloud Backup will return [1].
How this compares with earlier trust failures
Forkast counted this as the tenth 'trust-through-defaults' incident in 21 days, and noted that no CVE was assigned [2]. That framing is the outlet's own analysis. It still points to a useful distinction. A conventional software flaw has a patch, but a trusted connection that an attacker can reuse does not map cleanly onto a patch-based response. Admins will need to audit what they trusted, not only what they installed.
Credential theft also brings a familiar follow-up: rotation. For a different case where exposed keys may require replacement, see USA 24's coverage of the OpenCode console breach.
A separate Nextcloud flaw worth checking now
A separate and unrelated story matters for admins who run self-hosted collaboration tools. A critical flaw, CVE-2026-110447 with a CVSS score of 9.2, in the Collabora Online built-in CODE Server app is being exploited to plant web shells on Nextcloud servers [8][9]. Versions 26.4.302 and earlier are affected, and version 26.4.303 contains the fix [8][9]. Administrators should verify their versions directly.
What to watch next
Three open items will determine how far this goes: whether ConnectWise publishes a final tenant count, whether persistence in customer tenants is confirmed or ruled out, and when Cloud Backup returns. A confirmed rogue admin account would widen the cleanup far beyond disabled service principals. Until those answers arrive, MSPs should check their own tenants now rather than wait for a restore date, since ConnectWise has not set one.
