ConnectWise Backup Credential Opens Graph Access in 162 Tenants

A stolen ConnectWise Cloud Backup credential let an operator sign in to customer Microsoft 365 tenants and obtain Microsoft Graph tokens. Huntress confirmed unauthorized service-principal sign-ins in 162 tenants by 19:00 UTC on October 16. Any tenant that has consented to the backup application needs to identify its service principal, because the vendor-held credential works across those installations.

ConnectWise identified unauthorized access to application identities in its Cloud Backup environment and said at 05:11 UTC on October 17 that it was shutting off Cloud Backup application access. That interrupts new backups. Existing archives remain in place, according to ConnectWise, and its own investigation has found no indicator to date that partner backup data was compromised. The customer-tenant Graph sign-ins are a separate, observed access path.

A vendor credential crosses tenants

ConnectWise Cloud Backup, formerly SkyKick, needs consent to handle customer mail, files, Teams content and directory data. Huntress says the operator used a vendor-held client assertion to authenticate as the legitimate backup application, ID 506e08f9-6e9a-4da4-942b-a099a03644ae. Entra issued Graph tokens with that application’s existing permissions. This is app-only access: a user’s password, device sign-in and MFA prompt are outside the transaction. The specific permissions, and therefore what the token holder could do, depend on the consent in each tenant.

On October 15, Huntress saw the backup identity authenticate from hosting-provider address 144.172.64[.]128 between 06:13 and 08:34 UTC. Legitimate backup traffic normally came from Azure private IPv6 space. Huntress describes tenant GUIDs processed in sorted order seconds apart, consistent with a scripted list. Huntress concludes: “The app’s credential is in hostile hands.” Investigate token access across consenting tenants, including those outside Huntress’s confirmed sign-in set.

Another application added working secrets

Huntress also examined a different ConnectWise application in one partner tenant. At 03:44 to 03:49 UTC on October 15, ConnectWise Cloud Management - MS Teams, ID 24205314-2b89-4e07-a2a4-579e898a5640, assigned itself Global Administrator and changed two other applications: an MSP management app and the Huntress Security Platform app. Six of nine application changes succeeded, including new client secrets expiring in 2028. The activity used Python-urllib/3.12; Huntress says its reviewed ConnectWise management traffic used kiota-dotnet.

The app-only audit events omit the earlier changes’ source IP, so Huntress cannot link their operator to the later backup sign-ins from 144.172.64[.]128. Huntress saw no mail or file access in the one tenant it examined in detail; Graph directory reads leave no tenant audit trail. Disabling the backup app removes its tenant-local sign-in path; credentials already added to other apps remain available until their owners remove them. An MSP management application’s permissions may extend to client tenants, so review its consent and credentials across those tenants as well.

Find the app-only sign-ins

In Microsoft Entra admin center, open Monitoring > Sign-in logs > Service principal sign-ins. Filter for Cloud Backup application ID 506e08f9-6e9a-4da4-942b-a099a03644ae and examine October 15 activity, especially 144.172.64[.]128 and other addresses outside expected Microsoft/Azure ranges. The User sign-ins tab tracks a different kind of session. ConnectWise also lists Python-urllib/3.12 and python-requests/2.31 among observed authentication user agents; Huntress saw curl/7.88.1 during password spraying from the same address on October 13 and 14. Pair those strings with the initiating identity, operation, target and time before escalating.

Review Entra audit events since October 13 for Add member to role, Update application and Add service principal credentials, especially self-assigned Global Administrator or Privileged Authentication Administrator roles and new client secrets or certificates on management and security applications. Compare each application’s current credentials with approved records. Inspect current credentials because app-only audit events lack the source IP and added-secret details.

Disable access and inspect persistence

Find Cloud Backup under Entra ID > Enterprise apps > All applications, open Properties, set Enabled for users to sign-in? to No, and save. Microsoft documents that this sets the tenant service principal’s accountEnabled property to false and prevents tokens from being issued for that app in the tenant. In Monitoring > Sign-in logs > Service principal sign-ins, retain the October 15 events for app ID 506e08f9-6e9a-4da4-942b-a099a03644ae with their time, result and source IP. Compare these rows with directory-role and application-credential change events in the Entra audit log. Read back accountEnabled after saving and expect false. Retain the application for investigation and eventual recovery rather than deleting its consent.

Huntress also recommends disabling Cloud Management - MS Teams, ID 24205314-2b89-4e07-a2a4-579e898a5640, and reviewing other ConnectWise or SkyKick Cloud Manager applications. Check their directory roles and remove assignments you did not approve after disabling them. Inspect client secrets and certificates on the other applications they could manage, particularly MSP and security tools, and remove credentials you did not create. Check workload-identity Conditional Access exclusions that could allow the vendor application to authenticate from unexpected locations.

Cloud Backup service interruption means a gap in new recovery points; confirm retention and restore arrangements with ConnectWise. Wait for ConnectWise to confirm its credentials have been reset before restoring affected application sign-ins. Then verify each tenant’s service-principal state, role assignments and application credentials against the approved inventory, and continue investigating any anomalous sign-in or application change. Keep inspecting credentials after a quiet search for 144.172.64[.]128; the new secrets could support another route into those applications.