ConnectWise Cloud Backup Breach: Disable SkyKick Apps and Hunt Microsoft Entra Backdoors

What happens, however, when the vendor’s master key falls into the wrong hands?

Managed service providers (MSPs) and Microsoft 365 administrators are confronting that exact nightmare this weekend. Threat actors have compromised a vendor-side Microsoft 365 credential belonging to ConnectWise Cloud Backup—the widely deployed MSP backup platform formerly known as SkyKick—and used it to authenticate directly into customer Microsoft 365 environments. Following initial incident disclosures by cybersecurity firm Huntress and subsequent confirmation from ConnectWise, the vendor has shut off Cloud Backup application access across all regions, temporarily halting automated backup operations until further notice.

Here is everything Windows and Microsoft Entra administrators need to know about the breach, how the attack chain operates, why shutting off the app is only half the battle, and the exact steps required to audit and lock down your tenants today.

The Anatomy of the ConnectWise SkyKick Breach​

According to threat research published by Jonathan Semon and the incident response team at Huntress, along with reporting from Cyber Press, the core of the incident involves a compromised Microsoft 365 API secret—specifically a client assertion credential—belonging to the ConnectWise Cloud Backup application. Because a client assertion lives inside the vendor’s own environment (3f9cd7a0-127a-4ed4-bf06-2f830d5616b7), nothing a customer did or failed to do inside their own tenant generated this exposure.

On October 15, 2026, between 06:13 and 08:34 UTC, Huntress observed the ConnectWise Cloud Backup application (506e08f9-6e9a-4da4-942b-a099a03644ae) authenticating to customer Microsoft 365 tenants and obtaining Microsoft Graph access tokens from 144.172.64[.]128, an IP address tied to hosting provider RouterHosting (AS14956). Legitimate traffic from ConnectWise Cloud Backup normally originates from Azure private IPv6 space, making the public hosting provider IP an immediate red flag.

The attackers did not browse casually. Huntress noted that the authentications stepped through customer tenants in sorted GUID order just seconds apart—classic behavior for an automated script working down a pre-compiled target list. As of 19:00 UTC on October 16, Huntress had confirmed unauthorized sign-ins across 162 tenants (with broader industry tracking from Microsoft Threat Intelligence and outlets like The Hacker News noting up to 173 affected partner and customer tenants as investigations expanded). Crucially, because a multi-tenant vendor credential works against any environment where the application is installed and consented, every organization running ConnectWise Cloud Backup is potentially within reach of the compromised credential until remediation is complete.

Timeline of Observed Activity​

Huntress’s telemetry reveals a multi-day sequence of events surrounding the suspicious infrastructure and ConnectWise service principals:

• October 13–14, 2026: The IP address 144.172.64[.]128 conducted password spraying against four law firm tenants alongside scripted OAuth2 token requests using the curl/7.88.1 user agent. Smart lockout blocked two accounts, and Huntress saw no successful user logins from this phase. The same address also attempted scripted sign-ins against client application IDs belonging to other tools.
• October 15, 2026 (from 01:58 UTC): Across roughly 50 Huntress-monitored tenants, service principals for ConnectWise Cloud Management applications (covering Exchange Online, Microsoft Teams, and Microsoft Graph) assigned themselves directory roles, predominantly Exchange Administrator. These calls used the kiota-dotnet user agent typical of ConnectWise’s own.NET SDK automation, though Huntress noted it had not yet confirmed with ConnectWise whether this specific wave was routine vendor automation.
• October 15, 2026 (03:44 to 03:49 UTC): In one partner tenant, a secondary application—ConnectWise Cloud Management – MS Teams (24205314-2b89-4e07-a2a4-579e898a5640)—assigned itself the Global Administrator role at 03:44 UTC and again at 03:48 UTC. Using a Python script (Python-urllib/3.12), it executed nine modification attempts against two other privileged applications in that tenant: an MSP management tool and the partner’s single-tenant Huntress Security Platform app. While a certificate addition failed due to a thumbprint mismatch, the script successfully planted new client secrets set to expire in 2028 on both applications.
• October 15, 2026 (06:13 to 08:34 UTC): Roughly two and a half hours after the Global Administrator escalation, the ConnectWise Cloud Backup app began its scripted Microsoft Graph token sweep from 144.172.64[.]128.
• October 16, 2026 (17:48 UTC): ConnectWise posted an initial security advisory acknowledging unauthorized access attempts associated with the Cloud Backup environment and listing 144.172.64.128, Python-urllib/3.12, and python-requests/2.31 as indicators of compromise.
• October 17, 2026 (05:11 UTC): ConnectWise updated its status page to confirm unauthorized access to application identities within the Cloud Backup environment and announced it was shutting off Cloud Backup application access globally as a protective measure.

Section Summary: Attackers leveraged a compromised vendor-side client assertion for ConnectWise Cloud Backup to script Microsoft Graph token requests across well over a hundred Microsoft 365 tenants from a third-party hosting IP, while separate activity in at least one tenant saw a ConnectWise Cloud Management app escalate to Global Administrator and plant long-lived backdoor secrets on third-party MSP and security apps.

Operational Reality: Service Shutdown vs. Tenant Disabling​

One point of confusion in early reporting stems from how fast the incident evolved. When Cyber Press and Huntress published their initial analyses, ConnectWise’s status page still listed Cloud Backup as "Operational," prompting warnings that a green status light did not mean the threat was over.

By 05:11 UTC on October 17, however, ConnectWise flipped the kill switch on its end. According to ConnectWise’s official status advisory, the company shut off Cloud Backup application access across all regions (North America, EMEA, APAC, and Other Regions) to protect partners and clients, interrupting automated backup services until further notice.

ConnectWise emphasized two critical points regarding customer data:

• The company has no indicators to date that partner backup data stored in the Cloud Backup archive has been compromised.
• Existing cloud backup archives are not impacted or deleted by the service interruption and will become accessible again once services are restored.

Even with ConnectWise cutting off application access from the vendor side, security researchers strongly advise M365 administrators to disable the enterprise applications inside their own Microsoft Entra tenants immediately—especially because secondary ConnectWise Cloud Management applications were observed participating in privilege escalation, and because any planted credentials on other apps remain active regardless of what ConnectWise does on its servers.

Why OAuth Supply Chain Attacks Are So Dangerous​

To understand why security teams are treating this with five-alarm urgency, consider how modern cloud applications authenticate. When a user logs into Microsoft 365, they face Conditional Access policies, device compliance checks, and multi-factor authentication (MFA) prompts.

When an Enterprise Application (service principal) authenticates using an app-only token, there is no user, no interactive device, and no MFA prompt. The application simply presents its client secret or certificate to Microsoft Entra ID and receives an access token carrying every permission the tenant administrator previously consented to.

Because ConnectWise Cloud Backup is designed to back up and restore whole environments, its default permission scope is massive: it can read and write mailboxes, OneDrive files, SharePoint sites, Microsoft Teams messages, and Entra directory data.

Worse still is the persistence mechanism Huntress uncovered in the affected partner tenant (tracked under MITRE ATT&CK as T1098.001: Additional Cloud Credentials and T1098.003: Additional Cloud Roles):

• When an application holds role-assignment permissions, it can promote itself to Global Administrator.
• Once acting as a Global Administrator, it can generate new client secrets on other trusted applications already residing in your tenant—such as an RMM/MSP management tool or a security platform.
• Whoever generates a client secret in Entra ID gets to read its plaintext value at the moment of creation.
• Even if you disable ConnectWise Cloud Backup today, and even after ConnectWise rotates its own master keys, an attacker holding a 2028-expiring secret planted on another app in your tenant can walk right back in through that second app.

Furthermore, administrators must contend with a frustrating visibility blind spot in Microsoft 365: attribution and read-auditing limits. Huntress noted that the Global Administrator role assignment and secret creation happened roughly 2.5 hours before the 144.172.64[.]128 token sweep, and because Microsoft’s Entra audit log does not record source IP addresses for app-only actions, researchers have not definitively proved whether the same operator conducted both phases. In Microsoft's sign-in logs, the second application connection showed a private IPv6 Unique Local Address (fde4:8dba:2600:37ce:6d26:200:a76:*), which is internal Microsoft cloud routing space shared by legitimate ConnectWise and unrelated customer traffic alike—meaning that IPv6 address cannot be used to identify the attacker. Finally, directory reads executed via Microsoft Graph often leave no audit trail at all unless paid Microsoft Graph activity logging is specifically configured, meaning a "clean" audit log does not guarantee directory data wasn't enumerated.

Section Summary: App-only OAuth tokens bypass MFA and user-level protections, inheriting broad backup permissions across mail, SharePoint, OneDrive, and Teams. Because attackers can use privileged apps to plant secondary secrets on unrelated apps—and because standard Entra logs lack source IPs for app-only audit events and don't log basic Graph directory reads—admins cannot rely on vendor-side fixes or clean user logs alone.

Step-by-Step Incident Response and Hunting Guide for M365 Admins​

Do not wait for proof of compromise in your logs before taking containment action. Follow this structured remediation workflow across your tenant (and across all client tenants if you are an MSP).

Step 1: Disable (Do Not Delete) Affected Enterprise Applications​

Both Huntress and ConnectWise stress that you should disable the affected service principals rather than deleting them. Disabling immediately revokes the app's ability to sign in or access data, whereas deleting the application strips out your OAuth consent configuration and complicates future service restoration.

• Sign in to the Microsoft Entra admin center.
• Navigate to Identity > Applications > Enterprise applications.
• Search by Application ID (do not rely solely on display names, as older deployments may still appear under legacy SkyKick or SkyKick Cloud Manager names).
• Locate the primary applications and open Properties for each.
• Toggle Enabled for users to sign-in? to No and click Save. (Despite the label wording, setting this toggle to "No" on an Enterprise Application completely blocks app-only service principal tokens as well.)

Review and disable the primary abused applications, and strongly consider temporarily disabling the remaining ConnectWise Cloud Management suite until ConnectWise confirms all credentials have been reset:

Step 2: Check Service Principal Sign-In Logs (Not User Logs!)​

A common mistake during OAuth incidents is checking the default Entra sign-in screen and breathing a premature sigh of relief. Application token requests never appear under User sign-ins.

• In the Microsoft Entra admin center, go to Monitoring & health > Sign-in logs.
• Click the Service principal sign-ins tab.
• Add a filter for Application ID and enter 506e08f9-6e9a-4da4-942b-a099a03644ae (repeat for the other IDs in the table above).
• Inspect the IP address column. Normal egress traffic for ConnectWise Cloud Backup uses Azure private IPv6 ranges. Look for any public IPv4 addresses or non-Azure hosting infrastructure, specifically 144.172.64.128.
• Remember: if your tenant lacks the Entra ID P1/P2 licensing required to retain or query detailed logs via Graph, or if the sweep hit outside your current filter window, a clean log does not guarantee safety—keep the app disabled regardless.

Step 3: Hunt for Planted Secrets and Rogue Role Assignments​

Because disabling the ConnectWise apps will not invalidate secrets planted on other applications, you must audit your broader Entra environment from October 13, 2026, onward:

• Audit Directory Roles: Check Roles & admins in Entra ID. Look for any ConnectWise or SkyKick service principal holding privileged directory roles—especially Global Administrator, Privileged Role Administrator, Application Administrator, Cloud Application Administrator, or Exchange Administrator. Once the application is disabled, remove any directory role you did not explicitly intend for it to hold.
• Audit All App Registrations and Enterprise Apps for New Credentials: Check App registrations > All applications (as well as Enterprise application properties). Inspect the Certificates & secrets blade on every privileged application—starting with MSP management tools, RMM/PSA integrations, and security platforms like the Huntress Security Platform. Immediately revoke and delete any client secret or certificate created since October 13 that your team cannot explicitly account for (watch closely for secrets set to expire in 2028).
• Review Entra Audit Logs: Go to Monitoring & health > Audit logs and filter for activities including:
• Add member to role
• Update application
• Add service principal credentials
• Check the initiating actor and the User-Agent field inside the audit details. While ConnectWise’s own.NET services typically display kiota-dotnet, the malicious credential-planting activity observed by Huntress used Python-urllib/3.12.

Update: Microsoft confirms active supply-chain attack and persistence attempts (October 17, 2026)​

Microsoft has now confirmed malicious authentication activity involving ConnectWise Cloud Backup on October 15, according to BleepingComputer. Microsoft Threat Intelligence reportedly characterizes the incident as an active supply-chain attack in which the actor likely abused the permissions already granted to the vendor application, including directory read/write access.

Microsoft also observed post-authentication persistence activity: Microsoft Graph reconnaissance and attempts to add additional credentials after service-principal sign-ins. That aligns with Huntress’s earlier finding that a ConnectWise Cloud Management application obtained Global Administrator rights in one tenant and created backdoor secrets on other trusted applications.

For defenders, the new confirmation reinforces that checking the compromised Cloud Backup app alone is insufficient. Admins should review OAuth grants, application credential changes, and Graph activity, while treating newly added secrets or certificates since October 13 as potentially hostile. BleepingComputer also reports a further suspicious user agent, python-requests/2.34.2, in addition to the previously identified Python and curl indicators.