When a Trusted Cloud Application Becomes an Attack Path

Conceptual illustration supplied by the owner. It does not show how many customer tenants were affected, and no tenant count is implied.

An October 2026 incident involving ConnectWise Cloud Backup exposed a security risk that extends beyond employee accounts. Attackers used credentials associated with trusted applications to authenticate across Microsoft 365 customer environments, showing why third-party application identities are part of an organization’s security boundary.

The application was trusted. Its credential was not.

Organizations regularly authorize third-party applications to access their Microsoft 365 environments. A cloud backup service, for example, needs permission to retrieve information from Exchange Online, SharePoint, OneDrive and other services. It uses that access to create backups and support restoration.

The backup service must work even when no employee is signed in. An organization therefore authorizes the application’s identity rather than requiring a person to approve every scheduled operation.

In October 2026, this arrangement became central to a security incident involving ConnectWise Cloud Backup, formerly SkyKick. ConnectWise confirmed unauthorized access involving application identities associated with its cloud backup environment. Independent security investigators observed attackers authenticating through those identities against Microsoft 365 customer tenants.

On October 15, Sophos X-Ops identified automated authentication requests in which the ConnectWise Cloud Backup application identity was used to obtain Microsoft Graph access tokens. Huntress independently reported unauthorized sign-ins in 162 customer tenants as of 19:00 UTC on October 16.

These findings establish that trusted application identities were being used without authorization. They do not establish that all 162 tenants experienced data theft, administrative compromise or persistent attacker access.

Investigators also observed more serious application-permission and credential changes in at least one tenant. Those findings require separate examination because the available evidence does not establish that all related activity was conducted by the same attacker. Sources: ConnectWise Trust Center, Sophos X-Ops investigation, and Huntress investigation.

How a backup application accesses Microsoft 365

Understanding this incident requires separating an employee’s identity from an application’s identity. When an employee accesses Outlook, Microsoft Entra ID authenticates that person according to the organization’s sign-in requirements. These may include multifactor authentication, device checks and Conditional Access policies.

An automated backup service operates differently. It needs to access information without an employee being present. Microsoft Entra supports this through application identities, which allow software to authenticate and request access to services.

For a third-party application used by many organizations, Microsoft Entra distinguishes two related objects. The application registration represents the software application. The publisher maintains it in its own tenant, including the credentials used to authenticate the application.

A service principal represents that application’s presence within a particular customer tenant. It provides the local identity through which permissions and access can be assigned. A multitenant application can therefore have one publisher-controlled application registration and separate service principals in many customer organizations.

This is a normal design used by software-as-a-service platforms. Each customer decides whether to authorize the application and what permissions to grant. The vendor ordinarily controls the credential used by its application to prove its identity.

Microsoft documents this relationship in its guidance on application objects and service principals.

How an application sign-in works

Consider a backup service retrieving information from a customer tenant. The application authenticates to Microsoft Entra using a supported credential, such as a client secret or certificate, and requests an access token for a particular resource.

Microsoft Entra verifies the application identity, evaluates the applicable authorization and policy requirements, and determines whether the request can be approved. If those checks succeed, Entra issues an access token for the requested resource, reflecting the application’s authorized permissions. The application presents that token to Microsoft Graph, which evaluates whether the requested operation is permitted.

Two different security decisions are involved. Authentication establishes which identity is making the request. Authorization determines what that identity is allowed to access or change.

A valid application credential does not provide unrestricted access to every Microsoft 365 tenant or service. Access depends on the application’s presence in the target tenant, its granted permissions and any applicable restrictions.

Microsoft Entra supports two important permission models. With delegated permissions, an application acts in the context of a signed-in user. With application permissions, software can act without a signed-in user, subject to its authorized permissions.

The ConnectWise token activity involved application-only authentication through the OAuth 2.0 client-credentials model. This explains why the attacker did not need to obtain an individual employee’s password or complete that employee’s ordinary interactive MFA challenge.

It does not mean MFA malfunctioned. Nor does it mean application identities have no security controls. It means the attacker was attempting to authenticate as a workload identity rather than as a human user.

The security boundary failed when the attacker obtained a credential capable of proving the identity of an application that customers had already authorized.

How one credential could reach multiple organizations

ConnectWise Cloud Backup was designed to operate across multiple Microsoft 365 tenants. Each customer maintained its own environment and granted the application access through its own authorization process. However, the vendor-controlled application credential could be used to authenticate the same application identity across consenting customer tenants.

An attacker possessing that credential could therefore attempt authentication against more than one organization without separately compromising each organization’s employee accounts. Sophos observed this mechanism during an automated token sweep on October 15.

Requests originated from a virtual private server at 144.172.64[.]128 and targeted customer tenants in a systematic order. Sophos observed the activity for approximately 96 minutes and reported that it could not determine what the attacker ultimately did with the issued tokens. Huntress independently observed unauthorized authentication involving the same source infrastructure, although its investigation covered a different set of tenants and observations.

The technical significance is that the attacker was using an authorization relationship that already existed between each customer and the vendor’s application. The customer tenants were not merged into one security environment. Each retained its own permissions and controls. But the same compromised vendor credential could be presented wherever that application was authorized.

For a backup service, the granted permissions may include access to mailboxes, files, directory information and operations required for restoration. An attacker obtaining an access token could potentially exercise the permissions represented by that token.

However, the evidence must be interpreted carefully. An authentication request is not the same as a successful sign-in. A successful sign-in is not necessarily proof that a requested Microsoft Graph operation succeeded. And a valid token does not establish that customer information was downloaded or modified.

Those are different findings requiring different evidence. Sources: Sophos X-Ops technical analysis and Huntress incident investigation.

The investigation also identified a route to persistent access

The unauthorized token requests were not the only concerning findings. Huntress documented a separate sequence of application-identity changes in one customer tenant on October 15.

Between approximately 03:44 and 03:49 UTC, a related application named ConnectWise Cloud Management – MS Teams assigned itself the Global Administrator directory role. During the same period, it modified two other application identities, adding new client secrets.

One of those identities belonged to an MSP management application. The other belonged to the Huntress Security Platform application within that tenant. Huntress subsequently identified successful authentication using an unauthorized credential associated with its application.

These observations demonstrate why application-credential changes matter during a cloud identity investigation.

How a second credential creates a separate access path

A client secret allows an application to authenticate as its registered identity. If an attacker has sufficient authorization to add a new secret to another application, the attacker may be able to authenticate using that application’s identity and its existing permissions. That creates an access path separate from the original compromised credential.

For example, disabling the ConnectWise Cloud Backup identity would not automatically remove an unauthorized secret added to an unrelated management application. The second application must be investigated and its unauthorized credentials removed or invalidated through the appropriate response process.

However, possessing an application’s credential does not automatically provide the authority to modify another application or assign a privileged role. Those actions require separate permissions or privileges. This distinction is particularly important because the incident involved several ConnectWise application identities with different authorization relationships.

What investigators could and could not establish

The timing of the observed activity matters. Huntress recorded the Global Administrator assignments and additional credential creation before the later authentication activity from the identified public IP address.

The earlier events involved traffic recorded from Microsoft-hosted private address space. Huntress could not establish that the earlier activity and the later public-IP token sweep were performed by the same operator. It also observed other application role-assignment activity resembling legitimate ConnectWise automation, which required further investigation rather than automatic attribution to the attacker.

On October 21, ConnectWise said that, based on the evidence available to it, including threat intelligence shared by Microsoft, it appears that a China state-aligned group was responsible for the attack on ConnectWise Cloud Backup, and that the group used an openly available agentic AI framework. That is the vendor’s assessment. Sophos named no actor, and Huntress had not tied the earlier and later phases of activity to the same operator. Source: ConnectWise Trust Center.

The evidence therefore supports a precise conclusion:

Unauthorized application authentication occurred across multiple customer tenants, and a separate, concerning credential-persistence sequence was documented in at least one tenant. The complete relationship between those activities was not established.

It would be inaccurate to describe them as one conclusively reconstructed attack sequence affecting every customer. Source: Huntress, ConnectWise/SkyKick vendor credential investigation.

Why vendor containment did not complete customer remediation

ConnectWise responded by disabling affected application identities, revoking credentials and suspending related cloud services while investigating. According to its October 18 guidance, the company disabled seven ConnectWise application identities at 07:00 UTC on October 17.

That action prevented new authentication through the affected connections. It did not automatically reverse changes previously made inside customer Microsoft 365 tenants. Previously issued tokens could remain valid until expiry or effective invalidation. More importantly, additional credentials, permissions or privileged assignments established on separate identities required their own investigation.

There is also a distinction between a vendor disabling an application connection and a customer verifying the state of the corresponding enterprise application in its own tenant. The two are separate administrative controls.

This means incident response has two connected parts. ConnectWise must secure its own application credentials, investigate its services and confirm when affected connections can safely be restored. Customer administrators and managed service providers must establish whether unauthorized activity occurred within the tenants they are responsible for.

What administrators should investigate

The investigation should focus on evidence relevant to the affected application identities rather than indiscriminately changing unrelated credentials.

Service-principal sign-in records can show authentication involving workload identities. These events are distinct from ordinary employee sign-in activity and may not be visible in the reports administrators routinely review.

Microsoft Entra audit logs can identify changes to application credentials, permissions, service principals and directory-role assignments. Investigators should examine which identity initiated a change, which identity was modified and whether an unexpected credential was later used.

ConnectWise recommends reviewing relevant activity beginning October 13, 2026, and expanding the investigation where the available evidence indicates a need. Sophos and Huntress also provide incident-specific indicators, including source addresses, application identities and observed client software.

Those indicators should be interpreted in context. A suspicious IP address can support an investigation, but the absence of that address does not prove a tenant was unaffected. Similarly, Microsoft-hosted private network addresses can appear in legitimate activity and do not identify an attacker by themselves.

Another important limitation concerns visibility. Microsoft Entra sign-in records can establish that an application authenticated. Audit logs may show identity and permission changes. They do not necessarily record every piece of information that an application subsequently read through Microsoft Graph.

Where additional Graph activity logs are available, they may help investigators establish the downstream operations performed. Their availability and coverage depend on the tenant’s configuration, licensing and logging arrangements. Consequently, the absence of an observed data-access event cannot always establish that no access occurred.

Administrators should preserve relevant evidence, verify application state and follow the current vendor guidance when disabling or reconnecting affected applications. Immediately deleting the application objects may remove useful investigative context. The incident-response guidance recommends disabling affected connections while preserving what is needed to understand their activity.

Changing employee passwords or revoking user sessions alone would not resolve unauthorized credentials associated with application identities. Sources: ConnectWise Trust Center and remediation guidance, Sophos X-Ops investigation, and Huntress technical findings.

The effect on customer backups

The security investigation also caused an operational disruption. ConnectWise suspended Cloud Backup and related services while securing its environment and validating affected application connections. Scheduled backup operations, archive access and restoration capabilities were interrupted during the suspension.

ConnectWise reported that existing Cloud Backup archives remained encrypted and isolated, with no indication at the time that those archives had been compromised. That finding concerns the provider’s stored backups. It does not establish that every customer’s live Microsoft 365 environment was unaffected by unauthorized application authentication.

An attacker could potentially use a backup application’s granted Microsoft Graph permissions to access information in a live tenant without compromising the separate archive where previously backed-up data is stored. The two concerns must therefore remain distinct: security of existing backup archives and unauthorized access to live customer environments.

ConnectWise began phased service restoration on October 21, but this did not constitute confirmation that all services had recovered or that all affected customer tenants had completed investigation. Administrators were instructed to keep affected application connections disabled until formal restoration and reconnection guidance was issued. Source: ConnectWise Trust Center.

What this incident demonstrates

The ConnectWise incident does not establish that third-party Microsoft 365 applications are inherently unsafe. Cloud backup and management platforms need access to customer environments to provide their services. Multitenant application identities and application-only authentication are normal parts of that architecture.

The risk emerges when an attacker obtains the credential used to prove the identity of an application that customers have already authorized.

In this case, investigators confirmed unauthorized application authentication across multiple customer tenants. Huntress also documented privileged application changes and unauthorized credentials in a specific tenant, while explicitly acknowledging limits in attributing the different phases of activity.

Those findings explain why replacing the original vendor credential was necessary but insufficient to establish that every customer environment was secure. Organizations also needed to determine whether access had been extended through separate identities, permissions or credentials.

The security boundary of a Microsoft 365 organization includes the third-party applications it authorizes, not only the people who sign in to its systems.

Protecting user accounts remains essential. Understanding and monitoring application identities is a separate responsibility, particularly when a single vendor-controlled credential can be trusted across many customer tenants.

Go deeper

Research reviewed October 21, 2026. Incident investigations may produce additional findings. Tenant counts reflect dated observations, not the final number of organizations confirmed to have suffered data theft or persistent compromise.

Vendor advisories and guidance

• ConnectWise Trust Center, Cloud Backup incident advisories, official incident statements, containment actions, affected services and restoration instructions.
• ConnectWise Cloud Backup Technical Investigation and Remediation Guide, October 2026, application identifiers, investigation scope, evidence preservation and customer remediation guidance.

Independent investigations

• Sophos X-Ops, ConnectWise Cloud Backup application abused in cross-tenant token sweep, independent analysis of automated application authentication and Microsoft Graph token requests.
• Huntress, ConnectWise/SkyKick vendor credentials abused in Microsoft 365 attacks, unauthorized authentication observations, privileged application changes, credential persistence and attribution limitations.
• Kudelski Security, ConnectWise Cloud Backup vendor credential abuse, independent incident analysis and technical context.

Microsoft documentation

• Microsoft, Application objects and service principals, explains application registrations, customer-tenant service principals and multitenant authorization.
• Microsoft, Service-principal sign-ins, explains workload-identity authentication records.
• Microsoft, Application authorization and resource access, explains application access decisions and authorization boundaries.

Organizations investigating potential exposure should follow current ConnectWise and Microsoft security guidance appropriate to their environments.

Related reading on TechiesJournal

• The MCP Credential Boundary: Why an MCP Server Should Not Decide Where Your OAuth Credentials Go for another look at where application credentials should and should not be trusted.
• CI/CD Supply Chain Attacks: How Attackers Reach Your Pipeline for another way a trusted connection can become an entry point.