Stolen ConnectWise backup credential opened M365 tenants
An attacker used the ConnectWise Cloud Backup (SkyKick) app's own credential to sign in to 162 Microsoft 365 tenants. How it worked and what to check in Entra.
By Yaali. October 20, 2026, 6 min read, Identity, Threat intel, Resilience.
ConnectWise has switched off Cloud Backup, the Microsoft 365 backup product it bought as SkyKick, after an attacker used the application's own credential to sign in to customer tenants. Huntress, which picked up the activity after one of its partners flagged it, had confirmed unauthorised sign-ins in 162 Microsoft 365 tenants by 19:00 UTC on October 16. SaaS Security and Cloud Management, which run on the same integration, went offline with it, and ConnectWise has given no date for bringing them back.
If any tenant you run, or that your managed service provider (MSP) runs for you, has ever consented to ConnectWise Cloud Backup, SkyKick Cloud Manager or ConnectWise Cloud Management, check it this week. Revoking the vendor credential stops new sign-ins. It does not remove roles or secrets an attacker added inside your tenant, and that clean-up falls to each customer. While the service is down, backups are not running and restores are unavailable.

How it works
Cloud Backup is a multitenant application. It is registered once, in ConnectWise's own Microsoft Entra ID tenant. Each customer who signs up grants it consent, which creates a service principal (the app's local identity) in their tenant holding the permissions a backup needs: mail, OneDrive, SharePoint, Teams and directory data.
To run a backup, the app proves who it is to Microsoft with a credential kept in the vendor's tenant, names the customer tenant it wants, and receives an access token for Microsoft Graph carrying whatever that customer approved. That credential is what the attacker had. Huntress describes it as a client assertion, a signed token the app presents in place of a password; Todyl, another security firm, calls it a client secret. Both place it in ConnectWise's tenant, so nothing a customer did could have prevented the theft.
With that credential, the attacker could request a token in any tenant that had consented to the app. No user signs in during this flow, so there is no MFA prompt, and Conditional Access policies written for users do not apply. Microsoft described it as "an active supply-chain attack involving the compromise of a trusted OAuth App" and said the attacker "likely abused permissions previously granted by customers." How the credential leaked is still under investigation, and ConnectWise says it has not established whether a product vulnerability played a part.
What attackers did
On October 15, between 06:13 and 08:34 UTC, the Cloud Backup app requested Graph tokens from 144.172.64.128, an address at a hosting provider, instead of the private Azure addresses its legitimate traffic uses. It moved through tenants in sorted GUID order, a few seconds apart, which Huntress says "points to an automated script working from a target list." The same address had run a password spray against four law firm tenants on October 13 and 14, without success.
Earlier that morning, at 03:44 UTC, the ConnectWise Cloud Management app for Microsoft Teams added itself to the Global Administrator role in one tenant. Within about five minutes, a Python script had added new client secrets, valid until 2028, to two other trusted applications in that tenant, one of them Huntress's own agent app. A second tenant showed the same sequence two minutes later. Secrets like these give the attacker a way back in that no longer depends on ConnectWise's credential.
A separate wave between 09:25 and 14:20 UTC went after 16 tenants in policy, national security, trade and critical minerals, most of which do not use ConnectWise products. Huntress also found close to 1,000 tenants with sign-ins from the attacker's address, more than 300 of them successful. It has not established whether one operator is behind every phase.
Not every role change may be hostile. At 01:58 UTC on October 15, Cloud Management service principals in about 50 tenants gave themselves directory roles, mostly Exchange Administrator, with the user agent kiota-dotnet that ConnectWise's own automation uses. Huntress suggests this was vendor automation; ConnectWise has not confirmed it.
Data theft is unconfirmed either way. In the one tenant Huntress reviewed in detail it found no mail or file access, but Graph directory reads leave no audit record, so a clean log does not prove nothing was read. ConnectWise says its stored backup archives are encrypted, isolated and show no sign of access.
On October 17 ConnectWise disabled seven application identities, revoked the certificates used for affected connections and invalidated the shared Cloud Backup credentials. It says it has seen no successful attacker activity since. It also warns that tokens issued before the shutdown may stay usable until they expire, and that it cannot see inside customer tenants, so it cannot say which ones were breached.
What to do

Disable the apps, do not delete them. In the Microsoft Entra admin center, open Enterprise applications and search for "ConnectWise" and "SkyKick". For each one, open Properties and set "Enabled for users to sign-in?" to No. The Cloud Backup app ID is 506e08f9-6e9a-4da4-942b-a099a03644ae and the Cloud Management Teams app is 24205314-2b89-4e07-a2a4-579e898a5640; older tenants may list "SkyKick Cloud Manager". Deleting the app removes the consent, which makes restoring the service later harder. Tokens already issued can stay valid for up to 90 minutes after you disable it.
Check service principal sign-ins. In Sign-in logs, switch to the Service principal sign-ins tab, since the default user view does not show app traffic. Filter on the Cloud Backup app ID and look for 144.172.64.128 and any address outside Microsoft ranges. ConnectWise added 144.172.64.99 and 144.172.64.60 to its advisory on October 19. Huntress suggests covering at least 01:00 UTC on October 15 to 02:00 UTC on October 16. A clean result does not clear the tenant, so disable the apps regardless.
Search the audit log from October 13. In Entra audit logs, filter on the activities Add member to role, Update application and Add service principal credentials. Flag any service principal that put itself in a directory role or changed another application. Python-urllib/3.12 was the user agent on the planted credentials, although plenty of legitimate tooling uses it too.
Remove what you did not add. On every enterprise application and app registration, starting with management and security tools, delete client secrets and certificates added since October 13 that your team did not create. Take away directory roles held by ConnectWise or SkyKick apps that you never granted, Global Administrator and Privileged Authentication Administrator first. Then follow ConnectWise's own list: mailbox forwarding, inbox rules, delegated mailbox access and federation trusts.
Keep the apps off until ConnectWise says otherwise. Leave them disabled until it publishes formal restoration instructions and confirms every credential has been reset. If Cloud Backup was your only copy of Microsoft 365 data, you have no restore path today, so treat deletions and retention changes with extra care until it returns.
The wider lesson for app consent
Backup and management tools hold some of the broadest consent in a Microsoft 365 tenant, and they sign in as themselves, outside the MFA and Conditional Access controls built around users. List the enterprise apps in your tenant that hold directory roles or high-privilege Graph permissions and remove any you no longer use. Application management policies in Entra can block new client secrets and cap credential lifetimes on the apps and service principals in your tenant, which makes secrets like the ones valid until 2028 much harder to plant. Keep the Application Administrator and Cloud Application Administrator roles to a short list of people.
Our security operations team reviews Entra sign-in and audit logs for this kind of service principal activity, and our safeguarding and hardening work covers app consent and credential policy in Microsoft 365. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the check.
Sources: Huntress, Help Net Security, The Record, CSO Online, Cybersecurity Dive, Quisitive.
Read next
- Hijacked .gh, .sl and .as registries minted Google certificates
- Denmark CPR breach: one firm's lookup access, 8.8M people
- 543,699 live keys sit in public GitHub repos
Back to the blog, or tell us about your system in the chat. Yaali, our AI agent, answers first and brings in an engineer.