Microsoft blames Storm-0940 for the ConnectWise supply-chain breach, with its ARTEX agent hitting 2,250+ tenants at 2,900 sign-in attempts a minute
Microsoft tied the ConnectWise Cloud Backup breach to China-state Storm-0940 on Oct 21: ARTEX agents reached 2,250+ tenants at 2,900 sign-ins a minute.
Microsoft attributed the ConnectWise Cloud Backup supply-chain compromise to Storm-0940 in a threat-intelligence report published on October 21, 2026, and said the group had been using ARTEX, an open-source multi-agent penetration-testing framework, to automate attacks since September 2026. The report carries one checkable gauge: during the ConnectWise incident the actor used stolen application credentials to reach more than 2,250 Microsoft 365 tenants at 2,900 sign-in attempts per minute. Microsoft did not say how many tenants were actually compromised.
Key points
- Microsoft describes Storm-0940 as a China-state aligned actor active since 2021, which historically won initial access through password spraying and exploits against internet-facing applications, then persisted inside cloud environments by adding credentials to existing OAuth applications.
- ARTEX is an open-source multi-agent framework with a Go backend and a Next.js frontend. Its interface and output default to English and can switch to Korean, Mandarin, Spanish or Japanese. Microsoft says its LLM-driven agents run an autonomous test from reconnaissance through data exfiltration with little human interaction.
- The October 10–14 password spray against 327 accounts at eight organizations failed outright: 151,000+ failed logons, a peak of 2,900 failures per minute on October 11, more than 111,000 failures in a single day, 48 accounts with over 1,000 failures each, and lockout responses making up nearly 98% of activity. Microsoft’s wording is that “no successful authentication, token issuance, Graph call, or directory change was observed.”
Timeline
Microsoft’s account joins two timelines: how ARTEX spread as a tool, and what happened downstream at ConnectWise.
| Date (UTC) | Event | Source |
|---|---|---|
| 2026-07-26 | Earliest commit in trhhubsd/ARTEX: “chore: ARTEX 初始化” | GitHub |
| 2026-10-04 | Wayback capture of Autumn-27/ARTEX still returns 200 | Internet Archive |
| 2026-10-07 | Same address, still 200 | Internet Archive |
| 2026-10-08 | Capture turns 404; trhhubsd/ARTEX created at 20:35 | Internet Archive |
| Oct 10–14 | 144.172.64[.]99 sprays 327 accounts across eight organizations | Microsoft |
| Oct 11 | Failed sign-ins peak at 2,900 per minute | Microsoft |
| Oct 15 | Public reports of the ConnectWise compromise name 144.172.64.x IOCs | Microsoft |
| Oct 16 | ConnectWise publishes its first advisory | Microsoft, ConnectWise |
| Oct 17 05:01 | ConnectWise announces the Cloud Backup service interruption | BleepingComputer |
| Oct 17 07:00 | Seven application identities disabled and credentials revoked | ConnectWise guide |
| Oct 18 | ConnectWise publishes a 15-page investigation and remediation guide | ConnectWise |
| Oct 21 18:23 | Microsoft publishes; updated at 00:54 and 04:01 UTC on Oct 22 | Microsoft |
| Oct 21 | ConnectWise says phased restoration has begun and will take days | CyberScoop |
ARTEX’s open-source status has its own wrinkle. Microsoft calls it an open-source penetration-testing framework, and the original repository, Autumn-27/ARTEX, now returns 404. Wayback captures show 200 on October 4 and 7, then 404 from October 8 onward. What resolves today is trhhubsd/ARTEX, whose README states on line 454 that it continues maintaining Autumn-27/ARTEX. The repository’s created_at is 2026-10-08 while its earliest commit is dated July 26, which makes it a re-uploaded mirror. As of October 22, 2026 it has 1,582 stars, 776 forks and an AGPL-3.0 license.
What the agents did
Microsoft breaks ARTEX’s role in the ConnectWise incident into three jobs: speeding up scanning and reconnaissance, running the password spray, and abusing OAuth applications at downstream victims. Of the three, the spray Microsoft quantified, 327 accounts at eight organizations, succeeded zero times. Microsoft also says several other ARTEX-driven intrusions did reach privileged cloud access.
What carried the actor into customer tenants was the stolen credential for ConnectWise’s cloud applications. Those application identities already held admin-consented permissions inside each tenant, and they authenticate as themselves rather than through an interactive user sign-in, so MFA has nothing to challenge. Todyl researchers, as BleepingComputer reported, found that the attacker authenticated directly to Microsoft 365 as the backup application using its secret, inheriting exactly the permissions customers had granted it.
Once the actor controlled the identities of multiple ConnectWise cloud applications, Microsoft writes, the agents acting on its behalf kept using the same IP range to authenticate into customer environments on the strength of those stolen app credentials. In some environments the agents moved past authentication into Microsoft Graph and directory operations: reconnaissance, application credential changes to establish persistence, and changes to identities, groups and privileged roles. Microsoft says it found evidence of follow-on activity in multiple customer environments, and cautions that the presence of an affected application, or even a successful authentication, does not by itself mean customer data was accessed or exfiltrated.
On scale, Microsoft’s figure graphic credits four application credentials with 200+ sign-ins in under four minutes, and the report says several ARTEX-driven intrusions went from initial targeting to privileged cloud access in under three hours. Two different 2,900s appear in the report: the October 11 failure peak, and the attempt rate against 2,250 tenants. Both are per minute.
The tenant numbers disagree
The 2,250 figure is the easiest one to misread. It counts tenants that were targeted with sign-in attempts. Elsewhere in the same report, in the earlier “What’s happening” section, Microsoft writes that “the majority of the targeting wasn’t successful,” and it never states a compromised-tenant count. CyberScoop’s October 21 story says so directly: Microsoft did not say how many customers were compromised.
Huntress gave reporters a different measure over a different window. CyberScoop on October 20 quoted Jonathan Semon, a principal security operations analyst at Huntress: sign-in activity from the malicious infrastructure appeared across almost 1,000 Entra tenants, with more than 300 of those sign-ins appearing to succeed, and Huntress confirmed unauthorized sign-ins in 162 tenants. BleepingComputer on October 17 reported Huntress saying it had identified at least 162 compromised tenants, and that across nearly 50 tenants it monitors, service principals for ConnectWise’s Cloud Management apps assigned themselves directory roles, mostly Exchange Administrator. ConnectWise itself published only the disablement time for seven application identities, with no tenant count.
The four numbers mean four different things: 2,250 were attempted, almost 1,000 showed sign-in activity, more than 300 appeared to succeed, and 162 were confirmed. They are not interchangeable, and all of them are one-sided or lower bounds: Microsoft gave no compromise count, and Huntress said it sees only a subset.
Checking your own tenant
If you run Microsoft 365 tenants, note that Microsoft’s hunting queries and ConnectWise’s guide do not list the same applications. The table follows the 04:01 UTC revision of October 22, which cut every application-ID array in the hunting queries to three. The sentence above them still says “Inventory all four application IDs,” so trust the arrays.
| Application | Client ID | Appears in |
|---|---|---|
| ConnectWise Cloud Backup | 506e08f9-6e9a-4da4-942b-a099a03644ae | Both lists |
| Cloud Management - MS Teams | 24205314-2b89-4e07-a2a4-579e898a5640 | Both lists |
| Cloud Management - MS Graph | 0de14c77-b9b0-4137-9360-34878a929827 | Both lists |
| Cloud Management (main application) | 2399d300-6fca-4e6a-a686-399fefe75b83 | ConnectWise only |
| Cloud Management - Exchange Online | b78f6a77-d4e5-46fb-87e5-d1648bd02519 | ConnectWise only |
| Cloud Management - Partner Center | 412dcf96-176d-4b3a-a1b0-4981ad66971e | ConnectWise only |
| Cloud Management - SharePoint Online | b2b55f5b-7758-4719-8d8f-88ae172e6bdb | ConnectWise only |
The two lists now overlap on all three of Microsoft’s IDs, and the union is seven: Microsoft has no ID that ConnectWise’s table lacks. Running only Microsoft’s three IDs misses the main Cloud Management application, Exchange Online, Partner Center and SharePoint Online. Matching on the ID matters for another reason too. Display names differ: Microsoft’s query comments call two of those IDs “ConnectWise - MS Teams” and “ConnectWise - MS Graph”, while ConnectWise’s table calls them “Cloud Management - MS Teams” and “Cloud Management - MS Graph”.
The previous revision, the one marked 00:54 UTC on October 22, carried a fourth ID: SkyKick Partner Portal, c921256f-04a7-44e8-9b2a-69c33929ba19. It appears four times in each of the Wayback captures from 18:42 and 22:44 on October 21 and 02:03 on October 22, and zero times in the 04:46 capture, which shows the same 04:01 timestamp. Microsoft did not say why it was removed, and the page carries no note about it. Figure 1 on the same page still reads “using 4 application credentials,” sitting alongside the three-ID arrays; Microsoft does not explain the mismatch. If you ran this checklist late on October 21 or early on October 22, that fourth entry was part of the list you used.
Microsoft’s other instructions: search by application ID rather than display name; disable rather than delete so configuration and evidence survive; review activity from at least October 15, extending to October 1 where records exist; and read service-principal sign-ins together with Graph activity and directory changes. ConnectWise’s guide adds two points worth repeating. Vendor-side containment does not change the enterprise-application configuration inside any tenant, so every tenant needs its own check. And previously issued tokens may remain usable until they expire or are invalidated. Entra keeps sign-in and audit records for seven days on Free and 30 days on P1/P2; a license upgrade does not recover history that has already expired.
Our take
The distinction that matters in Microsoft’s attribution is between AI-accelerated and AI-caused. The password spray left 151,000+ failure records and achieved nothing. The stolen application credential is what opened the door. What ARTEX changed was the speed after that credential was in hand: cross-tenant authentication, Graph reconnaissance, credential additions and role changes compressed into minutes, leaving defenders too little time to coordinate between an alert and a response.
One gap remains: how the ConnectWise credential was taken. Microsoft does not say, and ConnectWise declined to answer that question when CyberScoop asked. So the evidence supports “ARTEX was used downstream,” not “ARTEX broke ConnectWise.”
The tool also has a prior outing. Microsoft’s own report notes that in October 2026 public reporting tied ARTEX to the personal data breaches at South Korean financial institutions. Recorded Future’s Insikt Group tracks the actor behind those attacks as TAG-217 and found it testing infrastructure and assembling tools as early as August 2026; per the public reporting that report cites, the breaches exposed personal data belonging to at least 68,000 people across at least seven institutions. Microsoft and Recorded Future gave the two campaigns separate designations and neither says whether the same people were behind both. What is settled is that one framework served two operators in a month.
For readers, the lesson lands on identity governance rather than model defense. A multi-tenant application shared with a third party, long-lived application credentials, and a backup tool installed across hundreds of tenants are the three things that compounded here. If you do one thing, search each tenant by application ID and confirm that integrations you stopped using are actually disabled.
We have covered adjacent failures before: Cairn agent panels used in intrusions and LiteLLM’s compromised release chain. In all three the credential, the panel or the release chain fell first, and the agents widened the damage afterward, which is the same point CSO Online’s post-mortem makes.
Worth watching next: whether ConnectWise’s phased restoration holds to its word, whether any tenant confirms data was read, and whether Microsoft ever publishes a compromised-tenant count.