Here is the part that should worry anyone running a Microsoft 365 tenant: the attackers never touched a user account. No phishing email, no stolen password, no MFA fatigue push. They authenticated straight into customer tenants as a vendor application, using a valid app secret that the vendor itself held. The vendor was ConnectWise Cloud Backup, formerly known as SkyKick, and for a few days last week that app secret was effectively a master key.
What happened
ConnectWise shut down customer access to its Cloud Backup service after discovering unauthorized access to application identities in its Cloud Backup environment. Huntress, the managed security provider, first confirmed 162 compromised tenants in its own fleet, then widened the picture considerably: nearly 1,000 tenants showed sign-in activity from the attacker’s IP, and more than 300 of those sign-ins succeeded. The full victim count across the whole ecosystem is still unknown, which is the part I find genuinely uncomfortable.
Todyl’s investigation traced all the activity to a single rented server in Sydney, Australia. The attackers worked through tenants in strictly ascending GUID order, one token per tenant, spaced one to six minutes apart. That is not a hacker in a basement picking targets. That is a script walking a sorted list, and it suggests the attacker held the tenant list itself.
Microsoft Threat Intelligence characterized the incident as an active supply-chain attack and assessed that the attacker likely abused the app’s existing permissions, which included Directory.ReadWrite.All.
Why the usual defenses did nothing
The attack used OAuth 2.0 client credentials, the app-only flow. A valid secret, no user involved. That means multi-factor authentication was irrelevant, Conditional Access policies never fired, and revoking user sessions accomplished nothing, because there was no user session to revoke. Every control most organizations stack their security on assumes a human at the keyboard somewhere.
Once inside, the app’s grants gave the attacker tenant-wide reach: mail and attachments, OneDrive and SharePoint files, Teams chats, directory data. Worse, the attackers went after persistence. Huntress caught the Cloud Management app granting itself Global Administrator in one partner tenant and adding credentials to other applications, including Huntress’s own app. Five minutes of work, and the foothold survives the vendor’s cleanup.
There is also a logging gap worth naming. Todyl could not confirm or rule out data exfiltration because MicrosoftGraphActivityLogs was not being collected in the affected tenants, so the source IPs of Graph API requests were invisible. App-only access is exactly the traffic nobody watches, and when you finally go looking, the logs were never switched on.
The second wave
The part that moves this from “embarrassing vendor breach” to something more serious: on October 15, a second wave unsuccessfully targeted 16 tenants in policy, national security, trade, and critical mineral sectors. Most of them did not even use ConnectWise products. That looks like targeting, not opportunism, and it raises the question of what else the attacker holds.
Containment, and why it is not enough
ConnectWise disabled seven application identities on October 17, revoked certificates, brought in a third-party forensics firm, and suspended Cloud Backup, SaaS Security, and Cloud Management services. The company says it has no indicators that partner backup data was accessed and that stored archives remain encrypted and preserved. It also says, notably, that it does not yet know how the attacker stole the credential in the first place.
Here is the asymmetry that MSPs are now dealing with: disabling the app blocks new tokens, but it does nothing about credentials the attacker already planted inside customer tenants, and already-issued tokens stay valid until they expire. The vendor’s fix does not remediate customer environments. Each tenant has to do its own cleanup.
One more detail from Inforcer’s writeup: one managed estate had about 3,800 tenants with the backup app installed, and roughly two-thirds were not actively using it. Dormant, high-privilege consent grants are standing attack surface, and this incident is the argument for auditing them.
What to do this week
- Disable (do not delete) the ConnectWise Cloud Backup app and Cloud Management app identities in every tenant you manage, including tenants that never used them. Some appear under the old SkyKick Cloud Manager name.
- Audit service principal sign-ins from October 13 onward, not user sign-ins. Flag the IP 144.172.64.128 and the user agents python-urllib, python-requests, and curl.
- Check every application in the tenant for secrets or certificates added since October 13, plus directory role assignments, consent grants, federation trusts, mailbox forwarding rules, and inbox rules.
- Turn on MicrosoftGraphActivityLogs collection if you have Entra ID P1 or P2. It is not retroactive, so the earlier gaps stay gaps, but future app-only traffic gets source IP attribution.
- Export audit logs now if you are on Entra ID Free. The retention window is seven days and it is already ticking.
The uncomfortable summary: a vendor that held one shared credential across thousands of customer tenants was a single point of failure, and the blast radius followed every consent grant ever made, active or not. Vendors in that position are effectively super-tenants. They need to be secured like one, and until the industry treats app credentials with the same rigor as user identity, this kind of breach is a waiting game.