Storm-0940, ARTEX and ConnectWise Cloud Backup: What to Check

The headline version of this story is that Chinese hackers used AI to attack supply chains. The operational version is narrower. A trusted backup app's credentials were stolen, and an autonomous tool then tried those credentials against thousands of Microsoft 365 tenants at machine speed. The AI element mostly changes how fast the attack runs. The entry point is an old problem: a vendor-held application identity with broad access to customer tenants.

What happened

ConnectWise has said it identified unauthorized access to application identities in its Cloud Backup environment, the product formerly sold as SkyKick. Public reporting puts the identification date at October 15, 2026, and ConnectWise published its advisory on October 16. Security firm Huntress raised the alarm after seeing the app sign in to customer tenants from a commercial hosting address. ConnectWise then disabled seven application identities on October 17 at 07:00 UTC, revoked the certificates used for the affected connections, and suspended Cloud Backup. SaaS Security and Cloud Management were also taken offline because they integrate with Cloud Backup.

On October 21, Microsoft Threat Intelligence published a blog post attributing the compromise to Storm-0940. Microsoft describes Storm-0940 as a China-state-aligned actor active since 2021, with no known industry aliases. Its name follows the convention for a developing actor. Microsoft says the group used ARTEX, an open-source agentic AI penetration-testing framework, from at least September 2026. Microsoft describes ARTEX as a system of LLM-driven agents that run an autonomous penetration test. In this campaign it sped up scanning, reconnaissance, password spraying and OAuth application abuse.

Key figures from Microsoft's reporting, as relayed by the press:

• Storm-0940 attempted sign-ins at more than 2,250 Microsoft 365 tenants using stolen ConnectWise app credentials. These authenticated as the applications, with no interactive user sign-in.
• Four application credentials produced more than 200 sign-ins in under four minutes, all from the same IP range.
• Some attacks reached privileged access less than three hours after initial targeting. In one tenant, an app assigned itself a top administrator role on October 15.
• A separate password-spray run between October 10 and 14 hit 327 accounts across eight organizations. It produced more than 151,000 failed logons, peaking near 2,900 failures per minute on October 11, and had no successes.

Microsoft says its own products were not compromised or vulnerable. The Chinese Embassy in Washington rejected the allegations.

Who is affected

The exposure is any Microsoft 365 / Entra tenant where a ConnectWise Cloud Backup or SkyKick-related enterprise application is, or ever was, consented. Most of these are small and mid-sized businesses served by MSPs. One report notes that older tenants may list Cloud Management apps as “SkyKick Cloud Manager,” so searching by display name is unreliable. Search by Application ID instead.

Scale needs careful reading. The 2,250 figure counts tenants Storm-0940 attempted to sign in to, not tenants breached. Confirmed numbers are lower:

• Huntress confirmed unauthorized sign-ins in 162 tenants, later reported by other outlets as 173, and found almost 1,000 tenants with sign-in activity from the attacker's address.
• Microsoft says it identified Storm-0940 authentication and follow-on activity in multiple customer environments. It also says most targeting attempts failed, and that an affected app or successful sign-in does not prove data was accessed or exfiltrated.
• ConnectWise says it has no indicators that stored Cloud Backup data was compromised. It also says it has no view into customer tenants, so it cannot say whether any individual tenant was accessed.
• One MSP community report described exfiltration of email, Teams and SharePoint data from client tenants. That comes from a vendor blog summarizing community posts and is not confirmed in Microsoft's reporting.

Reported target sectors include aerospace and defense, semiconductors, government, military, energy, financial services, automotive manufacturing, technology and think tanks. Microsoft lists 14 industries in total, and coverage is global. Public reporting does not give a tenant count by country or a confirmed list of named victims.

How the attack works

No CVE has been published for this incident. It is a credential and trust-relationship compromise, not a software flaw. How the ConnectWise credentials were originally stolen is unconfirmed. ConnectWise has declined to say, and its status updates say it is still working with outside specialists. One secondary blog claims the credentials came from the October 10-14 spray against ConnectWise's own authentication systems. Microsoft's reporting, as relayed by the press, describes that spray as targeting eight organizations. Treat the secondary claim as unverified.

Observed attack chain

1. Credential theft from the vendor. The actor obtained credentials for multi-tenant app identities, including the Cloud Backup app (AppId 506e08f9-6e9a-4da4-942b-a099a03644ae). The method is unknown.
2. App-only authentication into customer tenants. The credential works in every tenant that consented to the app, and the actor signed in as the application itself. A service principal authenticates with its own secret or certificate, so no user password or MFA prompt is involved. The “MFA bypass” headlines are imprecise: MFA was never evaluated, because no user was signing in.
3. Graph reconnaissance. Microsoft observed Microsoft Graph API reconnaissance after sign-in.
4. Persistence. The actor tried to add extra credentials to the service principal in target tenants, creating a backdoor that survives disabling the original ConnectWise connection. In at least one tenant an app granted itself a privileged directory role.
5. Parallel spraying. ARTEX-driven password spraying against user accounts ran alongside, at high volume and with no confirmed success.

A Wiz write-up, as summarized by secondary sources, describes ARTEX's structure as a planner agent directing worker agents that run standard tools such as nmap, curl and Impacket. Microsoft's point is that the agents work around the clock and try multiple breach paths at once.

ATT&CK mapping

• T1199 Trusted Relationship: abuse of the vendor's app trust in customer tenants.
• T1078.004 Valid Accounts: Cloud Accounts: authenticating with legitimate app credentials.
• T1110.003 Brute Force: Password Spraying: the October 10-14 spray.
• T1087.004 Account Discovery: Cloud Account: Graph directory reconnaissance.
• T1098.001 Account Manipulation: Additional Cloud Credentials: credentials added to service principals.
• T1098.003 Account Manipulation: Additional Cloud Roles: the app self-assigning an administrator role.

Published indicators

• Application ID: 506e08f9-6e9a-4da4-942b-a099a03644ae (ConnectWise Cloud Backup / SkyKick). ConnectWise has disabled seven application identities in total, and Microsoft's sample queries use a subset. Use the vendor's full list from its advisory.
• IPs published by Microsoft: 144.172.64[.]60, 144.172.64[.]99, 144.172.64[.]128.
• ConnectWise says the app normally connects from Azure private IPv6 addresses. A public IPv4 address from a hosting provider is therefore anomalous.

Treat the IPs as leads, not proof. ARTEX activity is not confined to three addresses, and the absence of a hit does not clear a tenant.

Detection guidance for defenders

Start in Service principal sign-ins. ConnectWise warns that the default user sign-in view will not show this activity. Review from October 15 at minimum, and from October 1 where retention allows. Microsoft's Defender XDR detections and hunting queries cover suspicious Graph activity and known infrastructure.

What to look for

• Successful service principal sign-ins for the Cloud Backup AppId from public IPv4 or hosting-provider addresses.
• New secrets or certificates on any application or service principal since October 13, including ones with unusually long expiry.
• Directory role assignments initiated by a ConnectWise or SkyKick app, and new apps, owners or consent grants.
• Bursts of Graph reads from one service principal.
• High-volume failed user sign-ins from a small set of IPs, which is the spray signature.

Example hunting queries (KQL)

// 1. Successful app-only sign-ins from the affected app that are not from the expected IPv6 space
AADServicePrincipalSignInLogs
| where TimeGenerated > datetime(2026-10-01)
| where AppId == '506e08f9-6e9a-4da4-942b-a099a03644ae'
| where ResultType == 0
| where IPAddress !contains ':' or IPAddress startswith '144.172.64.'
| summarize Signins=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated) by IPAddress, ServicePrincipalName, ServicePrincipalId, ResourceDisplayName
| order by FirstSeen asc

Finds successful sign-ins by the Cloud Backup app from public IPv4 space or the published Storm-0940 range. The IPv4 filter is a heuristic based on ConnectWise's note about normal IPv6 traffic, so tune it for your environment.

// 2. Credential or role changes on apps/service principals since Oct 13
AuditLogs
| where TimeGenerated > datetime(2026-10-13)
| where OperationName has_any ('credentials', 'Certificates and secrets', 'Add app role assignment', 'Add member to role')
| extend ActorApp = tostring(InitiatedBy.app.displayName), ActorUser = tostring(InitiatedBy.user.userPrincipalName), ActorIP = tostring(InitiatedBy.app.ipAddress)
| project TimeGenerated, OperationName, ActorApp, ActorUser, ActorIP, TargetResources, Result
| order by TimeGenerated asc

Surfaces persistence and privilege escalation, such as secrets added to service principals or roles granted, so you can see whether an app or an unfamiliar actor made the change.

Microsoft Graph activity logs must be enabled to see the follow-on reconnaissance. Check whether they were on before October 15. If they were not, the reconnaissance may be invisible, and you have to rely on sign-in and audit logs alone.

Mitigation and response

There is no patch, and Microsoft says there is no flaw in its products to patch. The fixes are configuration and credential hygiene, in this order:

1. Keep the ConnectWise connections disabled. Microsoft's advice is to leave affected app connections disabled until ConnectWise issues formal restoration instructions. Huntress advises disabling the service principal rather than blocking the ID or deleting the enterprise app. In Entra, set “Enabled for users to sign-in” to No on the app's properties.
2. Preserve evidence first. Export service principal, user and non-interactive sign-in logs, Entra audit logs, Purview Audit records and any SIEM data. Record the tenant-local service principal Object ID, because logs reference it and not the global AppId.
3. Hunt for persistence, not just entry. Disabling the vendor app does not remove a secret the actor planted on another application. Review every app and service principal for credentials added since October 13, along with new apps, owners, consents, app role assignments and privileged role changes.
4. Remove and rotate. Delete unauthorized credentials, rotate secrets for any identity the actor touched, and revoke sessions and refresh tokens where user accounts were involved. Remove any role the app assigned itself.
5. Scope data exposure. If successful sign-ins appear, review Graph and Purview audit data for mailbox, SharePoint and Teams access. Neither Microsoft nor ConnectWise can answer this for you.
6. Harden workload identities. Use Entra application management policies to restrict client secrets and cap their lifetimes. Limit who holds Application Administrator and Cloud Application Administrator. Where licensed, apply Conditional Access for workload identities to restrict sign-ins to known IPs, and enable ID Protection's risky service principal detection.
7. If you are an MSP, repeat the above in every managed tenant, track which clients need restored backups, and notify them. Customers cannot restore from Cloud Backup while the service is offline.

FAQ

Is there a CVE or a patch?

No. Public reporting does not identify a CVE. Microsoft says the attacks did not result from a compromise of, or vulnerability in, its own systems. The remediation is to disable the apps, review logs and rotate credentials.

Did the attackers bypass MFA?

Not in the usual sense. The actor signed in as the application using its own credential, so no user MFA challenge occurred. Conditional Access policies written for users would not have applied to these sign-ins. Policies for workload identities are a separate control.

Does a hit on the app in my tenant mean I was breached?

No. Microsoft states that an affected app, or even a successful sign-in, does not by itself prove data was accessed or taken. It does mean you should investigate fully, because the actor attempted to add backdoor credentials and, in some tenants, reached privileged roles.

Bottom line

The AI angle is real but secondary. Microsoft's own account says most targeting failed, and the damage came from a vendor-held credential that worked across every consenting tenant. The more durable lesson is that multi-tenant app identities with broad Graph permissions are high-value targets, and that machine-speed tooling shrinks the window to catch them. Tenants with any ConnectWise or SkyKick consent should treat this as an active investigation until the log review is done and persistence has been ruled out.

Original reporting: Yahoo