When Your Backup Tool Becomes the Breach: Lessons from the ConnectWise SkyKick Incident

In October 2026, a Microsoft 365 tenant belonging to a small accountancy firm in Leeds was quietly read top to bottom. No phishing email landed. No one clicked anything dodgy. Multi-factor authentication was switched on across every account, and the firm had paid for a security monitoring contract. None of it mattered.

The attacker, tracked by threat researchers as Storm-0940, never touched a single user's password. Instead they compromised an OAuth credential belonging to ConnectWise Cloud Backup — a tool the firm's MSP had connected months earlier to back up its mailboxes and SharePoint sites. That one credential gave Storm-0940 a quiet, authenticated path into roughly 2,250 Microsoft 365 tenants at once. The backup tool had already been granted broad read access to everything it was meant to protect. The attackers simply used it.

If you run or rely on an MSP, this is the incident that should keep you up at night — not because it was clever, but because it was ordinary. It exploited something nearly every managed IT estate has: third-party apps with far more access than anyone remembers granting.

Why MFA and endpoint hygiene did nothing

Most of our mental model for "getting breached" involves a person being tricked. Someone clicks a link, hands over a password, and the attacker walks in wearing their credentials. We've built an entire industry around stopping that moment — MFA prompts, phishing training, conditional access, endpoint detection.

OAuth sidesteps all of it.

When you connect a tool like a cloud backup service to Microsoft 365, you're not giving it a password. You're granting it a set of permissions — the ability to read mail, read files, read user directories — through an app registration that authenticates on its own behalf. That consent is persistent. It doesn't expire when a user changes their password. It doesn't trigger an MFA challenge, because there's no user logging in. The app holds a token, and the token keeps working until someone explicitly revokes it.

So when Storm-0940 got hold of ConnectWise Cloud Backup's OAuth credential, they inherited exactly the access that app had been given: deep, standing, read-level reach into thousands of tenants. MFA protects user logins. This wasn't a user login. The security contract monitored endpoints and alerted on suspicious sign-ins. This generated no suspicious sign-ins, because from Microsoft's point of view the backup tool was doing precisely what it was authorised to do.

The uncomfortable truth is that the firm's defences were well configured. They were just aimed at the wrong threat.

The real problem: OAuth blast radius

Every third-party app you connect to Microsoft 365 or Google Workspace is a door. The question that almost nobody asks is: how wide does that door open, and who else could walk through it?

Backup tools are among the worst offenders because of what they do. To back up a tenant properly, they request sweeping permissions — often Mail.Read across all mailboxes, Files.Read.All, Sites.Read.All, directory access, sometimes more than they strictly need. Vendors ask for the broadest scope that will work in every customer scenario, because it's easier than scoping tightly. MSPs grant it once, during onboarding, and move on. Years later the permission is still live and nobody can tell you why it reaches as far as it does.

That accumulated, forgotten access is what security people mean by "blast radius." If one app's credential is stolen, how much of your world does the attacker get? In the ConnectWise case, the answer was: nearly everything, across 2,250 organisations, with a single stolen key.

This is also why the incident is specifically dangerous for MSPs. A single MSP often connects the same handful of tools — backup, PSA, documentation, monitoring — across every client tenant it manages. One compromised vendor credential doesn't hit one business; it hits the whole book. The blast radius isn't a tenant. It's a portfolio.

A Monday-morning checklist

You can't patch your way out of this, and you can't buy a product that makes it go away. What you can do is take stock of every third-party app with access to your Microsoft 365 estate and ruthlessly cut back what you find. Here's where to start.

1. Pull a full list of enterprise applications and app registrations. In the Entra admin centre, go to Enterprise Applications and export everything. Do the same for App Registrations. For Google Workspace, use the admin console's app access control report. You're looking for the complete inventory — not the apps you think are there, the apps that actually are. Expect surprises.

2. Flag anything with tenant-wide or admin-consented permissions. Sort by permissions granted. Any app holding .All scopes — Mail.Read.All, Files.ReadWrite.All, Directory.Read.All — goes on a priority list. These are the ones with real blast radius. For each, ask a blunt question: does this tool genuinely need to read every mailbox, or was that just the default the vendor requested?

3. Check last-used dates and sign-in logs. Many of your listed apps haven't done anything in months. Entra's sign-in logs include service principal activity. An app with broad permissions and no recent use is pure risk with no benefit — revoke it.

4. Verify who consented, and when. Look at the consent records. If you find admin consent granted during an onboarding two years ago by someone who's since left, that's exactly the forgotten door we're talking about. Document the business reason for each app that stays. If you can't write a one-line justification, it probably shouldn't be there.

5. Revoke and re-scope the backup tools specifically. Given the ConnectWise incident, treat backup and recovery apps as a special case. Confirm the vendor's current recommended minimum permission set and compare it to what's actually granted. Where you can reduce scope without breaking backups, do it. Where you can't, note the residual risk and raise it with the vendor.

6. Turn off end-user consent entirely. If your users can still approve third-party app access on their own, close that off now. Set consent to admin-approval-only so that no new door opens without a human checking it first. This is a two-minute configuration change that prevents the next forgotten permission from ever being granted.

7. Set a recurring review. This isn't a one-off. Put a quarterly reminder in the diary to repeat the inventory and prune anything new. Permission sprawl grows back.

The shift in thinking

For a decade, security advice has pointed at the endpoint and the user. Patch the laptop, train the staff, enforce MFA. That advice is still correct — it's just no longer sufficient. The ConnectWise SkyKick incident shows that your attack surface now includes every vendor you've ever trusted with an OAuth grant, and the weakest of those vendors becomes your weakest link.

The tools we connect to protect our data are, themselves, part of the data's risk profile. A backup service with standing read access to 2,250 tenants is both a safety net and a skeleton key, depending on who holds its credential.

If you're not sure what's connected to your Microsoft 365 tenant, or you'd like a hand working through the audit above, that's exactly the kind of review we do for clients across Nottingham and the East Midlands. Get in touch with Cloudworks and we'll help you find the forgotten doors before someone else does.