Skip to content
audiotale.net
Sign in
NewsNews

Microsoft blames China-linked Storm-0940 for ConnectWise Cloud Backup breach, says attackers used ARTEX AI framework

Microsoft says Storm-0940 used the open-source ARTEX framework against hundreds of organisations after stealing ConnectWise app credentials; what to check in your Microsoft 365 tenant.

audiotale.net team

· 8 min read

Written by AI from the sources linked below. How we use AI

On this page
  1. Key points
  2. What happened
  3. Background
  4. The numbers
  5. What it means
  6. What we don't know yet
  7. What to watch next
  8. Sources

Microsoft said on 21 October 2026 that a China state-aligned actor it tracks as Storm-0940 was behind the compromise of ConnectWise Cloud Backup, and that the group used ARTEX, an open-source AI penetration-testing framework, to run the follow-on attacks at "machine speed". ConnectWise's chief executive has since said the company agrees that a China state-aligned group was responsible. For anyone who connected a ConnectWise or SkyKick-branded app to Microsoft 365, the practical message is to check the app's service principal in your own tenant, because switching the vendor's service off does not undo what was already changed inside customers' environments. China's embassy in Washington rejected the attribution.

Key points

  • Microsoft attributes the ConnectWise Cloud Backup supply chain compromise to Storm-0940, a China state-aligned actor active since 2021; ConnectWise's CEO Manny Rivelo told Reuters that "a China state-aligned group was responsible".
  • Between 10 and 14 October 2026, one Storm-0940 address (144.172.64.99) tried a password spray against 327 accounts at eight organisations, producing more than 151,000 failed sign-ins, peaking at 2,900 a minute on 11 October; Microsoft saw no successful sign-in in that spray.
  • On 15 October the attackers gained control of identities of several ConnectWise cloud applications and used them to sign in to customer Microsoft 365 tenants; ARTEX-driven sign-in attempts reached more than 2,250 tenants, and some attacks reached privileged cloud access in under three hours.
  • ConnectWise disabled seven application identities on 17 October 2026 and suspended Cloud Backup, SaaS Security and Cloud Management; Microsoft says to keep the connections disabled until ConnectWise issues restoration instructions.
  • Microsoft says the activity did not come from a flaw in its own products, and that a compromised app or a successful sign-in does not by itself prove customer data was taken.

What happened

ConnectWise says its monitoring identified the problem on 14 October 2026. Huntress, a security firm that watches many small-business tenants, tied scripted sign-in attempts from a single address, 144.172.64.128, to 13 and 14 October. On 15 October, sign-ins using the Cloud Backup application's own credentials began to succeed across customer tenants. According to BleepingComputer's account, Huntress counted at least 162 compromised tenants among those it monitors, and in one tenant the attacker went from a Cloud Management service principal to Global Administrator and added credentials to other tools within about five minutes. Huntress separately told The Hacker News that it saw almost 1,000 Entra tenants with sign-in activity from the address, around 300 of them successful; it said missing service principals in some tenants stopped the attempts.

The mechanism is what makes this a supply chain incident. Cloud Backup is a multi-tenant application: each customer grants it permissions in their own Microsoft 365 tenant, and the vendor holds the credentials that prove the app is who it says it is. Whoever holds those credentials can authenticate as the app in every tenant that trusts it, with no user present, no password prompt and no multi-factor authentication. Microsoft describes the attackers "operating without requiring an interactive user sign-in", using permissions that customers had already approved. Security firm Todyl, quoted by BleepingComputer, made the same point about MFA: automated app sign-ins do not trigger it.

On Saturday 17 October at 07:00 UTC ConnectWise disabled seven application identities, one for Cloud Backup and six for Cloud Management (covering Teams, Exchange Online, Microsoft Graph, Partner Center and SharePoint Online), and suspended Cloud Backup by revoking the certificates behind the affected connections. It also took SaaS Security and Cloud Management offline as a precaution. Scheduled backups stopped, and archive access and restores became unavailable. ConnectWise says existing archives remain encrypted and isolated, with no evidence they were accessed. It also said that disabling the connections "does not reverse changes previously made inside a tenant", and it had not said how the credentials were exposed or whether a product vulnerability played a part.

On 21 October Microsoft published its analysis. It names Storm-0940, says the group began using ARTEX as early as September 2026, and says targeting spans hundreds of organisations in aerospace and defence, automotive, chemicals, energy, financial services, government, legal, manufacturing, media, semiconductors, software, technology and think tanks. Microsoft says most targeting was unsuccessful, but that the group gained privileged cloud persistence at many organisations in a short time, with several cases taking under three hours from first targeting to privileged access.

Background

Storm-0940 is not new. Microsoft first described it in November 2024, when it was using a botnet called Quad7 (also tracked as CovertNetwork-1658) to run highly evasive password-spray attacks. Microsoft says the group exploits internet-facing applications for initial access, moves through environments with compromised accounts, and persists by adding credentials to existing OAuth applications so that it can read mail and files through Microsoft Graph.

ARTEX is the other thread. Microsoft describes it as an open-source, multi-agent penetration-testing framework written in Go with a Next.js interface that can run on any AI model and carries out reconnaissance through to data exfiltration, recording what it finds in a graph. The Hacker News reports that it was made closed-source after it was abused in attacks on South Korean financial institutions. Recorded Future's Insikt Group tracks the cluster behind those attacks as TAG-217, and Zscaler's ThreatLabz later analysed a custom ARTEX deployment that included synchronisation scripts and a Claude Code prompt history. Zscaler found it configured to use a DeepSeek model through an OpenAI-compatible gateway, with other settings naming GLM and Grok, and prompts asking one model to review another's work. Zscaler cautioned that configured model names do not prove which models answered. Importantly, Zscaler's operator is described as a separate, Chinese-speaking cluster; reporting does not establish that it is the same actor as Microsoft's Storm-0940, and Microsoft says it has seen several actors in different regions using ARTEX.

We have covered earlier incidents where a trusted vendor's credentials became the way in, including the TeamUpdraft breach and the compromised OVHcloud CLI releases. This one differs in what was stolen: not code that customers install, but the identity that customers' own tenants already trust.

The numbers

The figures below come from Microsoft's analysis of the password-spray phase and describe attempts, not compromises. Reported counts of affected tenants differ by who is counting, which is expected: each firm sees only its own customers.

type: bar
title: ConnectWise Cloud Backup incident, counts reported by different sources
unit: tenants or accounts
source: Microsoft Security Blog; Huntress via BleepingComputer and The Hacker News
highlight: Tenants with ARTEX sign-in attempts
Tenants with ARTEX sign-in attempts (Microsoft) | 2250
Entra tenants with sign-ins from the IP (Huntress) | 1000
Successful sign-ins in those tenants (Huntress, approx.) | 300
Compromised tenants in Huntress's own base (Huntress) | 162
Accounts in the 10-14 Oct password spray (Microsoft) | 327

Other figures from Microsoft: 151,000 failed sign-ins over 10-14 October, a peak of 2,900 failures a minute on 11 October, more than 111,000 failures in that one day, and 48 accounts with more than 1,000 failures each. The sign-in attempts against more than 2,250 tenants also ran at about 2,900 a minute. Lockout responses made up nearly 98% of the spray activity. Note that the chart mixes different measures; read each bar by its label rather than as a ranking of one quantity.

What it means

For IT teams and managed service providers. Search every tenant for the affected applications by application ID, not display name, including tenants where the integration is no longer used. Microsoft lists three IDs in its hunting queries: 506e08f9-6e9a-4da4-942b-a099a03644ae (ConnectWise Cloud Backup), 24205314-2b89-4e07-a2a4-579e898a5640 (ConnectWise MS Teams) and 0de14c77-b9b0-4137-9360-34878a929827 (ConnectWise MS Graph). Review service-principal sign-ins from at least 15 October, and from 1 October where records exist, and do not limit the search to the published addresses (144.172.64.128, .99 and .60). Look for added credentials, new owners, app-role assignments, consent grants, privileged-role assignments, and mailbox forwarding or transport rules.

Order matters. Microsoft's guidance is to keep the ConnectWise connections disabled, preserve evidence first, and not delete the enterprise applications as a first response. Only after logs and configuration are saved should you revoke permissions and remove unauthorised credentials. The reason is persistence: the Hacker News and Microsoft both note that credential changes made by the attacker can remain as a backdoor even after the original app is dealt with, and ConnectWise's own CEO warned that containment does not remove access that may already exist in customer tenants.

For everyone who grants OAuth apps access. Multi-tenant apps with broad permissions such as Directory.ReadWrite.All are a concentrated risk: one stolen vendor secret opens every customer at once. Least-privilege permissions, alerts on credential additions to service principals and monitoring of app-only activity are the controls Microsoft recommends. Microsoft's separate argument that AI agents should be treated as insiders landed days earlier and is relevant here: the attacker's tooling was agentic, while the stolen identities were non-human ones.

For defenders on speed. Microsoft's point is that AI automation shortens the window: a reconnaissance and persistence loop that once took a human operator hours now fits inside a sign-in rate of thousands a minute. That does not make the attack unstoppable. The spray phase produced no successful sign-ins and was mostly met with lockouts; the successful route was the stolen app identity, which is a credential-hygiene problem rather than an AI problem.

What we don't know yet

  • How the attackers obtained the ConnectWise application credentials. ConnectWise says its analysis of the exposure mechanism is ongoing and has not said whether a product vulnerability contributed.
  • How many customers had data accessed. Microsoft states plainly that "the presence of an affected application or successful threat actor authentication does not necessarily indicate that customer data was accessed or exfiltrated".
  • The true victim count. The 162, roughly 300 and 2,250 figures measure different things and come from different vantage points; no one has published a complete tally.
  • Whether the Zscaler and Recorded Future ARTEX operator is connected to Storm-0940. Public reporting does not say so.
  • When services return. ConnectWise says it is restoring services in phases but has given no firm timeline in the sources we read.
  • Attribution rests on Microsoft's analysis and ConnectWise's agreement. A spokesperson for China's embassy in Washington said China "opposes and fights hacking activities in accordance with the law" and rejected the claims as smears; no independent party has published its own attribution that we could find.

What to watch next

ConnectWise's restoration guidance and any root-cause statement; additions to the indicator lists beyond the three addresses and three application IDs published so far; whether Microsoft or the vendor tightens how multi-tenant apps hold and rotate credentials; and further reports from Huntress, Zscaler and Recorded Future on how widely ARTEX is used and whether the open-source version remains available.

Sources

Written by

audiotale.net team

The official account of the people who run audiotale.net: announcements, conversation starters and the newsroom's drafts. Posts written with AI say so. Every other account here is a real person.