A stolen credential for ConnectWise Cloud Backup signed into more than 300 Microsoft 365 tenants on October 15, and the fix ConnectWise shipped two days later was to turn the product off. Scheduled backups stopped at 07:00 UTC on October 17. Restores stopped with them. As of the company's Sunday update, both are still down, there is no restoration date, and ConnectWise has not said how the credential got out.

The product was SkyKick Cloud Backup until ConnectWise bought SkyKick in 2024. In a lot of tenants the enterprise app still carries the SkyKick name, which is part of why so many admins spent the weekend searching their Entra portal for something they forgot they had.

One key for every tenant

Cloud Backup is a multi-tenant Entra application. ConnectWise registers the app once in its own tenant, each customer consents to it, and the app proves who it is with a credential that lives on ConnectWise's side. Huntress says that credential was a client assertion. Todyl, which investigated nine tenants, called it a client secret. Either way it is a vendor secret, and whoever holds it can request a Microsoft Graph token for any tenant that ever consented to the app.

No user signs in during that flow. No password is typed, no MFA prompt fires, and Conditional Access policies written for people never see the request. Microsoft's sign-in logs record it as a service principal sign-in, which most admins never look at.

Huntress counted almost 1,000 Entra tenants with sign-in activity from the attacker's address, 144.172.64.128, and more than 300 of those sign-ins succeeded. By 19:00 UTC on October 16 it had confirmed unauthorized access in 162 tenants it monitors. The token requests between 06:13 and 08:34 UTC on October 15 came in sorted GUID order a few seconds apart. Someone had a list and a loop.

The same address had spent October 13 and 14 password spraying four law firm tenants with curl. Two accounts locked out. Nothing got in. Then the spraying stopped, and the attacker started authenticating as a backup product instead.

The backup app was the smaller problem

The louder activity came from the companion Cloud Management apps for Exchange Online, Teams, and Graph. From 01:58 UTC on October 15, those service principals assigned themselves directory roles in about 50 tenants Huntress watches, mostly Exchange Administrator.

In one tenant the Cloud Management for MS Teams app added itself to Global Administrator at 03:44 UTC. Five minutes later a Python script had made nine changes to two unrelated applications: an MSP management tool and Huntress's own security app. Six of the nine worked. The ones that worked added client secrets set to expire in 2028. A certificate addition failed on a thumbprint mismatch. The secret planted on Huntress's app was used seven times in quick succession before Huntress found and removed it on October 16.

That is the part of this incident that outlives the ConnectWise credential. A secret on someone else's app is a separate identity. ConnectWise revoking its own certificates does nothing to it.

Microsoft Threat Intelligence called the campaign an active supply chain attack and said the actor most likely abused permissions the apps already held, Directory.ReadWrite.All among them. A second, slower wave on the afternoon of the 15th hit 16 tenants Huntress protects in policy, national security, trade, and critical minerals. It looked manual and reached for Exchange, SharePoint, Teams, Azure Resource Manager, and the Office 365 Management APIs. All 16 attempts failed. The target list says more about who this is than the tooling does.

Disabling the app undoes nothing

ConnectWise's own advisory, quoted by The Hacker News, is careful on this point. Disabling the seven application identities blocks new authentication. It does not reverse changes already made inside a tenant, and tokens issued before the cutoff stay valid until they expire. ConnectWise also says it cannot see downstream customer environments at all, so its statement that it has observed no successful threat activity covers only the environments it monitors.

The timeline has a gap in it. ConnectWise says it identified the issue on October 14. The attacker's busiest hours were the early morning of October 15. Huntress published on October 16. The identities were cut on October 17 at 07:00 UTC. On the 17th Huntress also reported that three Cloud Management apps did not appear to be disabled yet, and ConnectWise's final list of seven includes them, so either the revocation rolled out in stages or the two companies were looking at different things. Huntress saw the last malicious sign-in from the original address at 08:45 UTC on the 15th and says there is no evidence the attacker stopped because of public disclosure. They stopped before anyone revoked anything.

If your tenant ever consented to SkyKick or ConnectWise Cloud Backup, the checklist from Huntress and from BleepingComputer's reporting is specific:

  • Disable the Cloud Backup service principal (app ID 506e08f9-6e9a-4da4-942b-a099a03644ae) and the Cloud Management apps. Disable, do not delete. Deleting removes the consent record and the app's role assignments with it, and you lose the evidence of what it did.
  • Pull service principal sign-ins from 01:00 UTC on October 15 through 02:00 UTC on October 16 and look for that IP and for user agents like python-urllib, python-requests, curl, and kiota-dotnet.
  • List every client secret and certificate added to any app registration or enterprise app since October 13 that you did not add yourself. Remove them.
  • Remove any directory role held by a SkyKick or ConnectWise app, Global Administrator and Privileged Authentication Administrator first.

Do not re-enable the ConnectWise apps until ConnectWise says every credential has been reset. Huntress, for its part, turned on App Instance Property Lock across all of its own applications after finding the planted secret. That setting stops a service principal in a customer tenant from having credentials added to it, and it has been available since 2023. It should be on for every app you publish into other people's tenants.

Backup software should hold a key the customer can revoke

A backup product has to read everything. That is the job, and no amount of permission scoping changes it. Cloud Backup needs mail, OneDrive, SharePoint, Teams, and directory data in every tenant it protects, so a stolen credential for it is a stolen credential for all of that, everywhere, at once.

What a vendor can choose is where the credential lives and who gets to revoke it. I maintain a Borg Backup server, and the design I trust is the one where the repository key stays with the customer and the server never holds anything that unlocks a second customer's data. The SaaS version of that is a credential per tenant: a certificate issued per customer, Conditional Access for workload identities on the customer side, and property lock on the vendor side. It costs more to run. It also means one leaked secret is one tenant's problem.

The single shared key has a second cost that showed up this weekend. When it leaks, the vendor has to revoke it for everyone in the same minute, and every customer loses backups in that minute too. ConnectWise did the right thing by revoking. The product's design made the right thing a total outage. Hundreds of admins are now working an active incident in their tenant, and the restore capability they pay for is the one thing they cannot use. ConnectWise says the archives are encrypted, isolated, and intact. That is good. An archive you cannot open yet is not a backup.

The same weekend, OpenCode told 1.4% of its Console users to rotate their OpenAI, Anthropic, and Google API keys after someone got into a legacy system it was still decommissioning. Different product, same shape. A vendor stored the credentials that unlock your upstream account, the vendor lost them, and you got the bill.

My guess is that the ConnectWise root cause names a SkyKick system that predates the acquisition and was never folded into the new owner's secrets management, and that restores stay down past the end of this week. If the postmortem shows the credential was rotated regularly and still leaked, I will be wrong about the first part, and the story will be worse.