Storm-0940 reached 2,250 tenants with app credentials, not passwords.

The password spray in this campaign failed completely. What worked was an app credential. On 21 October 2026, Microsoft Threat Intelligence published its account of a campaign it attributes to Storm-0940, a China-state aligned actor: the group drove an open source agent framework called ARTEX, took control of several ConnectWise cloud application identities, and used them to attempt sign-ins to more than 2,250 Microsoft 365 tenants. No person signed in anywhere along that path.

#What Microsoft published

Storm-0940 is not a new name. Microsoft has tracked the group since at least 2021, and its usual tradecraft is password spraying and exploiting internet-facing applications. The new element is the tooling. Microsoft says the group used ARTEX, which it describes as an open source agentic penetration testing framework written in Go, running a multi-agent system over any AI model, able to carry a test from reconnaissance through to data exfiltration with little human involvement. Microsoft adds that it has seen several threat actors in different regions using it.

The spray itself is worth reading as a control group. Between 10 and 14 October, infrastructure at a single address sprayed 327 accounts across eight organisations, producing more than 151,000 failed logons. Microsoft states it observed no successful authentication, no token issuance, no Graph call and no directory change from that campaign.

Microsoft also states plainly that the activity did not result from a compromise of, or a vulnerability in, Microsoft corporate systems, products or services. The entry was somewhere else.

#The access path, step by step

# as published by Microsoft Threat Intelligence and SpecterOps
ARTEX agents  # recon, credential attacks and exfiltration, largely unattended
  → app credential  # identities of several ConnectWise cloud applications
  → Entra tenant    # app-only sign-in on consent the tenant already granted
  → Microsoft Graph # recon, credential additions, role and group changes
  → Key Vault secrets # bulk secret reads, key enumeration, key unwrapping

ConnectWise confirmed unauthorised access to application identities in its Cloud Backup environment and turned off Cloud Backup, SaaS Security and Cloud Management connections. In comments reported by The Register, CEO Manny Rivelo said the affected connections had been contained and services were being restored gradually, while acknowledging that shutting those connections would not necessarily remove an attacker already inside a customer environment. That last point is the whole problem in one sentence.

#The credential MFA does not apply to

The reason this path worked is structural, not clever. SpecterOps points out that the credential belongs to the application, not to a person, so MFA does not apply to it. The application signs in on its own behalf and inherits exactly the permissions the tenant granted it. For a backup product those permissions are broad by design: it must read mailboxes, OneDrive and SharePoint content, Teams data and directory information in order to back any of it up.

That is the entire escalation. There was no exploit between the credential and the data. The grant was the reach.

Persistence followed the same logic. Microsoft describes application credential changes made for persistence, along with changes to identities, groups and privileged roles. SpecterOps reports that in one tenant a second ConnectWise application granted itself Global Administrator and added client secrets to two other trusted applications, which leaves a way back in even after the original credential is reset. A password reset does nothing here. Neither does disabling one app, if the attacker has already written credentials into three.

#What the agents actually added

It would be easy to read this as an AI story. It is more useful to read it as an identity story with an AI throttle setting.

Nothing in the path above is a new technique. Multi-tenant application credentials, consent already granted, Graph reconnaissance, secrets read out of a vault: all of that was in the playbook before any of it was automated. What the agents changed is the rate. Microsoft reports over 200 sign-ins in under four minutes using four application credentials, and describes attacks that went from target selection to privileged cloud access in under three hours. Agents work continuously and try several routes at once.

The implication is simple. Controls that assume an attacker needs days to find the useful grant now have hours. If your review of which applications hold which permissions is an annual exercise, the attacker iterates faster than your inventory does.

#What to check this week

1. Keep the affected ConnectWise application connections disabled until ConnectWise publishes formal restoration instructions. SpecterOps notes that tokens already issued can stay valid for up to 90 minutes after you disable an app.
2. Inventory by application ID, not display name. Microsoft is explicit about this. Record the local service principal object ID in each tenant, and review every tenant where the apps were installed or authorised, including ones you no longer use.
3. Preserve the logs before you remove anything. Entra sign-in and audit logs, Purview audit records, SIEM data and Graph telemetry. Microsoft recommends reviewing activity from at least 15 October, and extending service principal sign-in review back to 1 October.
4. Review credential additions across all applications. Any client secret or certificate added to any app since mid-October deserves an explanation. This is where persistence lives, and it survives rotating the credential that was stolen.
5. Review successful and failed service principal sign-ins separately, and do not limit the review to published IP addresses. A list of indicators is a starting point, not a scope.
6. Then ask the structural question. For every multi-tenant application with standing consent, what would its credential reach if someone else held it? If you cannot answer that, the answer is whatever the vendor asked for at install time.

#FAQ

Every multi-tenant application with standing consent is a non-human identity with a reach nobody measured at install time. Elmoz maps those identities and shows what each grant actually reaches, so the question above has an answer before someone else asks it.