Compromised ConnectWise backup secret gave attackers access to 300+ Microsoft 365 tenants

What happened

A secret belonging to ConnectWise Cloud Backup, a hosted backup service formerly sold as SkyKick, was compromised and used to authenticate to customer Microsoft 365 tenants as the backup application itself. ConnectWise said it had identified unauthorized access to application identities within its Cloud Backup environment, shut down application access for partners and clients, and found no indication that stored partner backup data had been taken. Microsoft, which confirmed unauthorized authentication attempts beginning 15 October 2026, described the activity as an active supply-chain attack.

Huntress, which monitors customer environments, attributed the sign-ins to the legitimate Cloud Backup application and confirmed unauthorized sign-ins in 162 tenants as of 19:00 UTC on 16 October. Its update the following day raised the scale: nearly 1,000 Entra tenants logged sign-in activity from the attacker's address, and more than 300 of those attempts succeeded. The Hacker News reported 173 affected tenants on the same day. Both accounts trace the authentication to the address 144.172.64.128, which Huntress linked to scripted sign-in attempts on 13 and 14 October using curl, python-urllib and python-requests user agents.

Administrators saw the problem before it was public. A Reddit user reported a Privileged Identity Management notification on 15 October stating that a SkyKick service principal had assigned itself the Exchange Administrator role in a tenant that had not used the application in years.

How the access escalated

The intrusion went beyond what the backup application was meant to touch. Huntress reported that service principals for ConnectWise Cloud Management applications, covering Exchange Online, Teams and Microsoft Graph, assigned themselves directory roles, mostly Exchange Administrator, across nearly fifty tenants it monitors. In one partner tenant, the Cloud Management - MS Teams application granted itself Global Administrator, and a Python script then made nine changes adding credentials to two other applications, six of them successful, with the new secrets set to expire in 2028.

Responders disagree on how far the attackers got. Todyl, which analysed nine tenants, saw only sign-in activity and no created accounts, changed passwords or persistence through the backup application. Microsoft, by contrast, observed a backdoor following successful service principal authentication, along with Microsoft Graph reconnaissance and attempts to add further credentials.

Why multi-factor authentication did not apply

Multi-factor authentication verifies a person, and no person was authenticating. According to Todyl, the requests were app-only, so MFA and other user-facing protections never triggered. Conditional access policies written for interactive sign-ins, such as compliant-device requirements for administrators, do not apply to application tokens either.

The permissions administrators had already granted did the rest. Microsoft's threat intelligence assessed Directory.ReadWrite.All, a directory-wide write permission, as one of the permissions likely abused, reach that goes well beyond what a backup service needs to copy mail and files.

Containment steps for affected tenants

Huntress's guidance orders the work in three parts:

• Immediately disable two application IDs: Cloud Backup (506e08f9-6e9a-4da4-942b-a099a03644ae) and Cloud Management - MS Teams (24205314-2b89-4e07-a2a4-579e898a5640), and consider disabling the other Cloud Management applications for the duration.
• Disable rather than delete. Deleting an application removes its consent, so restoring service would require going through consent again; disabling pauses backups while leaving the stored backups in place.
• Audit every credential on every enterprise application. Disabling stops new use but does not remove credentials the attacker already added, and those added secrets remain valid until they are found and revoked.

Why it matters

Every vendor application onboarded into a Microsoft 365 tenant, whether for backup, monitoring, ticketing or HR, carries the same property: the vendor's secret is a long-lived key to the customer's environment, and the customer's only view of it is a row in the enterprise applications list. This incident shows the blast radius of a single vendor-side compromise spreading across hundreds of tenants at once, along a path that MFA and interactive conditional access never touch. The practical lesson is uncomfortable but simple: inventory which applications hold which grants, and rotate their secrets on a schedule that assumes the vendor's side will eventually be breached.