Storm-0940 Used ConnectWise Apps to Target 2,250 Microsoft 365 Tenants, Microsoft Says

Start with the correction. Microsoft says Storm-0940 used ARTEX to attempt sign-ins to more than 2,250 tenants, at up to 2,900 sign-in attempts per minute. That is a count of targets, not breaches. CybersecurityNews put it the same way: the actors used ARTEX to attempt access to more than 2,250 Microsoft 365 tenants following the ConnectWise Cloud Backup breach. Microsoft says most of the targeting failed. Even so, the actor got privileged cloud persistence at "many" organizations in a short time. If your tenant ever authorized ConnectWise Cloud Backup (formerly SkyKick), you should be hunting right now.

What Microsoft actually disclosed​

Microsoft says the ARTEX activity began as early as September 2026, targeting hundreds of organizations around the world. The report adds that several of these Storm-0940 ARTEX-driven attacks have resulted in the actor obtaining privileged access to an organization's cloud infrastructure – including multiple instances where the time from initial targeting to privileged access was less than 3 hours.

The targets cover aerospace and defense, automotive, chemicals, energy, financial services, government, legal, manufacturing, media, military, semiconductors, software, technology, and think tanks and nonprofits. According to Microsoft, Storm-0940 is a China-state aligned actor (with no known industry aliases) that has been active since 2021 and targets organizations across multiple industries for data theft. Its usual playbook includes password spraying and exploitation of internet-facing applications. In cloud environments, it has also added credentials to existing OAuth apps for persistence and used Microsoft Graph to pull out mail and other data.

The new part is the automation. Microsoft says that in multiple affected environments it saw AI-accelerated follow-on activity through Microsoft Graph, including reconnaissance, application credential changes, and attempts to modify privileges that could enable expanded or persistent access. Microsoft also states that the activity did not come from a compromise of, or vulnerability in, its own systems or products.

Section summary: Microsoft attributes the campaign to a China-aligned group. Over 2,250 tenants were targeted, not all were compromised, and the fastest cases went from first contact to privileged access in under three hours.

Phase one: a password spray that failed​

Between October 10 and 14, Microsoft saw infrastructure at 144.172.64[.]99 run an automated cross-tenant password-spray campaign targeting 327 accounts across eight organizations to gain access to Microsoft 365 and Exchange Online. Telemetry recorded more than 151,000 failed logons. Activity peaked on October 11 at 2,900 failures per minute, with more than 111,000 failures in that one day. Forty-eight accounts each took more than 1,000 failed attempts, and lockout responses made up nearly 98% of all events.

None of it worked. Microsoft observed no successful authentication, token issuance, Graph call or directory change in this phase. Smart lockout and MFA held up. The 2,900-per-minute figure is a peak rate, not a constant pace across the whole campaign.

Phase two: the vendor's key opened the door​

On October 15, reports of the ConnectWise compromise appeared with indicators in the same 144.172.64.x range. Microsoft says the actor's AI agents took control of several ConnectWise cloud application identities. They then authenticated to customer tenants through those apps' existing authorization, using the trust each tenant had already granted. In some environments the agents went on to Graph reconnaissance, application credential changes, and changes to identities, groups and privileged roles.

Neither Microsoft nor ConnectWise has said publicly how the vendor-held credential was first obtained. That is the biggest open question in this story. ARTEX made the abuse faster, but the evidence does not show that the AI caused the original credential theft.

Three security vendors have published what they saw in their own telemetry. Each view is limited to their own customers, so the numbers don't add up to one total:

• Huntress saw almost 1,000 Entra tenants with sign-in activity from 144.172.64[.]128, and more than 300 of those sign-ins succeeded. In one tenant, between 03:44 and 03:49 UTC on October 15, the ConnectWise Cloud Management app for Teams added itself to the Global Administrator role. It then ran a Python script that added client secrets to two other applications, one of them Huntress's own. Those secrets were set to expire in 2028. Huntress says the credential additions came from private Azure IPv6 space, not the 144.172.64[.]128 address.
• Huntress also flagged a second, targeted wave on October 15 against 16 tenants in the policy, national security, trade and critical minerals sectors. Most of those attempts failed because the ConnectWise service principal wasn't installed there.
• Sophos X-Ops saw an app-only Graph token sweep from 07:11 to 08:47 UTC on October 15. The requests came in ascending tenant-GUID order, one to six minutes apart, and included tenants with no active backup subscription. In the tenants Sophos reviewed, it found no new secrets, apps, consents or role assignments.

A few of the most-shared details deserve caution. Huntress did report about 50 tenants where ConnectWise Cloud Management service principals assigned themselves directory roles, mostly Exchange Administrator. But Huntress notes those events carried the kiota-dotnet user agent that ConnectWise's own apps use, which points to vendor automation, and it hasn't confirmed either way. Treat those 50 as unresolved, not as confirmed victims. Huntress's 06:13–08:34 UTC window covers authentications in 17 of roughly 290 tenants it checked. The tightly sorted, machine-paced sweep comes from Sophos's separate observation.

Section summary: The spray failed. The stolen vendor credential worked. At least some tenants received backdoor credentials that will survive simply disabling ConnectWise's apps.

Why MFA never came into it​

"MFA bypassed" makes a good headline, but that isn't what happened. Microsoft's Entra documentation explains that service principal sign-ins involve no user. The app or service authenticates with its own credential, such as a certificate or client secret. Sophos confirmed the sign-ins it saw required no user password and no MFA, because the actor authenticated as the application itself.

Microsoft says the same: abusing the already-authorized apps allowed the threat actor to operate without requiring an interactive user sign-in. No second factor was defeated, because no second factor applies to an app signing in with its own secret.

So the controls that matter are app permissions, credential protection and watching service principal activity. Those sign-ins are recorded in their own service principal sign-in log. If you only look at the regular user sign-in view, you won't see them.

What ARTEX is, and what it isn't​

Microsoft describes ARTEX as an open-source, multi-agent LLM framework written in Go with a Next.js frontend. It can use any AI model and can run a penetration test from reconnaissance through data exfiltration with little human involvement, collecting discovered assets and vulnerabilities in a graph as it goes. The interface defaults to English and can switch to Korean, Mandarin, Spanish or Japanese. CybersecurityNews notes that ARTEX is a security-testing framework, not a newly discovered malware family.

Microsoft says it has seen threat actors in multiple regions using ARTEX. Zscaler published separate ARTEX research the same day, but CybersecurityNews reports that Zscaler examined a Chinese-speaking operator's broader workflow without establishing that both investigations covered the same actor. Some claims in the original coverage are not backed by the primary sources available here: specific planner/worker agent internals, a CrowdStrike quote, and a Five Eyes advisory. Treat them as unverified.

What to do now​

The guidance below comes from Microsoft, ConnectWise, Huntress and Sophos:

1. Keep ConnectWise connections disabled. ConnectWise disabled seven application identities at 07:00 UTC on October 17. As of its October 21 update, Cloud Backup, SaaS Security and Cloud Management were still suspended, so backup jobs, archive access and restores are unavailable. ConnectWise says stored archives remain encrypted and isolated with no sign of compromise. It also stresses that this says nothing about whether any individual tenant was affected.
2. Don't delete the enterprise apps first. Sophos recommends removing consent, while Microsoft warns against deletion as a first move. Both can be right: preserve configuration and logs first, then let authorized responders remove access.
3. Inventory by application ID, not display name. Older tenants may show SkyKick names. Record each local service principal object ID.
   • ConnectWise Cloud Backup: 506e08f9-6e9a-4da4-942b-a099a03644ae
   • ConnectWise – MS Teams: 24205314-2b89-4e07-a2a4-579e898a5640
   • ConnectWise – MS Graph: 0de14c77-b9b0-4137-9360-34878a929827
   • SkyKick Partner Portal: c921256f-04a7-44e8-9b2a-69c33929ba19
4. Hunt in service principal sign-ins. Start from at least October 15 and go back to October 1 if your retention allows. Review successful and failed sign-ins separately. Huntress specifically flags 01:00 UTC October 15 through 02:00 UTC October 16.
5. Use the indicators as leads, not proof.
   • IPs: 144.172.64[.]60, 144.172.64[.]99 and 144.172.64[.]128
   • 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
   • Microsoft also lists transient VPN IPs 187.15.88[.]186, 187.15.90[.]217 and 187.15.89[.]186 for the October 15–16 window
   • Because of Huntress's IPv6 finding, an IP-only search can miss the persistence step entirely.
6. Audit Entra changes. Look for new credentials on apps and service principals, new apps, owners, consent grants, app-role assignments, privileged role assignments, and changes to users, groups, authentication methods and Conditional Access. A secret planted to expire in 2028 doesn't go away when the ConnectWise app is disabled.
7. Check Microsoft 365 audit data. Look for unusual directory or permission listing, mail and file access, downloads, forwarding, inbox or transport rules, and delegated mailbox permissions.

For the longer term, Huntress points to Entra application management policies that restrict client secrets and cap their lifetimes. It also recommends limiting who holds the Application Administrator and Cloud Application Administrator roles, using Conditional Access for workload identities (this needs extra licensing), and turning on ID Protection's risky service principal detection.

The bigger picture​

A widely approved, highly privileged third-party app is effectively a shared key to every tenant that trusts it. Kaseya showed this in 2021. This campaign adds speed. The question for every MSP and tenant admin isn't whether MFA is on. It's which apps can act in your tenant without asking anyone, and whether you'd notice if one of them made itself Global Administrator at 3:44 a.m.

One more caution from Microsoft: finding an affected app, or even a successful sign-in, doesn't prove data was accessed or exfiltrated. A clean search doesn't prove you're safe either. Check each tenant on its own evidence.