ConnectWise Microsoft 365 Incident Puts App Credentials and Tenant Audits in Focus

The ConnectWise incident shows how a vendor credential can cross tenant boundaries without a customer user logging in. A credential tied to the company’s Cloud Backup platform was used to obtain Microsoft Graph access tokens in customer Microsoft 365 environments. Huntress had identified suspicious sign-ins across 162 organizations by 19:00 UTC on October 16.

That distinction matters because organizations often investigate a breach by looking first for a compromised employee account. Here, the authentication path ran through a vendor application, so an ordinary user sign-in might not appear as the starting point. If you’re working in this space, the incident is a reminder to include application identities in the same review as user accounts.

Huntress traced authentication activity to October 15, between 06:13 and 08:34 UTC. The Cloud Backup application connected from 144.172.64[.]128, a hosting provider address outside the Azure private IP space where it normally communicated. Microsoft’s sign-in logs recorded the events, giving investigators a source for tracing when and where the application authenticated.

An unexpected source address can be a useful warning, but it doesn’t explain by itself what happened after authentication. Investigators still need to establish which permissions the application had, which operations those permissions allowed, and whether those operations left records. That’s a wider problem with cloud incidents: access can be clear while the full scope of activity remains harder to reconstruct.

Vendor applications had broad tenant access

Cloud Backup needs extensive permissions to back up and restore data across Exchange Online, OneDrive, SharePoint and Teams. Huntress said the exposed credential let the application request Graph tokens in customer tenants without an individual user signing in. Because the credential was held in ConnectWise’s environment, customers couldn’t have created it through activity in their own tenants.

That arrangement reflects a basic trade-off in hosted services: a vendor application may need broad access to perform work across a customer’s systems, while the customer has limited visibility into the vendor’s credential handling. The same permissions that make automated backup practical can also make a compromised application identity consequential. This is more significant than it looks.

That application authentication also bypasses the usual user password and multi-factor authentication (MFA) prompt. MFA remains important for user accounts, but it doesn’t turn an application credential into a user login or necessarily stop misuse of that credential. For administrators, the key investigative question is therefore which application identities authenticated and what they changed, rather than which user account logged in.

Huntress found a separate sequence involving ConnectWise’s Cloud Management for Microsoft Teams application in one partner tenant. The application assigned itself the Global Administrator role, then added credentials to two other applications, one of which was specific to that Huntress partner. The sequence took about five minutes. Huntress hasn’t established whether one operator carried out every step.

That sequence raises a different investigative concern from the initial token access: an application identity may be able to change roles or credentials, potentially creating additional paths into a tenant. The available account doesn’t establish the full purpose or scope of those actions, and it’d be a mistake to infer more than the evidence supports. But the speed of the sequence shows why reviewing only the original sign-in can leave important activity unexamined.

Containment has a service cost

ConnectWise acknowledged the activity and, on October 17, disabled seven application identities, revoked certificates tied to affected connections, and suspended Cloud Backup, SaaS Security and Cloud Management. These steps block new authentication through the disabled connections, but they don’t undo changes already made in customer tenants. Previously issued tokens may also remain valid until they expire or are otherwise invalidated.

Containment is therefore only one part of the response. Administrators still need to check for changes made before the applications were disabled, and determine whether any access established during that period persists through other credentials or settings. The incident account doesn’t say that such persistence was found across customer environments; it identifies it as a reason to inspect tenant configuration.

The suspensions affect day-to-day operations: scheduled backups, access to affected archives and restoration are unavailable, as are SaaS Security monitoring and alerts and Cloud Management’s user and license functions. Those interruptions create a practical dilemma for customers: the services are intended to protect or manage Microsoft 365 environments, yet their suspension removes capabilities organizations may rely on during an incident.

ConnectWise said it had no indication that existing backup archives had been compromised and that they remain encrypted and isolated. That statement addresses the status of the archives, but it doesn’t answer every question about activity inside customer tenants. Its October 19 advisory added two addresses, 144.172.64[.]99 and 144.172.64[.]60, identified through downstream monitoring. (And this is the part most people overlook: indicators can expand as monitoring continues, so an initial list may not capture every address later associated with an investigation.)

ConnectWise reported no successful threat activity in monitored environments after containment, but had not set a date to restore the services. Microsoft did not immediately respond to a request for comment.

Audit records have limits

Huntress said it had not confirmed data theft. In the one tenant it examined in detail, the firm found no logged access to mail or files, while cautioning that the absence of those records doesn’t prove data wasn’t taken. Some Microsoft Graph directory reads don’t generate an audit trail, leaving investigators with gaps in the available evidence.

That limitation affects how confidently an organization can describe the scope of an incident. A clean audit record may mean an action didn’t occur, or it may mean the action wasn’t recorded in a way investigators can use. Here’s the thing: a lack of evidence in one logging source isn’t the same as evidence that no access happened.

ConnectWise and Huntress urged partners and administrators to inspect application sign-ins, credentials, directory roles, consent grants and policy changes, as well as mailbox forwarding and other ways an intruder could maintain access. Taken together, those checks cover both the application’s authentication and changes that could preserve access after the original credential is disabled. Administrators will need to compare what they find with known service configuration, since legitimate automation can also create activity in these areas.

ConnectWise advised partners to leave the affected applications disabled until formal restoration instructions arrive. The investigation and service recovery were still underway as of October 19.

What the incident means for customers

For customers, the central issue is the dependency that comes with delegated access: the vendor controls credentials that can operate inside customer tenants, while each tenant still has to assess what those credentials did. That doesn’t make vendor applications inherently unsafe, but it does mean incident plans need to account for service identities and the provider’s response process. A user-focused review alone can miss the path that matters.

The next useful signal will be clear restoration guidance and evidence customers can use to verify their own environments. Until then, the advice to keep affected applications disabled leaves organizations balancing service disruption against uncertainty about access. And yet, the available facts call for measured conclusions: Huntress hadn’t confirmed data theft, ConnectWise reported no successful threat activity in monitored environments after containment, and important audit gaps remained.