The ConnectWise Supply-Chain Attack That Walked Straight Into Microsoft 365

Someone walked straight into Microsoft 365 through the front door — using ConnectWise's own trusted application as the key. The ConnectWise supply chain attack, confirmed by ConnectWise and Microsoft over the past week, hit 173 partner and customer tenants in under two and a half hours without stealing a single password or breaking past MFA. There was nothing to steal and nothing to bypass. The attacker simply showed up as a legitimate app and was waved through.

ConnectWise detected the unauthorized access on October 14 through its own internal monitoring, then issued an advisory on October 17. The affected piece: application identities belonging to its Cloud Backup service, the one formerly known as SkyKick. Per the advisory update on October 19, ConnectWise has disabled seven affected application identities, revoked certificates, and suspended Cloud Backup, SaaS Security, and Cloud Management entirely. All three are still suspended as of writing. ConnectWise says there is no indication backup data itself was compromised — but how the attacker got hold of the app credential in the first place is still unknown.

How the ConnectWise supply chain attack worked

Here's the timeline, and it reads like an operations manual. The attack window was October 15, 06:13 to 08:34 UTC. Tenants were hit seconds apart, all from a single hosting-provider IP: 144.172.64[.]128. That's not a person clicking around a dashboard — that's a script working down a target list.

Huntress, the security firm that first raised the alarm, initially counted unauthorized sign-ins in 162 tenants. That number later grew to 173. The method: the attacker authenticated as the app's trusted service principal. No passwords to phish, no MFA prompts to dodge. The app was already consented into these tenants with powerful permissions, including Directory.ReadWrite.All. Once inside, in dozens of tenants the attacker granted itself Exchange Administrator roles.

The one that should make your stomach drop: in at least one tenant, a Cloud Management application made itself a Global Administrator and added secrets to two other apps. Read that again. A persistence path, built on the fly, from a trusted third-party app. Microsoft called it an active supply-chain attack, and it's hard to argue with the label — the compromise didn't touch the victims' networks at all. It came through the software they had already approved.

The victim count is probably much larger than 173

One hundred seventy-three tenants is the confirmed number. The real exposure is almost certainly wider. CISO Voice reported nearly 1,000 Entra tenants showing suspicious sign-ins tied to this activity, including more than 300 successful authentications from the attack IP.

That tracks with the mechanics of the thing. This wasn't a targeted intrusion into 173 specific companies — it was a stolen credential that works against every tenant where the app was consented. The attacker's script apparently ran a finite target list, but nothing stopped that list from being longer. Every organization that had granted these ConnectWise app identities permissions is a potential victim, whether they show up in the confirmed count or not.

This is also why the "no passwords stolen" framing, while technically accurate, is beside the point. The credential that matters here was the app identity itself — and nobody had to phish anyone for it. If your incident response plan for October assumed the threat model was compromised user credentials, it's worth revisiting — and the pattern fits this month's broader breach wave, where trusted vendors keep turning out to be the entry point.

Why trusted apps are the scariest attack surface

Let me be blunt: your organization spent the last five years hardening the front door — phishing training, MFA rollouts, conditional access — while leaving the service entrance wide open. Enterprise apps are the service entrance. They authenticate without human interaction, they hold standing permissions that no user would ever be granted casually, and almost nobody audits them.

Think about what made this work. Directory.ReadWrite.All is the kind of permission a vendor asks for during onboarding and nobody questions, because the alternative is a broken integration. Once granted, it sits there indefinitely — consent given once, never reviewed, across hundreds of tenants simultaneously. A single leaked app credential then becomes a master key to all of them. That's not a bug in the OAuth model. That is the OAuth model.

We've seen this movie before with stolen OAuth tokens — the Meta and GitHub credential compromises showed how trusted integrations become attack vectors. But this one is worse, because the victims didn't click anything, install anything, or misconfigure anything. They bought legitimate software from a legitimate vendor. The "user education" answer doesn't apply here. The only answer is scrutiny of the apps themselves.

What to do: audit your app consents this week

This isn't a patch to install — it's an audit to run. If you run Microsoft 365, do these this week:

1. List every app with high-privilege permissions. In the Entra admin center, go to Enterprise applications and filter for apps holding Directory.ReadWrite.All, Application.ReadWrite.All, or any -Admin role. You will probably find apps you forgot existed.
2. Revoke consents you don't actively need. Vendors whose contracts ended, trials that expired, tools the team replaced two years ago — remove them. An app you don't use is pure attack surface.
3. Require admin consent for app registration. If users can consent to third-party apps themselves, stop that today. It's the single most effective policy change here.
4. Watch service principal sign-ins, not just user sign-ins. The attacker here was an app identity. If your detection only monitors human logins, you are blind to exactly this class of attack. Set alerts for unusual sign-in locations on service principals.
5. Check for unexpected privileged role assignments. Look for app identities holding Exchange Administrator, Global Administrator, or similar roles. An app with standing global admin is a compromise waiting to be discovered.

ConnectWise did the right thing by shutting down the affected services rather than trying to keep them limping along. But the services are suspended, not retired — and the credential's source is still unknown. Until that's answered, treat every third-party app in your tenant as a credential that could already be in someone else's hands. Because that's exactly what happened here.