The Backup Tool Became the Backdoor: Inside the ConnectWise Application Identity Compromise

The October 2026 ConnectWise incident shows a fundamental flaw in the way the managed service provider ecosystem assigns trust to vendor applications. It wasn't due to a software vulnerability, no CVE was issued, no phishing email was sent and no user password was broken. Rather, an unknown threat actor acquired the credentials of a legitimate backup application for which broad consent had been given and then used them to log directly into Microsoft 365 tenants worldwide, taking on all the permissions that the application had been granted. This was a supply chain attack carried out via application identities, and its consequences go well beyond the Microsoft 365 tenants that appeared in the sign-in logs.

The Credential That Did Not Need a User

ConnectWise Cloud Backup, which was previously called SkyKick Cloud Backup, is a service designed for managed service providers so that they can safeguard their clients' Microsoft 365 data. In order to carry out this function, the application is given extensive permissions when it is admitted to the customers' tenancies covering Exchange Online mailboxes, files in OneDrive and SharePoint, conversations in Microsoft Teams, and directory data. This level of permission is not excessive; it is in fact the smallest amount necessary to read, back up, and restore the full range of data which an MSP is responsible for.

The application logs into Microsoft Entra ID as a service principal by means of a client assertion or secret that is kept by ConnectWise. If a threat actor acquires that secret, there is no need for them to gain access to any individual user account; instead, they can directly request Microsoft Graph tokens, which Entra ID will then issue in accordance with the permissions that the customer has already given to the application. The authentication process is recorded in the Service principal sign-ins log, not in the User sign-ins log, and since no human is involved, a multi-factor authentication prompt is not displayed.

The Todyl researchers gave a precise account of how the attack worked: the attacker logged in directly to Microsoft 365 as the backup application by means of its secret and thus obtained the permissions which the customers had already granted to it. The sign-in requests were automated and, since they did not require a user to log in, measures such as multi-factor authentication became irrelevant. The application had already been given wide-ranging permissions in each tenant that had been granted previously, and as a result of these sign-ins the attacker acquired the technical capability to read and write mail and attachments, as well as files in OneDrive and SharePoint and chats in Teams.

The Attack Sequence

The instance of credential abuse noticed by Huntress and Microsoft started on October 15, 2026 and came from one IP address, namely 144.172.64.128, which is located at a hosting provider within the RouterHosting autonomous system. Huntress recorded the Cloud Backup sign-in period as running from 06:13 to 08:34 UTC on October 15, whereas Todyl's analysis of the tenants it itself was monitoring shows the sign-ins occurring between 07:11 and 08:47 UTC on that same day. The requests were processed in sorted GUID order, with only a few seconds between each one, a sequence which strongly suggests that a script was being used from a predefined list rather than involving manual interaction.

It should be pointed out that the same IP address was seen carrying out password spraying against the tenants of a law firm on October 13 and 14, even though there were no instances of successful user sign-ins in that telemetry data. It has not yet been determined whether that earlier activity was carried out by the same operator as the application credential abuse.

Huntress first stated that there had been unauthorized sign-ins involving 162 tenants and then brought the number up to 173. At the same time, Huntress found almost 1,000 Entra tenants who had sign-in activity from the attacker's address, including more than 300 successful sign-ins. Since the credentials work for every tenant where the application has been given consent, the attacker was not restricted to just the tenants that Huntress was able to observe.

The Cloud Backup credential was not the only application identity involved. Starting at 01:58 UTC on October 15, Huntress noticed service principals associated with ConnectWise Cloud Management applications assigning themselves directory roles, mainly Exchange Administrator, across about 50 tenants that it was keeping an eye on. The User-Agent for these events was kiota-dotnet, which is the one that ConnectWise's own applications use, a fact that at first appeared to indicate automated activity by the vendor. However, the connection between this earlier activity and the later Cloud Backup logins has not yet been firmly established, and Huntress has been careful to point out that the two phases have not been linked to the same operator.

In the case of one tenant the behaviour progressed to a persistent one. Over a period of about five minutes the ConnectWise Cloud Management application for Microsoft Teams, with application ID 24205314–2b89–4e07-a2a4–579e898a5640, acquired the Global Administrator role. It then executed a Python script using a User-Agent of Python-urllib/3.12 which altered two other applications within the tenant: an MSP management application and Huntress's own Security Platform application. New client secrets were added to both of these applications with their expiry dates set for 2028. A subsequent attempt to add a certificate credential, however, failed due to a thumbprint mismatch.

What makes this situation differ from a simple credential leak is that it constitutes a persistence operation. There are two methods by which an application can prove its identity to Entra ID: by using a client secret or by using a certificate, and in either case the person who has it gets the same level of access — that is, the ability to sign in as that application from anywhere using the permissions already granted to it. It is well known that adding credentials to an already existing application is a form of persistence and this is listed as MITRE ATT&CK T1098.001. The two applications which were given new secrets were trusted and privileged tools. When a credential is added to the MSP management application it can grant access beyond just one tenant since those applications are usually given consent in the tenants of MSP's customers. The credentials on a security tool's application give the holder all the rights that that tool has.

Why Customer-Side Controls Did Not Apply

The kind of defences that most organisations use to guard Microsoft 365 are based on user identities. Since multi-factor authentication, conditional access policies, session controls and password resets all work on the basis that an authentication process involves a human or a device which has to go through policy checks, application-only authentication avoids all of these.

Conditional Access for workload identities is available, but its scope is limited. According to Microsoft's documentation, it only applies to single-tenant service principals that are registered in the customer's own tenant; Microsoft and third-party SaaS applications, including multitenant applications such as ConnectWise Cloud Backup, are not included. The ConnectWise application is owned by the vendor and is multitenant, and therefore customer-side Conditional Access cannot be used to restrict it.

The second gap is visibility, since sign-ins by service principals appear in a separate log category to those of interactive user sign-ins. Those organizations which do not regularly check the Service principal sign-ins tab in Entra ID would have failed to notice this activity altogether. Huntress has also warned that directory reads carried out via Microsoft Graph might not be recorded in the audit logs, which means that the lack of an audit record does not prove that the data was not accessed. This results in an uneasy evidentiary vacuum: even in cases where exfiltration has not been confirmed, the absence of evidence is not evidence of absence.

What ConnectWise Disabled and What It Did Not Fix

On October 17, 2026, at 07:00 UTC, ConnectWise turned off seven application identities and suspended the Cloud Backup service by revoking the certificates that were used for the application connections of all users. The company said that the shared Cloud Backup credentials in question are no longer valid, although access tokens that had already been issued might still be usable until they expire or are otherwise cancelled. It was reported that the tokens issued to the application were valid for up to 90 minutes, which means that a single token can be used for reading mailboxes, files, or directories without further authentication during that time.

The advisory issued by ConnectWise itself admits that the most important point for defenders is that disabling the affected connections stops new authentication from taking place via those connections, but it does not undo the changes that had already been made within a tenant; any unauthorized credentials, permissions, or other access set up through separate identities will still need to be reviewed and remediated. The vendor is able to revoke its own credential, but it cannot revoke the client secrets which were added to other applications within customer tenants.

Huntress took the unauthorized credential out of its own application and turned on the App Instance Property Lock feature for all Huntress applications. However, in each tenant where the attacker had added a secret to an MSP management tool or to any other privileged application, that tenant must carry out its own audit. The fact that the original ConnectWise credential is no longer valid does not imply that the attacker has left.

The Structural Lesson

Most of the people affected are MSP partner tenants and the customers who come after them. A partner tenant of an MSP often has delegated administrative relationships with a number of customers, for example by having been given admin privileges or more specific delegated admin privileges. The extent of access within an MSP tenant goes beyond what the number of reported tenants would indicate. While this is an inference and not a finding that has been reported, it is in line with the way the MSP ecosystem is designed: management tools are constructed to allow access across tenants, and as a result their credentials are very valuable.

This situation is part of a pattern which has now become increasingly familiar within SaaS supply chains. The point of entry was not due to a fault in the victim's environment but rather to the use of durable third-party OAuth trust. The vendor had a credential with permanent, tenant-wide permissions and, when that credential was compromised, all tenants in which the application had obtained consent became accessible. Customer-side security measures were of no significance since the authentication took place through a trusted application and not via a user.

For those defending the system, the key operational points are clear. They should check the Service principal sign-ins log, not the User sign-ins log, by filtering it for the application IDs of ConnectWise and look out for IP addresses that lie outside the Microsoft and Azure address ranges; the application's usual egress is via Azure private IPv6. Instead of deleting the affected applications, they should disable them so that they can be re-enabled without going through a new consent procedure once ConnectWise has confirmed that the credentials have been rotated. Most important of all, each enterprise application in the tenant should be audited to see which ones have had credentials added after October 13, 2026. The attacker has shown that it is possible to add secrets to applications which administrators might not carefully examine. Although the original credential is no longer there, a secret with an expiry date in 2028 does not require the original credential in order to function.

It has not been made public how the ConnectWise credentials were first made available. What has been established is that an application which was meant to safeguard data ended up being the method by which that trust was misused. The backup tool served as the backdoor, and the one thing preventing the attacker from accessing the data was a permission grant which the customer had no reason to doubt.