ConnectWise Cloud Backup: One Vendor App Credential, and the Customers’ Microsoft 365 Tenants Behind It

No customer lost a password in this incident. A vendor's application credential was enough. Huntress reports that a client credential for the ConnectWise Cloud Backup application, formerly SkyKick, was used from attacker-controlled infrastructure to obtain Microsoft Graph tokens in customers' Microsoft 365 tenants. ConnectWise says it has identified unauthorised access to application identities, disabled seven of them on 17 October, and suspended Cloud Backup.

That makes it a supply-chain incident of a kind many organisations have not planned for: the thing that failed was not your sign-in but an integration you authorised years ago and may have forgotten.

What is confirmed

ConnectWise's statement, as reported by The Hacker News and BleepingComputer, says the unauthorised access affected application identities, that seven were disabled at 07:00 UTC on 17 October, and that it revoked the certificates used for affected connections, which suspended Cloud Backup for all users. Cloud Management and SaaS Security services were also taken offline as a precaution. ConnectWise says the cause is under investigation, and that backup archives remain encrypted and isolated with no evidence they were accessed. Restores are unavailable. BleepingComputer adds that Microsoft confirmed suspicious sign-ins from 15 October.

Huntress's write-up is the detailed account. It reports the following sequence, in UTC:

13 to 14 October. Password spraying against four law-firm tenants from a hosting-provider address. Two accounts were locked out; Huntress saw no successful user sign-ins from that address.
15 October, from about 02:00. In roughly 50 Huntress-monitored tenants, ConnectWise Cloud Management service principals assigned themselves directory roles, mostly Exchange Administrator. In one partner tenant, the Cloud Management Teams app added itself to Global Administrator, then changed two other applications, one of them Huntress's own, adding new client secrets that expired in 2028.
15 October, morning. The Cloud Backup application's identity signed in from the hostile address and received Graph tokens. Huntress confirmed it in 17 of the first roughly 290 tenants it checked.
15 October, later. A second, targeted wave hit 16 Huntress-protected tenants, mostly in policy, national security, trade and critical minerals. Those attempts failed where the relevant service principal was absent.
16 October. As of 19:00, Huntress had confirmed unauthorised sign-ins in 162 tenants. It also reports sign-in activity from the attacker's address in about 1,000 Entra tenants with over 300 successful, a broader figure it does not call fully confirmed. Huntress says these counts are likely undercounts because it can only read sign-in logs in tenants where it has the right access and licensing.

BleepingComputer, relaying Huntress, Microsoft and the security firm Todyl, notes that the sign-ins were automated and made as the application using its credential, which bypasses multi-factor authentication because no user is signing in. Todyl saw no account creation, password changes or persistence in the nine tenants it analysed.

What is not known

How the credential was obtained. Huntress describes it as a client assertion held in the vendor's own tenant. ConnectWise has not said how it was exposed, and whether a product vulnerability played a part is not stated.
What was read. Huntress found no mail or file access in the audit log of the tenant it examined in detail, but notes that Graph reads are not logged, so access cannot be ruled out.
The total victim count. The figures above are Huntress's and are lower bounds.
Whether one actor did all of it. Huntress does not tie the early-October role changes to the later sign-in phase.
Whether the remaining vendor apps are safe. Huntress says it cannot verify this, and said some newly identified apps did not appear disabled in an early update on 17 October.

Why this is a secrets problem

A service principal is an identity for software. It authenticates with a client secret or a certificate rather than a person's password, so it often skips multi-factor authentication and lives for years. A backup tool needs wide permissions to read mail, files and directory data, which makes its credential worth far more than any single user's.

The follow-on behaviour is the second lesson. Apps that grant themselves roles and add client secrets to other trusted applications are buying persistence: even after the original application is switched off, a secret planted on a different app still works. That is why the advice below is about auditing credentials across all applications, not only the vendor's.

What to do in your Microsoft 365 and Entra tenants

Find the vendor apps. Look in Entra for enterprise applications and app registrations from ConnectWise and SkyKick, including old entries such as a SkyKick cloud manager from past migrations or backups. Do this for your own tenant and for any customer tenants you manage.
Disable, do not delete. Huntress advises disabling the Cloud Backup and Cloud Management Teams apps, because deleting removes consent and requires re-consent to restore service. Consider disabling other ConnectWise and SkyKick apps until ConnectWise confirms they are safe, and do not re-enable them until it confirms all credentials were reset.
Audit credentials on every app. Look at client secrets and certificates on all enterprise applications and app registrations, especially management and security tools, for any added since 13 October that you did not create, and remove them.
Read the audit log. Look for ConnectWise or SkyKick apps adding themselves to directory roles or modifying other applications, and for service-principal sign-ins from non-Microsoft addresses from about 01:00 UTC on 15 October. Huntress notes the vendor's own activity used a .NET user agent while the suspicious changes used a Python one.
Remove roles you did not grant. After disabling the apps, take any Global Administrator, Privileged Authentication Administrator or Exchange Administrator role off them.
Check the places an intruder hides. Mailbox forwarding and transport rules, delegated access, consent grants, federation trusts and recent policy changes.
Understand what disabling does not do. It stops new tokens, but tokens already issued remain valid until they expire, and revoking user sessions does not end access held by an application. Plan on a window of residual risk.
Shrink the next incident. Use application management policies to restrict client secrets, limit who holds Application Administrator roles, and consider protections for workload identities such as Conditional Access.

The rotation handover

If you replace secrets and certificates on your own applications, the new values have to reach whoever configures them. During a vendor incident that is the moment values end up pasted into a chat or ticket in the same tenant that may be compromised. Deliver each value once to the one person who needs it, over a channel that does not retain it and does not depend on the tenant under suspicion.

Where Secretus fits, and where it does not

Secretus covers that handover: a person encrypts a short text secret in the browser and shares a link that stops working after the expiry they set or the first successful open. Team Split can require several holders to reconstruct a high-value text secret.

It is not an identity or cloud-security product. It cannot disable an Entra application, audit secrets across your tenants, revoke tokens or tell you whether your tenant was among the victims. Use Microsoft's tooling, Huntress's guidance and your own process for that, and a one-time link for the moment one person gives another a new credential.