ConnectWise Cloud Backup supply chain attack compromises M365 via elevated permissions

1. Executive summary

A credential belonging to the ConnectWise Cloud Backup application (formerly SkyKick) was used on 2026-10-15 to authenticate as the backup service into customer Microsoft 365 tenants and obtain Microsoft Graph tokens, an abuse of permissions customers had already granted the app. Huntress confirmed unauthorised sign-ins in 162 tenants, with the credential used from 144.172.64[.]128 between 06:13 and 08:34 UTC, and in one tenant a second ConnectWise application escalated itself to Global Administrator and added new client secrets to two other applications valid until 2028. ConnectWise has suspended Cloud Backup, SaaS Security and Cloud Management, revoked the affected certificates and stated it has no visibility into partner or customer environments, so it cannot say whether any given tenant was breached. No CVE is associated with this item and no CISA KEV entry applies; the exposure is identity-based and reaches every tenant where the app was consented, including EMEA financial services firms whose MSPs resell or operate ConnectWise tooling. The material risk is not the initial access but the persistence the actor can leave behind: disabling the ConnectWise apps does not remove credentials already added to other applications.

2. Regulatory framing

3. Technical analysis & attack chain

ConnectWise Cloud Backup is a backup and recovery service for Microsoft 365 and Google Workspace data, sold mainly to managed service providers. To copy mailboxes, OneDrive and SharePoint files, Teams chats and directory data, an administrator at each client consents the app through Microsoft Entra ID. The app then exists in the tenant as an application identity (service principal) and reads and writes data without a person signing in. The credential that authenticates it is a client assertion held in ConnectWise's own tenant, so nothing a customer did in their environment could have produced the sign-ins Huntress observed.

Confirmed sequence, from Microsoft sign-in logs and Huntress telemetry:

1. 2026-10-13 to 10-14: password spraying against four law firm tenants from 144.172.64[.]128, with scripted OAuth2 token requests carrying 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 address.
2. 2026-10-15, from 01:58 UTC: in roughly 50 tenants monitored by Huntress, service principals for ConnectWise Cloud Management apps (Exchange Online, Microsoft Teams, Microsoft Graph) assigned themselves directory roles, mostly Exchange Administrator. The User-Agent on these events was kiota-dotnet, the one ConnectWise's own apps use, which points to vendor automation; ConnectWise has not confirmed this.
3. 2026-10-15, 03:44 to 03:49 UTC, one 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 added new client secrets to two other applications in the tenant, an MSP management application and Huntress Security Platform. A follow-up attempt to add a certificate failed. The new secrets were set to expire in 2028.
4. 2026-10-15, 06:13 to 08:34 UTC: the Cloud Backup application authenticated from 144.172.64[.]128 and received Microsoft Graph access tokens in customer tenants. Legitimate traffic for the app comes from Azure private IP space. The sign-ins moved through tenants in sorted GUID order a few seconds apart, which indicates a script working from a target list. Huntress confirmed unauthorised sign-ins in 162 tenants by 19:00 UTC on 10-16.
5. A second wave targeted organisations in the policy, national security, trade and critical mineral sectors. Most of those tenants do not use ConnectWise products and the attempts failed because the relevant service principal was not present.

The permissions involved are broad by design. Microsoft stated the actor likely abused permissions customers had previously granted, including Directory.ReadWrite.All. Huntress reported nearly 1,000 Microsoft 365 accounts with sign-in attempts from the actor address, more than 300 of them successful, which is wider than the 162 confirmed breaches; that figure is single-sourced to Huntress and should be treated as an upper bound pending corroboration. The actor's tooling is the app's own authentication path: it authenticates as the backup service and inherits the app's existing permissions rather than exploiting a software flaw.

Persistence is the part that survives vendor remediation. An application that can assign directory roles can make itself Global Administrator, and an administrator can add credentials to other applications, create new applications and grant them permissions, reset passwords and authentication methods, and change Conditional Access policies. Each step gives the actor a route back that does not depend on the original vendor credential. Huntress's warning is explicit: disabling the M365 apps, including the abused ConnectWise apps, will not remove credentials already added, and credentials on all M365 applications must be reviewed. The 2028 expiry on the secrets added in the one observed tenant is the concrete illustration.

ConnectWise's response: it identified unauthorised access to application identities in the Cloud Backup environment on 10-15 and published an advisory on 10-16. It suspended Cloud Backup, SaaS Security and Cloud Management, disabled seven ConnectWise application identities (including ConnectWise Cloud Backup, 506e08f9-6e9a-4da4-942b-a099a03644ae), revoked certificates used for affected application connections across all users so that shared Cloud Backup credentials are no longer valid, and disabled integrations between Cloud Backup and Exchange, Teams, SharePoint Online and its own products. It states existing archives remain encrypted, isolated and preserved with no evidence of unauthorised access, and that it has seen no successful threat activity since these actions. It has given no restoration timeline and says it cannot discuss attribution.

Attribution is unconfirmed. No actor is named in any source and ConnectWise has declined to discuss it. The password spraying against law firms and the sector targeting in the second wave are consistent with espionage-motivated collection, but no source states a motive and this advisory does not assign one. The claim that the Cloud Management role assignments reflect vendor automation rather than the actor is Huntress's inference from the User-Agent and is not confirmed by ConnectWise.

4. Mitigation & containment

P1, within 24 hours:

• Enumerate every enterprise application in each managed tenant and list credentials and permissions for each. In Entra ID: Entra admin center > Applications > Enterprise applications, then App registrations > Certificates & secrets for owned apps. For each app, record client secrets and certificates with their expiry. Any secret or certificate you cannot account for is suspect, particularly one expiring in 2028.
• Remove unknown credentials from all applications, not only ConnectWise ones. Disabling the ConnectWise apps does not revoke secrets already added to other applications.
• Review directory role assignments, starting with Global Administrator and Exchange Administrator, and remove any held by service principals that should not have them. Check the audit log for role assignments made by ConnectWise application identities on 2026-10-15.
• Search sign-in logs for application sign-ins from 144.172.64[.]128 and for the User-Agents curl/7.88.1, kiota-dotnet and Python-urllib/3.12 on application authentication events in the 10-13 to 10-15 window.
• Review Conditional Access policy changes and any password or authentication-method resets made on 10-15.
• Treat backup data as intact per ConnectWise's statement but do not treat the tenant as clean on that basis. ConnectWise has said it cannot determine whether a given customer environment was breached; get a written scope statement from your MSP and from ConnectWise.

P2, within 72 hours:

• Reduce standing permissions on backup and SaaS-management applications to the minimum the service needs, and replace long-lived client secrets with short-lived certificates where the vendor supports it.
• Require workload identity sign-ins to originate from expected infrastructure. Where the vendor publishes its egress ranges, restrict the app with a Conditional Access workload identity policy or a named location so authentication from hosting-provider address space is blocked or alerted.
• Confirm with each MSP which ConnectWise products it uses on your behalf and whether your tenant had the Cloud Backup service principal consented. If it did, assume the credential was usable against your tenant until ConnectWise's revocation.
• Keep Cloud Backup, SaaS Security and Cloud Management disabled on your side until ConnectWise restores service and states what changed. Do not re-consent the applications before that statement.

P3, within 7 days:

• Add application-credential review to the periodic access review for every third-party app with directory read or write scope.
• Require contractual notification from MSPs and SaaS vendors of credential compromise within a defined window, and a scope statement naming affected tenants.
• Test detection for anomalous application authentication (new ASN or hosting-provider source, unusual User-Agent, rapid sequential tenant access) in the SIEM.

5. Indicators of compromise

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 the authentication and application-management behaviours. The YARA rule targets the Python script's User-Agent string and the ConnectWise application identifiers where they appear in tooling or logs captured to disk; it is a low-fidelity net and should be paired with the Sigma rule, which is the stronger detection here.

rule ConnectWise_CloudBackup_Abuse_Artifacts
{
    meta:
        author = "Adverse Trace"
        date = "2026-10-20"
        reference = "https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access"
        description = "Strings associated with abuse of ConnectWise Cloud Backup and Cloud Management application identities in M365"
    strings:
        $ua1 = "Python-urllib/3.12" ascii wide
        $ua2 = "curl/7.88.1" ascii wide
        $ua3 = "kiota-dotnet" ascii wide
        $app1 = "24205314-2b89-4e07-a2a4-579e898a5640" ascii wide nocase
        $app2 = "506e08f9-6e9a-4da4-942b-a099a03644ae" ascii wide nocase
        $ip = "144.172.64.128" ascii wide
    condition:
        uint32(0) != 0x464c457f and filesize < 10MB and 2 of them
}

title: Suspicious Application Identity Authentication and Credential Addition in Entra ID
id: 8f3c2a71-4d6e-4b19-9c2a-7e5f1b0d3a64
status: experimental
description: Detects application sign-ins from hosting-provider infrastructure and application-initiated credential or role changes consistent with abuse of a vendor application identity
references:

  - https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access
author: Adverse Trace
date: 2026/10/20
logsource:
  product: azure
  service: signinlogs
detection:
  selection_ip:
    IPAddress: '144.172.64.128'
  selection_ua:
    UserAgent|contains:

      - 'Python-urllib/3.12'
      - 'curl/7.88.1'
  selection_app:
    AppId:

      - '24205314-2b89-4e07-a2a4-579e898a5640'
      - '506e08f9-6e9a-4da4-942b-a099a03644ae'
  condition: selection_ip or selection_ua or selection_app
falsepositives:

  - Legitimate vendor automation using kiota-dotnet (excluded from this rule)
  - Administrative scripting from approved automation hosts
level: high
---
title: Application Added Credentials to Another Application in Entra ID
id: 1b7d9e42-6a3f-4c88-b0d5-2f9e4a7c6b13
status: experimental
description: Detects Add service principal credentials or Add app role assignment operations performed by an application identity, the persistence mechanism observed in the ConnectWise incident
references:

  - https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access
author: Adverse Trace
date: 2026/10/20
logsource:
  product: azure
  service: auditlogs
detection:
  selection_op:
    OperationName:

      - 'Add service principal credentials'
      - 'Update application - Certificates and secrets management'
      - 'Add member to role'
  selection_actor:
    InitiatedBy|contains: 'AppId'
  condition: selection_op and selection_actor
falsepositives:

  - Approved automation that rotates application secrets
level: medium

7. Sources

• Huntress, "ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks", https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access, 2026-10-16 (updated).
• Recorded Future News (The Record), "ConnectWise suspends Cloud Backup service after supply chain attack", https://therecord.media/connectwise-suspends-cloud-backup-service-supply-chain-attack, 2026-10-19.
• Help Net Security, "ConnectWise suspends Cloud Backup service after attackers abuse its Microsoft 365 access", https://www.helpnetsecurity.com/2026/10/19/connectwise-cloud-backup-suspended-security-incident/, 2026-10-19.
• The Register, "ConnectWise turns off its SaaS-y backup, security, and management services to probe security SNAFU", https://www.theregister.com/security/2026/10/19/connectwise-turns-off-its-saas-y-backup-security-and-management-services-to-probe-security-snafu/5303758, 2026-10-19.
• 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-19.
• 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, 2026-10-19.

8. Adverse Trace position

No CVE is associated with this item and no CISA KEV entry applies, so there is no patch to prioritise; the exposure is an application-identity credential held by a vendor and usable against every tenant that consented the app. The confirmed scope is 162 tenants, the wider attempted scope is nearly 1,000 accounts with more than 300 successful sign-ins, and the persistence mechanism (new secrets valid to 2028 on non-ConnectWise applications) means vendor revocation alone does not close the incident. The 162-tenant figure and the wider attempt count are single-sourced to Huntress; the IP address and the application IDs are corroborated by ConnectWise's own advisory and by multiple outlets. Attribution is unconfirmed and no actor is named. Adverse Trace assesses that EMEA financial services firms using ConnectWise directly, or through an MSP, should treat their tenant as potentially in scope until they have enumerated application credentials and role assignments themselves, and we will update this advisory when ConnectWise restores service or publishes a scope statement.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.