A compromised ConnectWise Cloud Backup service principal opens 173 Microsoft 365 tenants
On October 17, 2026, ConnectWise shuts down access to its Cloud Backup service after attackers compromised the service’s application identity and signed into Microsoft 365 tenants using permissions customers had already granted. Audit your vendors’ service principals, disable the implicated ConnectWise apps, and revoke their secrets.
October 15, 2026. Microsoft spots unauthorized authentication attempts from a single IP address, 144.172.64.128, against Microsoft 365 tenants. October 16, 2026. Huntress confirms at least 162 compromised tenants in its environment, and Todyl details the mechanics. October 17, 2026, 05:01 UTC. ConnectWise shuts off customer access to its Cloud Backup service, formerly SkyKick Cloud Backup. Why it matters: the attacker cracked no password and bypassed no MFA. It used the secret of a legitimate backup application, and the permissions customers had already granted it, to walk into their tenants.
A supply-chain attack that runs through the application identity, not the data
The entry point is neither a workstation nor a user account. It is the service principal — the application identity — that ConnectWise Cloud Backup uses to back up its customers’ Microsoft 365 data. To function, the service relies on permissions granted through Microsoft Entra ID: an identity known as a service principal represents the software inside the customer’s tenant and accesses resources according to the rights it was given.
According to Todyl, the attacker authenticated directly to Microsoft 365 as the backup application, using its secret. The sign-ins were performed by an automated script, and because they involved no user login, protections such as MFA had no effect.
The consequence is brutal. “Because the application already held broad, previously granted permissions in each tenant, those sign-ins gave the attacker the technical ability to read and write mail and attachments, OneDrive and SharePoint files, and Teams chats,” Todyl summarizes. Across the nine tenants analyzed in depth, however, the researchers found only sign-in activity — no account creation, no permission addition, no password change, and no persistence through the backup app.
Persistence: a Global Admin role granted in five minutes
The picture darkens on Huntress’ side. Across nearly 50 tenants it monitors, the platform saw ConnectWise Cloud Management service principals — Exchange Online, Microsoft Teams, and Microsoft Graph — assign themselves directory roles, most often Exchange Administrator.
In one tenant, the researchers watched the attacker establish persistence in roughly five minutes. The Cloud Management - MS Teams application granted itself a Global Administrator role, then added credentials to an MSP management tool and to Huntress’ own application.
Microsoft confirmed the same pattern: persistence via a backdoor after a successful service-principal authentication, followed by Microsoft Graph API reconnaissance and attempts to add further credentials. Microsoft Threat Intelligence characterized the incident as an active supply-chain attack, assessing that the attacker likely abused existing permissions, including Directory.ReadWrite.All.
The indicators to hunt for right now
The three security vendors — Huntress, Microsoft, and Todyl — all tied the activity to the same IP address, 144.172.64.128. Huntress identified the legitimate application ID used in the attacks and linked it to scripted sign-ins as early as October 13 and 14, with the user agent curl/7.88.1. Three other user agents are associated with the malicious activity: python-urllib/3.12, python-requests/2.31, and python-requests/2.34.2.
Here are the application IDs to look for in your Entra ID logs:
ConnectWise Cloud Backup 506e08f9-6e9a-4da4-942b-a099a03644ae
ConnectWise Cloud Management 2399d300-6fca-4e6a-a686-399fefe75b83
ConnectWise Cloud Management - MS Teams 24205314-2b89-4e07-a2a4-579e898a5640
ConnectWise Cloud Management - Exchange b78f6a77-d4e5-46fb-87e5-d1648bd02519
ConnectWise Cloud Management - MS Graph 0de14c77-b9b0-4137-9360-34878a929827ConnectWise recommends filtering service-principal sign-ins in Entra on these IDs and examining unexpected source addresses. Microsoft advises reviewing application credential changes, OAuth grants, and related Graph activity. Older tenants may list these apps under SkyKick Cloud Manager.
To automate the hunt across your logs, the Microsoft Graph query below lists the backup service principal’s sign-ins:
# Microsoft Graph PowerShell — Cloud Backup service principal sign-ins
Get-MgAuditLogSignIn -Filter "appId eq '506e08f9-6e9a-4da4-942b-a099a03644ae'"Then filter for unexpected source IPs and cross-reference the directory roles assigned in Entra — Get-MgDirectoryRoleMember lists a role’s members. Any Exchange Administrator or Global Administrator role assigned to a backup application is an immediate red flag.
Beyond the sign-in logs, review the application’s OAuth consent grants and any credential additions since October 13. Huntress advises disabling the implicated apps, but remember Todyl’s caveat: existing tokens stay valid until they expire, so disabling the app is the start of the cleanup, not the end.
What this changes for MSPs and their customers
The incident redraws the trust boundary between an MSP and the software it deploys at its customers. An MSP running ConnectWise Cloud Backup has, by design, installed an application identity inside dozens or hundreds of Entra ID tenants. Each such service principal is a delegated privileged identity: it carries the permissions the customer consented to, often broad, and it authenticates with no human interaction.
That is what makes the breach so asymmetric. The attacker did not have to target each customer one by one. By obtaining the backup application’s secret, it inherited a skeleton key that opens every tenant where that app is consented. MFA, which protects human sign-ins, simply does not apply to scripted application sign-ins.
For end customers, the consequence is an inversion of the security reflex: the question is no longer “was my vendor breached?” but “what permissions did I grant my vendor, and who watches how its application uses them?” The answer is not to drop your MSP — it is to treat their service principals as privileged accounts, with logging, alerting, and secret rotation.
The blind spot: shutting the app down is not enough
The service interruption announced by ConnectWise does not remove credentials already planted in tenants. Huntress stresses that admins must review the secrets and certificates of all applications since October 13 and delete unauthorized additions.
Todyl points to a subtler trap. Disabling an application stops new tokens from being issued, but existing tokens remain valid until they expire. And revoking user sessions does not end application-based access. A compromised application that already holds a long-lived token keeps acting, even after the service is cut.
The initial vector — how the attacker obtained the vendor’s secret — remains unknown at the time of publication, as does the exact victim count and the real extent of exfiltration. ConnectWise reported no evidence that stored backups were compromised.
Verdict
If your organization is a customer of an MSP using ConnectWise Cloud Backup, act before waiting for the vendor’s communication: disable the implicated ConnectWise apps, revoke the secrets and certificates added since October 13, and audit directory roles — especially any Exchange Administrator or Global Administrator assigned to a service principal. If you are not a customer, the lesson still holds: every third-party application holding permissions in your Entra ID tenant is a privileged identity to monitor continuously, not a vendor to forget after onboarding. MFA does not protect application authentication — only secret rotation and consent controls do. Treat every vendor service principal like a break-glass account: scoped permissions, short-lived secrets, and an alert when it does something it has never done before. And if the query above returns nothing today, run it again next week — once persistence is established, the attacker’s window is measured in minutes, and the only reliable tripwire is continuous monitoring of application sign-ins.