ConnectWise Cloud Backup Breach Explained: Hackers Broke Into Microsoft 365 Tenants and What to Do Now

ConnectWise has suspended its Cloud Backup service after attackers stole a vendor application credential and used it to sign into Microsoft 365 tenants across the managed-service-provider ecosystem. The attackers needed no passwords and bypassed multifactor authentication, because they authenticated as the trusted backup application itself. ConnectWise disabled seven application identities on October 17, 2026, at 07:00 UTC and took Cloud Backup, SaaS Security, and Cloud Management temporarily offline while it investigates.

What happened: the timeline so far

ConnectWise says it first identified the issue on October 14, 2026, through what it described as advanced cybersecurity monitoring and diligence, and then activated internal and external incident investigation and response actions. The first public warning signs surfaced on October 15, when an MSP posted on the r/msp community that a dormant SkyKick Cloud Manager service principal had assigned itself the Exchange Administrator role outside of Privileged Identity Management, listing itself as the assigner. That was roughly 40 hours before ConnectWise published its advisory.

On October 16, 2026, ConnectWise published an investigating advisory on its status page, and Huntress emailed its managed partners with a rapid response alert listing affected Microsoft 365 tenant IDs. Then, on Saturday October 17 at 07:00 UTC, ConnectWise disabled seven application identities, including ConnectWise Cloud Backup, Cloud Management, MS Teams, Exchange Online, MS Graph, Partner Center, and SharePoint Online, and revoked the certificates used for the affected application connections across all users. Scheduled backups stopped running, and access to backup archives and restore capabilities went offline.

How the attack worked: one stolen credential, no passwords needed

The attackers compromised an application identity credential belonging to ConnectWise Cloud Backup, the backup product formerly sold as SkyKick. In Microsoft Entra ID, this application appears as a trusted service principal with the application ID 506e08f9-6e9a-4da4-942b-a099a03644ae, which MSPs had already consented into their customers’ Microsoft 365 tenants with broad permissions covering mailboxes, OneDrive, SharePoint, Teams, and directory data.

With the vendor’s credential in hand, the attacker could authenticate as the application itself and request access tokens directly from Microsoft Entra ID using the permissions customers had already granted. That means no user passwords were stolen, no phishing was required, and regular MFA prompts never fired, because the activity used an app-only identity rather than a human login. Huntress confirmed the login records showed a client assertion, meaning the secret came from the vendor’s home tenant rather than from anything inside each customer environment.

Because the backup application held extensive permissions, the attacker could go further: potentially adding the application to the Global Administrator role, adding client secrets to other trusted applications in a tenant, and creating entirely new applications with granted permissions. Those added secrets would give the attacker a way back in even after the original stolen credential was revoked. In at least one documented case, another ConnectWise application assigned itself the Global Administrator role and added new credentials to two other applications.

The scope: hundreds of tenants touched, a targeted second wave

The scale of the intrusion is still being established, but several figures have been reported. Huntress identified almost 1,000 Entra tenants with sign-in activity from the attacker-controlled IP address 144.172.64[.]128, of which around 300 succeeded. Later analysis put the number of confirmed unauthorized sign-ins across partner and customer tenants at 173 (with a subset figure of 162 within Huntress’s own monitored environment). In some tenants, the absence of a service principal prevented the attacker from getting in despite a successful sign-in.

The attack was not random. On October 15, the attacker signed in from the malicious IP address and received Microsoft Graph access tokens between roughly 06:13 and 08:34 UTC, moving through tenant identifiers in sorted GUID order only seconds apart, which Huntress says points to an automated script working from a prepared target list. Then a second, targeted wave on the same day singled out just 16 tenants in the policy, national security, trade, and critical mineral sectors, with one sweep between 09:25 and 12:35 UTC and a manual sweep between 13:54 and 14:20 UTC hitting Exchange Online, SharePoint Online, Teams, Azure Resource Manager, Entra, and the Office 365 Management APIs. That second wave was unsuccessful. Huntress has not observed new malicious activity since October 15, but it also notes there is no evidence the stoppage was caused by public disclosure.

Microsoft Threat Intelligence is tracking the activity as an active supply chain attack against the application’s OAuth identity, and BleepingComputer reported that Microsoft saw unauthorized authentication attempts from the single IP address starting on October 15. One threat-intelligence label for the activity is UNC7017.

What ConnectWise has done in response

Disabling the affected connections on October 17 prevents any new authentication through those connections, but ConnectWise itself warned that this does not reverse changes already made inside a tenant. It stated that the shared Cloud Backup credentials are no longer valid, although previously issued access tokens may remain usable until they expire or are invalidated, and any unauthorized credentials, permissions, or other access established through separate identities require additional review and remediation.

Scheduled backups are not running, and access to the affected backup archives and restoration remains unavailable during the investigation. ConnectWise emphasized that existing archives remain encrypted, isolated, and preserved, with no evidence they were breached or accessed. It also said it has not observed successful threat activity in the environments it monitors since implementing the mitigations, while cautioning that this does not establish the status of downstream customer environments, which it cannot directly observe. It is still unclear whether a product vulnerability contributed to the compromise of the application identities; the exact exposure mechanism is under analysis.

What you should do right now: the remediation checklist

If your business uses ConnectWise Cloud Backup or SkyKick, or your IT is handled by an MSP that does, Huntress and ConnectWise advise working through these steps immediately:

• Review both your own Microsoft 365 tenant and every managed customer tenant, including environments with dormant SkyKick connections. Find the application in the Microsoft Entra admin center under Enterprise applications by searching for SkyKick Backup, ConnectWise Cloud Backup, or CW Cloud Backup Service Provider, or by filtering on application ID 506e08f9-6e9a-4da4-942b-a099a03644ae.
• Verify the status of the listed application connections and keep the affected applications disabled until ConnectWise gives further notice.
• Review sign-ins across all identities from October 13, 2026, through now, specifically looking for activity from 144.172.64[.]128, and preserve available sign-in and audit records before starting containment.
• Review application and user authentication, application credentials and federation trusts, directory roles, owners, consent grants, and recent policy changes.
• Check for unauthorized mailbox forwarding rules, inbox or transport rules, and delegated mailbox access.
• Investigate any other identities changed or used during the suspicious activity window.

For longer-term hardening, Huntress notes several Entra controls that limit the damage if an application credential is stolen: application management policies that restrict or block client secrets on app registrations and cap credential lifetimes, limiting who holds the Application Administrator and Cloud Application Administrator roles, Conditional Access for workload identities to restrict where an application can sign in from, and Microsoft Entra ID Protection to flag risky service principals. None of these replace reviewing credentials, but they make a planted secret harder to use and easier to spot.

Why this breach matters beyond ConnectWise

This incident is a supply-chain attack on identity rather than on software. No perimeter was breached, no phishing email was clicked, and no ransomware was deployed. One trusted vendor credential came with the standing access of thousands of tenants attached, and Microsoft 365’s standard identity defenses, built around user logins and MFA, had little to say about an attacker authenticating as a legitimate application. It follows a busy season of identity and trust failures in the MSP and enterprise world, from the Ivanti Connect Secure zero-day exploitation to the GhostAction credential theft across GitHub Actions, and it lands days after Microsoft’s massive October Patch Tuesday. For MSPs, the lesson is that a backup agent’s service principal is as powerful as an admin account, and it deserves the same level of monitoring and least-privilege scrutiny.

Frequently asked questions

What is the ConnectWise Cloud Backup breach?

Attackers compromised a vendor application credential belonging to ConnectWise Cloud Backup (formerly SkyKick) and used it to sign into customers’ Microsoft 365 tenants as the trusted application, gaining access to mail, files, chats, and directory data. ConnectWise disabled seven application identities and suspended Cloud Backup, SaaS Security, and Cloud Management on October 17, 2026.

Was my data stolen in the ConnectWise breach?

ConnectWise says it has no indicators to date that Cloud Backup partner backup data was compromised, and that existing backup archives remain encrypted, isolated, and preserved. However, the attacker had access to Microsoft 365 data inside affected tenants through the application’s permissions, and the full extent of data access is not yet known. Tenants should review sign-in and audit records from October 13, 2026, onward.

How do I check if my Microsoft 365 tenant was affected?

Look for the ConnectWise Cloud Backup service principal in Microsoft Entra ID (Enterprise applications), search for application ID 506e08f9-6e9a-4da4-942b-a099a03644ae, and review sign-in logs from October 13 onward for activity from IP address 144.172.64[.]128 and any unexpected role assignments or consent grants.

Is ConnectWise Cloud Backup working again?

As of the latest advisory, scheduled backups are not running and access to backup archives and restore capabilities remains unavailable while the investigation continues. ConnectWise has not announced a restoration date.

Why did multifactor authentication not stop the attack?

The attacker never logged in as a user. They authenticated as the backup application itself using a stolen application credential (a client assertion), and app-only authentication does not trigger user MFA. The tokens were issued based on permissions customers had already granted the application.

What is SkyKick’s connection to this breach?

ConnectWise Cloud Backup was formerly sold as SkyKick. ConnectWise acquired SkyKick, and the compromised application identity was the one MSPs originally consented as SkyKick Backup, which is why dormant SkyKick connections in tenants are also in scope for the review.