ConnectWise Credential Compromise Exposes 173 Microsoft 365 Tenants to Unauthorized Access

Unknown attackers obtained a valid credential from ConnectWise Cloud Backup, a cloud recovery service designed to help managed service providers (MSPs) back up and restore customer Microsoft 365 data. Rather than attempting to exploit software vulnerabilities or launch a mass phishing campaign, these threat actors used the compromised credential to authenticate directly into customer M365 tenants. Security researchers identified unauthorized login activity across at least 173 separate customer environments, suggesting the attackers had systematic access to multiple organizations through a single compromised service account.

The credential in question appears to have been used legitimately by ConnectWise for backup operations, meaning it carried the trust and permissions needed to interact with many customer accounts. Once compromised, it became a master key to dozens of organizations' email systems, files and collaboration platforms.

MSPs and backup service providers maintain broad administrative permissions across many customer environments by design. They need these permissions to perform legitimate operations like data recovery, system maintenance and configuration. This creates an inherent security tension: granting a trusted vendor the access they need also means that if their credentials are stolen, attackers inherit the same broad permissions across many organizations at once.

ConnectWise Cloud Backup's role in this chain shows how tightly interconnected modern business services have become. One stolen credential from a backup provider can lead to simultaneous unauthorized access to M365 environments, Exchange mailboxes and potentially sensitive files stored in SharePoint or OneDrive. The attack didn't require hacking into M365's infrastructure or bypassing multi-factor authentication on individual customer accounts. Instead, attackers simply authenticated using legitimate credentials that the victim organizations had explicitly trusted to a third party.

Once attackers authenticated to a M365 tenant using the compromised ConnectWise credential, they could operate as if they were ConnectWise staff performing authorized backup and recovery tasks. This likely allowed them to:

• Browse mailboxes and email messages across the organization
• Access files stored in cloud storage services tied to Microsoft 365
• Create additional user accounts or modify existing permissions to maintain persistence
• Export data or implant malware without alerting security teams who expected ConnectWise to be legitimate

The attackers' activity might have looked routine to automated security tools. M365 logs would show successful authentication and file access, but the source would appear to be a trusted service provider. This is why detecting third-party compromise often takes longer than spotting external attackers. By the time researchers published their findings, 173 customer environments had been accessed, yet many organizations may not have realized they were breached.

Organizations cannot eliminate third-party vendor access without losing critical business functions. Instead, they must apply layered controls that reduce both the likelihood of credential compromise and the blast radius if it happens.

Key protective measures include:

1. Limiting third-party credentials to the minimum permissions required for their specific function
2. Creating separate service accounts for each vendor rather than sharing credentials across multiple providers
3. Implementing conditional access policies in Microsoft 365 that flag or block logins from unexpected geographic locations or IP ranges
4. Monitoring third-party account activity through Azure AD logs and alerting on unusual patterns like bulk file downloads or mailbox forwarding rule creation
5. Requiring vendors to use multi-factor authentication and regularly rotating their credentials
6. Requesting audit logs and incident response plans from vendors before granting them access
7. Maintaining an up-to-date inventory of which vendors have access to which systems and with what permissions

These controls don't prevent credential theft, but they can limit how far an attacker can move after compromising a vendor's account.

If your organization uses ConnectWise Cloud Backup or other M365 backup services, take these steps immediately.

1. Contact your service provider and ask whether your credentials were affected in this incident
2. Check Microsoft 365 sign-in logs for any ConnectWise-related accounts, looking for logins from unfamiliar locations or times
3. Review mailbox forwarding rules, delegated access permissions and user accounts created during the exposure window to identify suspicious changes
4. Rotate the credentials used by ConnectWise and any other backup services to access your M365 environment
5. Verify that mailbox audit logs are enabled and review recent Activity reports for unusual data exports or file access
6. If you detect unauthorized activity, consider engaging incident response specialists to determine what data may have been accessed

The ConnectWise incident reveals why third-party vendor access is one of the hardest parts of enterprise security. You cannot audit or control a vendor's security hygiene completely, yet you must trust them with sensitive systems. This means your own controls around vendor access, credential rotation and activity monitoring become critical compensating factors.

The attackers didn't need to be sophisticated. They didn't exploit zero-day vulnerabilities or defeat multi-factor authentication. They simply used a credential they possessed to authenticate against systems that were configured to trust them. This pattern is common in supply chain attacks: the trusted relationship is the attack surface.

Start by cataloging which vendors have credentials to your M365 environment and what permissions those credentials hold. Then apply the principle of least privilege ruthlessly: if a backup service only needs to access mailboxes, don't grant it access to SharePoint or user management. If it needs access for certain hours of the day, use conditional access policies to enforce that window. Assume that any vendor credential could be compromised, and design your access controls so that one compromised credential limits the attacker to the smallest possible domain.

**How do I know if my organization was affected by this breach?

Contact your MSP or ConnectWise Cloud Backup provider directly and ask whether your credentials were among those compromised. You can also audit your Microsoft 365 sign-in logs for any ConnectWise-related accounts logging in during the attack window and check for suspicious changes to mailbox rules or user permissions.

**Can I use Microsoft 365 safely if my backup service was breached?

Yes, but you should immediately rotate the credentials used by that service, enable multi-factor authentication on the replacement account and monitor activity logs closely. M365 itself was not compromised; the attack exploited stolen credentials for a legitimate third-party account.

**What is a "tenant" in this context?

A Microsoft 365 tenant is a single organization's isolated instance of Microsoft 365 services, including Exchange Online for email, SharePoint for files and Teams for communication. Each tenant is a separate security boundary, so 173 compromised tenants means 173 separate organizations were breached.

**Should I stop using backup services?

No, backups are essential for security and business continuity. Instead, follow the protective measures outlined above: limit the scope of credentials, enable monitoring, rotate passwords regularly and use conditional access policies to restrict where the service account can log in from.

**How is this different from a phishing attack?

Phishing targets individual users with social engineering, typically attempting to steal their personal credentials or trick them into clicking malicious links. This attack used legitimate service credentials that the victim organization had intentionally shared with a trusted vendor, making it much harder to detect because the authentication itself appeared normal.

Source: The Hacker News