Threat

AI-Driven Supply Chain Attack Reached Privileged Cloud Access in Under Three Hours

Page published · Page updated

Dossier

Publication date unknown · First observed: 13 Nov 2026

Coverage timeline

13 Nov 2026blackberry.comobserved

Single-source incident — one report is available.

Why it matters

The ConnectWise Cloud Backup compromise illustrates how autonomous agents can compress response windows while creating secondary access that survives remediation of the originally compromised application.

Storm-0940 reportedly used the ARTEX autonomous multi-agent penetration-testing framework in a ConnectWise Cloud Backup supply-chain compromise, attempting sign-ins to more than 2,250 downstream Microsoft 365 tenants with stolen application credentials. According to the article's account of Microsoft findings, some intrusions reached privileged access in under three hours, with follow-on credential changes, persistent access, and large-scale reading of Azure Key Vault secrets.

campaign

Summary

BlackBerry's November 6, 2026 article reports that Microsoft attributed a ConnectWise Cloud Backup supply-chain compromise to Storm-0940, described as a China-state-aligned actor active since 2021. The actor reportedly used ARTEX, an open-source multi-agent penetration-testing framework, against hundreds of organizations across sectors including government, military, aerospace and defense, energy, and financial services. This is a reported named-actor campaign, rather than a disclosed software vulnerability with a defined vulnerable-version range.[0]

The reported downstream access path relied on stolen credentials for trusted ConnectWise cloud application identities. These identities authenticated to customer Microsoft 365 environments as applications, without interactive user sign-ins. Agents attempted sign-ins to more than 2,250 tenants, although most targeting was reportedly unsuccessful. The article describes more than 200 sign-ins in under four minutes using four application credentials and, in multiple instances, privileged cloud access less than three hours after initial targeting. Those figures describe targeting and selected successful activity, not 2,250 confirmed compromises.[0]

The principal containment concern is access surviving remediation of the original integration. Reported activity included application credential changes, changes involving identities, groups and privileged roles, Microsoft Graph operations, and secret reads across multiple Azure Key Vaults. The article warns that actor-created credentials and access paths can persist through other identities and cloud services. Recommended containment therefore combines disabled application connections, evidence preservation, tenant-wide investigation, and review of sign-in and audit records from at least October 15.[0]

The evidence base is limited to the supplied BlackBerry article. It attributes technical findings and containment guidance to Microsoft, but the linked Microsoft report itself was not supplied for examination. Attribution, timing, scale, and observed behaviors should therefore be treated as single-source reporting rather than independently corroborated findings.[0]

Attack chain

  1. Earlier password spraying without successful authentication: During October 10–14, the same infrastructure reportedly generated more than 151,000 failed logons against 327 accounts at eight organizations, reaching 2,900 failures per minute. No successful authentication was reported for this phase. The article does not establish that this spraying obtained the application credentials used in the downstream compromise.[0]
  2. Control of trusted vendor application identities: The actor reportedly took control of several ConnectWise cloud application identities and possessed stolen application credentials. ConnectWise disclosed unauthorized access associated with Cloud Backup on October 16. The supplied account does not explain the initial intrusion method or how the application credentials were acquired.[0]
  3. App-only authentication into downstream tenants: Using the compromised application identities, agents attempted authentication to more than 2,250 customer Microsoft 365 tenants without an interactive user sign-in. Most targeting was reportedly unsuccessful. The reported downstream activity included more than 200 sign-ins in under four minutes using four application credentials; privileged access followed initial targeting by less than three hours in multiple instances.[0]
  4. Post-authentication directory operations and persistence: In some environments, activity progressed to Microsoft Graph and directory operations, including application credential changes and changes involving identities, groups, and privileged roles. Microsoft also reportedly observed secret reads at scale across multiple Azure Key Vaults. Credential changes could establish access paths that survive remediation of the original application; the article does not provide a precise ordering among these post-authentication operations.[0]

Disclosure timeline

DateEvent
2026-10-10 to 2026-10-14Reported password-spray activity generated more than 151,000 failed logons against 327 accounts at eight organizations, with no successful authentication.[0]
2026-10-16ConnectWise reportedly disclosed unauthorized access associated with Cloud Backup.[0]
2026-10-21Microsoft reportedly attributed the ConnectWise supply-chain compromise to Storm-0940 and published the campaign analysis cited by BlackBerry.[0]
2026-11-06BlackBerry published the supplied account summarizing the reported campaign, its cloud-identity implications, and containment recommendations.[0]

Actor profile

Storm-0940

BlackBerry, attributing its account to Microsoft, describes Storm-0940 as a China-state-aligned actor active since 2021 that targets multiple industries for data theft. The reported campaign used ARTEX against hundreds of organizations globally since at least September, including government, military, aerospace and defense, energy, and financial-services organizations. The supplied evidence does not independently corroborate the attribution or establish that every targeted organization was compromised.[0]

How it works

The described access mechanism is abuse of trusted cloud application identities, not a documented software exploit. Stolen credentials allowed the actor to authenticate as ConnectWise applications that customers had already authorized. Because this was app-only authentication without an interactive user sign-in, protections applied at the user sign-in step, including user MFA, did not provide an intervention point for those authentications.[0]

After authentication, the actor reportedly performed Microsoft Graph and directory operations that included credential and privilege changes. The article identifies changes involving applications, identities, groups, and privileged roles, together with large-scale reads of Azure Key Vault secrets. These are reported post-authentication behaviors; the supplied evidence does not identify the exact application permissions or API operations used.[0]

Persistence depended on changes beyond the original compromised application. Actor-made credentials and changes involving other identities or cloud services could preserve a backdoor after that application was remediated. Consequently, disabling the affected integration addresses the original access path but does not by itself establish that all actor access has been removed.[0]

Affected versions and patch status

ProductAffectedPatch status
ConnectWise Cloud Backup and its authorized Microsoft 365 application connectionsThe reported compromise involved several ConnectWise cloud application identities. Investigation scope includes every tenant where affected applications were installed or authorized. More than 2,250 tenants were reportedly targeted, but most targeting was unsuccessful; this is not a confirmed victim count. No affected software-version range or literal application IDs are provided.The supplied article provides no version-specific patch or confirmed restoration status. Its reported guidance is to keep affected application connections disabled until ConnectWise provides restoration instructions.[0]

Key takeaways

  • Application identity security is central to this reported campaign: trusted vendor credentials enabled app-only access without the interactive user sign-in step on which user MFA operates.[0]
  • Separate targeting scale from confirmed compromise. More than 2,250 tenants were reportedly targeted, most targeting was unsuccessful, and the earlier password-spray phase produced no successful authentication.[0]
  • Disabling the original application is not proof of eradication. Reported credential and privilege changes could preserve access through other identities and cloud services.[0]
  • No actionable indicator literals are supplied for an IOC list. The article instead supports investigation through affected application identities, service-principal sign-ins, credential changes, and privilege changes; its linked primary report was not available in the supplied evidence for independent corroboration.[0]

Defensive actions

  • Identify every tenant where the affected ConnectWise applications are or were installed or authorized, using application IDs rather than display names.: The reported access path used trusted application identities across downstream customer tenants. The article explicitly recommends application-ID-based identification; it does not supply the IDs themselves.[0]
  • Keep affected ConnectWise application connections disabled until ConnectWise provides restoration instructions.: The reported compromise used those application connections to authenticate into customer environments. Continued disablement is the containment guidance relayed in the article, while restoration may also affect backup and restore workflows.[0]
  • Preserve relevant configuration, Entra sign-in and audit records, and Microsoft 365 audit data before making irreversible changes.: The article explicitly prioritizes evidence preservation during containment. Credential and privilege changes may extend beyond the initially compromised application, making preserved configuration and audit history important to establishing the scope of access.[0]
  • Review service-principal sign-ins and credential, role, and privilege changes from at least October 15 across all in-scope tenants.: The campaign reportedly used non-interactive application authentication and subsequently changed credentials and directory privileges. User sign-in records alone would not cover the described access path.[0]
  • Investigate changes involving other application credentials, identities, groups, privileged roles, and cloud services before treating remediation of the original application as complete eradication.: The article warns that actor-created access paths can remain after the originally compromised application is remediated. It also reports secret reads across multiple Azure Key Vaults, reinforcing that investigation cannot stop at the vendor integration.[0]
  • Inventory third-party applications with privileged tenant access, apply least privilege to their permissions, and monitor credential additions and privilege assignments.: The reported campaign exploited authorization already granted to vendor applications and then made credential and privilege changes. These controls address the specific trust relationships and persistence behaviors described in the article.[0]
  • Establish and test a response communication channel outside the Microsoft 365 tenant under investigation, and plan coordinated containment around an hours-scale response window.: The article notes that responders' email and Teams environment may itself be in scope, while privileged access was reportedly achieved in less than three hours in multiple instances. Its recommendations explicitly address both independent response communications and machine-speed attack timelines.[0]