A ConnectWise Cloud Backup subscription could be inactive while its Microsoft 365 tenant still allowed the backup application to sign in. Sophos X-Ops observed an automated sweep of app-only Microsoft Graph token requests on October 15 that included tenants without active backup subscriptions. Anyone who used ConnectWise Cloud Backup or its former SkyKick service needs to check the old application consent, even if they stopped paying for backups.
Sophos’s research extends Nulltap’s earlier account of the ConnectWise credential incident to former customers. As ConnectWise begins a phased service restoration, an inactive subscription is still the wrong filter for deciding which tenants to examine. The sign-ins Sophos saw ran from 07:11 to 08:47 UTC, from 144.172.64[.]128, in ascending tenant GUID order. Sophos assesses with high confidence that a script worked through a list of consenting tenants.
One application, many tenant consents
ConnectWise Cloud Backup used a multi-tenant Microsoft Entra application. A customer granted that application permission to read Microsoft 365 data for backups. The vendor-held application identity could then request a Microsoft Graph token in each consenting tenant under the permissions that tenant had granted. During this incident, the attacker authenticated as that application, so the requests needed neither a user’s password nor the user’s MFA challenge. Sophos says this activity is consistent with abuse of a compromised vendor-held application credential; the route by which the actor obtained it remains under investigation.
Sophos observed one app-only Graph token request per targeted tenant, spaced one to six minutes apart. Its report specifically includes “tenants with no active backup subscription” in the sweep. A tenant can retain the application’s consent after its backup subscription ends. Sophos could not determine what the actor did with the obtained tokens; where Graph activity records were already collected, administrators can check which requests reached Graph.
Find the sign-ins in Entra
ConnectWise’s incident updates identify the affected Cloud Backup application ID as 506e08f9-6e9a-4da4-942b-a099a03644ae. In the Microsoft Entra admin center, open Monitoring & health → Sign-in logs → Service principal sign-ins and filter on that application ID. Microsoft distinguishes service-principal sign-ins from interactive user sign-ins; the default user view misses this app-only activity.
Review October 15–17 sign-ins for the Cloud Backup or SkyKick application, including tenants that used the product previously. Sophos observed the source IP 144[.]172[.]64[.]128 and user agents Python-urllib/3.12 and python-requests/2.31. ConnectWise also lists 144[.]172[.]64[.]99 and 144[.]172[.]64[.]60 as infrastructure reported through downstream monitoring; Sophos says it did not observe those two addresses in its own telemetry. Match the application identity, time and source together before judging a sign-in; ConnectWise says an indicator match alone warrants investigation.
Sophos reported no new secrets, applications, consents or role assignments in the tenants it reviewed at publication. Review Entra audit records since October 13 for new application credentials, app registrations, grants and role assignments associated with the affected identities. Also look for changes made through other identities: ConnectWise says disabling its app connections cannot undo changes already made inside a tenant. If you find an unexpected credential or grant, revoke that access and investigate the affected identity and activity.
Remove old access and test recovery
ConnectWise says it disabled seven affected application identities on October 17 and revoked the certificates used by the affected connections. It completed a reset of Cloud Backup environment accounts and credentials on October 19. Previously issued access tokens could remain usable until expiry or invalidation, and separate identities established during the incident need their own remediation. For your tenant, follow the vendor’s current service instructions, remove consent for the disabled Cloud Backup applications as Sophos recommends, and keep affected connections disabled until ConnectWise gives formal re-enablement instructions for your service.
If your tenant already collected Microsoft Graph activity logs, correlate the application’s AppId, ServicePrincipalId, IPAddress, RequestUri and TimeGenerated with the sign-in window to see what requests reached Graph. Collection requires a Microsoft Entra ID P1 or P2 tenant license, an authorized administrator to configure Azure Monitor diagnostic settings, and an Azure subscription with a permitted Log Analytics, Storage or Event Hubs destination. Check whether collection was enabled during the incident window. If it was absent, use available sign-in and audit records and record the visibility gap. For active-backup tenants, the app’s granted permissions cover data it needs to read for backups.
ConnectWise says its encrypted backup archives are preserved and that its monitoring has seen no successful threat activity since its October 17 mitigations. It also says it cannot inspect each partner’s or customer’s live Microsoft 365 tenant on their behalf. Scheduled backups, archive access and restores were still unavailable in the captured status update as the vendor prepared phased restoration. Plan backup coverage during the interruption rather than assuming a disabled integration still protects new data.
Verify the tenant’s remaining grants
After investigating the sign-ins, compare each current and former Cloud Backup tenant’s enterprise-app consent and credentials with the affected identities in ConnectWise’s guidance. Check for unexpected credentials, grants and role assignments since October 13, revoke any unauthorized access, and document Graph activity if collection was already enabled. Then verify that the disabled connections remain disabled and that the old app consent is gone where removal is appropriate; any reauthorization should follow the vendor’s formal instructions. A service-principal token request and an empty user sign-in view answer different questions, so base the response on the service-principal and audit records for each tenant.