ConnectWise Cloud Backup Credential Compromise Exposes Microsoft 365 Customer Access

A compromised credential belonging to ConnectWise Cloud Backup, formerly SkyKick, has been used to sign in to customers’ Microsoft 365 environments, according to a Huntress investigation published on October 16. ConnectWise has restricted Cloud Backup application access while it investigates.

The immediate concern is not a stolen employee password. It is an application credential that can inherit the backup service’s existing permissions to business email, files and other sensitive information. For organizations using the service, checking ordinary user sign-ins or resetting employee passwords is not enough.

Huntress confirmed unauthorized sign-ins in 162 Microsoft 365 tenants as of 19:00 UTC on October 16. A tenant is an organization’s separate Microsoft cloud environment. That figure describes confirmed authentication in Huntress’s visibility, not a final count of affected customers or proof that data was stolen from each organization.

A backup service’s permissions became the access route

ConnectWise Cloud Backup helps managed service providers protect their customers’ cloud data. To back up and restore information, its application needs extensive permissions, potentially covering Exchange mailboxes, OneDrive, SharePoint, Teams and directory information.

According to Huntress’s investigation, the application authenticated from a hosting-provider address, 144.172.64[.]128, on October 15 between 06:13 and 08:34 UTC. The researchers observed sign-ins moving through tenants in sorted identifier order, seconds apart, suggesting scripted activity.

Microsoft issued access tokens through Microsoft Graph, the interface applications use to work with Microsoft 365 data. Those tokens carry the permissions already granted to the application. The attacker therefore did not need to persuade each customer to approve a new application or disclose an employee’s password.

Huntress says the credential used was a client assertion held in the vendor’s own tenant, rather than something created by a customer’s configuration. The researchers have not established publicly how the credential was obtained.

Confirmed access is not the same as confirmed data theft

In its security advisory, updated October 17 at 05:01 UTC, ConnectWise confirmed unauthorized access to application identities and said it was shutting off Cloud Backup application access. The company said it had no indicators that partner backup data had been compromised. Its investigation and remediation remained ongoing.

That statement should not be read as an all-clear for customers’ live Microsoft 365 environments. Stored backup data and the mailboxes or files accessible through an application’s Microsoft permissions are different parts of the exposure.

Huntress said the detailed audit log it reviewed for one tenant showed no mail or file access by the actor. However, it warned that some Microsoft Graph directory reads leave no audit trail. Successful authentication establishes access; the absence of visible reads does not settle whether information was taken.

The Hacker News independently reported the incident on October 17, citing Huntress, another investigation by Todyl and ConnectWise’s response. The publicly available evidence does not yet establish a complete victim count, the identity of the attacker or the full data impact.

A second application complicates containment

Huntress also identified concerning activity involving ConnectWise Cloud Management for Microsoft Teams in one customer tenant. That application assigned itself Global Administrator privileges and added new client secrets to an MSP management application and a single-tenant Huntress application belonging to that partner.

A client secret is a credential that lets software authenticate as an application. Adding an unauthorized secret to another trusted application can preserve a separate route into the environment, even after the original application is disabled.

There is an important attribution limit: Huntress said the credential additions happened roughly two and a half hours before the observed sign-ins from the suspicious hosting address. It has not tied both phases to the same operator. Other role assignments seen across additional tenants may have been vendor automation; the researchers said that remained unconfirmed.

The practical implication is nevertheless clear: blocking one application does not remove credentials already added elsewhere. Administrators need to inspect related application changes, not simply switch off the backup integration and assume containment is complete.

What affected organizations should check now

Huntress recommends disabling, rather than deleting, the ConnectWise Cloud Backup and ConnectWise Cloud Management–MS Teams applications while their safety is unresolved. Deletion removes consent and can complicate restoring the service. The Cloud Backup application ID is 506e08f9-6e9a-4da4-942b-a099a03644ae; the Teams management application ID is 24205314-2b89-4e07-a2a4-579e898a5640.

In Microsoft Entra, administrators should review Service principal sign-ins, not just the default user sign-in view, filtering by the affected application ID. Check the reported suspicious address alongside the application, timing and other evidence. ConnectWise cautions that an indicator’s presence alone does not establish compromise.

Review application secrets and certificates for unexpected additions since October 13, particularly on management and security tools. Also investigate unapproved directory-role assignments and remove unauthorized credentials. Huntress advises waiting for ConnectWise to confirm credential resets before re-enabling affected applications.

Disabling the integration pauses automated backups, according to Huntress, but does not delete existing backups or stop normal email and file access. Organizations should confirm retention, restoration options and any gap in recovery points with their provider.

For employees and small-business owners, the useful question for an IT provider is whether these application identities were present, whether service-principal logs were checked and whether other application credentials were reviewed. A VPN does not block an attacker authenticating directly to Microsoft with a valid cloud application credential. This incident requires cloud-identity containment and investigation, not a change of network connection.