How Hackers Exploited a Compromised ConnectWise Credential to Access 173 Microsoft 365 Environments

In an active campaign first identified by cybersecurity researchers, attackers obtained a valid Microsoft 365 credential that belonged to ConnectWise Cloud Backup, a cloud-based backup and recovery service widely used by managed service providers (MSPs). Using this single compromised credential, the threat actors were able to log in to at least 173 separate M365 tenant environments belonging to customers of ConnectWise. The attackers did not need to break into each customer independently; one stolen credential from the service provider opened 173 doors.

ConnectWise Cloud Backup (formerly marketed as SkyKick) holds legitimate, administrative-level access to customer M365 environments in order to perform backup and restore functions. This is standard practice in the MSP industry. However, when that credential is compromised, it becomes a master key. Attackers can use it to enumerate, modify or exfiltrate data from customer tenants without triggering the suspicion that would normally accompany a brute-force attack or credential-stuffing attempt.

Supply-chain attacks against software vendors and service providers are among the hardest to detect and defend against because they exploit trust relationships that exist by design. A customer's security team expects that ConnectWise will have high-level access to their M365 environment; that is part of the contract. An alert log showing ConnectWise connecting to the tenant might trigger scrutiny, but an attacker using ConnectWise's own credentials will appear to be the legitimate service provider.

This kind of compromise is especially potent in the MSP ecosystem because MSPs are trusted to manage security infrastructure for multiple clients at once. A single compromised credential can multiply the damage across dozens or hundreds of organizations that rely on the same service. The customer organizations may not discover the breach until much later, after data has been copied, mailboxes have been accessed, or administrative accounts have been created for persistence.

When an MSP like ConnectWise needs to back up a customer's Microsoft 365 environment, it typically receives an application permission grant or a service account credential that allows it to connect to the tenant and read (and in some cases write) data. This access is necessary for the backup service to function. However, it also means that anyone who gains control of that credential can impersonate the service provider.

In a compromise scenario, attackers can use the credential to perform reconnaissance inside each tenant: listing users, discovering shared mailboxes, identifying high-value data and accounts. They can export mailboxes, download OneDrive files or SharePoint documents, and modify user permissions to create new backdoor accounts. Because the credential belongs to a known and trusted service, audit logs may show the activity as legitimate, making it harder to spot the intrusion in real time.

M365 tenants have their own security features, including conditional access policies and sign-in risk detection, but these are often configured to allow known service providers. An attacker using a legitimate service provider credential can bypass many of these controls.

Affected organizations may not realize they have been compromised for weeks or months. The breach itself may not trigger a visible alert because the access is legitimate at the credential level; it appears to come from ConnectWise's infrastructure and uses a trusted application ID. Organizations would need to either receive a notification from ConnectWise or from a threat intelligence vendor, or they would need to conduct a manual review of audit logs looking for suspicious behavior patterns from ConnectWise.

Customers who use ConnectWise Cloud Backup should assume that during the window when the credential was active, an attacker had the same access that ConnectWise has. This means sensitive emails, files in shared drives, and potentially user account details could have been accessed. Depending on the attacker's objectives, they may also have created new administrative accounts, modified security settings, or set up forwarding rules on high-value mailboxes for ongoing data exfiltration.

Service provider credentials are high-value targets. According to incident disclosures and law-enforcement press releases, threat actors specifically hunt for credentials belonging to trusted third-party services because a single credential unlocks multiple customer environments. The ROI on compromising a service provider is far higher than compromising a single customer organization.

Audit logging alone is often insufficient. M365 audit logs record actions by credential, not by human intent. If an attacker uses ConnectWise's credential, the logs will show activity from ConnectWise, making it difficult for a customer's SOC to distinguish legitimate backup activity from unauthorized access without additional context or external notification.

MSP environments are often under-monitored for third-party access. Research and incident reports indicate that organizations frequently fail to implement conditional access policies or sign-in restrictions specific to third-party service accounts, treating them as too operationally sensitive to limit.

Lateral movement is difficult to prevent once initial access is obtained. Once inside a tenant, an attacker with service provider credentials can often create new accounts, grant themselves additional permissions or access tokens, and establish persistence that survives credential rotation.

Organizations that use ConnectWise Cloud Backup should take the following actions:

1. Contact ConnectWise directly to confirm the status of the compromised credential and obtain a precise timeline of when it was active.

1. Request a complete audit of all sign-in and data access activity from the ConnectWise service account during the exposure window.

1. Review M365 audit logs for unusual administrative activity, mailbox forwarding rules, new accounts or permission changes that correlate with the compromise timeline.

1. Reset all relevant M365 administrative passwords and review active sessions to identify and terminate any unauthorized connections.

1. Implement a conditional access policy that restricts the ConnectWise service account to specific IP addresses and limits the scope of operations it can perform.

1. Consider enabling audit logging for sensitive operations and configuring alerts for any changes made by third-party service accounts.

No organization can eliminate the need to grant third-party service providers access to critical systems. However, you can reduce risk by implementing the following controls:

• Maintain an inventory of all third-party accounts and the specific permissions they hold in your M365 environment. This list should be reviewed quarterly.

• Use application-specific permissions and conditional access policies to limit what each service provider account can do and when it can do it. Avoid granting broad administrative roles.

• Require multi-factor authentication on all service provider accounts, even though this may require additional coordination with the vendor.

• Monitor for anomalous activity from service provider accounts: unusual sign-in times, access from unexpected locations, or operations outside the normal scope of the service.

• Establish a communication channel with your MSP or service provider so you can receive timely notifications if their infrastructure is compromised.

• Perform periodic red-team exercises that simulate compromise of a third-party credential to test your detection and response processes.

The ConnectWise compromise illustrates a structural vulnerability in cloud service ecosystems: the need to grant service providers high-level access creates a concentration of risk. If a service provider's infrastructure or credential storage is compromised, the attacker's reach extends across all of that provider's customers simultaneously. This is why some organizations are moving toward zero-trust architecture for third-party integrations, requiring service providers to authenticate on a per-action basis rather than holding standing credentials.

The incident also reinforces the importance of external threat monitoring and incident notification channels. Many affected organizations may not discover the breach through their own internal tools; they will find out when ConnectWise or a security vendor alerts them. This asymmetry between detection and notification means that victims are often unaware they have been compromised until after significant damage has been done.

If your organization uses ConnectWise Cloud Backup or any similar third-party backup or management service for Microsoft 365, the most practical step you can take right now is to request a security incident report from your service provider. Ask them explicitly whether their credentials have been compromised and, if so, what detection and recovery steps they have taken. If you manage multiple tenants or subsidiaries, request the same information for each one. Do not wait for a formal notification; proactive communication with your vendors can significantly reduce the time between compromise and discovery.

Source: The Hacker News