ConnectWise Cloud Backup: Microsoft 365 Access Incident

ConnectWise Cloud Backup: Microsoft 365 Access Incident | 2026

Executive Summary

On October 15, 2026, attackers abused a compromised ConnectWise Cloud Backup credential to authenticate as a trusted Microsoft 365 application in customer tenants. Huntress confirmed unauthorized sign-ins in at least 162 tenants by October 16, while later reporting cited 173 partner and customer tenants. ConnectWise disabled affected application access and suspended Cloud Backup while it resets credentials and investigates.

This is a cloud trust and identity incident, not a conventional endpoint malware outbreak. The exposed application held broad permissions over Microsoft Graph, Exchange Online, Teams, SharePoint, and directory data. Defenders should audit service-principal sign-ins, application credentials, role assignments, and consent changes immediately—even if their own organization did not knowingly grant an attacker a user account.

What Happened?

The incident involved the former SkyKick Cloud Backup application, now branded ConnectWise Cloud Backup. A vendor-held client credential was used from 144.172.64[.]128, a hosting-provider address, rather than the private Azure ranges associated with normal application traffic. The attacker then obtained Microsoft Graph access tokens in tenants where the application was installed.

Huntress also documented a more invasive path in one tenant: a ConnectWise Teams application assigned itself Global Administrator and added new credentials to other applications, including a Huntress application. That activity demonstrates why service-principal and application-management logs matter alongside user sign-in logs.

Timeline

Who Is Affected?

Potentially affected organizations include Microsoft 365 tenants with the ConnectWise Cloud Backup/SkyKick service principal or other identified ConnectWise cloud-management applications installed. The confirmed count is not a complete global exposure count: the same vendor credential could work in every tenant where the application had consent and permissions.

The incident is especially relevant to managed service providers (MSPs), their customers, and organizations that delegated broad access to backup, migration, Exchange, Teams, or SharePoint integrations. A successful application sign-in does not by itself prove that data was read or exfiltrated; tenant-specific audit evidence is required.

Initial Access and Kill Chain

This is an abuse of trusted identity and access control in a multi-tenant cloud ecosystem. It also illustrates a cloud supply-chain attack pattern: compromise at a service provider can become an identity event inside many customer environments.

Indicators and Detection

Identity and application logs

Review Microsoft Entra sign-in and audit logs from at least October 1 onward for:

• Application ID 506e08f9-6e9a-4da4-942b-a099a03644ae (ConnectWise Cloud Backup, formerly SkyKick).
• Application ID 24205314-2b89-4e07-a2a4-579e898a5640 (ConnectWise Cloud Management - MS Teams).
• Successful application sign-ins from 144.172.64[.]128.
• Add member to role, Add service principal credentials, Update application, consent, owner, and permission-grant events involving ConnectWise applications.
• New credentials with unexpected expiry dates or applications that changed permissions without a matching change ticket.

Example Microsoft Sentinel pattern (adapt field names to the tenant schema):

AuditLogs
| where TimeGenerated >= datetime(2026-10-01)
| where ActivityDisplayName has_any (
    "Add member to role", "Add service principal credentials",
    "Update application", "Consent to application")
| where tostring(TargetResources) has_any (
    "506e08f9-6e9a-4da4-942b-a099a03644ae",
    "24205314-2b89-4e07-a2a4-579e898a5640",
    "ConnectWise", "SkyKick")
| project TimeGenerated, ActivityDisplayName, InitiatedBy, TargetResources, Result
| order by TimeGenerated desc

Endpoint, email, and network telemetry

Correlate suspicious application events with mailbox access, unusual SharePoint or OneDrive downloads, new inbox or transport rules, anomalous Teams activity, and sign-ins that do not match the vendor’s normal service profile. Preserve logs before retention windows expire and treat missing application-read telemetry as an uncertainty, not proof that no data was accessed.

Containment and Remediation Checklist

🔴 Immediate containment (0–24 hours)

1. Disable the ConnectWise Cloud Backup/SkyKick enterprise application and the affected ConnectWise cloud-management applications in every tenant you manage, following ConnectWise guidance.
2. Review service-principal sign-ins from October 1 onward, prioritizing October 15–16.
3. Remove unauthorized application credentials, owners, role assignments, consents, and delegated permissions.
4. Revoke refresh tokens and active sessions where the investigation indicates suspicious access.
5. Search for new mail-flow rules, forwarding settings, OAuth grants, and unusual file or mailbox access.
6. Preserve Entra, Unified Audit, Exchange, SharePoint, Teams, and Defender evidence for incident response.
7. Escalate to ConnectWise and your MSP or customer contacts; do not re-enable integrations until formal restoration guidance is available.

🟠 Hardening (24–72 hours)

1. Inventory all multitenant applications with tenant-wide Graph, Exchange, SharePoint, or directory permissions.
2. Enforce administrative approval for new consent and restrict who can add credentials to applications.
3. Apply workload-identity conditional access and location or risk controls where supported.
4. Enable alerting for service-principal sign-ins from new hosting providers or geographies.
5. Confirm that backup integrations use least privilege and have documented owners, expiry, and business justification.
6. Validate that application and audit logs are exported to a protected SIEM workspace.

🟡 Longer-term controls (1–4 weeks)

1. Reassess third-party SaaS and MSP trust boundaries as part of the organization’s identity and access management program.
2. Require supplier incident-notification, credential-rotation, and forensic-cooperation commitments in contracts.
3. Test tenant recovery from independent, immutable backups; backup security is not the same as application trust security.
4. Run a tabletop exercise for a compromised multitenant OAuth application.
5. Feed confirmed indicators and lessons learned into detection engineering and third-party risk reviews.

Strategic Analysis: Trust Is an Attack Surface

The incident shows how a single vendor-held credential can bypass many customer-side controls because the resulting activity is authenticated as a permitted application. MFA for human administrators does not automatically stop a stolen workload credential. Nor does disabling an individual user account address persistence created through application credentials.

The defensive priority is therefore identity visibility: know which applications can read or change tenant data, alert on service-principal behavior, and make high-impact permissions reversible. Organizations should treat trusted SaaS integrations as privileged identities with lifecycle management, not as invisible plumbing.

References

1. Huntress investigation
2. ConnectWise service update
3. The Hacker News reporting
4. Help Net Security reporting