ConnectWise suspends Cloud Backup: review Microsoft 365 application identities
An advisory on application access and backup gaps. Individual research observations are not evidence of ransomware or compromise at every customer.
Updated: · Vietnam time (UTC+7)
The vendor advisory and original Huntress and Todyl research were checked. Verified refers to these attributed publications and observations, not a finding that every tenant was compromised, ransomware occurred or data was copied. Ransomware.VN has not examined organizations' original logs or samples and has not verified an affected Vietnamese organization.
Sources read on 18 October 2026. ConnectWise's advisory is newer than the 16–17 October research; older credential-status statements are not presented as current. Artwork is illustrative, not incident evidence. The checklist is editorial analysis for authorized administrators only.
Evidence: service status on 18 October
At 01:00 UTC on 18 October 2026, ConnectWise said Cloud Backup, formerly SkyKick, remained suspended: scheduled backups and affected archive restores were unavailable, with no restoration ETA. No evidence of archive access was reported; that does not clear individual Microsoft 365 tenants.
Evidence: Todyl's observation scope
Todyl observed Microsoft Graph access through the Cloud Backup identity in monitored tenants on 15 October. It found no backup-app credential additions, privilege changes or persistence in that set. The report does not confirm bulk copying: permission to read is not proof of reading. These findings cannot be generalized to every tenant.
Evidence: Huntress observed additional access paths
Huntress described one tenant where Cloud Management – MS Teams assigned itself Global Administrator and added credentials to two other applications. Disabling the original app therefore does not remove secondary access paths. Its 17 October update also describes failed attempts where the relevant service principal was absent; sign-in totals are not a global victim count.
Technical assessment: a controlled review checklist
- Identify the correct tenant and responsible administrator. Match Application IDs against original sources, not display names alone. An App ID identifies a legitimate application; it is neither a credential nor proof of compromise.
- Preserve sign-in and audit logs alongside urgent containment. Microsoft documents UTC timestamps and retention limits; record the export filters, time window and unavailable data.
- Review both application and service-principal objects: new credentials, owners, API permissions, consent and role assignments. Reconcile changes with authorized administrative work.
- If disablement is needed, follow Microsoft's service-principal guidance in the correct tenant with appropriate permissions. Avoid bulk deletion or unilateral re-enablement; coordinate changes with the provider and incident-response team.
Assessment: protect recovery readiness without assuming ransomware
Operations teams should document the last successful backup, the possible gap against their recovery point objective and an approved alternative recovery path. A reopened service portal is not proof that recovery is healthy: validate data, access and a safely scoped restore test.
This is an application-identity and backup-availability advisory, not a ransomware attribution. The reviewed evidence does not establish a ransomware family, global victim total, copied-data scope or Vietnamese impact. A clean log search also cannot exclude activity outside available visibility.
Sources
Each source's scope and date are recorded separately when available. A citation does not independently verify every assessment.
Update history
· Published VI/EN coverage from public advisories and original research, separating observation scope, editorial guidance and unresolved questions, with six event-specific illustrations.
· Adjusted further reading to two renderable guides on backup and timeline reconstruction. Facts, URL and original publication date are unchanged.
Corrections policy
