Microsoft Ties the ConnectWise Attacks to a China-Aligned Group and the ARTEX AI Framework, Citing 2,250 Tenants Targeted but No Count of Compromises
Microsoft says the China-aligned group Storm-0940 used the ARTEX AI framework to attempt sign-ins to more than 2,250 tenants with stolen ConnectWise credentials, but it publishes no count of...
On October 21, Microsoft published a report that ties the ConnectWise Cloud Backup compromise to Storm-0940, which it describes as a China-state aligned actor, and to ARTEX, an open-source AI penetration-testing framework. ConnectWise’s FAQ now says that, based on evidence “including threat intelligence shared by Microsoft,” it “appears that a China state-aligned group was responsible for the attack on ConnectWise Cloud Backup.” Microsoft’s report says the actor used ARTEX “to attempt to sign-in to more than 2,250 tenants” with the stolen application credentials. It does not say how many tenants were compromised, how the credentials were obtained, or which indicators are specific to ARTEX, and ConnectWise says the credential-exposure mechanism “remains under investigation.”
Table Of Content
- What Microsoft says it saw
- What ConnectWise says now
- The counts come from different vantage points
- Where the accounts do not line up
- The speed figures
- The link between the spray and the app sign-ins
- AI agents or scripts
- Headlines and the text
- Which applications
- What to check now
- What is still unknown
- Sources and method
This follows our October 17 report, when the public count was 162 tenants with confirmed unauthorized sign-ins and none of the sources we cited had named an actor. The new figures are larger, but they come from different vantage points and measure different things, and the coverage has already blurred them: TechCrunch says the hackers “used AI agents to rapidly hack into around 2,250 organizations,” while Microsoft’s text says they attempted to sign in. The figures here are as of 19:21 UTC on October 22, when we last re-read the sources. ConnectWise’s latest advisory update is timed 13:00 UTC and says the next will come by 01:00 UTC on October 23. For administrators, the practical points are at the end: ConnectWise’s full list of application IDs, the persistence checks, and a log-retention clock that may already be running out.
What Microsoft says it saw
Microsoft describes Storm-0940 as “a China-state aligned actor (with no known industry aliases) that has been active since 2021.” It says the group used ARTEX “as early as September 2026” against “hundreds of organizations globally,” and that during the ConnectWise compromise it used the framework “to accelerate scanning and reconnaissance, password spraying, and OAuth application abuse at downstream victims.” ARTEX, in Microsoft’s words, is “an open-source penetration testing framework that can use any AI model,” “written in GO with a Next.js frontend,” and Microsoft says it has “identified threat actors across multiple geographic regions leveraging the ARTEX framework.” The post also notes that October reporting tied ARTEX to the breaches at Korean financial institutions, which we covered in our report on CrowdStrike’s findings. In that report we noted that the developer said on October 8 that the project “will no longer be updated and will be converted to a closed source.”
Before the ConnectWise credential showed up in customer logs, Microsoft says, infrastructure in the same address range ran a password spray. Between October 10 and 14, an address it gives as 144.172.64[.]99 targeted 327 accounts at eight organizations, producing “151,000+ failed logon events” and peaking on October 11 at 2,900 failures a minute. Microsoft says “no successful authentication, token issuance, Graph call, or directory change was observed” from that campaign. It links the spray to ConnectWise by address: ConnectWise’s advisory, it says, “shared later additional indicators with one IP address matching exactly the 144.172.64[.]99 infrastructure responsible for the earlier password-spray campaign.” In ConnectWise’s advisory, that address first appears in the update of October 18 at 18:45 UTC, marked NEW.
Once the actor held ConnectWise’s application credentials, Microsoft says, it signed in to customer tenants “through applications that had already been granted access,” so no interactive user sign-in was needed. In “multiple affected environments” it saw follow-on activity through Microsoft Graph, “including reconnaissance, application credential changes, and attempts to modify privileges.” Its detection list includes an alert titled “Application self-assigned Global Administrator role,” and its ATT&CK table describes “self assignment of global admin from one of the ConnectWise Management Application.” Microsoft warns that the credential changes “can remain active as a backdoor” even after the compromised application itself is dealt with.
The speed claim covers ARTEX attacks in general, not only this incident. “Several” of the ARTEX-driven attacks gave the actor privileged cloud access, Microsoft says, “including multiple instances where the time from initial targeting to privileged access was less than 3 hours,” and it adds that “the majority of the targeting wasn’t successful.” The post does not say how many of those attacks involved ConnectWise’s applications.
What ConnectWise says now
ConnectWise’s FAQ dates its discovery of the problem to October 14, 2026, and says it then “initiated internal and external incident investigation and response actions.” It says that at 07:00 UTC on October 17 it “disabled the seven ConnectWise application identities” listed in its technical guidance, which is more than two days after the discovery date it gives (our arithmetic; it does not give a time on October 14). A “full reset of all accounts and credentials in the affected Cloud Backup environment” followed on October 19. Its update of October 21 at 00:30 UTC still listed Cloud Backup, SaaS Security and Cloud Management as suspended. By 12:45 UTC it said it had begun restoring services in controlled phases, a process it expects to take “several days,” and it cautions that “the start of restoration does not mean all capabilities are available.” Its latest update, on October 22, says it will share service-specific reconnection instructions “as they are confirmed,” and it says: “We have no indication that other ConnectWise products, services or offerings are impacted by this incident.” It also says its measures “do not remove unauthorized access that may already have been established within individual customer tenants.”
The counts come from different vantage points
Each firm sees only the tenants whose logs it can read, and each counts something different.
| Source and date | What the figure counts | Figure |
|---|---|---|
| Huntress, as of 19:00 UTC on October 16 | Tenants with “confirmed unauthorized sign-ins” | 162 |
| The Hacker News, citing Huntress | Partner and customer tenants with confirmed unauthorized sign-ins | 173 |
| Huntress, update of October 17 (5:15 PM ET, which is 21:15 UTC) | Entra tenants with sign-in activity from 144.172.64[.]128 |
almost 1,000, of which “Over 300 of those succeeded” |
| Huntress, update of October 19 (1:30 PM ET, which is 17:30 UTC) | Tenants with ConnectWise applications whose sign-in logs Huntress can see (the pool it reviewed, not a victim count) | more than 10,000 |
| Huntress, update of October 19 | Tenants where it saw post-compromise activity (the application granting itself Global Administrator and planting new secrets) | two |
| Microsoft, October 21 | Tenants where Storm-0940 attempted to sign in (text) or that were “reached with app-only sign-ins” (Figure 1) | more than 2,250 |
These are not one number growing. Huntress’s figures come from tenants it monitors, and as of October 19 it had seen post-compromise activity in two of them. Microsoft operates Entra, so its view is not limited to a customer base, but the post does not say how the 2,250 was measured, its text describes attempts rather than outcomes, and its count of environments with follow-on activity is “multiple.” ConnectWise says: “We have not identified confirmed downstream customer compromise,” and adds that “the absence of confirmed compromise is not assurance that no unauthorized activity occurred.” That is a statement about what ConnectWise’s own investigation has found, while Microsoft and Huntress are describing what they see inside customer tenants.
Where the accounts do not line up
The speed figures
Microsoft’s text says Storm-0940 attempted sign-ins to “more than 2,250 tenants at 2,900 sign-in attempts per minute.” The same post gives 2,900 as the October 11 peak of failed logons in the password spray. Figure 1 shows “2,900 attempts per minute” as its own tile, with no label saying which activity it measures, beside a separate tile for the app-only sign-ins: “200+ sign-ins in under 4 minutes using 4 application credentials.” That works out to more than 50 a minute during that burst (our arithmetic: 200 divided by 4), well below 2,900. The post does not reconcile the two. TechCrunch (“almost 3,000 attempted sign-ins per minute”) and The Register (“at times reaching 2,900 attempts a minute”) repeated the text’s version.
The link between the spray and the app sign-ins
Huntress’s October 19 update checked the neighboring addresses against its data. It reports that “144.172.64[.]128 and Microsoft-internal ranges are the only addresses that produced application sign-in activity” across “more than 10,000 tenants with ConnectWise applications (where we can see those logs).” It lists 144.172.64[.]99 as a “Failed user password spray, concentrated (October 10 to 14),” the same dates Microsoft gives, and 144.172.64[.]60 as “A few failed user logins (October 18),” and it says: “At this time, we do not believe those attempts are related to the application sign-ins described in this post.” Microsoft’s indicator table lists all three addresses as “seen performing Sign-ins and Graph API activity in customer environments of ConnectWise apps.” Two firms with different telemetry can both be right, but the public record does not yet explain why one connects the spray to the app sign-ins and the other does not. Huntress’s post had not been updated since October 19 when we last read it, so its view predates Microsoft’s report by two days.
AI agents or scripts
Microsoft states that ARTEX agents drove the activity and calls the follow-on activity “AI-accelerated.” The indicators it publishes are generic: three IP addresses, three VPN addresses, and the user agents Python-urllib/3.12, python-requests/2.31.0, python-requests/2.34.2, curl/7.88.1 and azure-toolkit/1.0. The post does not label any of them as specific to ARTEX, and it does not say what Microsoft saw that distinguishes agent behavior from a conventional script.
Huntress, which read the logs in its own tenants, describes scripted behavior. It says the actor “moved through tenants in sorted GUID order, a few seconds apart, which points to a script working from a target list.” In the two tenants where it saw post-compromise activity, the behavior was “fast, scripted, and notably indiscriminate”: the application “granted itself Global Administrator, then planted a new secret on a small number of other applications,” and the choice of applications “appeared to be random.” In a second, targeted wave against 16 tenants that Huntress says was unsuccessful, the later sweep “appeared to be manual.” None of that rules out ARTEX, which Microsoft describes as running “an autonomous penetration test from reconnaissance through data exfiltration with little needed human interaction,” and Microsoft has telemetry that outsiders cannot see. It does mean the public evidence for the AI part is Microsoft’s assessment, not something a reader can check from the published indicators.
Headlines and the text
TechCrunch’s headline says Chinese hackers “spied on thousands of companies,” and The Register’s says the breach “let Chinese spies loose on 2,250 cloud tenants.” Microsoft’s text says the actor attempted sign-ins, says of its ARTEX attacks overall that “the majority of the targeting wasn’t successful,” and says “the presence of an affected application or successful threat actor authentication does not necessarily indicate that customer data was accessed or exfiltrated.” The Register’s own article says Microsoft “hasn’t disclosed how many customers were compromised or whether any data was stolen.”
Which applications
ConnectWise’s count is seven application identities, and one FAQ answer names an eighth ID. Microsoft’s text tells administrators to “Inventory all four application IDs listed in this profile,” Figure 1 says “4 application credentials,” and its three sample hunting queries search only three IDs. Two of those are labeled ConnectWise - MS Teams and ConnectWise - MS Graph where ConnectWise’s guide calls them Cloud Management - MS Teams and Cloud Management - MS Graph. Huntress said on October 17 that it had “high-confidence” the actor also abused the Cloud Management apps for Exchange Online, Teams and SharePoint Online, and two of those three are absent from Microsoft’s queries. We could not check which four IDs Microsoft’s own threat analytics profile lists, because it sits inside its portal.
What to check now
Both vendors say to keep the ConnectWise applications disabled until ConnectWise issues formal restoration instructions, and to disable rather than delete them. Microsoft’s words: “Do not delete enterprise applications as the first response.” ConnectWise’s guide says to match on Application ID rather than display name, because older installations may show SkyKick Cloud Manager names. The table below is ConnectWise’s published list, with a column showing whether Microsoft’s three sample queries cover each ID.
| Application | Application ID | In Microsoft’s three sample queries |
|---|---|---|
| ConnectWise Cloud Backup | 506e08f9-6e9a-4da4-942b-a099a03644ae |
Yes |
| ConnectWise Cloud Management | 2399d300-6fca-4e6a-a686-399fefe75b83 |
No |
Cloud Management - MS Teams |
24205314-2b89-4e07-a2a4-579e898a5640 |
Yes |
Cloud Management - Exchange Online |
b78f6a77-d4e5-46fb-87e5-d1648bd02519 |
No |
Cloud Management - MS Graph |
0de14c77-b9b0-4137-9360-34878a929827 |
Yes |
Cloud Management - Partner Center |
412dcf96-176d-4b3a-a1b0-4981ad66971e |
No |
Cloud Management - SharePoint Online |
b2b55f5b-7758-4719-8d8f-88ae172e6bdb |
No |
| The ID in ConnectWise FAQ answer 15 (no name given) | c921256f-04a7-44e8-9b2a-69c33929ba19 |
No |
Look for what the actor may have left behind, not only the sign-ins. Huntress warns that “Disabling M365 apps, including the abused ConnectWise apps will not remove credentials that were already added.” Microsoft’s review list includes application or service-principal credential additions, new app-role assignments and consent grants, and privileged role assignments, and the Defender alert “Application self-assigned Global Administrator role” covers a pattern both firms describe. Huntress’s example was a Cloud Management app that gave itself Global Administrator and then planted new secrets on other applications in the tenant.
Check how far back your logs go. ConnectWise’s guide says “Entra normally retains audit and sign-in records for seven days on Free and 30 days on P1/P2,” and Microsoft’s retention page lists seven days for audit logs and sign-ins on the Free edition. Seven days before this post’s as-of time is 19:21 UTC on October 15, which is after the Cloud Backup sign-ins Huntress and Todyl logged on the morning of October 15 (06:13 to about 08:47 UTC) and after the role changes Huntress saw in two tenants around 03:45 UTC. On a strict rolling window, a Free-edition tenant may already have lost those records (our arithmetic; Microsoft’s page does not define the cutoff). The Microsoft 365 Unified Audit Log is separate: the same page says its retention is managed through Purview Audit and “is not affected by Microsoft Entra ID licensing changes.” Microsoft’s advice is to preserve what exists, review activity “starting from at least October 15, 2026,” extend the review to October 1 where records allow, and “not delay urgent containment while waiting for exports.”
What is still unknown
Four questions remain open in the public record. First, how the credential was obtained: ConnectWise says whether a product vulnerability contributed “has not been established.” Second, how many tenants ended up with persistent privileged access: Huntress counts two in its own data, while Microsoft gives “many organizations” for the ARTEX campaign overall and “multiple” environments for ConnectWise, with no number. Third, what in the logs separates ARTEX activity from a script. Fourth, whether the neighboring addresses 144.172.64[.]99 and 144.172.64[.]60 were part of the ConnectWise intrusion, which Microsoft’s table says they were and Huntress says it does not believe. ConnectWise’s next advisory update is due by 01:00 UTC on October 23.
Sources and method
We read Microsoft’s report (its page metadata gives October 21 at 18:23 UTC as the publication time and October 22 at 04:01 UTC as the last modification), ConnectWise’s Trust Center advisory with its FAQ and technical guide, Huntress’s post with its dated updates, Todyl’s post, TechCrunch, The Register, The Hacker News and Microsoft’s Entra retention page. Huntress’s page answers plain scripted requests with HTTP 403, so we read it through a text-extraction tool. Figure 1 in Microsoft’s post is an image, and we read its labels by eye. We did not test anything in a Microsoft Entra tenant, did not run or look for ARTEX, and do not link to it. Times are UTC, and Huntress’s Eastern times are converted with the October offset of four hours. The arithmetic (200 sign-ins in under 4 minutes, the seven-day cutoff, the days since discovery and the application ID counts) is ours. For the earlier reporting, see our October 17 report and our ARTEX report.








No Comment! Be the first one.