Storm-0940 Used ARTEX Agents Against 2,250 Microsoft 365 Tenants

Microsoft disclosed on October 22 that China-state-aligned Storm-0940 exploited the ConnectWise Cloud Backup supply chain using ARTEX, a Go-based agentic pentest framework. Between October 10 and 14, Microsoft says ARTEX agents ran password sprays at 2,900 attempts per minute against 2,250 Microsoft 365 tenants, generating 151,000 failed logins.

By October 15, according to Microsoft, the agents had taken over ConnectWise application identities and begun authenticating into customer environments. The activity pivoted to Microsoft Graph operations and privilege changes. That progression makes this a review of delegated application trust as well as a report about automated authentication attacks.

The 2,250 figure describes tenants targeted, not a verified total of tenants compromised. Similarly, 151,000 failed logins is an activity count rather than a successful-access count. A buyer deciding how to respond needs those definitions intact. Large targeting numbers can establish scope for investigation without establishing the outcome in every environment.

The application identity is the critical trust boundary

The October 15 transition from password sprays to application-identity takeover changes the question defenders need to ask. Reviewing failed logins alone would leave the reported customer-environment authentication unexplained. A relevant investigation should also examine which application identities could authenticate and what authority those identities carried. That is a defensive review priority derived from Microsoft's sequence, not a claim about every customer's exposure.

Microsoft's October 22 account names the ConnectWise Cloud Backup supply chain as the route exploited. For a customer, the important dependency is not simply the software vendor's presence in an inventory. It is the relationship between that integration and the customer's environment. An application-trust review should describe what access is intended and whether the observed identity activity is consistent with that purpose.

The reported pivot to Microsoft Graph operations and privilege changes by October 15 gives reviewers a specific category of post-authentication behavior to examine. The supplied facts do not identify particular Graph calls or exact privileges changed. Do not invent those details in a detection plan or incident summary. Ask the responsible analyst to establish them from the organization's evidence and the applicable disclosure.

Rate, volume and targeting are different measurements

The 2,900-attempts-per-minute figure is a reported attack rate. It is not evidence that the same rate continued throughout October 10–14. The 151,000 failed-logins figure describes observed volume in the reported activity. Multiplying the rate across the entire window would produce a new and unsupported total, rather than clarify what Microsoft actually disclosed.

The 2,250 targeted Microsoft 365 tenants likewise should not become a denominator for an invented compromise rate. The supplied facts say application identities were taken over and customer authentication began, but do not give a count of successfully accessed tenants. Your own exposure decision needs evidence about your integration and identities, not an estimated outcome inferred from the targeting population.

ARTEX's role in the October 22 disclosure is concrete: Microsoft says agents using the framework conducted the activity. The supplied account does not provide a model name, a model-provider attribution or a comparison with a non-agent attack. An accurate assessment can identify agentic tooling as part of the attacker's capability without claiming a measured productivity gain or inventing which model drove the framework.

The trade-off is reviewing trust without inventing exposure

The October 10–15 sequence supports a focused review, but it does not justify declaring every ConnectWise customer compromised. A security owner should establish whether the relevant integration and application identities exist in the environment before drawing an exposure conclusion. That work can be less immediately dramatic than repeating the tenant figure, yet it is the necessary connection between a public report and an internal response.

Application identities implicated by October 15 also make broad access changes a decision requiring care. A reviewer should establish the identity's legitimate function before recommending permission changes or containment to the authorized owner. The supplied report does not prescribe a universal revocation action. A response should connect an identified risk to the actual integration rather than imply that the news alone specifies a safe configuration change.

The 151,000 failed logins are useful evidence of attack activity, not assurance that authentication defenses prevented the later access. Conversely, the reported application takeover does not establish that every failed-login target was eventually reached. A disciplined incident record keeps those observations separate while investigating their connection. That prevents both premature reassurance and an unsupported expansion of the confirmed breach.

What To Do About It

• Inventory the integration: Ask the Microsoft 365 owner to establish whether ConnectWise Cloud Backup and its application identities are present, then document their intended access. Use the named dependency as a scoping question rather than marking every tenant affected by Storm-0940.
• Review the activity window: Have an authorized analyst examine relevant authentication records and preserve the distinction between attempts and successful access. Start the scoped historical review with the period Microsoft identifies for password spraying, October 10–14.
• Inspect application authority: Ask the identity owner to review applicable application permissions and any evidence of changes. Compare actual behavior with the integration's intended function, giving particular attention to the access Microsoft describes by October 15.
• Correlate post-authentication evidence: Connect relevant application authentication to observed Graph activity and privilege changes before declaring impact. Do not fill missing evidence with a tenant-wide assumption; inspect the operations reported by October 15 in Microsoft Graph.

The Bottom Line

Microsoft's 2,250 targeted tenants establish the breadth of the reported campaign, not the number of confirmed compromises. The October 15 application-identity takeover is the operationally important turn because it connects the supply-chain intrusion to customer access. ARTEX is an attacker capability in this account, not a demonstration detached from real environments. Buyers should review their application trust path and evidence of use rather than let the 151,000 failed logins stand in for an impact assessment.