ConnectWise Cloud Backup Breach: Compromised Application Identities and Microsoft 365 Tenants

ConnectWise, a major provider of software used by managed service providers (MSPs) and IT organizations, announced on October 18 that it had discovered unauthorized access to seven application identities within its systems. These identities had been obtained by unknown threat actors, who then used them to gain access to customer Microsoft 365 environments. The compromised identities included ConnectWise Cloud Backup and six other application credentials that had not been publicly detailed in initial disclosures. The company took the step of disabling all affected identities immediately upon discovery and began a formal investigation into the scope and timeline of the breach.

The fact that multiple application identities were compromised simultaneously suggests this was not a single weak password or a one-off social engineering incident, but rather a more systematic compromise of ConnectWise's credential management or infrastructure. When an application identity (essentially a service account or OAuth token used by a software service to access systems on behalf of users) is stolen, an attacker gains the permissions that the application itself has been granted, which in Microsoft 365 environments can be extensive.

Application identities in cloud services like Microsoft 365 are designed to allow software to perform automated tasks: backing up data, syncing configurations, generating reports, and so on. When a legitimate service like ConnectWise Cloud Backup is granted access to a customer's Microsoft 365 tenant, Microsoft creates an identity for that application and grants it specific permissions (scopes). The identity is protected by a secret or certificate that ConnectWise stores securely.

If that identity's credentials are stolen, an attacker inherits all the permissions that identity has been given. In the case of a backup application, this often includes broad read access to mailboxes, SharePoint sites, OneDrive files, and Teams data. From there, an attacker can exfiltrate data, modify or delete information, and potentially move laterally to connected systems. The attacker also doesn't need to know the customer's password: they authenticate as the trusted application, which looks identical to legitimate automated operations from Microsoft 365's perspective.

This is fundamentally different from a phishing attack that compromises a user's personal account. Because the application identity is trusted and widely deployed, the breach affects multiple customers at once, not just one organization.

MSPs and their software are attractive targets for attackers because they are a single point of access to many customer environments. ConnectWise in particular manages IT operations, remote monitoring, backup services, and billing for thousands of MSPs worldwide. A compromise of ConnectWise's infrastructure or credentials doesn't harm just one end customer: it potentially harms everyone that ConnectWise manages on behalf of.

Attackers have learned this lesson repeatedly. Historical precedent includes incidents where breaches of centralized service providers (such as SolarWinds in 2020, 3CX in 2023, and Okta's support engineering environment in 2023) were used as springboards to compromise large numbers of downstream customers. In those cases, the attackers compromised the software supply chain or the service provider's own infrastructure, then moved laterally into customer networks using the trust that had been placed in the provider's tools.

ConnectWise's cloud backup service is precisely the kind of tool that attackers would want to compromise because backup and disaster-recovery systems often have permissions that other applications do not, and they often have access to sensitive operational data that can inform further attacks.

Organizations using ConnectWise Cloud Backup or other affected ConnectWise services should take the following actions:

1. Review audit logs in Microsoft 365 for any activity by the ConnectWise application identities during the compromise window; the exact dates remain unclear and ConnectWise has not published a detailed timeline, so check with ConnectWise directly for the affected date range.

1. Check for unexpected data exports, mailbox rules, mailbox forwarding rules, or delegated access that may have been set up by attackers using the compromised identities.

1. Verify that no new cloud applications or OAuth consents have been granted to unfamiliar applications in the Azure portal.

1. Force a re-authentication and re-authorization of ConnectWise applications in your Microsoft 365 tenant once ConnectWise confirms that the compromised identities have been replaced with new credentials.

1. Contact ConnectWise support to confirm whether your tenant was affected and request details on what data the compromised identities accessed.

This incident reflects a pattern observed by security researchers and law-enforcement reports: application credentials in cloud services are a lucrative target because they provide automated, persistent access without triggering user-facing warnings. Unlike a user password breach, which a victim might notice through unusual account activity, a stolen application identity can be used silently to export data or modify configurations over days or weeks.

Security vendor incident reports have documented that attackers often prioritize stealing OAuth tokens and application secrets from cloud environments because they reduce the attacker's operational footprint and lower the risk of detection. The Tor Project and related privacy-focused organizations have highlighted how cloud-based SaaS dependencies create a inherent trust relationship that can be weaponized: customers must trust not only the software they use directly, but also the security practices of every third party that software vendor uses.

The fact that ConnectWise disabled seven identities at once also raises questions about whether there were gaps in credential rotation, monitoring, or access control in ConnectWise's own environment. Public details on how the credentials were initially compromised remain limited, and ConnectWise has not disclosed whether attackers obtained them through network compromise, employee account breach, accidental exposure, or other means.

The ConnectWise incident underscores a fundamental risk in the cloud services ecosystem: the security of your data depends not only on your own controls, but on the security practices of every vendor and service provider in your stack. Customers of ConnectWise customers (the downstream organizations) had no direct relationship with ConnectWise, yet their Microsoft 365 tenants were exposed because a ConnectWise credential was stolen.

This creates incentives for organizations to periodically audit their cloud application permissions, to enforce expiration and rotation of OAuth tokens, and to monitor for unusual activity by third-party applications. Many organizations are unaware of how many third-party apps have access to their Microsoft 365 environments, and even fewer regularly review or revoke unnecessary permissions.

For MSPs and IT teams, the lesson is to assume that any centralized service they rely on is a potential compromise vector and to design their security posture accordingly: use least-privilege access for third-party applications, enable strong audit logging, and implement detection mechanisms for unusual data access or exfiltration.

What should I do if I use ConnectWise Cloud Backup? Contact ConnectWise support to confirm whether your Microsoft 365 tenant was affected by the breach, ask for details on the dates when the identities were compromised, and request guidance on verifying and re-authorizing the backup application.

Can attackers still access my data using the ConnectWise identities? Not if ConnectWise has revoked the identities and reissued new credentials. However, data that was exfiltrated during the compromise period remains in the attacker's hands; the compromise stops further ongoing access, but does not undo any data theft that may have already occurred.

How do I check if an attacker used my Microsoft 365 tenant through a compromised application? Examine the audit log in the Microsoft 365 Security & Compliance Center, specifically looking for app-only authentication (OAuth flows) from the ConnectWise application identity during the affected dates. Look for unusual operations like bulk mail export, mailbox delegation, or SharePoint downloads.

Should I stop using ConnectWise services entirely? Not necessarily, but treat this as a signal to review your third-party cloud permissions more broadly. The incident shows that even large, established service providers can suffer compromises. The risk is inherent to cloud services, not unique to ConnectWise. Implement strong monitoring and least-privilege access controls when you resume using any third-party cloud service.

Source: The Hacker News