HIGH: ConnectWise Cloud Backup Breach Hits 173 Microsoft 365 Tenants

If you run a managed service provider, the nightmare was never really the ransomware note on a client laptop. It was the quieter possibility that one of your own trusted tools, the software you bolt into every customer tenant because it makes your life easier, could be turned into a skeleton key. That possibility stopped being hypothetical on October 15, when attackers used a compromised credential belonging to the ConnectWise Cloud Backup application to sign straight into 173 Microsoft 365 partner and customer tenants without ever touching a password prompt or a multifactor challenge.

This is not a vulnerability story in the usual sense. There is no CVE to patch, no buffer overflow, no missing input validation. What failed here is something far more uncomfortable for the channel, namely the trust model that lets a single vendor application carry broad, standing permissions across hundreds of downstream environments. When the credential for that application lands in the wrong hands, every tenant that granted it consent becomes reachable in one motion, and the attacker inherits whatever access the app was already allowed to have.

The application at the center of this is ConnectWise Cloud Backup, formerly known as SkyKick, a service MSPs use to back up Microsoft 365 data such as mail, files, and Teams content. Because backup software needs deep read access to do its job, the consented permissions were exactly as alarming as you would expect. Security firm Todyl described the inherited access as read and write to mailboxes and attachments, including full mailbox access by way of Exchange Web Services, along with OneDrive and SharePoint files, Teams chats, and restore functions. Microsoft noted that the actor likely abused permissions that customers had already granted, including Directory.ReadWrite.All, which is the kind of directory level power you really do not want a stranger holding.

Here is the part that should make every administrator sit up. The attacker did not log in as a person. They authenticated as the application itself using their own tooling, then requested Microsoft Graph tokens against the app's existing permissions. Huntress, the incident response firm that caught the activity, put it bluntly when they said the app's credential was in hostile hands. Because this was a machine identity rather than a human one, there was no end user sign in to challenge and no multifactor prompt to satisfy. The usual advice to enable MFA, which is normally sound, does nothing against an attacker who is already holding the keys to a service principal. Worse, Huntress warned that directory reads performed through Microsoft Graph in this fashion may leave no audit trail at all, which means some of the reconnaissance simply does not show up where defenders expect to look.

The timeline reads like a well rehearsed operation. On October 13 and 14, a single IP address ran password spraying against four law firm tenants, and none of those attempts succeeded. Then on October 15, between 06:13 and 08:34 UTC, the real event unfolded. The attacker pulled Graph tokens from tenant after tenant originating from the IP address 144.172.64.128, and the tenants were processed in sorted GUID order a few seconds apart, the unmistakable rhythm of automation grinding through a list. Microsoft separately observed broad, successful service principal authentication from that same address on the fifteenth. Huntress noticed something almost darkly funny in the targeting, observing that the most interesting victims seemed to cluster near the start of the alphabet, with names beginning in "A" drawing early attention, which fits the mechanical march through sorted identifiers.

What the attacker did once inside is the part that turns an embarrassing incident into a genuine persistence problem. This was not a smash and grab. Microsoft observed Graph API reconnaissance followed by attempts to add fresh credentials to related service principals, which Microsoft accurately characterized as planting a backdoor. In at least one partner tenant, a separate ConnectWise Cloud Management Teams application added itself to the Global Administrator role, then proceeded to add new client secrets to an MSP management application and, with no small amount of nerve, to Huntress's own application registration. That last move matters because it illustrates the whole point of the attack. Once you own one trusted app identity, you use it to mint credentials for other trusted app identities, and revoking the original credential no longer evicts you.

ConnectWise's response was to shut off Cloud Backup application access until further notice while investigation and remediation continue. The company says it has found no evidence that partner backup data itself was compromised, which is a meaningful statement, though it is worth remembering the difference between no evidence of compromise and evidence of no compromise. The event is still being described as developing, and the honest reading today is that the full blast radius is not yet known. ConnectWise did publish useful indicators, pointing administrators at Entra sign in logs under the service principal sign ins tab and telling them to hunt for App ID 506e08f9-6e9a-4da4-942b-a099a03644ae alongside connections from IP addresses outside the expected Microsoft and Azure ranges. The app's normal egress is Azure private IPv6, so the appearance of that lone public IPv4 address, 144.172.64.128, is the tell.

If you are reading this and you run Cloud Backup or SkyKick in any client environment, the remediation is specific and the order matters. Disable the application rather than simply resetting user passwords or revoking user sessions, because this was never about user sessions. Todyl made the crucial point that disabling the app stops new tokens from being issued, but tokens already issued can remain valid for up to ninety minutes, so there is a window where the attacker keeps working even after you think you have closed the door. Turn on Microsoft Graph activity logs if you have not already, since the default logging leaves gaps precisely where this actor operated. Then audit every application in your tenant for credentials added since October 13, not just the ConnectWise apps, because the follow on activity shows the attacker seeding secrets into unrelated service principals. Check your Entra audit logs for any ConnectWise or SkyKick application that added itself to a directory role, and treat a self promotion to Global Administrator as the five alarm fire it is. Microsoft's broader guidance echoes all of this, directing defenders to review service principal sign ins from unrecognized IPs, scrutinize app credential changes, and inspect OAuth grant activity tied to the app ID.

The lesson threaded through this whole mess is that identity has quietly become the real perimeter, and the identities that matter most are no longer the ones attached to people. They are the application and service principal identities that hum along in the background with standing consent and almost no one watching them. We spent a decade teaching users to distrust phishing emails and to embrace MFA, and that work was not wasted. But an attacker holding an app credential walks right past all of it, because the app was trusted by design. Every OAuth consent screen an administrator clicked through years ago is a door that is still open, and most organizations have never gone back to count the doors.

For MSPs specifically, there is an uncomfortable mirror here. The same multi tenant tooling that makes the managed services model economically viable is exactly what makes a single compromised credential catastrophic. The efficiency and the fragility are the same architecture viewed from two angles. That is not an argument against the model, but it is an argument for treating every third party application in your stack as a privileged asset that deserves inventory, monitoring, and periodic review, the same way you would treat a domain administrator account.

The business angle for MSPs is that this incident is the most persuasive sales conversation you will have all quarter, and you did not have to manufacture it. Identity threat detection and response for Microsoft 365, specifically continuous monitoring of service principal sign ins, OAuth grants, and app credential changes, is a service most of your clients do not have and did not know they needed until this week. Pair that with a one time application consent audit, a tidy fixed fee engagement where you inventory every app with standing permissions in a tenant and flag the risky ones, and you have a package that sells itself against a headline clients will have already seen. Position it as closing the doors nobody has looked at since onboarding, and you are selling a service that would have caught this exact attack while it was still a password spray against four law firms.