ConnectWise Cloud Backup Breach: 173 Microsoft 365 Tenants

ConnectWise Cloud Backup breach exposed 173 Microsoft 365 tenants after attackers stole the backup app's own credential. No phishing email, no stolen password, and no MFA prompt stood in their way.

That is what makes this incident so unsettling. The attackers did not break into 173 organizations one by one. They stole one key that a trusted backup service uses to do its job, and that single key opened doors across every customer environment where the app had been given permission. For more stories like this, see our more cybersecurity news.

Image: The Hacker News

What happened in the ConnectWise Cloud Backup breach

ConnectWise Cloud Backup is a cloud backup and recovery service built for managed service providers, or MSPs, the outside IT teams that look after technology for many small and mid-sized businesses at once. The backup service, formerly known as SkyKick, protects clients' Microsoft 365 or Google Workspace data. To do that job, it needs broad access: mailboxes, OneDrive, SharePoint, Teams, and directory data in every tenant where it is installed.

According to security researchers at Huntress, attackers got hold of the application's own credential and used it to sign in to customers' Microsoft 365 environments. Huntress confirmed unauthorized sign-ins in 173 partner and customer tenants, up from 162 on October 16 as the investigation expanded. Because the stolen credential works in every tenant where the app has been consented, the real exposure is wider than any single count: every organization running the app is potentially within reach until the credential is fully reset.

Microsoft is tracking the incident as an active supply chain attack. ConnectWise has shut off Cloud Backup application access while its investigation continues. The company says it has found no evidence that partner backup data was compromised. How the attacker obtained the credential has not been disclosed.

How one stolen credential opened 173 tenants

To understand this attack, it helps to know the difference between a user sign-in and an app sign-in.

When you sign in to Microsoft 365, you type a password and usually approve an MFA prompt on your phone. That is a user sign-in. But apps can sign in too. When a business approves a backup app, it grants that app permission to act on its own, without a person at the keyboard. The app proves who it is with its own credential, a kind of secret key, and receives access tokens carrying the permissions the business already approved.

In this incident, the attackers used the ConnectWise Cloud Backup application's credential, so they signed in as the trusted app itself. As Huntress researcher Jonathan Semon put it: "The app's credential is in hostile hands." No user was phished, and no MFA prompt was bypassed, because no user was involved at all. The attacker inherited everything the backup service could already reach.

The timeline investigators pieced together

• October 13-14: The same IP address behind the later attack engaged in password spraying against four law firm tenants. Huntress detected no successful user sign-ins from that activity.
• October 15, 06:13-08:34 UTC: The ConnectWise Cloud Backup application signed in to customer tenants from the IP address 144.172.64.128, a hosting-provider address, and obtained Microsoft Graph access tokens. The sign-ins moved through tenants in sorted ID order, seconds apart, pointing to an automated script working from a prepared target list.
• October 16: Huntress confirmed unauthorized sign-ins in 162 tenants by 19:00 UTC, later rising to 173.
• October 17: ConnectWise shut off Cloud Backup application access, and Microsoft publicly described the activity as an active supply chain attack.

Why this attack is harder to clean up than a normal breach

Three details make this breach especially tricky for defenders.

First, the backdoor risk. In at least one partner tenant, researchers saw a separate ConnectWise application, Cloud Management for MS Teams, grant itself the Global Administrator role, then add new client secrets to two other trusted applications. A new secret on a trusted app is a spare key: it can give an attacker a way back in even after the original stolen credential is reset. That is why simply disabling the backup app is not enough on its own.

Second, old tokens keep working for a while. Disabling the app stops new tokens from being issued, but tokens already handed out can stay valid for up to 90 minutes. Any tenant where the app is still enabled stays exposed until ConnectWise rotates the credential.

Third, some access leaves little trace. Directory reads through Microsoft Graph may not produce the same audit evidence as ordinary mailbox or file activity. Huntress cautioned that a lack of visible mail or file access does not prove that data was not taken.

What to do now if you run Microsoft 365 or use an MSP

If you are an IT administrator or your business uses an MSP, treat this as an active incident check:

• Disable the affected ConnectWise applications in your tenant and keep them disabled until ConnectWise confirms all credentials have been reset.
• Check your sign-in logs. In the Microsoft Entra admin center, go to Monitoring, then Sign-in logs, then the Service principal sign-ins tab, and filter by Application ID 506e08f9-6e9a-4da4-942b-a099a03644ae. The normal User sign-ins tab will not show this activity.
• Look for the suspicious IP address 144.172.64.128 in those logs. The application's normal traffic comes from Azure private IPv6 space, so a public hosting-provider address stands out.
• Audit every application credential added since October 13. Look for new client secrets or certificates on any app, not just ConnectWise apps, and remove anything unauthorized.
• Check for privilege changes. Review Entra audit logs for ConnectWise or SkyKick applications adding themselves to a directory role.
• Turn on Microsoft Graph activity logs if they are not already enabled.
• Remove consents you no longer use. If you do not actively use ConnectWise Cloud Backup or SkyKick, remove its application consent from your tenant entirely.

ConnectWise listed several application IDs the threat actor abused, including ConnectWise Cloud Backup and multiple ConnectWise Cloud Management apps. If any of those apps are consented in your tenant, include them in your review.

If you are an everyday Microsoft 365 user rather than an admin, there is no button you can press to fix this yourself. The right move is to ask your IT provider or MSP one direct question: do we use ConnectWise Cloud Backup, and have you checked our tenant against this incident?

The bigger lesson: your vendor's apps are part of your security

Supply chain attacks work because trust is transitive. When you approve a vendor's app, you hand it a set of permissions and then mostly forget about it. That app becomes part of your security boundary, even though it lives outside your company. One compromised vendor credential can then reach every customer who ever said yes to that app.

The ConnectWise investigation is still developing, and the confirmed tenant count may rise again as more organizations check their logs. In a world where apps sign in on our behalf, protecting the app's credentials matters just as much as protecting our own passwords. For more on how cloud services and business software intersect, see our more technology news.

Sources: The Hacker News, SpecterOps