Threat Intelligence Report: Storm-0940, ARTEX and ConnectWise Cloud Credential Abuse

Scope: ConnectWise/SkyKick application-credential abuse and the associated Storm-0940 campaign, with an archive review covering 2026-07-25 through 2026-10-25. Intelligence was obtained exclusively through TI Mindmap HUB MCP; no external webpages, tenant queries or live infrastructure were accessed.

Evidence convention: attributed findings reflect HUB's retrieved summaries, IOC records and available source text, not independent incident verification. Recommendations and analytical ATT&CK mappings are identified as such. Shared software, infrastructure or language artifacts are not sufficient to merge threat actors. Classification is assigned to this synthesis, not asserted for every underlying source.

1. Reports Summary Table

The corpus contains 11 articles from ten publishers: five directly cover the ConnectWise incident, one covers the broader linked Storm-0940 vendor-targeting campaign, and five provide separate ARTEX context. Dates are HUB record dates, not independently verified original publication dates: publication and ingestion fields commonly coincide. Microsoft's original article URL is dated October 21, while HUB records October 22.

Exclusions: archive matches for August 29 ScreenConnect abuse and September 30 RMM phishing concern different product-abuse chains. No retrieved evidence ties them to this application-credential incident. They are not counted as earlier Storm-0940/ConnectWise reports. Secondary summaries of the same observations are not independent victim confirmations.

2. Executive Summary

Overview

Microsoft attributes the compromise of ConnectWise's multi-tenant cloud applications to Storm-0940, a China-state-aligned actor active since 2021. The attacker used vendor-controlled application authentication material to request tokens and access downstream Microsoft 365 tenants through permissions customers had already granted. ARTEX, an agentic penetration-testing framework, accelerated reconnaissance, authentication attempts and follow-on cloud operations. This is not evidence of a newly disclosed Microsoft vulnerability or a poisoned software update.

The incident illustrates an identity supply-chain failure: trust in a vendor application can expose many tenants without compromising each customer's user password. Application-only access also means that user MFA and password changes do not directly remediate the abused credential path.

Huntress confirmed unauthorized sign-ins in 162 tenants by 19:00 UTC on October 16. Microsoft reports attempted access to more than 2,250 tenants, and privileged persistence in multiple organizations. Those figures describe different populations and outcomes and must not be combined into a compromise rate. Installed applications, successful authentication, data access and exfiltration are distinct evidentiary stages.

Diagram: Attack Flow Overview

Compromise of vendor application authentication material
                 | initial acquisition mechanism unresolved
                 v
Trusted ConnectWise / SkyKick multi-tenant applications
                 |
ARTEX-assisted app-only token requests across customer tenants
                 |
                 +--> Failed requests / no effective permission
                 |
                 +--> Successful authentication and Graph access
                                   |
                     Directory / permission reconnaissance
                                   |
                     +-------------+--------------------+
                     v                                  v
             Privileged role changes          Secrets added to other apps
                     |                                  |
                     +--------------+-------------------+
                                    v
                 Persistence beyond original vendor identity

Separate branch: user password spraying -> many failures;
not demonstrated as the source of the vendor application's credentials.

Attribution & Threat Actor

Storm-0940 attribution: Microsoft assesses the actor as responsible for the ConnectWise compromise and describes a broader campaign beginning as early as September. Wiz reports overlapping infrastructure, tooling and behavior against software vendors. Individual earlier Huntress phases lacked enough source-IP evidence to independently tie every event to one operator; preserve that distinction even when discussing Microsoft's broader attribution.

ARTEX is not an actor identity. Recorded Future's TAG-217, the financial operator covered by Zscaler and Security Affairs, and GMO's Japanese incident observations must not automatically become Storm-0940 operations. Shared framework use, Chinese-language artifacts or overlapping generic clients do not prove common control.

Three-Month Historical Assessment

Finding: extending beyond one week adds a material direct source, Huntress on October 17, plus earlier ARTEX reporting. In the retrieved corpus, the documents selected for the specific incident remain October-dated; operational histories go back further. No directly linked July/August ConnectWise incident article was found in these searches.

3. Technical Details

3.1 Access and Persistence Analysis

Stage 0: Vendor Credential Compromise

Huntress describes client-assertion evidence placing the abused credential in the vendor environment. The retrieved evidence does not resolve how ConnectWise's authentication material was first obtained. Failed user password spraying is documented but is not established as that acquisition mechanism. Microsoft states the incident did not originate from a compromise or vulnerability in Microsoft systems, products or services.

Stage 1: Cross-Tenant Application Authentication

The attacker requested Microsoft Graph tokens using established ConnectWise application identities. Tenant access depended on the customer's existing consent and effective permissions. Sophos observed one app-only token request per targeted tenant in its telemetry, including historical integrations without active backup subscriptions. Huntress observed tenant GUIDs processed in sorted order and seconds between requests, consistent with automation.

Potentially available resources included directory information, email, Teams, SharePoint and OneDrive, depending on the application's actual permissions. These permissions describe possible access, not demonstrated collection from every tenant. User-password resets alone do not revoke a compromised application credential or remove attacker-created secondary credentials.

Stage 2: Roles and Secondary Application Credentials

Huntress observed one tenant where a Cloud Management-MS Teams application assigned itself Global Administrator and modified two other applications. Between 03:44 and 03:49 UTC on October 15, nine changes included six successes and three failures. Unauthorized client secrets expiring in 2028 were planted in a legitimate MSP management application and a tenant-specific Huntress Security Platform application. A certificate addition failed with a thumbprint mismatch.

Such changes can preserve access through other identities after the original vendor credential is rotated. They do not establish that the MSP application's downstream customers were subsequently compromised. The earlier changes preceded the first observed .128 token-sweep authentication in that tenant by roughly 2.5 hours; Huntress lacked source-IP evidence to independently connect those phases.

At approximately 01:58 UTC that day, around 50 monitored tenants also showed ConnectWise Cloud Management role assignments, mostly Exchange Administrator. The kiota-dotnet client suggested possible vendor automation, but legitimacy had not been confirmed by Huntress. Those events must not all be labeled attacker escalation without additional evidence.

Stage 3: Broader Identity Targeting

Wiz describes source-map and API discovery, password-recovery probing, cross-tenant authorization tests and malformed OAuth/JWT attempts against software vendors. Many returned HTTP 401/403. Expel separately observed Okta self-registration, authenticator enrollment and SSO activity from overlapping infrastructure; no ConnectWise application was involved in that Okta case. Treat it as related investigative context, not another proven ConnectWise customer compromise.

3.2 Operational Timeline and Exposure Metrics

Microsoft also reports approximately 2,900 sign-in attempts/minute for downstream ARTEX activity. That must not be confused with the separately reported October 11 peak of 2,900 failed user authentications/minute.

3.3 Cross-Source Discrepancies and Visibility Limits

4. Detection Opportunities

4.1 Identity and Authentication Detections

• Inventory relevant enterprise applications by App ID, not display name. Include historical consents and dormant vendor integrations.
• Review service-principal sign-ins and token activity, explicitly separating failures, successes, effective permissions and downstream operations.
• Correlate source IP, application ID, resource, user agent and time; programmatic clients or a successful sign-in alone do not establish malicious data access.
• Investigate app-only access from unexpected networks and automated requests traversing multiple tenants. Do not assume user MFA covers application authentication.

4.2 Persistence and Privilege Detections

• Review all applications for unexpected secrets, certificates, owners, grants and role assignments; scope is broader than the affected ConnectWise identities.
• Prioritize self-assignment of privileged roles and credentials added to existing trusted applications, including MSP and security-product integrations.
• Separate unconfirmed vendor automation from confirmed malicious changes. Preserve operation outcomes and failure details, not just event names.
• Investigate unusual credential expiry, authorization changes and activity by secondary applications after the original vendor identity was disabled.

4.3 Data-Access Correlation

• Correlate Entra records with existing Microsoft Graph, Microsoft 365 and Purview audit coverage to assess directory, mailbox, SharePoint, OneDrive and Teams access.
• Examine forwarding rules, unusual downloads, high-volume reads and unexpected application access where telemetry is available. These are hunting leads, not asserted observations in every affected tenant.
• Absence of Entra directory-change events does not establish absence of Graph read operations. Retention gaps and missing workloads must remain explicit investigation limitations.

4.4 Broader Campaign Detections

• Hunt for source-map retrieval followed rapidly by calls to newly discovered internal APIs, repeated recovery/registration attempts and cross-tenant authorization probes.
• Correlate Okta self-registered accounts, new authenticator enrollments and unusual OAuth/SSO activity with supporting infrastructure evidence, without treating the separate Okta case as ConnectWise access.
• Track password-spray outcomes separately from service-principal use; many reported sprays failed completely.

4.5 Retrospective Hunt Window

Prioritize service-principal and cloud changes from October 1, with detailed review of October 10-14 failed sprays, application/audit changes from October 13, and vendor-application/Graph activity on October 15-17. Continue through the reporting cutoff and until secondary persistence is resolved. Preserve older records in the three-month window where available for correlation, not because a July compromise is established.

Microsoft's minimum narrative review begins October 15, sample hunting reaches October 13, and extended guidance reaches October 1. These are investigation boundaries, not confirmed credential-theft dates. Hunting suggestions here were not executed against any tenant.

5. Conclusion

1. The trust boundary is the vendor application. Previously granted permissions enabled cross-tenant access attempts without separately obtaining every customer's password.
2. Persistence can survive initial containment. Rotating the original vendor credential does not remove unauthorized secrets or privileges planted in other applications.
3. Attempted reach is not confirmed compromise. More than 2,250 targeted tenants, 162 tenants with unauthorized sign-ins in one snapshot, and successful-event counts are not interchangeable.
4. Automation compresses response time. Microsoft reports rapid privileged access in selected cases, while many other attempts failed. ARTEX is an accelerator, not proof of universal success.
5. Historical ARTEX reporting is relevant but multi-actor. Earlier financial/Japanese cases add context without establishing a common operator or a July/August ConnectWise incident.

Recommended Immediate Actions:

• Preserve service-principal sign-ins, application configuration, consent state and audit evidence while containing promptly.
• Disable affected integrations where required; avoid deleting identities before evidence capture. Validate vendor restoration and credential-rotation instructions for each service.
• Inspect the entire tenant for unauthorized credentials, owners, grants and roles, then remove confirmed secondary persistence.
• Review tokens, sessions and resource access according to the affected services' revocation behavior; do not assume rotating one credential immediately invalidates every already issued token.
• Investigate tenant data access independently of backup-archive assurances and vendor-side visibility.
• Reduce application permissions, maintain an inventory of multi-tenant consents and alert on high-risk application identity changes.

6. Indicators of Compromise (IoC List)

IP addresses are defanged and time-bounded investigative leads. Legitimate application IDs and vendor tenant IDs are exposure/correlation identifiers, not intrinsically malicious objects. Shared or reassigned infrastructure requires context. The retrieved core evidence provides no campaign payload hash set; none is invented.

6.1 Network Indicators - Incident and Linked Campaign

6.2 Application and Tenant Identifiers

Huntress identifies the first seven applications. Microsoft independently highlights Cloud Backup, MS Teams and MS Graph. Expel supplies the eighth App ID without a resolved display name in the retrieved summary. Eight hunting identifiers do not imply eight vendor-disabled identities: ConnectWise reports seven disabled identities.

6.3 Client and Behavioral Artifacts

Huntress's private IPv6 observations also overlapped legitimate activity and are not promoted into external malicious infrastructure indicators.

6.4 Separate ARTEX Financial-Campaign Context

The following indicators belong to Zscaler's financial-operator reporting, not established Storm-0940/ConnectWise infrastructure. Keep them in a separately labeled intelligence set.

Public AI service use, Chinese-language text or an ARTEX artifact alone is insufficient to assign these indicators to Storm-0940.

7. MITRE ATT&CK Techniques

Mappings distinguish observed actions, analytical descriptions and unresolved acquisition steps. Framework capabilities and permissions alone are not evidence of collection or exfiltration.

No incident-wide exfiltration technique is asserted solely because applications could read mail or because Storm-0940 historically exfiltrated email. The separate Okta and financial-operator cases are not silently merged into this mapping.

Cross-source synthesis using TI Mindmap HUB MCP only. Analysis date: 2026-10-25 | Research window: 2026-07-25 to 2026-10-25 | Included articles: 11 (6 incident/linked campaign, 5 separate ARTEX context) | Classification: TLP:CLEAR.