A single compromised application credential belonging to ConnectWise Cloud Backup — the managed service provider (MSP) backup product formerly known as SkyKick — gave attackers direct access to at least 173 Microsoft 365 customer tenants this past week. ConnectWise has since disabled seven of its application identities and suspended Cloud Backup entirely, leaving thousands of MSPs without scheduled backups or restoration capability while the investigation continues.
What Happened
ConnectWise identified the compromise on October 14 through its security monitoring and activated incident response. However, the attacker had already been busy. Between 06:13 and 08:34 UTC on October 15, sign-ins from IP address 144.172.64[.]128 — a hosting provider — swept across nearly 1,000 Microsoft Entra tenants. Around 300 sign-ins succeeded, and security firm Huntress confirmed unauthorized access in 173 partner and customer tenants.
The attack worked because the compromised credential belonged to the ConnectWise application itself, not to any individual user. Cloud Backup needs broad permissions to do its job — access to mailboxes, OneDrive, SharePoint, Teams, and directory data — and those permissions are granted once by consent, then apply across every tenant where the app is installed. Multi-factor authentication offered no protection here: service principal sign-ins have no user, no device, and no MFA prompt. The attacker simply authenticated as the backup application and inherited everything it could reach.
Beyond Backup: Escalation and Persistence
What makes this incident especially alarming is what happened after initial access. Huntress observed attackers requesting Microsoft Graph tokens carrying the app’s existing permissions, which included Directory.ReadWrite.All — effectively read/write control over the entire directory. In at least one partner tenant, a second ConnectWise application (Cloud Management for Microsoft Teams) granted itself Global Administrator privileges and then ran a Python script that added new client secrets to two other trusted applications: an MSP management tool and, notably, Huntress’s own security platform app.
This is a textbook supply-chain pivot. An MSP management application is often consented into dozens or hundreds of customer tenants, so planting a credential in it opens a path from one compromised partner to an entire downstream customer base. The added client secrets function as persistent backdoors — they survive the original credential rotation and continue working until individually discovered and revoked.
A Second, Targeted Wave
After the initial automated sweep, Huntress observed a second, more deliberate wave. Between 09:25 and 14:20 UTC on October 15, the attacker manually targeted 16 tenants associated with organizations in the policy, national security, trade, and critical minerals sectors. The targeting pattern, shift from scripted to manual operation, and sector focus suggest a threat actor with strategic intelligence objectives — though ConnectWise and Huntress have not attributed the attack to any specific group. Huntress reported that these targeted attempts were unsuccessful.
ConnectWise’s Response
On October 17, ConnectWise disabled all seven affected application identities and revoked the certificates used for those connections. Cloud Backup is suspended: no scheduled backups are running and restoration is unavailable. The company also took its SaaS Security and Cloud Management products offline as a precaution. ConnectWise says existing backup archives remain encrypted, isolated, and preserved, with no evidence they were accessed.
But there is a critical caveat in ConnectWise’s own advisory: “Disabling the connections does not reverse changes previously made inside a tenant.” In other words, if the attacker planted credentials, modified roles, or created forwarding rules during their access window, those changes persist. Previously issued access tokens may also remain valid for up to 90 minutes after the apps are disabled. ConnectWise has acknowledged it cannot directly observe what happened inside downstream customer environments.
Who Is Affected
Every organization that had ConnectWise Cloud Backup (or its SkyKick predecessor) installed should consider itself potentially exposed, regardless of whether Huntress has confirmed activity in its specific tenant. The 173 confirmed compromises are a floor, not a ceiling — some directory reads through Microsoft Graph leave no audit trail, making the full scope of access difficult to confirm. Older tenants may have the app listed under SkyKick names rather than ConnectWise, so defenders need to check for both.
What Defenders Should Do Now
Security teams at affected organizations should take several immediate steps. First, disable the ConnectWise Cloud Backup application (ID: 506e08f9-6e9a-4da4-942b-a099a03644ae) in the Microsoft Entra admin center and keep it disabled until ConnectWise confirms all credentials have been fully rotated. Next, review service principal sign-in logs — not the default user sign-in tab — for activity from 144.172.64[.]128, particularly between October 13 and the present. Audit all applications for credentials added since October 13, and look specifically for new client secrets on trusted applications.
Check Entra audit logs for any ConnectWise or SkyKick application adding itself to a directory role, especially Global Administrator. Review mailbox rules for unauthorized forwarding or delegation. SpecterOps has published guidance on using its open-source AzureHound and BloodHound tools to map the attack paths from ConnectWise service principals to Tier Zero assets in your environment.
For longer-term hardening, Huntress recommends implementing application management policies to restrict client secrets and cap credential lifetimes, limiting who holds the Application Administrator and Cloud Application Administrator roles, and deploying Conditional Access policies for workload identities to restrict where applications can sign in from.
The Bigger Picture
This incident joins a growing pattern of attacks that weaponize the trust relationships MSPs rely on. When a backup tool needs — and is routinely granted — the keys to an organization’s entire Microsoft 365 environment, a single stolen credential scales into a mass-compromise event. The attacker does not need to phish a single employee, bypass MFA, or exploit a vulnerability. They just need the one key that was already consented into everything.
For security teams, the takeaway is uncomfortable but clear: every third-party application with broad tenant permissions is a potential supply-chain risk. Continuous mapping of app permissions, aggressive consent reviews, and monitoring service principal sign-ins — not just user sign-ins — are no longer optional. The ConnectWise incident is a sharp reminder that your backup provider’s security posture is, functionally, part of your own.
Leave a Reply