ConnectWise Cloud Backup Incident Turns App Trust Into Tenant Risk

ConnectWise says it is investigating unauthorized access to application identities associated with Cloud Backup, formerly SkyKick. At 07:00 UTC on October 17, the company disabled seven ConnectWise application identities and revoked certificates used by affected Cloud Backup connections. Cloud Backup remains suspended, scheduled backups are not running, and affected archives and restore functions are unavailable. ConnectWise says existing archives remain encrypted, isolated, and preserved, with no evidence that they were accessed.

The live Microsoft 365 tenant is a separate incident boundary. Huntress directly observed the Cloud Backup credential authenticate from 144.172.64.128 and obtain Microsoft Graph tokens in customer tenants. In one tenant, a second ConnectWise application granted itself Global Administrator and added credentials to two other applications. Disabling the seven vendor identities stops new authentication through those connections, but it does not remove attacker-added secrets, roles, consent, forwarding rules, or separate identities. MSPs need to preserve short-lived Entra evidence, review every managed tenant, remove confirmed persistence, and plan around the backup gap before reconnecting.

ConnectWise first published the advisory on October 16 after detecting attempts at unauthorized access associated with Cloud Backup. By its October 18 update, the company described unauthorized access to application identities, the disablement of seven identities, certificate revocation, a third-party forensic investigation, and a wider review of partner-facing services. It says no successful threat activity has been observed in the environments it monitors since the mitigations were applied.

That vendor-side status does not settle customer impact. ConnectWise says the design of Cloud Backup does not give it the downstream visibility needed to determine whether a particular Microsoft 365 tenant experienced unauthorized activity. The company is therefore directing partners to review their own tenant and every managed customer tenant, including environments with dormant SkyKick connections.

Huntress provides the direct tenant evidence. It reports that the Cloud Backup identity authenticated from 144.172.64.128 on October 15, between 06:13 and 08:34 UTC, and received Microsoft Graph tokens. The actor moved through tenants in sorted GUID order, seconds apart. As of 19:00 UTC on October 16, Huntress had confirmed unauthorized sign-ins in 162 tenants. That is not a universal victim count, and a successful token request does not by itself prove data access or theft.

Cloud backup needs broad permissions to copy and restore mailboxes, files, collaboration data, and directory information. In Microsoft Entra, a multitenant service is represented in each customer directory by a service principal. The vendor-controlled application authenticates with its own certificate or secret, then receives app-only tokens for the permissions administrators already granted. There is no employee typing a password during this flow.

That explains why ordinary user-focused checks are incomplete. The default user sign-in view does not show the relevant authentication. Administrators need the Service principal sign-ins view, filtered by application client ID, and must expand grouped records to see individual timestamps. Microsoft documents that these records show the identity, status, address, and target resource for certificate or client-secret authentication.

The distinction also changes containment. Resetting employee passwords or requiring stronger MFA does not revoke a third-party application's certificate, remove its consent, or erase a secret added to another application. User Conditional Access policies do not automatically govern app-only access, and Microsoft says workload-identity Conditional Access does not cover third-party multitenant applications in the same way it covers supported single-tenant service principals.

Huntress observed a more serious sequence in one partner tenant on October 15. The ConnectWise Cloud Management application for Microsoft Teams assigned itself Global Administrator, then a Python client modified an MSP management application and Huntress's own single-tenant application. Six of nine changes succeeded, including new client secrets with 2028 expiration dates. An attempted certificate addition failed.

This is why disabling the original Cloud Backup identity is necessary but insufficient. A new secret on another application is a separate authentication path. So are a new application or service principal, an unauthorized owner, a directory-role assignment, an elevated consent grant, a federation trust, a policy exclusion, a mailbox delegation, or an inbox or transport rule. Each can persist after the vendor credential stops working.

The known sequence took about five minutes. Review ApplicationManagement and RoleManagement events from October 13 onward for application or service-principal credential changes, new objects, owners, role assignments, consent, and delegated permission grants. Follow the initiating identity into every object it changed. A new valid vendor credential does not remove an attacker-created credential from a different object.

ConnectWise disabled seven application identities: Cloud Backup; Cloud Management; and Cloud Management integrations for Microsoft Teams, Exchange Online, Microsoft Graph, Partner Center, and SharePoint Online. Older tenants may display SkyKick Cloud Manager names. The reliable lookup key is the published application client ID, not a display name that can be duplicated or changed.

Partners should verify each local enterprise application's status even though ConnectWise disabled its side of the connection. Microsoft documents that setting a tenant's service principal accountEnabled property to false prevents token issuance for that application in the tenant while preserving the object for investigation. ConnectWise and Huntress both advise disabling rather than immediately deleting affected applications so administrators retain configuration and evidence and do not complicate eventual restoration.

Revoking ConnectWise's certificates invalidated the affected shared Cloud Backup credentials. ConnectWise warns that previously issued access tokens can remain usable until they expire or are otherwise invalidated. More importantly, the vendor cannot remove secrets, roles, consents, policies, or mailbox changes created under separate customer-controlled identities. Those changes belong to each tenant's response.

Start by exporting available Entra interactive-user, non-interactive-user, service-principal, and managed-identity sign-ins, plus directory audit logs and Microsoft Purview audit data. ConnectWise recommends reviewing from October 13 through the present and extending to October 1 where retention allows. Its published suspicious address, 144.172.64.128, is an important pivot, but an address match is an investigation lead rather than proof of successful compromise or exfiltration.

Do not reduce the hunt to one IP. Huntress observed a second application connection through an Azure private IPv6 range that is also used by legitimate ConnectWise and unrelated customer activity. User agents such as Python-urllib/3.12, python-requests, curl, and kiota-dotnet provide context but are not verdicts. Correlate initiator, target, result, resource, correlation ID, modified properties, and approved change records.

The negative-evidence limit is material. Huntress says Microsoft audit logs record role assignments and application changes, but app-only actions may lack source IP, credential detail, or a record of what was read through Graph. Directory reads can leave no audit trail. ConnectWise also notes that Entra normally retains audit and sign-in records for seven days on Free and 30 days on P1 or P2, while exported or SIEM copies may last longer. Record the actual coverage and every blind spot.

For each tenant, compare application and service-principal credentials with approved inventory; review high-impact directory roles; inspect application owners and permission grants; and check Conditional Access, named locations, user authentication changes, mailbox forwarding, inbox rules, transport rules, delegation, SharePoint, OneDrive, and Teams activity. Preserve the object IDs, key IDs, thumbprints, validity periods, timestamps, and event records before removing confirmed unauthorized access.

Cloud Backup, SaaS Security, and Cloud Management remain offline as of the October 18 update. Scheduled backup jobs are not running, archives and restore functions are unavailable, and there is no published restoration time. Existing archives are not reported lost or accessed, but organizations should document the last successful recovery point and the growing protection gap. Business continuity decisions should not silently trade tenant containment for an unverified reconnection.

Re-enable only after ConnectWise publishes restoration instructions, the tenant investigation is complete enough to explain suspicious changes, unauthorized credentials and privileges are removed, and new backup jobs and workload connections can be verified. Keep separate conclusions for vendor infrastructure, stored archives, live tenant access, persistence, and data activity. Evidence in one boundary does not automatically answer the others.