The Challenge
On October 15, hackers used ConnectWise's Cloud Backup service credentials to access Microsoft 365 tenants. At least 162 tenants were compromised. The attackers bypassed traditional security measures by using the application's own identity, a service principal already authorized by customers. These legitimate credentials meant multi-factor authentication didn't apply. The attackers ran scripts that signed in as the backup service, gaining permissions to read and write mail, OneDrive files, SharePoint documents, and Teams chats.
ConnectWise shut down customer access to the Cloud Backup service on October 17. However, disabling the application doesn't revoke already issued tokens, which remain valid until expiration. If attackers added credentials during their access, those persist even after the vendor disconnects the service.
Understanding the Environment
ConnectWise's Cloud Backup uses Microsoft Entra ID service principals, which represent software in a customer's tenant. Granting a backup tool access to your Microsoft 365 environment authorizes a non-human identity with broad permissions. The service requires Directory.ReadWrite.All to operate. This isn't negligence by the vendor; it's the permission model necessary for large-scale backup and recovery.
Huntress found that on nearly 50 monitored tenants, service principals for ConnectWise's Cloud Management apps assigned themselves directory roles, mainly Exchange Administrator. In one case, the attacker quickly escalated privileges: Cloud Management - MS Teams granted itself Global Administrator and added credentials to an MSP management tool and Huntress's application. This persistence operation took about five minutes.
Microsoft labeled this as an active supply-chain attack. The attacker likely obtained ConnectWise's application secret, allowing them to authenticate on behalf of all customers. No user interaction or MFA prompt was needed.
Response and Analysis
ConnectWise issued a security advisory and shut down application access for all partners and clients. They reported no evidence of compromised backup data archives but couldn't rule out data exfiltration from live tenants during the access window.
Microsoft Threat Intelligence traced the attacker to a single IP address: 144.172.64[.]128. Sign-in attempts began on October 13 and 14, using the user agent curl/7.88.1. By October 15, the attacker automated authentication with python-urllib/3.12, python-requests/2.31, and python-requests/2.34.2.
Todyl researchers found only sign-in activity in nine compromised tenants, with no account creation or password changes. However, Huntress observed role assignments and credential additions in other tenants, indicating varied attacker behavior.
Microsoft recommended reviewing application credential changes, OAuth grants, and Graph API activity. Huntress advised disabling implicated ConnectWise applications and checking for unauthorized credential additions across all Cloud Management integrations. They provided seven application IDs to search for, including ConnectWise Cloud Backup (506e08f9-6e9a-4da4-942b-a099a03644ae).
Results and Metrics
The vendor shutdown stopped new tokens from being issued, but existing tokens remained valid until expiration. Revoking user sessions doesn't end application-based access. If the attacker added secrets or certificates to other applications between October 13 and the shutdown on October 17, those credentials persist until manually removed.
An administrator on Reddit received a Microsoft Privileged Identity Management alert on October 15: a SkyKick service principal had assigned itself Exchange Administrator, despite the organization not using the app in years. This highlights a credential hygiene failure. The application identity was still authorized in the tenant, dormant but exploitable.
ConnectWise didn't provide a timeline for restoring service. At the time of their advisory, the victim count and extent of data theft remained unclear. The method used to obtain the vendor's application secret wasn't disclosed.
Lessons Learned
This breach revealed two control gaps that need addressing.
First, application credential hygiene. Organizations often authorize service principals and then forget about them. If you're not using a backup service anymore, revoke its Entra ID registration. Don't leave dormant applications with Directory.ReadWrite.All in your tenant. Huntress recommended reviewing secrets and certificates for unauthorized additions since October 13. Regular audits of application permissions and credential expiration dates are essential.
Second, vendor secret management. ConnectWise's application secret was compromised, but the method remains unknown. If you're a vendor managing service principals for thousands of customers, your secret management controls are a supply chain risk. Rotating application secrets on a schedule, using hardware security modules for storage, and monitoring for anomalous sign-in patterns should be standard practices.
Takeaways for Your Team
Audit your Entra ID service principals now. Filter by applications with Directory.ReadWrite.All or other high-privilege Graph API permissions. Cross-reference against your active vendor list. Revoke registrations for unused applications. For those in use, document who authorized them, when, and why.
Review application sign-in logs weekly. Look for unexpected source IP addresses, unusual user agents, or sign-in patterns that don't match normal service behavior. Microsoft Entra ID logs service principal authentication separately from user sign-ins. Don't ignore that telemetry.
Require vendors to disclose their application secret rotation policies. If a vendor can't tell you how often they rotate credentials or where they store them, that's a red flag in your pre-contractual assessment. Add it to your SIG Core questionnaire: "How do you manage and rotate application secrets for service principals in customer tenants?"
Plan for token validity windows. Disabling an application stops new tokens, but existing ones remain valid. Know your token lifetime settings. If you need to revoke access immediately after a suspected compromise, remove the application registration entirely, which may disrupt legitimate integrations. Document that tradeoff before an incident occurs.
Test your ability to detect credential additions. The attacker added secrets to applications during their access window. Can your monitoring detect that? Microsoft Graph API logs record credential changes. If you're not ingesting those logs or alerting on them, you're blind to persistence attempts that don't involve user accounts.
The ConnectWise breach wasn't sophisticated. The attacker used valid credentials and existing permissions. Your defenses against this pattern aren't just technical controls, they're governance: knowing what you've authorized, auditing it regularly, and having the operational muscle to revoke access fast when a vendor signals compromise.
