ConnectWise suspends cloud backup after attackers compromise M365 tenant identities

1. Executive summary

ConnectWise has disabled seven application identities, including ConnectWise Cloud Backup, after unknown actors used a compromised client assertion credential belonging to the Cloud Backup application to authenticate into customer Microsoft 365 tenants and obtain Microsoft Graph access tokens. Huntress confirmed unauthorized sign-ins in 162 tenants as of 19:00 UTC on 16 October, with the actor moving through tenants in sorted GUID order from a single hosting provider address, 144.172.64[.]128. The credential lives in ConnectWise's own tenant, so no customer-side control could have prevented the initial authentication, and the app's backup and restore permissions grant read and write access to mailboxes, OneDrive, SharePoint, Teams and directory data across every tenant where it is consented. For EMEA financial services clients running this app, the exposure is broad data access under a trusted service principal rather than malware on an endpoint, and the actor's ability to add client secrets to other applications in a tenant means the compromise can outlive the revocation of the original credential. No CVE has been assigned and no CISA KEV entry exists for this item.

2. Regulatory framing

3. Technical analysis & attack chain

ConnectWise Cloud Backup, formerly SkyKick, is a cloud backup and recovery service for MSPs protecting client Microsoft 365 and Google Workspace data. To function it is granted broad access to mailboxes, OneDrive, SharePoint, Teams and directory data in every tenant where it is installed. The credential at issue is a client assertion, meaning it lives in ConnectWise's own tenant and is presented by the application to Microsoft Entra ID. Nothing a customer did in their own environment could have produced the authentication.

Confirmed steps, drawn from Microsoft sign-in logs in affected tenants and Huntress telemetry:

1. On 15 October between 06:13 and 08:34 UTC, the ConnectWise Cloud Backup application identity signed in to customer Microsoft 365 tenants from 144.172.64[.]128, a hosting provider address, and received Microsoft Graph access tokens. Legitimate traffic for this application comes from Azure private IP space.
2. The actor moved through tenants in sorted GUID order, a few seconds apart, consistent with a script working from a target list rather than manual access.
3. The actor authenticated to the application using its own tooling, the same way the backup service does, and received tokens carrying the application's existing permissions. Because backup and restore both require read and write, those permissions allow reading the same mailboxes, files and directory data the backup service can reach.
4. Huntress confirmed unauthorized sign-ins in 162 tenants as of 19:00 UTC on 16 October. The credential works against every tenant where the app is consented, so the confirmed count is a floor, not a ceiling.

Huntress observed related activity from the same infrastructure that it has not attributed to the same actor with certainty:

• 13 to 14 October: password spraying against four law firm tenants from 144.172.64[.]128, with scripted OAuth2 token requests using User-Agent curl/7.88.1 from datacenter infrastructure. Two accounts were locked out by smart lockout. Huntress saw no successful user sign-ins from this IP in its telemetry.
• From 01:58 UTC on 15 October, in roughly 50 tenants Huntress monitors: service principals for ConnectWise's Cloud Management apps (Exchange Online, Microsoft Teams and Microsoft Graph) assigned themselves directory roles, mostly Exchange Administrator. The User-Agent on these events, kiota-dotnet, is the one ConnectWise's own apps use, which points to vendor automation, but Huntress has not confirmed that with ConnectWise.
• 03:44 to 03:49 UTC on 15 October, in one customer tenant: the ConnectWise Cloud Management app for Microsoft Teams (application ID 24205314-2b89-4e07-a2a4-579e898a5640) added itself to the Global Administrator role, then ran a Python script (User-Agent Python-urllib/3.12) that modified two other applications in the tenant, an MSP management application and Huntress's own application (Huntress Security Platform), adding new client secrets to both. A follow-up attempt to add a certificate failed. The new secrets were set to expire in 2028.

The persistence implication is the part that matters most. Adding client secrets to other applications gives the actor a second authentication path that does not depend on the Cloud Backup credential, and those secrets were set to expire in 2028. Revoking the original credential does not remove them. The self-assignment of directory roles, particularly Exchange Administrator, widens what the actor can reach inside a tenant beyond the backup application's own scope.

ConnectWise has acknowledged the incident on its website and confirmed the IP is associated with unauthorized activity. Todyl has also reported on the incident. The specific identity of the actor is not established in any source, and no MITRE ATT&CK profile is available for a named actor in this item. Attribution is unconfirmed.

The 162-tenant figure, the tenant-walking pattern, the directory role self-assignment and the client secret additions all rest on Huntress telemetry and are single-sourced. The authentication events themselves come from Microsoft's own sign-in logs in each tenant, which makes the core fact of unauthorized sign-in corroborated at the tenant level even where the wider campaign picture is not.

4. Mitigation & containment

P1 within 24 hours

• Enumerate every tenant where ConnectWise Cloud Backup (formerly SkyKick) and the ConnectWise Cloud Management apps are consented. Search Entra ID enterprise applications and service principals for the application ID 24205314-2b89-4e07-a2a4-579e898a5640 (Cloud Management for Microsoft Teams) and for the Cloud Backup application identity. Any tenant with the app installed is in scope regardless of whether a sign-in has been observed.
• Pull Entra ID sign-in logs for the Cloud Backup service principal and search for authentications from 144.172.64[.]128 and for any sign-in originating outside Azure private IP space. Treat any such event as a confirmed compromise of that tenant.
• Review directory role assignments made to service principals. Huntress saw ConnectWise Cloud Management service principals assign themselves Exchange Administrator, and in one tenant the Teams app added itself to Global Administrator. Remove any role assignment to these service principals that is not documented and expected.
• Audit all applications in each tenant for newly added client secrets or certificates, with particular attention to secrets with long expiry dates. Huntress observed secrets set to expire in 2028 added to an MSP management application and to the Huntress Security Platform application. Remove any secret or certificate you cannot account for and rotate the credentials of the affected applications.
• Where ConnectWise has disabled the seven application identities, confirm the effect in your own tenant rather than assuming it. A disabled identity in the vendor tenant does not remove secrets the actor added to applications in your tenant.

P2 within 72 hours

• Review Microsoft Graph activity for the affected service principals across the 15 October window and afterwards: mail read and send, file access in OneDrive and SharePoint, Teams message access, and directory reads. The actor held tokens with the application's full permissions, so scope the review to everything the backup service can reach.
• Check for mailbox rules, forwarding, delegate permissions and OAuth consent grants created in the window that would sustain access after credential rotation.
• If your tenant shows any of the persistence indicators above, treat it as a confirmed incident and start your DORA and NIS2 incident processes rather than a containment exercise.

P3 within 7 days

• Reassess the consent granted to backup and management applications. The permissions are broad by design, and this incident shows the consequence when the vendor-held credential is lost. Where a narrower permission set can do the job, move to it.
• Require conditional access or workload identity controls that restrict service principal sign-ins to expected network ranges, so that authentication from a hosting provider address is blocked or alerted rather than accepted.
• Confirm with ConnectWise what notification and remediation it will provide to affected tenants, and record it against your third-party risk file.

5. Indicators of compromise

The source lists seven disabled ConnectWise application identities but gives only the Cloud Backup GUID in full. The remaining six are not reproduced here because the values are not present in the source material.

ipv4  144.172.64[.]128
user-agent  curl/7.88.1
user-agent  kiota-dotnet
user-agent  Python-urllib/3.12
application-id  24205314-2b89-4e07-a2a4-579e898a5640
application-id  506e08f9-6e9a-4da4-942b-a099a03644ae

Behavioural indicators

6. Detection

The sources give usable artefacts for a Sigma rule: the source IP, the three User-Agents, and the Teams application ID. A YARA rule is not appropriate here because no file artefacts, hashes or on-disk strings are provided; the activity is entirely authentication and directory-level. The Sigma rule below targets Entra ID sign-in and audit telemetry.

title: ConnectWise Cloud Backup Service Principal Authentication from Hosting Infrastructure
id: 7f3c1a92-4b6e-4d21-9c8a-2e5f0b7d1a44
status: experimental
description: Detects authentication by the ConnectWise Cloud Backup application identity from the hosting provider address observed in the October 2026 M365 tenant compromise, and related scripted OAuth2 activity from the same infrastructure.
author: Adverse Trace
date: 2026-10-18
references:

  - https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access
  - https://thehackernews.com/2026/10/connectwise-suspends-cloud-backup-after.html
logsource:
  product: azure
  service: signinlogs
detection:
  selection_ip:
    ipaddr: '144.172.64.128'
  selection_ua:
    useragent:

      - 'curl/7.88.1'
      - 'kiota-dotnet'
      - 'Python-urllib/3.12'
  condition: selection_ip or selection_ua
falsepositives:

  - Legitimate administrative use of curl or Python against Microsoft Graph from within the organisation
  - ConnectWise vendor automation using kiota-dotnet, which is expected for the vendor's own apps
level: high

title: ConnectWise Cloud Management Teams App Added to Global Administrator
id: 2a8d5e41-9c37-4f60-b1d2-6e4a7c0f9b13
status: experimental
description: Detects the ConnectWise Cloud Management application for Microsoft Teams adding itself to the Global Administrator role, a step observed in the October 2026 M365 tenant compromise.
author: Adverse Trace
date: 2026-10-18
references:

  - https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access
logsource:
  product: azure
  service: auditlogs
detection:
  selection:
    activityDisplayName: 'Add member to role'
    targetResources.appId: '24205314-2b89-4e07-a2a4-579e898a5640'
    targetResources.modifiedProperties.newValue|contains: 'Global Administrator'
  condition: selection
falsepositives:

  - Documented administrative change to the ConnectWise Cloud Management app role assignment
level: critical

7. Sources

• The Hacker News, ConnectWise Suspends Cloud Backup After Attackers Compromise Microsoft 365 Tenants, https://thehackernews.com/2026/10/connectwise-suspends-cloud-backup-after.html, 2026-10-18
• The Hacker News, Hackers Use Compromised ConnectWise Credential to Sign In to 173 Microsoft 365 Tenants, https://thehackernews.com/2026/10/hackers-use-compromised-connectwise.html
• Huntress, ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks, https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access

8. Adverse Trace position

Adverse Trace assesses this as a high-impact supply chain compromise for any EMEA financial services client with ConnectWise Cloud Backup consented in a Microsoft 365 tenant, because the actor held tokens with the application's full read and write permissions and added client secrets to other applications that survive revocation of the original credential. The 162-tenant figure and the persistence detail are single-sourced to Huntress; verify the directory role and client secret indicators in your own tenant before acting on them, and treat the sign-in log evidence as the authoritative trigger. No CVE has been assigned and no CISA KEV entry applies, so this will not appear in vulnerability-driven prioritisation and must be handled through third-party and identity controls instead. We will monitor ConnectWise's advisories and Huntress's blog for an updated tenant count, the remaining six disabled application identities, and any confirmed attribution, and will reissue this advisory if the scope or the persistence picture changes.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.