On October 17, 2026, ConnectWise disabled seven application identities after attackers used stolen credentials to infiltrate nearly 1,000 Microsoft Entra ID tenants, succeeding in 300 of them. The company suspended its Cloud Backup service, revoking certificates across all users. Scheduled backups halted, and restoration capabilities went offline.
This wasn't a typical phishing attack targeting individual passwords. Instead, attackers compromised shared application credentials, allowing them to authenticate as the application itself.
The Challenge
ConnectWise discovered unauthorized access on October 14, 2026, through internal monitoring. Attackers had obtained credentials for ConnectWise's cloud applications, which customers use for managing their Microsoft 365 environments. These applications require extensive permissions: reading mailboxes, accessing SharePoint documents, managing Teams, and navigating directory structures.
Using the stolen credentials, attackers received access tokens from Microsoft Entra ID based on the application's permissions. They bypassed individual customer passwords by posing as a trusted application with existing consent across customer tenants.
The scale of the breach became evident quickly. Huntress identified sign-in activity from IP address 144.172.64[.]128 across nearly 1,000 Entra tenants. The first wave of malicious sign-ins occurred on October 15, with targeted manual activity continuing throughout the day. A second wave targeted 16 specific tenants in sectors like national security and trade.
The Environment and Constraints
ConnectWise operates in a multi-tenant SaaS model. Its applications need permissions that would typically be flagged as high-risk. However, backup and management platforms require these permissions to function effectively. You can't back up Exchange mailboxes without read access.
The attacker exploited this trust. Once authenticated as the application, they expanded access by adding the application to the Global Administrator role, injecting client secrets into other trusted applications, or creating new applications with permissions. Each client secret became a persistence mechanism. Even if ConnectWise revoked the original credential, any planted secrets would continue functioning until individually removed.
ConnectWise couldn't directly observe downstream customer environments. By design, the company lacks visibility into customer configurations or application activities post-authentication. This created a remediation challenge: ConnectWise could disable its application identities but couldn't revoke secondary credentials attackers may have established.
The Approach Taken
ConnectWise's first action was to contain the breach at the application layer. Disabling the affected application identities stopped new authentication attempts. The company also suspended Cloud Backup by revoking certificates for affected connections.
The disclosure clarified that while disabling connections prevented new authentications, it didn't undo changes made within a tenant. Previously issued access tokens remained valid until expiration. Unauthorized credentials or permissions required further review and remediation by each affected customer.
ConnectWise temporarily took SaaS Security and Cloud Management offline during the investigation. Existing backup archives were preserved, encrypted, and isolated, with no evidence of breach or access.
The company provided detailed remediation guidance to partners, including specific application IDs to verify, IP addresses to check in sign-in logs, and a timeline for log review starting October 13, 2026. The guidance stressed preserving sign-in and audit records before containment, recognizing the need for forensic visibility.
Results and Metrics
ConnectWise reported no successful threat activity in monitored environments post-mitigation. However, this didn't confirm the status of downstream customer environments.
Huntress found successful authentication in 300 of the nearly 1,000 targeted tenants. In some cases, the absence of a service principal prevented access despite successful sign-ins. The second wave on October 15 targeted 16 tenants but failed. This wave seemed manual, focusing on Exchange Online, SharePoint Online, Teams, Azure Resource Manager, Entra, and the Office 365 Management APIs.
The exact mechanism of credential exposure was still under investigation. ConnectWise hadn't confirmed whether a product vulnerability contributed to the breach.
Lessons Learned
The incident revealed gaps that weren't apparent before October 14. Application credentials acted as single points of failure across numerous customer environments. Once compromised, they allowed lateral movement and persistence at scale.
Huntress noted that Conditional Access for workload identities could limit where an application signs in, and Microsoft Entra ID Protection can flag risky service principals. These controls require additional licensing and weren't universally deployed.
Takeaways for Your Team
Review your application consent grants now, not after an incident. Every application with delegated permissions to your Microsoft 365 tenant is a potential attack vector if its credentials are compromised. Focus on applications with Global Administrator role assignments, directory read/write permissions, or access to mailboxes and SharePoint.
Implement policies to restrict client secrets on app registrations and limit credential lifetimes. Limit who holds the Application Administrator and Cloud Application Administrator roles. These measures won't prevent credential theft, but they constrain what an attacker can do with a stolen secret.
If you use Conditional Access, extend it to workload identities. Location-based restrictions won't stop a sophisticated attacker, but they provide detection opportunities when an application authenticates from an unexpected location.
Your sign-in logs are your ground truth. Preserve them before starting containment. In a multi-tenant compromise, you need to distinguish between legitimate application activity and attacker reconnaissance. That distinction is found in timestamps, IP addresses, and the specific APIs accessed.
Don't assume revoking a compromised application's access ends the threat. If attackers had time to plant client secrets in other applications or create new service principals, those mechanisms persist. Hunt for them explicitly.
The ConnectWise incident shows that application identity management isn't just a compliance task. It's an attack surface that scales across every tenant where your applications operate. Treat it with the seriousness it deserves.
