ConnectWise Cloud Backup (SkyKick) breach: compromised app credential used against 300+ Microsoft 365 tenants

On 15 October 2026, between 06:13 and 08:34 UTC, someone using the identity of ConnectWise Cloud Backup (formerly SkyKick Backup) requested Microsoft Graph tokens for one customer after another from 144.172.64[.]128, a hosting provider address. According to Huntress, the requests moved from one tenant to the next a few seconds apart and in identifier order, the cadence of a script working down a target list.

Nobody typed a password or approved an MFA prompt. The application's credential was enough, because in each of those tenants the application already held consent to read mailboxes, OneDrive, SharePoint, Teams and the directory.

The figures have grown with each Huntress update. By 19:00 UTC on 16 October it had confirmed unauthorised sign-ins in 162 tenants. Its update on the afternoon of 17 October counted almost 1,000 tenants with sign-in activity from that IP, more than 300 of them with successful access.

ConnectWise suspended Cloud Backup on 17 October by revoking certificates and disabling seven application identities, and on 18 October it also took SaaS Security and Cloud Management offline. Its status page says backup archives are preserved, but they cannot be accessed or restored while the outage lasts, and there is no restoration time yet.

What is known about the attack on ConnectWise Cloud Backup (formerly SkyKick)?

ConnectWise confirmed to iTnews on 18 October 2026 that it had identified unauthorised access to application identities in its Cloud Backup environment and had cancelled the credential. It also acknowledged that it has no view into customer tenants, so it cannot say whether any given one was accessed. It has not explained how the credential was obtained.

The service, sold mainly through managed service providers (MSPs), sits in each customer tenant as a multi-tenant application holding application permissions. It acts with nobody signed in and reaches every mailbox, site and team in the environment. Huntress identified the credential as a client assertion, which means it lives in the vendor's tenant and not in each customer's.

Microsoft called the episode an active supply chain attack in a post on X reported by The Hacker News. Its threat intelligence team, quoted by BleepingComputer, believes the attacker abused permissions already granted, such as Directory.ReadWrite.All, to run Graph reconnaissance and attempt to add credentials. As of 19 October no group has been publicly named.

What other activity does Huntress link to the same IP?

Huntress links further activity between 13 and 15 October 2026 to the same IP or the same ConnectWise applications, while stressing that it has not been able to tie it to a single operator.

When did the password spraying against law firms begin?

On 13 and 14 October, someone using 144.172.64[.]128 tried a small number of passwords across many accounts at four law firms, a technique known as password spraying, with curl/7.88.1 as the client. Smart lockout in Entra ID locked out two accounts, and Huntress saw no successful user sign-ins from the address.

How many tenants did the backup application reach?

The backup application appeared on 15 October, and in its first pass Huntress found it authenticating from the hosting provider's IP in 17 of roughly 290 tenants checked, each belonging to a different partner. Later updates raised the count to the 300-plus tenants mentioned above.

In the one tenant Huntress examined in depth, the audit log shows no mail or file access. Huntress points out that directory reads through Graph leave no trace in that log, so the issuing of tokens is recorded but their use is not.

A second wave that day, using tokens from the same application, went after 16 tenants belonging to organisations in policy, national security, trade and critical minerals. It failed, because most of them did not run ConnectWise products and the service principal the attacker needed did not exist in their tenants.

How did a management application make itself Global Administrator?

According to Huntress, in one tenant the Cloud Management - MS Teams application, also from ConnectWise, added itself to the Global Administrator role at 03:44 UTC on 15 October. A script identifying as Python-urllib/3.12 then attempted nine changes to two other applications in that tenant, an MSP management tool and the Huntress platform. Six went through, among them new client secrets valid until 2028, roughly two and a half hours before the backup application's first sign-ins.

Those changes did not come from 144.172.64[.]128 but from private Azure IPv6 addresses, so a filter on that IP will not find them. The credential added to the Huntress application was used for seven sign-ins before the company removed it on 16 October and switched on App Instance Property Lock.

On 17 October Huntress added, with high confidence, that the attacker had also abused the Cloud Management applications for Exchange Online, Teams and SharePoint Online. From 01:58 UTC on 15 October it had also seen Cloud Management service principals assign themselves directory roles in about 50 tenants, mostly Exchange Administrator, with the kiota-dotnet user agent. Huntress thinks this may be vendor automation, though ConnectWise has not confirmed it.

A secret planted on another application survives rotation of the original credential. If that application is an MSP tool or a security product, it keeps permissions that may reach several customers, and the persistence comes from ordinary Entra ID features, with no malware involved.

Why did MFA and Conditional Access not stop the sign-ins?

Nicholas Koken, head of detection engineering at Todyl, told The Hacker News on 17 October 2026 that revoking user sessions does not end this access. The application signs in with a secret or certificate through the OAuth client credentials flow, and with no user involved there is no second factor to ask for.

Conditional Access has policies for workload identities, but Microsoft's documentation limits them to single-tenant service principals registered in the tenant applying them. Third-party SaaS applications, multi-tenant ones included, are not covered. The policies also need a Workload Identities Premium licence and offer only a block. For Cloud Backup, registered in ConnectWise's tenant, that control does not exist.

Detection does extend to multi-tenant applications. Microsoft Entra ID Protection scores risk for single-tenant, third-party SaaS and multi-tenant service principals, with detections for suspicious sign-ins (a change of IP, ASN, user agent or credential type) and leaked credentials. Without Premium they are still raised, with less detail. They are calculated offline, and the suspicious sign-ins detection needs between 2 and 60 days to learn a baseline, so it cannot serve as an immediate alarm.

Disabling the application stops new tokens being issued, but tokens already issued can stay valid for up to 90 minutes, as both SpecterOps and ConnectWise's statement point out.

Where does the trail show up in Entra ID and Microsoft Sentinel?

Huntress recommends starting with the service principal sign-ins tab in Entra ID, which is easy to miss because the portal opens on user sign-ins, and reviewing the window from 01:00 UTC on 15 October 2026 to 02:00 UTC on 16 October. The starting filter is the Cloud Backup application ID, 506e08f9-6e9a-4da4-942b-a099a03644ae, together with the attacker's address.

Where those logs flow into Microsoft Sentinel or another SIEM, these KQL queries make a starting point.

• Sign-ins by any of the seven ConnectWise applications, filtered by their owner tenant, or from the attacker's IP: AADServicePrincipalSignInLogs | where TimeGenerated > datetime(2026-10-13) | where AppOwnerTenantId == "3f9cd7a0-127a-4ed4-bf06-2f830d5616b7" or IPAddress == "144.172.64.128" | summarize SignIns = count(), Resources = make_set(ResourceDisplayName) by AppId, ServicePrincipalName, IPAddress, ResultType
• Role assignments, application updates and added credentials where the initiator is an application: AuditLogs | where TimeGenerated > datetime(2026-10-13) | where OperationName has_any ("Add member to role", "Add service principal", "Certificates and secrets management", "Update application") | where isnotempty(tostring(InitiatedBy.app.servicePrincipalId)) | project TimeGenerated, OperationName, InitiatingApp = tostring(InitiatedBy.app.displayName), TargetResources

Huntress advises reading actor, operation and user agent together, since any one of them alone is a weak signal. The second query filters on servicePrincipalId because the appId field is often empty in events initiated by an application.

Microsoft Graph activity logs, which capture the directory reads the audit log leaves out, are off by default. They are switched on through a diagnostic setting, need Entra ID P1 or P2 and land in the MicrosoftGraphActivityLogs table. Enabled today, they cannot reconstruct 15 October, but they will help in the next incident, so this is a good moment to decide which logs go to the SIEM and how long to keep them.

SpecterOps has also published BloodHound queries which, fed with AzureHound data, map what each of the vendor's service principals controls and the paths from them to Tier 0 assets in the tenant. The output gives a risk committee a direct answer to how far someone could go with control of the application.

The published indicators of compromise are the IP 144.172.64[.]128 (AS14956, RouterHosting), the seven ConnectWise application IDs listed by Huntress, and the user agents Python-urllib/3.12, python-requests/2.31, python-requests/2.34.2 and curl/7.88.1. User agents on their own are a weak signal.

Which steps contain the ConnectWise application in a Microsoft 365 tenant?

Since 16 October 2026 Huntress has recommended disabling the application even when the logs look clean, because a clean result does not rule out access.

• Disable the application without deleting it. In Enterprise applications, set "Enabled for users to sign-in?" to No. Deletion removes consent, which would then have to be granted again to bring the service back. Treat any Cloud Management application you cannot verify the same way, and keep them disabled until ConnectWise confirms every credential has been rotated.
• Remove any directory role held by a ConnectWise or SkyKick application that you did not grant on purpose, starting with Global Administrator and Privileged Authentication Administrator.
• Go through secrets and certificates on every app registration and enterprise application, starting with management and security tools. Delete anything added since 13 October that nobody can explain. Planted credentials stay live whether or not the ConnectWise application is disabled.
• Check whether any user-facing Conditional Access policy excludes these applications as target resources, for instance from a location-based block.
• Expect backups to stay paused while ConnectWise keeps the service offline, and restores to be unavailable too. The company has told iTnews that existing archives are not affected. Confirm retention with the vendor anyway, and decide what protects new data during the outage.

Should a role assignment or secret turn up that the team cannot explain, treat it as an incident response case. Expect to review every other application in the tenant and, where an MSP is involved, any other customers its tooling can reach.

Which governance measures reduce the risk from third-party applications?

The Salesforce data theft through connected apps had already shown that an integration holding application permissions is a highly privileged non-human identity whose credential another company looks after. Handling it with the care given to an administrator account shapes several decisions.

• Keep a register of consents that separates delegated from application permissions and records who granted each one, why, and whether it is still in use. SpecterOps advises removing SkyKick or Cloud Backup consents that are not in active use, and the second wave shows why, since where the application was absent there was no way in.
• Apply least privilege to vendors as well. A management tool may have no business assigning roles, and a permission such as Directory.ReadWrite.All without an operational reason should be challenged before consent is given.
• Use application management policies to restrict or forbid client secrets and cap how long they last, and keep the Application Administrator and Cloud Application Administrator roles in very few hands. Huntress names both controls as defences against long-lived secrets. A Microsoft 365 security review should cover third-party service principals explicitly.
• Ask vendors, as part of third-party risk management, how they protect their multi-tenant application credentials, whether they use App Instance Property Lock, how fast they can revoke credentials and how they will notify you. Entities within the scope of NIS2 must manage supply chain security under Article 21(2)(d), including relationships with direct suppliers, and a backup service that can read every mailbox falls within that obligation.
• Treat a provider that both keeps your backups and holds broad permissions in production as two risks in one place. We made the same argument when recommending keeping copies beyond the cloud provider's reach after the IDCF Cloud attack. Applications of this kind belong in Tier 0 of a privileged access tiering model, each named, with an owner, in your non-human identity security programme.

How far does customer control over a multi-tenant application go?

A Microsoft 365 backup service has to read every message and every file, and no customer setting can pare that back without breaking the service. Every vendor with a multi-tenant application holds a credential that works across all of its customers. ConnectWise's response (revoking credentials, suspending the service and updating partners) is what you would expect from a supplier.

What each organisation does decide is whether it knows the application is in the tenant, whether it sees when the application connects from somewhere odd, and whether it can cut it off in minutes. In many organisations with years of integrations behind them, third-party service principals have no internal owner and no alerting, and their logs never reach the SOC.

Until ConnectWise explains how the credential got out, there is no telling whether its replacement is better protected. For now, the application should stay disabled, and any secret added since 13 October should be treated as suspect until someone can justify it.

Sources and attribution: this analysis draws on public disclosures by ConnectWise, Huntress, SpecterOps and Microsoft, and on reporting by The Hacker News, iTnews and BleepingComputer, as available on 19 October 2026. The investigation is ongoing and the figures have already changed more than once. No part of this analysis implies a security flaw in Microsoft 365 or Entra ID, since the vector described is the misuse of a legitimate application's credential. A future attribution to a specific group could change how the case is read.

The KQL queries and containment steps are a starting point. Adapt them to the tables and identifiers in your environment, and test them before using them in production. Disabling a third-party application interrupts its service, so coordinate with the vendor and with the internal service owner.