As reported by BleepingComputer, ConnectWise has taken its Cloud Backup service (formerly SkyKick Cloud Backup) offline following confirmed malicious activity targeting Microsoft 365 tenants through compromised application identities. Huntress has identified at least 162 affected tenants, and Microsoft has traced unauthorized authentication attempts to IP address 144.172.64[.]128 beginning October 15. This is not a vulnerability in the traditional sense — it's a supply-chain compromise that exploits the very trust model that makes SaaS integrations work.
Why This Matters Beyond the Headline Count
The attack vector here is structurally significant. Backup services like ConnectWise Cloud Backup require broad permissions across Microsoft 365 — Exchange, SharePoint, Teams, OneDrive — to do their job. These permissions are granted via Microsoft Entra ID service principals, which authenticate using application secrets or certificates. When an attacker gains access to those credentials, they inherit every permission the application holds across every customer tenant where it's been consented.
This is the SaaS equivalent of stealing keys to the kingdom from the locksmith. The attacker doesn't need to phish an end user, exploit a software bug, or brute-force authentication. They authenticate as the trusted application itself, moving laterally across tenant boundaries using the same access path that makes the backup service functional. Todyl's research confirms the attackers authenticated directly using the application's secret — meaning the credential compromise occurred on the vendor side, not the customer side.
Every third-party SaaS application you've consented into your Entra ID tenant is an attack surface you don't directly control.
Who Is at Risk
- MSPs and their clients: Managed Service Providers represent the highest-value targets because they centralize access across dozens or hundreds of tenants through a single platform. The blast radius scales with the MSP's client base.
- Any organization using ConnectWise Cloud Backup: Even if your specific tenant hasn't shown signs of compromise, the exposed credentials may have been valid before the October 15 detection.
- Organizations with legacy service principal grants: Reddit reports indicate some affected tenants hadn't actively used the SkyKick application in years — yet the permissions persisted. Dormant app registrations with elevated roles are latent risk.
- Tenants granting Global Admin or Exchange Admin roles to third-party apps: These are the highest-privilege delegations in M365 and should be treated as critical-severity exposure points.
The Broader Pattern: SaaS Supply Chains Are the New Software Supply Chains
This incident fits a growing pattern of attacks targeting the trust relationships between cloud platforms and their ecosystem partners. The SolarWinds paradigm — compromising a vendor to reach downstream customers — has migrated cleanly into SaaS identity infrastructure. What's different is that there's no patch to deploy and no binary to scan. The exposure lives in consent grants, OAuth scopes, and service principal credentials that most organizations don't inventory, monitor, or rotate with any regularity.
Microsoft's detection of the malicious IP on October 15 suggests the attack window may have been relatively short, but the lack of customer-side visibility into service principal authentication events means many affected tenants may not yet know they were targeted. The real damage assessment will come from Entra ID sign-in logs and Microsoft 365 audit logs, which many organizations don't actively monitor for service principal activity.
Shield53 Recommendations
Immediate Actions
Strategic Hardening
- Implement Conditional Access for service principals — restrict authentication to known IP ranges, require trusted locations, or block legacy authentication protocols entirely.
- Enforce least-privilege consent — never grant Global Admin to a third-party app when a more specific role delegation (e.g., Mail.Read for backup) will suffice. Review and scope down existing grants.
- Establish a service principal lifecycle process — onboarding requires documented justification, periodic access reviews (quarterly minimum), and automated offboarding when contracts end or usage ceases.
- Rotate application secrets and certificates regularly — and require vendors to support secret rotation without service disruption. Any vendor that cannot demonstrate credential hygiene practices is a supply-chain liability.
- Deploy service principal anomaly detection — whether through Microsoft Sentinel, Defender for Cloud, or a third-party CSPM tool, you need alerts on unusual service principal sign-in patterns, new consent grants, and role elevation events.
This incident should be a wake-up call for security teams who have focused on endpoint and network threats while leaving SaaS identity governance as a back-burner concern. The attack surface has moved — your defenses need to follow.