Stolen ConnectWise OAuth Credential Breaches 173 Microsoft 365 Tenants: Revoke App Access Now

ConnectWise Cloud Backup is a Microsoft-partnered SaaS backup tool (formerly SkyKick Backup) that MSPs install across their client tenants via Microsoft 365's multi-tenant application model. When an MSP onboards the application, their Microsoft 365 tenant and each client tenant they manage grants the ConnectWise service principal delegated permissions: read and write access to mail, OneDrive, SharePoint, and Teams.

The entire permission grant system relies on the security of a single OAuth client secret held by ConnectWise. A client secret is a credential that allows an application to authenticate directly with Microsoft's identity platform without a human login flow. The token exchange produces access tokens indistinguishable from those generated by legitimate ConnectWise backup operations. Conditional Access policies, MFA requirements, and sign-in risk evaluations do not apply. The application authenticated correctly from Microsoft's perspective.

Huntress identified the stolen credential and the Python-based automation tool the attackers used to enumerate and access affected tenants. The tool authenticated to login.microsoftonline.com with the stolen client secret, received access tokens for each tenant connected to the ConnectWise Cloud Backup application, and then queried Microsoft Graph API endpoints for mail, OneDrive, SharePoint, and Teams data. All sign-ins showed the same four user-agent strings: python-urllib/3.12, python-requests/2.31, python-requests/2.34.2, and curl/7.88.1.

ConnectWise said it became aware of unauthorized access to its Cloud Backup application on October 17 and shut down customer access to the service. The company confirmed that no backup data was accessed, but backup data is not the concern; the real concern is the delegated read-write access to every connected tenant's live Microsoft 365 environment. Valid tokens from the October 15 session window remain active until explicitly revoked, regardless of ConnectWise's service shutdown.

The scope of the breach scales with the MSP model. A single compromised MSP can manage dozens or hundreds of client tenants, each of which independently granted ConnectWise Cloud Backup delegated permissions. The 173 confirmed tenants represent a floor, not a ceiling. Huntress noted that this figure counts Entra tenant objects, and one MSP can appear as multiple tenants while representing a single organization.

The October 15 access window (06:13 to 08:34 UTC) gave attackers two and a half hours of uninterrupted access to all affected tenants simultaneously. The delegated permissions for the ConnectWise Cloud Backup application typically include:

• Mail.ReadWrite: read and modify all email in every user mailbox
• Files.ReadWrite.All: read and write all files in OneDrive for Business
• Sites.ReadWrite.All: read and modify all SharePoint site collections
• ChannelMessage.Read.All: read all Microsoft Teams channel messages

Huntress observed unauthorized sign-ins across 173 tenants, with scripted access patterns consistent with automated data enumeration rather than targeted lateral movement. The primary tenant count rose from 162 on October 16 to 173 on October 17, indicating that the initial investigation was still uncovering affected tenants 48 hours after the event.

The sign-ins originated from an Evoxt VPS at IP 144.172.64.128. Earlier sign-in activity on October 13 and 14 suggests the attackers tested connectivity and confirmed access scope before the main extraction window on October 15. Organizations should set the Entra log review window to start no later than October 13 to catch all attacker activity.

The most alarming finding from the Huntress and SpecterOps investigations is not the initial access. It is what the attacker did in at least one tenant after gaining it. Once authenticated as the ConnectWise Cloud Backup service principal, the attacker used the ConnectWise Cloud Management - MS Teams application (App ID 24205314-2b89-4e07-a2a4-579e898a5640) to assign itself the Global Administrator role in Entra ID.

Global Administrator is the highest privilege level in Microsoft 365 and Azure Active Directory. An application holding that role can read and modify every user account, group, and role assignment in the directory; issue credentials to any service principal; reset passwords for any user including break-glass emergency accounts; and access all tenant resources without restriction.

From that elevated position, the attacker added new credentials to two additional trusted applications in the same tenant, including one used by Huntress for security monitoring. Credentials added to a service principal persist independently of the application's service status. Shutting down ConnectWise's Cloud Backup service does not invalidate credentials planted on other service principals. Those credentials can generate fresh access tokens until an administrator explicitly removes them from each service principal's credential set.

This persistence path means the October 15 breach may already have secondary footholds that survive ConnectWise's remediation. Defenders must audit every service principal in their Entra ID for credentials added since October 13, not just the three ConnectWise App IDs.

The ConnectWise Cloud Backup breach has three confirmed network indicators and five application identifiers requiring immediate review. The attacker IP 144.172.64.128 belongs to Evoxt, a VPS hosting provider, and is not associated with legitimate ConnectWise infrastructure.

Application IDs to audit in Entra enterprise applications and service principal sign-in logs:

• ConnectWise Cloud Backup: 506e08f9-6e9a-4da4-942b-a099a03644ae
• ConnectWise Cloud Management: 2399d300-6fca-4e6a-a686-399fefe75b83
• ConnectWise Cloud Management - MS Teams: 24205314-2b89-4e07-a2a4-579e898a5640

The BigBear.ai AiTM phishing campaign targeting Microsoft 365 MFA earlier this year demonstrated that MFA bypass attacks against M365 leave similar audit log signatures: service principal or app-only sign-ins from unexpected infrastructure. The ConnectWise breach differs in scale but follows the same pattern: look for application sign-ins from non-ConnectWise infrastructure in the October 13-15 window.

Two generated Sigma rules target Microsoft Entra audit events that indicate ConnectWise OAuth supply-chain abuse: an unauthorized service principal sign-in from the attacker IP and a new credential addition to a ConnectWise service principal object. Both carry experimental status; validate against your Entra log field names and schema before enabling automatic blocking. These rules are authored against the Azure Entra audit log format natively ingested by most SIEM platforms.

Shut down the attack surface before hunting for evidence. Existing access tokens remain valid even after ConnectWise disabled the Cloud Backup service; active token revocation is the only reliable remediation. Work through these steps in order; steps 1 and 2 are time-sensitive.

The ConnectWise Cloud Backup breach is a textbook example of why perimeter-focused security fails against supply-chain OAuth attacks. No firewall rule would have blocked it. No MFA policy applied. No endpoint agent saw the authentication event. The attacker authenticated as a trusted application using a credential that Microsoft's identity platform accepted as valid, because it genuinely was.

MSPs are the highest-value target in this attack class. A single stolen credential for a multi-tenant backup application unlocks every client tenant simultaneously. A ransomware group that pivots from mail access to deploying payloads (as Qilin affiliates demonstrated earlier this year with CVE-2026-0257 on GlobalProtect) could have used this foothold to deploy ransomware across 173 organizations in the same 2.5-hour window.

The structural vulnerability is Microsoft's multi-tenant application permission model. When an MSP's application holds a client secret with delegated permissions, every tenant that consented to those permissions inherits the security posture of the application vendor. There is no technical barrier preventing an attacker who compromises that one secret from accessing every tenant. Microsoft's Conditional Access policies cannot address this because the attack operates at the application layer, not the user layer.

Defenders cannot fix the model unilaterally. But they can reduce blast radius by applying workload identity policies in Entra that restrict service principal sign-ins to named IP ranges (ConnectWise's own published IP ranges), by implementing Privileged Identity Management (PIM) for application role assignments, and by enabling Entra Workload Identity Protection where available.

The GhostAction GitHub Actions supply-chain attack targeted CI/CD pipelines with the same model: compromise one trusted credential to inherit access across every downstream consumer. OAuth application secrets are the equivalent for SaaS management tools. The question is not whether your backup vendor has been targeted. It is whether you have the detection in place to know when they are.