ConnectWise Cloud Backup Breach: How to Check Your Microsoft 365 Tenant for Storm-0940 Activity

On 21 October 2026, Microsoft Threat Intelligence attributed the compromise of a ConnectWise multitenant application to Storm-0940, a China state-aligned actor, and said the group used an open-source agentic AI framework called ARTEX to work at machine speed. If your organisation, or your managed service provider, ever connected ConnectWise Cloud Backup (formerly SkyKick) to Microsoft 365, the ConnectWise Cloud Backup breach is a reason to check your Microsoft 365 tenant today, not next week.

The headline number is that Microsoft saw Storm-0940 attempt sign-ins to more than 2,250 tenants. The number that matters more is what an attempt looks like in your logs, and where you have to look to see it.

Key finding: the door was a vendor’s app identity

This was not a vulnerability with a CVE. Attackers gained control of several ConnectWise cloud application identities, which are service principals that customers had already consented to in their own tenants. Because those identities already had access, the agents could authenticate without an interactive user sign-in, no password prompt and no MFA challenge for a human to approve.

Microsoft reports that, in several intrusions, the time from first targeting to privileged cloud access was under three hours. Follow-on activity ran through Microsoft Graph: reconnaissance, changes to application credentials, and attempts to change identities, groups and privileged roles.

Microsoft is careful to add that an affected app, or a successful authentication by the attacker, does not on its own show that data was accessed or stolen. Treat this as an exposure to investigate, not as proof of loss.

Technical analysis

Timeline (all 2026, per Microsoft and ConnectWise)

• 10 to 14 October: a cross-tenant password spray against 327 accounts at eight organisations, with more than 151,000 failed logons and a peak of 2,900 failures per minute on 11 October. Microsoft observed no successful authentication, token issuance, Graph call or directory change from this spray.
• 15 October onward: the attackers’ use of ConnectWise application identities against customer tenants.
• 17 October: ConnectWise disabled the affected application identities (per its notices).
• 21 October: Microsoft published its attribution.

The spray and the application abuse are two separate pieces of evidence. The spray failed. The app-identity path is the one to worry about.

Why service principal sign-ins are easy to miss

Most teams review the default user sign-in logs. Service principal sign-ins live on a separate tab in Entra (Monitoring, then Sign-in logs, then Service principal sign-ins). If you only ever look at user sign-ins, this activity does not appear. ConnectWise has said that normal traffic from these apps comes from Azure address space, so a sign-in from a public IPv4 address at a hosting provider is a warning sign.

Persistence: the backdoor that outlives the cleanup

Storm-0940 has a documented habit of adding credentials to existing OAuth applications for persistence. Microsoft warns that credential changes of this kind can survive after the original app is removed or disabled. That is why the guidance is to preserve evidence before you delete anything: once you remove the app, you may also lose the audit trail showing what was added to it.

Impact assessment

Risk rating: high for anyone who ever consented to ConnectWise Cloud Backup, including through an MSP; unknown for everyone else until checked.

Affected platforms are Microsoft 365, Exchange Online, Microsoft Graph and Entra ID. Microsoft names aerospace and defence, financial services, government, energy, semiconductors, automotive, chemicals and manufacturing among the targeted sectors, but a vendor-app compromise does not respect sector lines. Any tenant that granted the integration is in scope for review.

ConnectWise has said stored backup archives are encrypted and isolated with no sign of compromise, and has said this does not tell you whether customer Microsoft 365 tenants were affected. Its Cloud Backup, SaaS Security and Cloud Management services were suspended while it prepared a phased restoration.

The CloudShieldSecure perspective

This incident is a clean example of why we treat third-party access as part of your attack surface, not a footnote to it. At CloudKonsult, the question behind CloudShieldSecure is a simple one: do you know every non-human identity that can act in your tenant, what it can do, and when that last changed?

Three signals would have shortened the window here: a standing inventory of consented enterprise apps and their permissions, alerts on credentials added to an existing app, and alerts on role assignments made by a service principal. None of them require knowing the attacker’s name in advance. They require knowing what normal looks like for your vendor integrations.

Recommended actions

1. Keep ConnectWise connections disabled until ConnectWise publishes formal reconnection instructions.
2. Preserve evidence first. Export Entra sign-in and audit logs, Purview audit records and any SIEM data before deleting enterprise apps. Retention can be as short as 7 days on free tiers and 30 days on P1 or P2, so do this now.
3. Search by application ID, not display name, including in tenants where you no longer use the integration. Microsoft publishes the IDs in its blog post; use those rather than anything copied from a secondary source.
4. Review from 15 October at a minimum, and from 1 October where logs allow. Check successful and failed sign-ins separately, and use the Service principal sign-ins tab.
5. Audit for persistence. In the Entra audit log, look for new credentials on applications, new service principals or owners, app role assignments, consent grants and privileged role assignments. A service principal assigning a role to itself is a red flag.
6. Check for data access: unusual mail or file access, new inbox or transport rules, forwarding, and changes to delegated mailbox permissions.
7. Only after evidence is preserved, have an authorised responder remove unauthorised credentials and grants, revoke unneeded permissions and rotate remaining credentials.
8. Treat indicators as leads, not proof. Microsoft’s published IP addresses and user agents are useful starting points for hunting, but finding nothing does not prove nothing happened.
9. Apply least privilege to every multitenant app and set up alerting on credential additions and privilege assignments going forward.

If you use Microsoft Defender, Microsoft lists specific detections for this activity, including “Application self-assigned Global Administrator role” and “Unusual Microsoft Graph activity associated with Compromised ConnectWise Application”. Availability depends on your licensing.

Sources and references

• Microsoft Security Blog, “Storm-0940 uses ARTEX agentic AI in ConnectWise supply chain compromise,” 21 October 2026: https://www.microsoft.com/en-us/security/blog/2026/10/21/storm-0940-uses-artex-agentic-ai-connectwise-supply-chain-compromise
• Huntress, “ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks”: https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access
• ConnectWise Product and Services Status: https://status.connectwise.com/pages/incident/619cf82551fec9053d612f09/6ad263692dc48705ab3da2cb
• The Hacker News coverage: https://thehackernews.com/2026/10/china-linked-hackers-use-artex-ai.html