ConnectWise shut down its Cloud Backup service on October 17 after attackers compromised application identities and accessed at least 162 Microsoft 365 tenants. This breach shows how third-party service principals can bypass your perimeter controls, turning trusted vendor access into an attack vector that multi-factor authentication can't stop.
How the Breach Happened
Attackers obtained valid credentials for ConnectWise's backup application and authenticated directly to Microsoft 365 tenants as the service principal. Because the application already held broad permissions granted by customers, the sign-ins provided immediate access to email, OneDrive, SharePoint files, and Teams chats. The authentication occurred at the application layer, making user-level protections like MFA irrelevant.
Microsoft identified unauthorized authentication attempts from IP address 144.172.64.128 starting October 15. Huntress observed that in nearly 50 monitored tenants, ConnectWise's Cloud Management service principals assigned themselves directory roles, primarily Exchange Administrator. In at least one tenant, attackers established persistence within five minutes by granting the Cloud Management app Global Administrator privileges and adding credentials to other management tools.
The attack method was scripted. Todyl researchers identified automated sign-in requests using user agents python-urllib/3.12, python-requests/2.31, and python-requests/2.34.2. The attacker didn't need to create new accounts or change passwords because they already possessed the keys to the kingdom.
Key Findings
Application identities operate outside your identity perimeter. Service principals authenticate using secrets or certificates, not user credentials. Your conditional access policies, MFA requirements, and user behavior analytics don't apply. When ConnectWise's application identity was compromised, attackers inherited every permission your team had granted that application across all connected tenants.
Broad permissions create broad exposure. The compromised Cloud Backup application held Directory.ReadWrite.All permissions in many tenants. This Microsoft Graph permission allows reading and modifying directory objects, including users, groups, and applications. Combined with Exchange Administrator roles, attackers could access communications and potentially modify directory structure without triggering user-focused detection rules.
Vendor credential compromise leaves artifacts in your environment. ConnectWise's service interruption doesn't remove credentials attackers may have planted. Disabling an application stops new token issuance, but existing tokens remain valid until expiration. Revoking user sessions has no effect on application-based access. If attackers added secrets or certificates to other applications in your tenant during the breach window, those backdoors persist until you find and remove them manually.
Detection requires application-layer visibility. Traditional security controls monitor user behavior. This attack generated service principal sign-ins from an unexpected IP address, role assignments by non-human identities, and Graph API reconnaissance. If your security operations team isn't reviewing Entra ID application activity logs, you're blind to this entire class of compromise.
Supply-chain risk manifests as identity risk. You vetted ConnectWise's security practices when you selected their backup service. You didn't vet whoever compromised their credential management. The trust you extended to their application identity became a trust relationship with an unknown threat actor.
Implications for Your Team
Your vendor risk assessments need to explicitly address application identity management. Ask how vendors store and protect service principal credentials. Require evidence of credential rotation policies, secret management practices, and monitoring for unauthorized authentication attempts. The standard "SOC 2 Type II" checkbox doesn't cover this.
Your identity governance program probably focuses on user accounts. It needs to cover service principals with the same rigor. Every application with Directory.ReadWrite.All or Global Administrator equivalent permissions represents a potential full-tenant compromise if that application's credentials leak.
Your security operations team needs playbooks for application identity compromise. User account compromise procedures don't translate. You can't reset a service principal's password and force re-authentication. You need to inventory application credentials, identify unauthorized additions, and understand token lifetime policies.
Action Items by Priority
Immediate (this week): Review service principal sign-ins in Microsoft Entra ID for the specific ConnectWise application IDs listed by Huntress. Filter by application ID 506e08f9-6e9a-4da4-942b-a099a03644ae and examine source IP addresses. Check for the attacker IP 144.172.64.128 and unexpected geographic locations. Review application credential changes since October 13.
Short-term (this month): Audit all third-party applications with high-privilege permissions in your Microsoft 365 tenant. Identify applications holding Directory.ReadWrite.All, Mail.ReadWrite, Files.ReadWrite.All, or directory role assignments. For each application, document the business justification and verify the permission scope still matches current requirements. Remove applications you no longer use. ConnectWise customers who hadn't used the service in years still had active service principals with broad permissions.
Medium-term (this quarter): Implement continuous monitoring for service principal activity. Configure alerts for service principal sign-ins from unexpected locations, role assignments by applications, and credential additions to applications. Microsoft Sentinel and similar SIEM platforms can ingest Entra ID logs, but you need detection rules specifically for application identity events. User-focused rules won't catch this.
Ongoing: Build application identity governance into your vendor management program. Before granting a vendor application access to your tenant, document exactly what permissions you're granting and why each permission is necessary. Establish a review cycle for vendor application permissions independent of contract renewal. When you offboard a vendor, verify that you've removed their service principals, not just disabled user accounts.
Review your Incident Response Plan for scenarios where the initial access vector is a trusted application. Your containment procedures need to account for valid credentials that can't simply be revoked without business impact. Your communication plan needs to address supply-chain compromise where you're waiting for the vendor to complete their investigation before you have full visibility into the scope.
