Hackers Breach 173 Microsoft 365 Accounts Through Single ConnectWise Credential
Attackers compromised a single ConnectWise Cloud Backup credential to gain unauthorized access to 173 Microsoft 365 tenants across multiple organizations. The breach exploited the broad OAuth permissions granted to the backup application, demonstrating how vendor credential compromise can cascade across multitenant environments. Organizations using ConnectWise or similar backup solutions must immediately audit application permissions, rotate credentials, and implement enhanced monitoring for third-party application access to cloud tenants.
Introduction
A sophisticated attack campaign has exposed a critical weakness in the SaaS supply chain: the compromise of a single vendor credential with broad permissions. Attackers successfully leveraged compromised ConnectWise Cloud Backup credentials to access 173 separate Microsoft 365 tenants, affecting managed service providers (MSPs) and their downstream customers.
This incident represents a textbook example of how modern cloud environments amplify the impact of credential theft. Unlike traditional breaches where attackers must compromise individual systems, this attack exploited the trust relationship between Microsoft 365 and a legitimate backup application to gain immediate, authorized access to sensitive data across multiple organizations.
The breach underscores an uncomfortable reality for security teams: your organization’s security posture increasingly depends on the credential hygiene of third-party vendors with privileged access to your cloud infrastructure.
Background & Context
ConnectWise Cloud Backup (formerly Continuum Backup) is a cloud-based backup solution widely deployed by managed service providers to protect customer data across various platforms, including Microsoft 365. The application requires OAuth permissions to access mailboxes, SharePoint sites, OneDrive content, and Teams data for backup purposes.
These backup applications typically request highly privileged permissions, including:
- Full access to user mailboxes
- Read/write access to all SharePoint sites
- Access to OneDrive files across the organization
- Rights to enumerate users and groups
When an organization grants these permissions through Azure AD’s OAuth consent process, the application receives a token that functions like a master key to the tenant’s data. This design enables comprehensive backup functionality but creates a single point of failure if those credentials are compromised.
MSPs frequently manage dozens or hundreds of customer tenants through a single control plane, meaning one compromised credential at the vendor level can provide attackers with access to an entire portfolio of organizations. This multitenant architecture, while operationally efficient, creates an attack surface with devastating blast radius potential.
Technical Breakdown
The attack chain began with the compromise of ConnectWise Cloud Backup administrative credentials. While the initial access vector remains unclear, possibilities include phishing, credential stuffing against exposed accounts, or exploitation of ConnectWise infrastructure vulnerabilities.
Once attackers obtained valid ConnectWise credentials, they gained access to the backup management console. From this vantage point, they could view all connected Microsoft 365 tenants and the OAuth tokens associated with each.
The OAuth tokens granted to ConnectWise provided the following capabilities:
Application Permissions:
- Mail.ReadWrite (all mailboxes)
- Files.ReadWrite.All (all SharePoint/OneDrive)
- Sites.ReadWrite.All (all SharePoint sites)
- User.Read.All (enumerate all users)
- Group.Read.All (enumerate all groups)
Attackers leveraged these pre-authorized permissions to access Microsoft 365 tenants without triggering multi-factor authentication prompts or conditional access policies. From Microsoft’s perspective, these were legitimate, authorized requests from a trusted application.
The compromise allowed attackers to:
- Enumerate tenant structures – Identify high-value users, sensitive SharePoint sites, and organizational hierarchies
- Exfiltrate email data – Download mailbox contents from executives and sensitive departments
- Access cloud files – Retrieve documents stored in SharePoint and OneDrive
- Establish persistence – Potentially create additional application registrations or service principals for continued access
The attack’s efficiency stemmed from bypassing traditional security controls. No password guessing, no MFA bypasses, no exploitation of Microsoft vulnerabilities—just authenticated access through a legitimate, pre-approved channel.
Impact & Risk Assessment
The breach affected 173 Microsoft 365 tenants, though the actual number of compromised user accounts extends far beyond this figure. Each tenant potentially contains hundreds or thousands of users, meaning the total impact likely encompasses tens of thousands of individual accounts.
Data Exposure:
- Corporate email archives containing confidential communications
- Financial documents, contracts, and intellectual property stored in SharePoint/OneDrive
- Customer information and business strategy documents
- Potentially sensitive authentication tokens or credentials stored in email or files
Downstream Risks:
- Secondary attacks using harvested credentials or intelligence
- Business email compromise campaigns using stolen communication context
- Competitive intelligence gathering
- Regulatory compliance violations (GDPR, HIPAA, etc.)
Trust Erosion:
MSPs face potential customer attrition as organizations reevaluate the security of vendor access to critical systems. The incident damages the managed services model by demonstrating how consolidation of access creates concentrated risk.
Severity Assessment: Critical
Organizations should treat this as a confirmed data breach until proven otherwise. The broad permissions granted to backup applications mean attackers had access to essentially all data within affected tenants.
Vendor Response
ConnectWise has acknowledged the credential compromise and initiated an incident response process. The vendor reportedly:
- Forced password resets for affected administrative accounts
- Implemented additional authentication requirements for backup console access
- Initiated forensic investigation to determine the initial compromise vector
- Notified affected MSP partners and recommended customer notifications
However, questions remain about detection timelines. The gap between initial compromise and detection likely provided attackers with extended access windows for data exfiltration.
Microsoft has not issued specific guidance related to this incident but continues to recommend organizations regularly audit application permissions and implement Azure AD security monitoring.
Mitigations & Workarounds
Organizations using ConnectWise Cloud Backup or similar solutions should take immediate action:
Immediate Actions:
- Audit OAuth Permissions:
Get-AzureADServicePrincipal -All $true | Where-Object {
$_.AppRoles.Value -like "ReadWrite" -or
$_.AppRoles.Value -like "All"
} | Select-Object DisplayName, AppId, AppRoles- Review Sign-in Logs:
# Check for suspicious service principal activity
Get-AzureADAuditSignInLogs -Filter "appId eq 'ConnectWise-App-ID'" |
Select-Object CreatedDateTime, UserPrincipalName, IPAddress, Location- Rotate Credentials:
Force re-authorization of ConnectWise application access to invalidate potentially compromised tokens.
Long-term Hardening:
- Implement principle of least privilege for third-party applications
- Enable Azure AD conditional access policies for service principals
- Deploy application consent policies requiring administrative approval
- Segment critical tenants from standard backup solutions where feasible
Detection & Monitoring
Establish monitoring for indicators of OAuth token abuse:
Azure AD Audit Logs:
Monitor for unusual patterns in service principal activity:
- Access from unexpected geographic locations
- Unusual data volume transferred
- Access to mailboxes or files outside normal backup windows
- Multiple rapid tenant accesses
Detection Query:
// Detect abnormal service principal activity
AuditLogs
| where TimeGenerated > ago(7d)
| where InitiatedBy.app.appId == "backup-app-id"
| summarize count() by bin(TimeGenerated, 1h), IPAddress, TargetResources
| where count_ > baseline_thresholdBehavioral Indicators:
- Service principal accessing resources never previously accessed
- Downloads occurring outside maintenance windows
- Enumeration activities (bulk user/group queries)
Integrate Microsoft 365 audit logs with SIEM platforms to correlate backup application activity with other security telemetry.
Best Practices
Prevent similar vendor credential compromises through defense-in-depth:
Application Permission Hygiene:
- Conduct quarterly reviews of all OAuth consents
- Revoke unused or over-privileged applications
- Implement time-limited application access where possible
- Require business justification for high-privilege permissions
Vendor Security Requirements:
- Mandate MFA for all vendor administrative access
- Require vendors to maintain SOC 2 Type II compliance
- Contractually obligate breach notifications within defined timeframes
- Conduct annual vendor security assessments
Architecture Considerations:
- Isolate high-value tenants from shared backup infrastructure
- Implement customer-managed encryption keys (BYOK) where feasible
- Deploy Microsoft Cloud App Security for application governance
- Consider on-premises backup options for highest sensitivity data
Monitoring & Response:
- Establish baselines for normal backup application behavior
- Configure alerts for unusual service principal activity
- Develop playbooks for third-party credential compromise scenarios
- Practice incident response for OAuth token abuse scenarios
Key Takeaways
- Single credentials with broad OAuth permissions create catastrophic single points of failure in multitenant environments
- Third-party application compromise bypasses traditional security controls including MFA and conditional access
- MSP customers inherit the security posture of their service providers, creating transitive risk
- OAuth tokens function as persistent access mechanisms that attackers can abuse without triggering authentication alerts
- Detection requires behavioral analysis since malicious activity appears as legitimate, authorized access
- Regular permission audits are essential to identify and remediate over-privileged applications before compromise
References
- Microsoft 365 Security Best Practices: https://docs.microsoft.com/microsoft-365/security/
- Azure AD Application Consent: https://docs.microsoft.com/azure/active-directory/manage-apps/
- OAuth 2.0 Security Best Current Practice: https://tools.ietf.org/html/draft-ietf-oauth-security-topics
- MITRE ATT&CK – Valid Accounts (T1078.004): https://attack.mitre.org/techniques/T1078/004/
Stay updated at https://cydhaal.com — Your Daily Dose of Cyber Intelligence.
📧 Subscribe to our newsletter at https://cydhaal.com/newsletter/
