Nobody got phished. Nobody approved a push. No user password leaked.
On Oct 15, between 06:13 and 08:34 UTC, someone signed in to Microsoft 365 tenants as ConnectWise Cloud Backup, the MSP backup app formerly sold as SkyKick. They walked through tenants in sorted GUID order, a few seconds apart, from one hosting-provider IP, 144.172.64[.]128 (per Huntress, via The Hacker News). That’s a script working a target list. Huntress had confirmed unauthorized sign-ins in 162 tenants by 19:00 UTC on Oct 16, and 173 by Oct 17 (per The Hacker News).
How it worked. Huntress says the credential was a client assertion, which means it lives in the vendor’s own tenant. Nothing a customer did produced it, and nothing a customer configured stopped the sign-in. The app already held what a backup tool needs: read and write on mail and attachments, OneDrive and SharePoint files, Teams chats (per Todyl). Microsoft says the abused permissions likely include Directory.ReadWrite.All. User MFA never enters the picture. There is no user.
Then it got worse. In nearly 50 tenants, Huntress saw ConnectWise Cloud Management service principals assign themselves directory roles, mostly Exchange Administrator. In one partner tenant, the Cloud Management – MS Teams app made itself Global Administrator and added new client secrets to two other apps: an MSP management tool and Huntress’ own application. That’s the move to watch. A secret on an MSP management app can reach every customer that app is consented into. A secret on a security tool’s app inherits whatever the security tool can do.
The control gap. ConnectWise’s own remediation guide says it plainly: Conditional Access for workload identities covers single-tenant service principals registered in your tenant, not third-party multitenant SaaS apps. So the most privileged non-human identity in a lot of M365 tenants sits outside the policy engine most teams assume protects them. Your levers are consent scope, disable, and logs. That’s the list.
And the logs are thin. Huntress notes some of this access, like directory reads through Graph, leaves no audit trail unless Graph activity logs were already on. Entra keeps sign-in and audit records for 7 days on Free and 30 days on P1/P2 (per ConnectWise’s guide). Huntress can only check sign-in logs by API on P1 or higher. Plenty of MSP-managed small business tenants run exactly the licenses where the evidence ages out first.
The timeline is the buyer story. ConnectWise says it discovered the problem on Oct 14. Its first public advisory went up Oct 16 at 17:47 UTC. It shut off application access Oct 17 at 05:01 UTC and disabled seven app identities two hours later. As of Monday’s 13:45 UTC update, Cloud Backup, SaaS Security and Cloud Management are still suspended, with no restoration time. Scheduled backups aren’t running. So this is a breach path and a backup outage at once. ConnectWise says its encrypted archives show no sign of access.
What we’d do this morning. In Entra, open the Service principal sign-ins tab, not the default user tab. Filter on 506e08f9-6e9a-4da4-942b-a099a03644ae and the six Cloud Management app IDs. Treat anything outside Azure private IPv6 as a lead, and add 144.172.64[.]99 and .60, which ConnectWise published Sunday. Disable the apps, don’t delete them. Then audit credentials on every app registration and service principal since Oct 13, because disabling ConnectWise doesn’t remove secrets planted on your other apps. Check which apps now hold directory roles. Check inbox rules, hidden ones included, and transport rules. Tokens already issued can stay valid up to 90 minutes after you disable (per Todyl), so one quiet hour proves nothing.
The bigger read. Every M365 backup, archiving, SaaS security and email security vendor asks for standing consent like this. Each one is a shared secret in somebody else’s tenant with write access to yours. Buyers rarely ask how that secret is stored, rotated or scoped. They will now. Expect procurement to push backup vendors for per-tenant credentials, short-lived certificates and least-privilege scopes instead of directory-wide write. The vendors that can answer on one page will keep their renewals. The rest will be explaining why a backup tool needed Directory.ReadWrite.All.