Microsoft links ConnectWise compromise to Storm-0940 as restoration proceeds

Latest Trust Center update, October 22, 2026 at 00:45 UTC. ConnectWise says phased restoration is underway and expects it to take several days. Each step remains subject to security validation; service-specific availability and reconnection instructions will follow as confirmed. Keep affected connections disabled until formal instructions apply. ConnectWise says stored archives remain encrypted, isolated, and preserved with no indication of compromise, and it has no indication that other products or services are affected. These vendor findings do not establish the status of every partner or customer Microsoft 365 tenant; review each separately. (ConnectWise Trust Center advisory)

ConnectWise says it is investigating unauthorized access to application identities associated with Cloud Backup, formerly known as SkyKick. At 07:00 UTC on October 17, the company disabled seven ConnectWise application identities listed in its technical guidance. It also suspended Cloud Backup and revoked certificates used for the affected application connections. ConnectWise says disabling those connections prevents new authentication through them. It does not reverse changes already made inside a Microsoft 365 tenant. Previously issued access tokens may remain usable until they expire or are otherwise invalidated, and access established through separate identities requires its own review. These are separate controls and separate findings. (ConnectWise advisory)

Microsoft attributes the activity

In its October 21 22:00 UTC update, ConnectWise said evidence including Microsoft threat intelligence pointed to a China state-aligned group. Microsoft separately assesses that Storm-0940 was responsible for the ConnectWise multi-tenant application compromise. Microsoft says the group used the open-source ARTEX framework to accelerate activity, then used control of multiple ConnectWise application identities to authenticate to downstream Microsoft 365 environments through apps that already had access. Microsoft observed Graph reconnaissance, application credential changes, and attempts to modify privileges in multiple environments. Authentication by itself does not establish that customer data was accessed or exfiltrated. (ConnectWise Trust Center advisory; Microsoft Security Blog)

Microsoft describes a separate October 10 to 14 password-spray dataset: 327 accounts across eight organizations received more than 151,000 failed logons, with no successful authentication, token issuance, Graph call, or directory change observed in that dataset. Microsoft later describes downstream activity using compromised application credentials. These are distinct activity sets and should not be conflated. (Microsoft Security Blog)

Service disruption and compromise evidence

ConnectWise's October 22 00:45 UTC update says phased restoration has begun, but it has not yet specified which service capabilities are available or issued service-specific reconnection instructions. Keep affected applications disabled until formal guidance applies. The interruption has affected Cloud Backup scheduling, archive access and restores, along with SaaS Security monitoring and Cloud Management functions. The company says existing backup archives remain encrypted, isolated, and preserved with no indication of compromise. That statement concerns the stored archives and does not establish whether a partner or customer Microsoft 365 tenant experienced unauthorized activity.

Steps for managed service providers

Review the ConnectWise application identities in both the MSP's own tenant and each managed customer tenant. Use the application IDs in the ConnectWise technical guidance, since older installations may show SkyKick names and similar display names do not establish that an application is the same identity. Verify the local enterprise application state. ConnectWise has added a video walkthrough of its technical investigation and remediation guide for authorized administrators. The company cautions that completing the steps does not establish that a tenant is unaffected or that all unauthorized access has ended. Keep affected connections disabled until formal restoration instructions arrive. Microsoft's guidance explains that disabling sign-in for a tenant-local enterprise application prevents new tokens from being issued for that application. (Microsoft Entra application sign-in guidance)

ConnectWise’s October 18, 18:45 UTC update asks partners to include 144.172.64[.]99 and 144.172.64[.]60, alongside previously listed 144.172.64[.]128, in available Microsoft 365 authentication and audit-log reviews. ConnectWise says the two new addresses came from downstream security monitoring of partner and customer environments. A matching address is an investigation lead; it does not, by itself, confirm a tenant compromise.

Preserve available sign-in and directory audit records promptly, without delaying urgent containment. Review service-principal, managed-identity, interactive user and non-interactive user sign-ins, and export the records before the tenant's retention window removes them. Retention varies by license. Microsoft's documentation covers downloading sign-in and audit logs, and its application investigation playbook recommends checking service-principal activity, credential changes, owners, permissions and consent grants. (Microsoft Entra log export guidance; Microsoft compromised application investigation)

Follow ConnectWise's tenant review workflow with the organization's security team or incident response provider. Review application and user authentication, credentials and federation trusts, directory roles, owners, consent grants, policy changes, mailbox forwarding and rules, and relevant Microsoft 365 activity. Correlate events with authorized change records and expected service activity. A matching address, a failed sign-in, or a scripting user agent alone does not establish that a tenant was compromised or that data was copied.

If evidence indicates unauthorized tenant activity, investigate and contain each affected identity and access path through its owning control plane. Vendor-side certificate revocation, tenant-local application sign-in state, previously issued tokens, and access established through other identities are distinct. Confirm which credentials, permissions, or sessions were affected before restoring connections. For the backup gap, identify the last successful recovery point and plan for the period without scheduled backups or restores. Follow ConnectWise's restoration instructions before reconnecting affected services.