ConnectWise Suspends Cloud Services After Attackers Use Application Credentials to Access Microsoft 365

ConnectWise has suspended its Cloud Backup service, previously named SkyKick, and temporarily halted SaaS Security and Cloud Management services following a security incident involving unauthorized access to seven application identities. The compromise was detected internally on October 14, 2026; affected credentials were disabled two days later, with certificates revoked immediately after detection to prevent further intrusion into customer Microsoft 365 environments. While the company has confirmed no direct theft of customer passwords and noted that its other products appear unaffected, investigation continues into how the initial credentials were acquired.
The attack exploited pre-authorized access rather than targeting user logins directly; attackers leveraged compromised application credentials to impersonate trusted software and request tokens from Microsoft Entra ID to access sanctioned services like Exchange Online and SharePoint for various tenants. Threat intelligence noted suspicious login activity originating from a specific IP address across numerous Microsoft Entra tenants, though the number of successful logins does not guarantee data exfiltration in every case.
Users relying on these suspended services are advised by external analysts (Huntress) to conduct immediate internal reviews of their own M365 configurations—checking application credentials, Conditional Access policies, and directory roles—to mitigate residual risk following credential revocation actions.

ConnectWise, an IT management and cybersecurity provider, suspended its Cloud Backup service (SkyKick) and temporarily shut down SaaS Security and Cloud Management services.
The action followed the discovery of unauthorized access by attackers to seven application identities.
Detection occurred on October 14, 2026.
Affected identities were disabled on October 17, 2026.
Certificates used by the applications were revoked post-detection.
Attackers used existing, authorized ConnectWise application credentials within customers’ Microsoft 365 tenants.
Data accessed via these tokens included Exchange Online, SharePoint, Teams, and directory data.
Huntress reported suspicious login activity from IP address 144.172.64.128 across approximately 1,000 Microsoft Entra tenants, observing about 300 successful logins.
Targeted attempts against 16 organizations in policy, national security, trade, and critical minerals sectors occurred on October 15, all of which were unsuccessful.
The company found no evidence that backup archives were accessed or compromised; existing backups remain encrypted and separate.

The incident reveals a pivot point in enterprise threat modeling: the increasing danger posed not by brute-force credential theft against end-users, but through compromise of service identities—the digital keys granted to trusted applications operating on behalf of legitimate users or services. This shifts the vulnerability from human error (a forgotten password) to systemic trust relationships within cloud identity platforms like Microsoft Entra ID. The reliance on these application identities creates a deep and often invisible attack surface; when an entity authorized by IT management software is compromised, it inherits a high degree of implicit trust that circumvents perimeter defenses entirely.
The warning issued by external security researchers highlights the structural instability inherent in complex cloud governance. Simply revoking stolen credentials treats the symptom, not necessarily the disease. If the attacker gained persistence before revocation—by installing new client secrets or altering permissions within the tenant itself—the mechanism for re-entry remains viable, irrespective of temporary key invalidation. This necessitates that organizations move beyond reactive clean-up to proactive architectural resilience.
This scenario echoes historical patterns where trusted intermediaries become vectors of attack. The primary assumption under threat is that authentication credentials inherently imply authorized behavior; however, the event demonstrates that authorization (the permission granted) must be constantly reconciled with verification (the current intent). Who controls the lifecycle and scope of these third-party application consents? What structural safeguards exist to prevent a compromised "trusted agent" from unilaterally escalating its privileges within a regulated environment?
Patterns detected: none