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.

Update: Attacker-linked sign-in activity reportedly spans almost 1,000 tenants (October 18, 2026)​

Huntress has now identified almost 1,000 Microsoft 365 tenants with sign-in activity from the attacker’s address, according to iTnews’s October 18 reporting. That expands the investigation beyond the earlier 162 confirmed unauthorized sign-ins, but it should not be read as confirmation that almost 1,000 tenants were successfully compromised.

ConnectWise has reportedly revoked the stolen credential, according to iTnews. The outlet also reports that ConnectWise cannot determine whether individual customer environments were accessed because it lacks visibility into those tenants. For MSPs, that means vendor-side containment does not replace customer-level investigation.

According to iTnews, Huntress also identified unsuccessful attempts against 16 tenants in policy, national security, trade and critical minerals. Most reportedly did not have the ConnectWise application installed. These failed attempts further distinguish the attacker’s targeting scope from the number of confirmed intrusions.

On remediation, iTnews reports that Huntress removed the rogue credential it discovered on its own application. That is a specific cleanup action, not confirmation that credentials planted elsewhere have been removed. Administrators should therefore avoid treating either that removal or revocation of ConnectWise’s credential as an all-clear for their tenants.

Update: SaaS Security and Cloud Management also suspended (October 19, 2026)​

The service interruption reportedly extends beyond Cloud Backup: according to The Register’s October 19 reporting, ConnectWise has also suspended SaaS Security and Cloud Management because they are integrated with the affected backup platform. The outlet quotes ConnectWise describing those additional suspensions as precautionary measures while investigation and remediation continue—not confirmation that every suspended service or customer environment was compromised.

According to The Register, the services remained unavailable as of 16:00 UTC on October 18. The operational impact reportedly includes an inability to create backups, access existing archives, or restore data. This broadens the disruption described earlier: MSPs must account for unavailable security and management functions alongside the backup outage, while customers needing an urgent restore may also face delays.

The Register also reports that ConnectWise security operations vice president Jason Ferguson said existing archives remain encrypted, isolated and preserved, with no evidence of unauthorized access. For administrators, that distinction matters: preservation of stored backups does not mean those backups are currently accessible for recovery.

Update: ConnectWise reports no successful threat activity after containment, but no restoration timeline (October 19, 2026)​

ConnectWise reportedly says it has seen no successful threat activity since implementing containment measures, according to The Record’s October 19 reporting. A company spokesperson told the outlet that identified compromised credentials and identities have been remediated, while authentication monitoring, permission reviews and forensic analysis continue. That is a vendor-side assessment—not confirmation that affected customer tenants are free of attacker persistence.

Beyond the previously reported stolen-credential revocation, The Record reports that ConnectWise revoked certificates for affected application connections across all users during October 17–18. According to the outlet, ConnectWise says all shared credentials previously used for Cloud Backup are now invalid, removing its access through those connections. This expands the stated scope of credential containment but does not establish that secrets planted on unrelated customer applications have been removed.

There is still no timeline for restoring services, according to the spokesperson quoted by The Record. For MSPs and Microsoft 365 administrators, the practical distinction remains important: reported containment does not mean backup and recovery access has resumed.

Update: More than 300 tenants reportedly saw successful attacker-linked sign-ins (October 19, 2026)​

More than 300 Microsoft 365 tenants reportedly saw successful sign-ins from the attacker-linked IP address, according to iCounter researcher Roman Y. Sannikov, quoted in SC Media’s October 19 reporting. That adds a successful-authentication count to the previously reported nearly 1,000 tenants showing activity from that address. It does not establish what data was accessed or that every successful authentication led to further malicious actions.

SC Media also reports an additional investigation recommendation from Huntress principal security operations analyst Jon Semon: administrators should check for unexpected email forwarding and inbox rules, alongside the application-credential and permission reviews already described. This extends the recommended tenant checks to mailbox settings that could redirect communications. The recommendation is not evidence that malicious forwarding rules have been discovered in this incident.

Attribution remains unresolved, according to the researchers interviewed by SC Media. Sannikov cautioned against treating the broad tenant sweep and attempts against the smaller group of high-value organizations as one confirmed campaign. Suzu Labs CTO Denis Calderone likewise said shared infrastructure and a stolen credential do not, by themselves, establish a single operator.

Update: ConnectWise reportedly adds two suspected malicious IPs and offers SOC assistance (October 19, 2026)​

ConnectWise identified and published two additional IP addresses it believes are malicious on October 18, according to CTO David Raissipour’s October 19 interview with CRN. The addresses themselves are not included in CRN’s report. For administrators, the practical implication is to revisit the vendor’s security advisory for the expanded indicators rather than limit investigations to the address initially disclosed.

ConnectWise has also made its security operations center team available to help partners implement protective changes, according to Raissipour’s comments to CRN. He said partners must request assistance because ConnectWise cannot perform those changes directly inside their environments. This reportedly gives MSPs needing help with tenant-level remediation an additional support route.

Raissipour also told CRN that a third-party incident response company is assisting the investigation and remediation. He reportedly described significant progress toward restoring service and said ConnectWise had observed no suspicious activity in its own environment for more than 24 hours. However, his comments did not announce service restoration or provide a recovery deadline; the reported progress should not be treated as an all-clear for customer tenants.

Update: China-linked actor identified as phased service restoration begins (October 23, 2026)​

Microsoft has reportedly linked the ConnectWise Cloud Backup attack to China-nexus threat group Storm-0940, according to Cybersecurity Dive’s October 22 reporting on Microsoft’s newly released findings. The group reportedly used Artex, an open-source agentic AI penetration-testing tool, to automate its activity. This adds a specific attribution assessment where earlier reporting left the operator’s identity unresolved.

According to Cybersecurity Dive, Microsoft’s report describes attempted sign-ins against more than 2,250 Microsoft 365 tenants at approximately 2,900 attempts per minute. That expands the reported targeting scope, but it is not a count of successfully compromised tenants. Huntress analyst Jon Semon told the outlet that its observations support a working hypothesis of AI-agent activity using scripted tools with occasional human intervention—not proof that every action was autonomous.

ConnectWise is also reportedly beginning to restore services in controlled phases, according to CEO Manny Rivelo’s statement reported by Cybersecurity Dive. This changes the earlier position that services remained suspended without an announced restoration process. However, the company explicitly warns customers to keep their connections disabled until they receive direct instructions. For MSPs and Microsoft 365 administrators, phased recovery is therefore not authorization to re-enable ConnectWise applications across customer tenants.

Update: Backup restoration reportedly targeted for early next week, subject to validation (October 23, 2026)​

ConnectWise reportedly expects access to Cloud Backup restoration early in the week beginning October 26, provided security validation succeeds, according to NeoTeo’s October 23 reporting on the company’s October 22 update. This adds a conditional recovery window to the previously announced phased restoration—not confirmation that restore access is available or that normal backup operations will resume on that schedule. According to NeoTeo, partners must wait for service-specific instructions before reconnecting affected applications.

NeoTeo also reports a distinction that corrects our preceding update: the peak of approximately 2,900 attempts per minute belonged to a separate October 10–14 password-spray activity set, not the application-identity sweep targeting more than 2,250 tenants. According to the outlet’s account of Microsoft’s findings, that spray produced more than 151,000 failed logons against 327 accounts at eight organizations, with no successful authentication or downstream activity observed in that specific set. Those unsuccessful attempts do not negate the separately reported intrusions through ConnectWise application identities.