ConnectWise Cloud Backup Breach: OAuth Abuse, Microsoft 365 Exposure, IoCs and Remediation Guide

The ConnectWise Cloud Backup incident shows how much trust organizations hand to the third-party applications connected to their Microsoft 365 tenants. An unauthorized actor used compromised application authentication material to get Microsoft Graph access tokens through a legitimate backup application’s identity. That identity carried permissions covering sensitive organizational data, and separate activity involving related ConnectWise Cloud Management applications raised concerns about privilege escalation and persistence.

Managed service providers (MSPs) are hit hardest, because they often authorize the same vendor application across many customer tenants. When a shared application identity is compromised, an attacker gets a path into multiple organizations without stealing any employee’s password or defeating MFA on individual accounts.

As of October 18, ConnectWise had disabled seven affected application identities, revoked certificates used for the affected Cloud Backup connections, and suspended the service while it investigates. The company says the existing backup archives remain encrypted, isolated, and preserved, and that it has no evidence the archives were accessed. That statement says nothing about live Microsoft 365 environments. Customers and their MSPs have to investigate activity in their own tenants.

What happened in the ConnectWise Cloud Backup incident?

ConnectWise Cloud Backup, formerly SkyKick Backup, is a cloud backup and recovery service that MSPs use to protect Microsoft 365 and other supported cloud workloads. To work, it needs permissions to discover and retrieve data, manage backup operations, and restore information.

On October 15, 2026, an unauthorized actor used a credential tied to the Cloud Backup application to authenticate to Microsoft Entra ID and obtain Microsoft Graph access tokens. Huntress reported successful unauthorized application sign-ins from 144.172.64[.]128, an address associated with hosting infrastructure. Todyl independently documented similar activity in the Microsoft 365 tenants it monitors.

The application’s client ID is 506e08f9-6e9a-4da4-942b-a099a03644ae. The requests stood out because they didn’t match the legitimate service’s expected authentication pattern: they came from an external IPv4 address and carried Python-based HTTP client user agents.

Huntress’s October 16 update reported 162 tenants with confirmed unauthorized sign-in activity. That is what it had observed at that point in the investigation, not a final count of exposed organizations.

Todyl described automated authentication across tenant identifiers in ascending GUID order, with requests a few seconds or minutes apart. That fits a process iterating over a list of tenants where the application was authorized. How the actor obtained that list is unknown.

The investigation also turned up something potentially more consequential. Huntress saw suspicious role assignments involving related ConnectWise Cloud Management applications: Exchange Administrator assignments and, in at least one tenant, Global Administrator. It also reported new client secrets added to two other trusted applications. Changes like these could leave access paths that survive the disabling of the original Cloud Backup application.

ConnectWise’s October 18 advisory said the investigation is ongoing, the affected shared Cloud Backup credentials are no longer valid, and a third-party forensic firm has been engaged. It also warned that disabling the vendor-side connections does not reverse changes already made inside customer tenants.

Technical breakdown: how the OAuth application compromise worked

The attack used permissions that customers had already granted to a legitimate application. No new malicious application needed approval in each tenant.

Microsoft Entra ID separates an application registration, its service principal within a tenant, and the credentials the application uses to authenticate. The registration defines the application’s identity and configuration. The service principal represents the application inside a particular tenant, where administrators grant permissions and authorize its use. A client secret, certificate, or other supported mechanism lets the application prove who it is.

When a customer authorizes a third-party application, Entra ID records the permission grants. Depending on the integration, these can include application permissions that let the software reach data without a user signed in.

In the OAuth 2.0 client credentials flow, the application authenticates with its own credentials and requests an access token for a resource such as Microsoft Graph. Certificate-based authentication can use a signed client assertion. Once the identity platform validates the request and the authorization behind it, it can issue an app-only access token. The attacker presents that token to the resource API, and if the token carries the needed permissions and the operation passes the resource’s authorization checks, the API can return data or perform the action.

In this incident the sequence looks like this:

1. An unauthorized actor obtained authentication material associated with the legitimate ConnectWise Cloud Backup application.
2. The actor authenticated to Microsoft Entra ID using the application identity.
3. Entra ID issued Microsoft Graph access tokens based on the application’s existing authorization.
4. The actor could use those tokens for API requests within the permissions the application held.
5. Separate activity involving related management applications raised concerns about role escalation and additional application credentials.

The cited incident updates don’t establish how the original credential was compromised. Pinning it on a repository leak, malware infection, developer workstation, or software vulnerability would go beyond the evidence.

Why multifactor authentication was not enough

Application-only authentication doesn’t follow the flow of an employee signing in with a password and completing an MFA challenge. The transaction may involve no human user at all. User-focused MFA and Conditional Access policies therefore don’t automatically cover every application sign-in. Microsoft supports Conditional Access for workload identities in specific scenarios, but with limits, especially for third-party multitenant applications. Nobody should assume an ordinary user MFA policy will block a compromised vendor-side application credential.

That is why service principal sign-in logs, application credential controls, permission reviews, and monitoring of directory changes matter. A tenant can have strong controls for human administrators and still have an application identity that can reach large amounts of sensitive data.

What data and privileges were at risk?

The impact depends on the permissions granted to the application and the resources reachable through the relevant APIs.

Todyl reported that the Cloud Backup application’s existing authorization included broad access to mail and attachments, OneDrive and SharePoint files, Teams conversations, and restoration operations. The incident analysis also identified permissions such as Mail.ReadWrite.All and Directory.ReadWrite.All.

Those permission names need careful reading. Mail.ReadWrite.All is an application permission that can allow reading and modifying mail across mailboxes through Microsoft Graph, subject to the relevant authorization model and restrictions. Directory.ReadWrite.All allows extensive directory reads and writes, but it doesn’t automatically authorize every administrative operation. File and Teams access likewise depends on the exact permissions granted and the APIs involved.

The exposure falls into four groups.

Mailboxes. With the right mail permissions, an application can read messages and attachments, which may expose financial records, confidential correspondence, authentication links, customer information, and internal discussions. Write permissions may also allow some mailbox modifications.

Files and collaboration data. Depending on the grants, OneDrive and SharePoint documents and Teams data may be reachable. These environments often hold contracts, source code, operational documentation, and customer records.

Directory and administrative changes. An identity with enough directory privileges may be able to modify application credentials, permissions, or role assignments. The role-assignment and credential-addition activity seen on related ConnectWise management applications makes this a central investigative question.

Backup and recovery. Suspending Cloud Backup stops continued use of the affected connections, but it also halts scheduled backup jobs and removes access to the affected archives and restoration functions for now. Recovery plans have to account for that gap.

Todyl reported no evidence of directory changes made through the Cloud Backup application in the nine tenants covered by its analysis. Huntress documented suspicious activity on related management applications. The two findings don’t conflict, because they involve different application identities and different behavior.

Indicators of compromise (IoCs)

The indicators below come from ConnectWise’s published advisory and the technical reporting by Huntress and Todyl. Use them to guide investigation and correlation. A match alone doesn’t prove a tenant was compromised.

Network and authentication indicators

The source IP is the clearest published network indicator. Search both successful and failed sign-in events, and don’t stop at this address. Attackers change infrastructure and can keep using an identity after the original indicator disappears.

The user-agent strings help identify scripted authentication, but Python clients are common in legitimate automation. Correlate any match with the application ID, source IP, time, authentication result, and what happened afterward.

The clientAssertion value tells you the sign-in was application authentication, not a conventional interactive employee sign-in. Conditional Access showing as not applied isn’t a policy bypass or evidence of malice by itself, since workload identity policy coverage differs from user policy coverage.

Behavioral indicators to hunt for: application sign-ins in rapid succession across tenants, authentication from hosting providers, unexpected Graph token requests, role assignments made by application identities, newly added client secrets or certificates, unauthorized consent grants, and changes to other trusted service principals.

Affected ConnectWise application IDs

ConnectWise’s October 18 advisory lists seven application identities that it disabled on the vendor side on October 17, 2026.

Older installations may show SkyKick names instead of ConnectWise names, so search by client ID and record each tenant’s local service principal object ID.

The vendor disabling these identities doesn’t mean the matching enterprise applications are disabled in every customer tenant. Administrators should check the local state and look into any suspicious changes made before containment.

ConnectWise also names its publisher tenant as 3f9cd7a0-127a-4ed4-bf06-2f830d5616b7 in its technical guidance. Authorized investigators can use it to locate related application registrations and service principals, but an application sharing that publisher isn’t necessarily involved in the incident.

Immediate containment: what Microsoft 365 administrators should do

The first priority is to stop further authentication through the affected connections while keeping the evidence needed to scope the intrusion. MSPs should run this review in their own Microsoft 365 tenant and in every managed customer tenant, including ones with dormant or older SkyKick integrations.

Verify and disable affected enterprise applications

Sign in to the Microsoft Entra admin center at https://entra.microsoft.com/ and select the correct tenant.

Go to Entra ID → Enterprise applications → All applications and search for each of the seven client IDs above. For each application, record the tenant ID, client ID, local object ID, display name, existing permissions, and current enabled state.

If an affected application is still enabled, open its Properties, set Enabled for users to sign-in? to No, save, and confirm the change took effect.

ConnectWise has disabled the affected identities on its side, but the vendor-side action and the enterprise-application setting in a customer tenant are separate controls, so verify locally.

Don’t delete the application as a first response. Disabling it while keeping its configuration supports forensic analysis and makes it easier to confirm the exact permissions and object identifiers involved. Keep affected applications disabled until ConnectWise issues confirmed restoration and reauthorization instructions.

This will interrupt the integration, so tell the people who depend on backup schedules and recovery operations. Operational disruption is still no reason to leave a known affected application enabled.

Preserve logs before retention expires

Export the relevant Microsoft Entra sign-in and audit records now. Retention depends on licensing and configuration: Microsoft documents default retention of seven days for Free and 30 days for P1/P2 for the relevant sign-in and audit logs. Records that have already expired can’t be recovered by upgrading a license.

Collect service principal sign-ins, interactive and non-interactive user sign-ins, managed identity sign-ins, directory audit events, and relevant Microsoft Purview audit records. Export the relevant SIEM data and any Microsoft Graph activity logs you were already collecting.

Record the time zone used for every search and keep the original timestamps. The timeline should run from at least October 13, 2026, and extend back to October 1 where records exist, or further if earlier suspicious activity turns up.

Preserve evidence before destructive changes where you can, but don’t hold up urgent containment waiting for a complete export. Log every containment action, including who performed it and the UTC time.

SInvestigate service principal sign-ins

In Entra ID, open Monitoring & health → Sign-in logs → Service principal sign-ins. This is where application-based authentication shows up, and the default user sign-in view leaves out most of the app-only activity.

Search for the Cloud Backup client ID and the six related application IDs. Filter for 144.172.64.128, inspect the reported Python user agents, and look at any unexpected source addresses.

For every relevant event, capture the application ID, service principal identity, tenant ID, source IP, timestamp, authentication result, resource, correlation ID, and any other authentication details. Compare the activity with how the legitimate integration normally behaves.

Keep the categories separate: attempted authentication, successful token acquisition, directory changes, resource access, and confirmed data transfer. A failed sign-in isn’t successful access, and a successful sign-in isn’t proof that data was copied.

Microsoft’s documentation: Service principal sign-ins.

Hunt for persistence and privilege escalation

Disabling the original application isn’t enough if an attacker has created another credential, elevated another service principal, or changed a different trusted application. This is the follow-up that matters most after initial containment.

Review directory audit events

Go to Entra ID → Monitoring & health → Audit logs and review events from October 13 onward, going further back where logs allow.

Look for application-management activity such as:

• Additions or updates to application credentials, including certificates and client secrets.
• New application registrations or service principals.
• Changes to application and service principal owners.
• New application permission grants and admin-consent events.
• Role assignments involving application identities.
• Changes to Conditional Access policies, named locations, and other security settings.
• Unexpected user creation, password resets, or authentication-method changes.

Audit activity names vary with the operation and the portal’s presentation. Search for the underlying operation and read the event’s initiator, target, result, timestamp, correlation ID, and modified properties instead of relying on one display label.

Look at both the applications that initiated a change and the applications that were changed. A malicious service principal could add a secret to a different, previously trusted application, and a review limited to changes on the original Cloud Backup identity would miss that second path.

Review application credentials

Inspect the affected enterprise applications and any other application modified during the suspicious period. For locally owned registrations, check App registrations → All applications → Certificates & secrets and examine the credential metadata.

Record credential identifiers, key IDs, certificate thumbprints, validity periods, and any federated credential configuration, then compare them against approved configuration records and the directory audit events.

An expiration date doesn’t tell you when a credential was created, and a valid certificate isn’t automatically legitimate. You are looking for credentials that appeared unexpectedly or were added by an unauthorized identity.

Vendor-owned application registrations may not appear in the customer’s App registrations list. You still need to review the local enterprise application and service principal, and an authorized responder may have to inspect credential metadata through Microsoft Graph.

Preserve the evidence, then coordinate removal of unauthorized credentials with the incident-response team. Microsoft Graph has separate operations for removing service principal password credentials, application password credentials, and other credential types, and the right one depends on which object owns the credential. Verify the object ID and credential key ID before changing anything.

Investigate privileged directory roles

Review Entra ID → Roles & administrators and the matching role-assignment audit events. Start with unexpected assignments of Global Administrator, Privileged Role Administrator, Privileged Authentication Administrator, Application Administrator, Cloud Application Administrator, Exchange Administrator, and SharePoint Administrator.

Application identities and human users don’t necessarily follow the same role-assignment workflows, so investigate the actual service principal and its audit records.

For each suspicious assignment, establish who initiated it, which role was assigned, when, and whether it is still active. Once the evidence is preserved, have an appropriately authorized administrator remove confirmed unauthorized assignments.

Also review newly created applications, modified owners, elevated API permissions, and unexpected admin-consent grants. If a new malicious application turns up, disable it, preserve its configuration, and decide whether to delete it as part of eradication.

An attacker who can add a client secret to a second application can authenticate through that identity even after the original vendor credential is revoked. An unauthorized role assignment likewise creates capabilities that didn’t exist when the incident began. So every application, role assignment, credential, and permission changed by the suspicious identities needs its own evaluation.

Check Exchange Online, SharePoint, OneDrive, and Teams

After the directory review, move on to the Microsoft 365 workloads the application was authorized to reach.

Exchange Online

Use Microsoft Purview Audit and the available Exchange administration tools to look for unexpected mailbox activity and configuration changes: suspicious inbox rules, external forwarding, mailbox delegation, Send As permissions, Full Access permissions, and mail-flow rule changes.

Relevant Exchange audit operations include New-InboxRule, Set-InboxRule, Set-Mailbox, Add-MailboxPermission, Add-RecipientPermission, New-TransportRule, and Set-TransportRule. Which events are available depends on the operation and your logging configuration.

Where authorized, inspect inbox rules, including hidden ones, with Exchange Online PowerShell:

Get-InboxRule -Mailbox user@contoso.com -IncludeHidden

Replace [email protected] with the mailbox under investigation. Check forwarding destinations, rules that delete or hide messages, and other modifications against approved administrative activity.

Also review unexpected mailbox permissions and transport rules. Not every unauthorized application-access incident produces inbox rules, so their absence doesn’t clear a tenant.

SharePoint and OneDrive

Review Microsoft Purview audit records and any Graph activity logs you collected earlier for unexpected file access, downloads, modifications, sharing changes, and deletions.

Correlate events with the application IDs, tenant, timestamps, and known suspicious activity. Look into unusual access to sensitive sites, large collections of documents, and external sharing changes, and separate normal backup reads from activity that can’t be reconciled with the expected backup schedule.

Microsoft Teams

Where the audit data supports it, review Teams activity and changes to application permissions, membership, and collaboration data. Correlate what you find with the service principal sign-ins and the activity of the related Teams management application.

The logging limitation

Microsoft 365 audit data doesn’t always let you attribute a given read operation to the attacker when the legitimate backup service and the attacker use the same application identity. Todyl described this limitation in tenants where application reads couldn’t be reliably separated from normal backup activity. Microsoft Graph activity logs can add request-level context when configured, but turning them on after an incident doesn’t recover requests that were never recorded.

The incident report should separate confirmed events, suspected exposure, and activity that couldn’t be established because the logs weren’t there.

Microsoft Graph and PowerShell: practical investigation workflow

For organizations using Microsoft Graph PowerShell, the following read-only example finds enterprise applications by the published client IDs. It is meant for authorized incident response.

Install the Microsoft Graph PowerShell SDK if necessary, then connect with an appropriately authorized account:

Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "Application.Read.All"

Define the affected client IDs:

$affectedAppIds = @(
    "506e08f9-6e9a-4da4-942b-a099a03644ae",
    "2399d300-6fca-4e6a-a686-399fefe75b83",
    "24205314-2b89-4e07-a2a4-579e898a5640",
    "b78f6a77-d4e5-46fb-87e5-d1648bd02519",
    "0de14c77-b9b0-4137-9360-34878a929827",
    "412dcf96-176d-4b3a-a1b0-4981ad66971e",
    "b2b55f5b-7758-4719-8d8f-88ae172e6bdb"
)

Query the tenant’s service principals and display the matches:

$servicePrincipals = Get-MgServicePrincipal -All
$servicePrincipals |
    Where-Object { $_.AppId -in $affectedAppIds } |
    Select-Object DisplayName, AppId, Id, AccountEnabled

AppId is the application client ID and Id is the local service principal object ID. Actions against a tenant-local service principal need the local object ID, so keep the two straight.

Export the matching records for the investigation:

$servicePrincipals |
    Where-Object { $_.AppId -in $affectedAppIds } |
    Select-Object DisplayName, AppId, Id, AccountEnabled |
    Export-Csv ".\connectwise-service-principals.csv" -NoTypeInformation

This query is an inventory of the listed identities. It doesn’t show that they authenticated maliciously, and their current settings may differ from their state during the incident, so correlate the results with sign-in and audit logs.

To examine application credentials, an authorized responder can inspect the relevant application or service principal with the appropriate Microsoft Graph commands. Vendor-owned application registrations may be inaccessible to a customer tenant, so limit credential investigation to objects you are authorized to inspect. Keep private keys, tokens, and client secrets out of incident reports.

For broader hunting, start with the Entra service principal sign-in logs and audit logs, then move to Microsoft Purview and any retained Graph activity telemetry. Keep original timestamps, identifiers, and correlation information in every portal export and PowerShell query.

remove unauthorized access paths

Once the evidence is preserved and the scope is understood, remove the unauthorized access without destroying legitimate configuration or recovery evidence.

• Remove confirmed malicious client secrets, certificates, or federated credentials from the applications where they were added. Don’t stop after rotating one credential. Check each affected application’s full credential inventory and confirm the suspicious credential is gone or unusable.
• Remove suspicious application role assignments and other directory privileges once you’ve confirmed they weren’t approved administrative changes, and investigate whatever was done while the unauthorized privileges were active.
• Review new application permissions and consent grants, remove the ones confirmed as unauthorized, and check whether the affected application holds any other grants that could give continued access.
• Review applications created during the incident and changes to application or service principal ownership. Disable suspicious applications, preserve their configuration, and delete them only when the investigation and response plan support it.
• Remove malicious forwarding rules, inbox rules, mailbox delegates, transport rules, and other unauthorized mail or collaboration changes, and review suspicious changes to sharing permissions and file access settings.
• Investigate unexpected user accounts, authentication methods, password resets, Conditional Access modifications, and named-location changes. Correct what is confirmed malicious and verify the intended security configuration.
• If one application modified another, repeat the investigation for the second identity and for every identity it changed. The chain of persistence may run well past the original vendor integration.

All of this is tenant-specific. ConnectWise can disable its vendor-side identities and invalidate its credentials, but nobody should assume it removed every unauthorized credential or role assignment created in each customer environment.

Recovery: restoring backups safely

Backup and restoration services are part of the containment problem here, which makes recovery awkward.

As of ConnectWise’s October 18 advisory, Cloud Backup remained suspended, scheduled backups weren’t running, and access to the affected backup archives and restoration capabilities was unavailable. ConnectWise said the archives remained encrypted, isolated, and preserved, with no evidence they had been accessed. It hadn’t given a confirmed restoration time.

Work out your last successful backup, identify data created or changed since that recovery point, and document the protection gap. If the incident affects several customers, the MSP should keep a tenant-by-tenant record of backup status, operational impact, and any alternative recovery arrangements.

Don’t re-enable the affected application identities just because the vendor service is down. Wait for ConnectWise’s confirmed recovery instructions and verify that the relevant credentials and connections have been secured.

When restoration is authorized, verify the new or reauthorized application identity, its permissions, and its expected authentication behavior. Confirm that backup jobs complete, that new recovery points are created, and that restoration tests work. After reconnection, review the logs for unexpected sign-ins or permission changes. I’d treat reconnection as a security validation exercise: you want confidence that the integration can resume without reopening the original access path.

reducing the risk of another OAuth supply-chain compromise

No single control removes the risk of a compromised third-party application. The aim is to make credential compromise less likely, limit the privileges an attacker can reach, spot abnormal use quickly, and keep the ability to revoke access and recover safely.

Enforce least privilege for applications

Review every third-party application authorized in Microsoft Entra ID, particularly those with tenant-wide mail, file, directory, or administrative permissions. Record each one’s business purpose, owner, permissions, approved tenants, and expected authentication pattern.

Permissions such as Mail.ReadWrite.All and Directory.ReadWrite.All deserve extra scrutiny because of their reach. Where supported, use narrower permissions, resource-specific authorization, or other scoping mechanisms. Remove unused integrations and revoke grants with no documented purpose.

Least privilege is more than a one-time consent decision. Review application permissions whenever a service changes, a vendor adds functionality, or an integration’s business purpose ends.

Protect application credentials

Treat application secrets and private keys as high-value credentials. Prefer managed identities where they fit, or certificate-based authentication with secure private-key storage where the application architecture supports it. Neither removes all risk: certificates can still be abused if their private keys leak, and managed identities still need correct authorization and monitoring.

Where client secrets are unavoidable, use controlled storage, sensible expiration periods, restricted access, and a documented rotation process. Keep secrets out of source code, shared scripts, configuration files, and unrestricted build logs. Monitor credential additions and changes to application registrations and service principals.

Vendors that run multi-tenant applications also need tested procedures for credential rotation, emergency revocation, and customer notification.

Monitor workload identities

Include service principal sign-ins in security monitoring next to interactive user sign-ins. Alert on authentication from unexpected hosting infrastructure, unusual geographic locations, unfamiliar user agents, and activity outside the integration’s normal pattern.

Monitor changes to application credentials, service principal owners, API permissions, consent grants, and directory roles. Alert when an application creates another application, changes its own authorization, or adds credentials to a different identity outside an approved workflow.

Each alert should carry the application client ID, local object ID, initiating identity, target object, timestamp, source IP where available, and the operation performed, so responders can tell quickly whether an event was authorized.

Configure logging before an incident

Enable and retain the audit sources you need to investigate application-only activity. Depending on licensing and architecture, that may include Entra sign-in logs, Entra audit logs, Microsoft Purview Audit, Microsoft Graph activity logs, and centralized SIEM telemetry.

Set retention long enough to detect and investigate a vendor compromise, and export critical records to a location with suitable access controls and retention protection. A short retention window can turn a detectable intrusion into one whose scope you can never establish.

Graph activity logging helps when investigators need request-level context, but check availability and collection requirements for your tenant. Enabling it after an incident won’t reconstruct requests that were never collected.

Treat MSP integrations as shared-risk dependencies

MSPs should keep an inventory of the applications installed in their own tenant and in each customer tenant: application IDs, local object IDs, permissions, purpose, business owner, and the procedure for disabling the integration during an incident.

A shared vendor application is a potential cross-customer dependency. MSP incident-response plans should say who can disable the integration, how customer administrators will be contacted, which logs to preserve, and how the provider will keep protecting customers if the service goes down.

Where possible, don’t concentrate unrelated administrative functions in one identity. Separate management roles, constrain access to customer tenants, and regularly test that you can revoke an integration without damaging your wider recovery capability.

Test the response process

A response plan only works if administrators know how to run it. Tabletop exercises should cover a compromised vendor credential, unexpected application role assignments, additional client secrets, unavailable backups, and a supplier that can’t restore service right away.

The exercise should confirm that the organization can identify affected tenants, export logs, disable the correct service principals, remove unauthorized credentials, assess data exposure, and resume backups safely. MSPs should also test coordination across multiple customers.

What organizations should report and document

Each affected organization should keep a tenant-specific incident record: the application IDs found, local object IDs, sign-in events, suspicious IP addresses, relevant user agents, directory changes, credentials removed, roles revoked, workload activity investigated, and any gaps in log coverage.

Record the exact time of each containment action and who performed it. Keep confirmed malicious activity apart from suspicious events still under investigation. If data access can’t be ruled out because telemetry was missing, document that limitation instead of declaring the tenant clean.

ConnectWise asks partners to report suspicious findings to [email protected]. Include the affected tenant and application identifiers, UTC timestamps, relevant event or correlation IDs, and a concise description of the findings. Leave out passwords, private keys, access tokens, and other secrets.

Follow your organization’s incident-response procedures, and assess contractual, regulatory, or customer-notification obligations based on the evidence and the relevant jurisdiction.

Current status and unresolved questions

ConnectWise’s October 18 advisory says the company disabled seven application identities on October 17, revoked certificates used for the affected Cloud Backup connections, invalidated the affected shared credentials, and suspended Cloud Backup while it investigates. It also engaged an external forensic firm and said it had not observed successful threat activity in the environments it monitors since putting its mitigations in place.

Those containment measures don’t establish that every downstream customer tenant was unaffected. ConnectWise noted that its investigation of the vendor environment doesn’t give it the visibility to determine whether a particular customer’s live Microsoft 365 environment saw unauthorized activity.

The archives and the downstream customer tenants are separate investigative scopes. ConnectWise’s statement that it has no evidence the encrypted archives were accessed isn’t a finding that no live Microsoft 365 data was accessed.

Several questions remain open: how the original credential was compromised, the full population of affected tenants, whether particular messages or files were exfiltrated, how far the reported privilege escalation reached, and whether other persistence mechanisms remain. Answering them will take more evidence from the vendor and from affected organizations.

Conclusion

An attacker who authenticates as a trusted application can request tokens under permissions customers already granted to the legitimate backup service, so the actor in this incident had no need to compromise each customer’s accounts one by one.

The impact may extend beyond the original application. Huntress’s findings on related ConnectWise Cloud Management identities show why incident response has to cover application credentials, role assignments, consent grants, and every other identity modified during the intrusion. Disabling the first application is essential, but it won’t remove persistence created elsewhere.

For Microsoft 365 administrators, the immediate priorities are to verify that the affected applications are disabled, preserve sign-in and audit logs, find unauthorized credentials and role assignments, investigate mailbox and file activity, and document what can and can’t be established about data exposure. MSPs need to run those checks in their own environments and in every customer tenant they manage.

Third-party integrations sit inside an organization’s identity security boundary. Their permissions need justification, their credentials need protection, their activity needs monitoring, and their access has to be removable in an emergency. Backup software needs real access to protect data, and that access needs controls that still hold when the vendor’s own application identity is compromised.

This article reflects the published incident information available on October 18, 2026. The investigation is ongoing, and the technical scope and remediation guidance may change as ConnectWise, Microsoft, and independent security researchers publish more findings.