ConnectWise Halts Cloud Backup After App Identity Compromise Hits Microsoft 365 Tenants

ConnectWise suspended its Cloud Backup service after unknown attackers gained unauthorized access to its application identities and used them to enter Microsoft 365 tenants.

The company said it detected the issue on October 14, 2026, through its security monitoring and began an investigation. According to the ConnectWise account reported by The Hacker News, it disabled seven application identities and revoked the certificates supporting affected connections at 07:00 UTC on October 17.

A separate report says ConnectWise announced the Cloud Backup interruption at 05:01 UTC on October 17. These times refer respectively to the reported mitigation action and service announcement and should not be treated as a single timestamp.

The shutdown prevents new authentication through the affected connections, but it does not remove credentials, permissions or other persistence mechanisms that attackers may already have created inside customer tenants.

Backup and management services taken offline

Cloud Backup, formerly SkyKick Cloud Backup, provides backup and recovery for Microsoft 365 and Google Workspace. ConnectWise also temporarily took SaaS Security and Cloud Management offline while it reviews the incident.

Scheduled backups are not running, and customers cannot currently use affected backup archives or restore functions. ConnectWise says existing archives remain encrypted, isolated and preserved. The company has reported no evidence that stored backups or partner backup data were accessed or compromised.

ConnectWise said the shared Cloud Backup credentials involved in the incident are no longer valid. However, access tokens issued before revocation can remain usable until they expire or are separately invalidated. Disabling the original connection also does not neutralize credentials or permissions planted through other application identities.

The company listed these seven disabled identities:

In older tenants, some Cloud Management applications may appear under the name SkyKick Cloud Manager.

ConnectWise has not determined whether a vulnerability in one of its products contributed to the compromise. The mechanism through which the application credentials were exposed remains under investigation.

Application credentials bypassed user authentication

The attack did not require a Microsoft 365 user’s password. Researchers said the actor authenticated as the backup application by presenting its secret to Microsoft Entra ID and requesting tokens carrying permissions that customers had already granted.

Because this was application-based authentication rather than an interactive user login, user MFA did not apply. Revoking user sessions would not, by itself, terminate the application’s access.

Those existing permissions were extensive. Todyl said the application could technically read and write email and attachments, OneDrive and SharePoint files, and Teams chats. That describes what the authorization permitted, not evidence that all those data types were accessed.

Broader management permissions also created routes to persistence. Huntress observed service principals associated with ConnectWise Cloud Management assigning themselves directory roles in nearly 50 monitored tenants, most commonly Exchange Administrator. In one tenant, the Cloud Management - MS Teams service principal assigned itself Global Administrator and added credentials to an MSP management application and to Huntress’s own application. Huntress said the sequence took about five minutes.

Microsoft, as reported by BleepingComputer, characterized the operation as an active supply-chain attack and assessed that the actor likely abused existing permissions including Directory.ReadWrite.All. Microsoft reportedly observed a backdoor after successful service-principal authentication, followed by Microsoft Graph reconnaissance and attempts to add credentials.

Sign-in activity and confirmed compromise are different measures

Huntress found sign-in activity from the attacker’s IP address across almost 1,000 Entra tenants. Of those sign-ins, 300 succeeded, but a successful authentication did not always provide tenant access: in some cases, the required service principal was not present.

Within Huntress’s own environment, researchers identified at least 162 compromised tenants. That figure is distinct from the almost 1,000 tenants showing sign-in activity and the 300 successful sign-ins.

Other findings cover narrower samples:

• Todyl examined nine tenants and found only sign-in activity. It did not identify account creation, permission or password changes, or persistence through the backup application in those tenants.
• Huntress confirmed abuse of the Teams application in one tenant.
• Nearly 50 Huntress-monitored tenants showed directory-role self-assignment involving ConnectWise Cloud Management service principals.
• A second targeted wave selected 16 tenants in the policy, national security, trade and critical-mineral sectors, but Huntress said those attempts failed.

Huntress linked scripted attempts using curl/7.88.1 to October 13 and 14, 2026. ConnectWise detected the wider issue on October 14.

On October 15, Huntress recorded the last malicious sign-in from the original address at 08:45 UTC. A subsequent sweep targeting Graph tokens associated with the SkyKick application ran from 09:25:04 to 12:35:50 UTC. A second, apparently manual sweep against the same 16 tenants occurred from 13:54:39 to 14:20:24 UTC, targeting Exchange Online, SharePoint Online, Teams, Azure Resource Manager, Entra and Office 365 Management APIs.

Huntress said it had not identified new malicious activity after October 15. ConnectWise likewise said it had not seen successful activity in environments it monitors since applying its mitigations, while cautioning that it cannot directly observe downstream customer environments.

Indicators and tenant checks

The principal network indicator is:

• IP address: 144.172.64[.]128

User agents associated with the activity include:

• python-urllib/3.12
• python-requests/2.31
• python-requests/2.34.2
• curl/7.88.1

ConnectWise partners should examine both their own Microsoft 365 environments and every managed customer tenant, including dormant SkyKick connections. Recommended checks include:

1. Search Entra service-principal sign-ins for the seven application IDs and unexpected source addresses, particularly 144.172.64[.]128.
2. Review sign-ins across identities from October 13, 2026 onward.
3. Preserve sign-in and audit records before containment actions alter the available evidence.
4. Inspect application credentials, secrets and certificates for unauthorized additions made since October 13.
5. Review OAuth consent grants, directory roles, application owners, federation trusts and recent policy changes.
6. Look for newly added credentials on other trusted applications, not only the original ConnectWise identity.
7. Check Exchange for unauthorized forwarding, inbox or transport rules, and delegated mailbox access.
8. Review other Cloud Management integrations and investigate identities changed or used during suspicious activity.

Huntress also recommends restricting who holds Application Administrator and Cloud Application Administrator, using application-management policies to limit client secrets and credential lifetimes, and applying Conditional Access for workload identities where licensing permits. Microsoft Entra ID Protection can also identify risky service principals.

These controls do not replace credential review. ConnectWise’s revocation stops new authentication through the affected connections, but each tenant still needs to determine whether the attacker created a separate route that survives the original credential’s removal.