Storm-0940 ConnectWise Cloud Backup Breach: Hunt OAuth Abuse in Microsoft 365

The attribution matters, but it isn't the most urgent part. Microsoft says several of these AI-driven intrusions went from first targeting to privileged cloud access in less than three hours. If your tenant ever authorized ConnectWise Cloud Backup or the older SkyKick integrations, you have work to do even if you stopped using the service years ago.

What Microsoft says happened​

Microsoft describes Storm-0940 as a known actor that now works faster. 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. The actor has historically gained initial access using password spraying and exploitation of internet-facing applications, before using compromised accounts to move through targeted environments. In cloud environments, the actor has also established persistence by adding credentials to existing OAuth applications, allowing continued access to Microsoft 365 resources.

Microsoft says the ARTEX campaign started as early as September 2026. It lists targets in aerospace and defense, automotive, chemicals, energy, financial services, government, legal, manufacturing, media, military, semiconductors, software, technology, and think tanks and nonprofits. During the ConnectWise supply chain compromise, Storm-0940 used ARTEX to accelerate scanning and reconnaissance, password spraying, and OAuth application abuse at downstream victims.

The key technique is abusing applications that tenants had already approved. Storm-0940's use of ARTEX accelerated the speed of compromised application abuse to authenticate to Microsoft 365 customer environments through applications that had already been granted access. This allowed the threat actor to operate without requiring an interactive user sign-in. In multiple affected environments, Microsoft observed 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 is careful to separate exposure from damage. It says the presence of an affected app, or even a successful authentication by the attacker, does not on its own show that data was accessed or stolen. Microsoft confirmed no compromise of its own corporate systems or products. Keep in mind that the attribution is Microsoft's assessment. ConnectWise's status updates say it is still working with outside specialists to work out how the access began.

Section summary: Storm-0940 already used password spraying and OAuth persistence before this campaign. Microsoft says ARTEX let it do those things at machine speed, through apps tenants already trusted, without anyone having to sign in interactively.

ARTEX: a pen-test tool turned against its purpose​

Microsoft describes ARTEX as an open-source, multi-agent large language model (LLM) framework written in Go, with a Next.js frontend. It can use any AI model. It runs a penetration test from reconnaissance through data exfiltration with little human input, and its agents record discovered assets and vulnerabilities in a graph. The interface defaults to English and can switch to Korean, Mandarin, Spanish or Japanese. Microsoft says it has seen threat actors in several regions using ARTEX.

Some secondary reporting adds history that Microsoft's report doesn't include. Crypto Briefing reports that ARTEX was released in July 2026 for legitimate security testing, then went closed-source in October 2026 following reported misuse. The same outlet says that before the ConnectWise attack, the framework was linked to data breaches affecting roughly 68,000 individuals at South Korean financial institutions. Treat those details as that outlet's reporting. Microsoft's report says only that October public reporting tied ARTEX to breaches at Korean financial institutions.

Using offensive security tools for real attacks is nothing new; Cobalt Strike went down the same road. What's different is that the operator here is mostly a set of agents. Microsoft points out that agents don't need sleep, weekends or holidays, and can try several breach paths at the same time.

The timeline: from password spray to tenant access​

Here is the sequence as Microsoft and ConnectWise describe it:

The password spray was large and noisy. Microsoft recorded more than 151,000 failed logons. Activity peaked on October 11 at 2,900 failures per minute, with more than 111,000 failures that day alone. Forty-eight accounts each received over 1,000 failures, and lockout responses made up almost 98% of the activity. Microsoft says it saw no successful authentication, token issuance, Graph call or directory change from that spray.

Huntress, which responded to the incident independently, gives a slightly different view of the infrastructure. It identifies 144.172.64.128 as belonging to a hosting provider (AS14956, RouterHosting). Used for the October 13 to 14 password spray and the October 15 app authentications. Huntress also notes that the .99 and .60 addresses were Additional IP indicator shared by ConnectWise in its advisory (part of its update on 10/18 at 18:45 UTC). The spray windows and IPs differ slightly between the two firms, which likely just reflects what each could see. Either way, the same /24 network block keeps appearing.

The downstream phase is where the large numbers come from. Microsoft says that after the attacker took control of several ConnectWise cloud application identities, ARTEX agents reached more than 2,250 tenants at 2,900 sign-in attempts per minute. Through that opening, attackers abused OAuth application identities. Storm-0940 used those identities to fire off authentication attempts at a rate of 2,900 sign-in attempts per minute. Microsoft linked the group to abuse affecting more than 2,250 tenants. Don't mix up these figures with the earlier password-spray numbers. They measure different activity.

One correction to coverage circulating today: at least one outlet called this a "ConnectWise ScreenConnect" compromise. Microsoft and ConnectWise both describe it as the Cloud Backup service, formerly SkyKick. The incident concerns OAuth application identities in Microsoft 365, not remote-access software.

Section summary: First came a loud, unsuccessful password spray. Then came quiet authentication using stolen app credentials across thousands of tenants, all from overlapping infrastructure, within about a week.

Why the three-hour window should worry you​

Microsoft's own point is that AI-driven attacks generate plenty of logs and alerts, and that this doesn't help much. When automated with AI, these activities generate a large volume of traffic and log data that may generate alerts. However, the speed of the activity allows very little time for Defenders to respond to those alerts and remediate the actor's access in a coordinated fashion.

Many security teams work business hours and treat alerts as a queue. A detection that fires at 2 a.m. Saturday may not be looked at until Monday. If an agent can get from target selection to Global Administrator in under three hours, that alert is old news by the time anyone reads it.

There is also a structural problem. Multi-tenant backup apps need broad read access to mail, files and Teams data to do their job. When one of those app identities is compromised, every tenant that granted it consent is exposed at once. ConnectWise sits in exactly that kind of connective position, and the supply chain compromise opened doors at many downstream customers simultaneously.

The persistence risk is serious. Microsoft says credential changes made by the attacker's agents can create persistence through other identities and services, and can stay active as a backdoor after the original app is fixed. ConnectWise says the same thing: disabling its connections blocks new authentication but doesn't undo changes already made inside a tenant. Tokens issued earlier may also keep working until they expire or are invalidated.

What to do now: a practical checklist​

Microsoft and ConnectWise agree on the main steps. Here they are in order:

1. Keep the affected ConnectWise connections disabled until ConnectWise publishes formal reconnection instructions.
2. Don't delete the enterprise apps first. Microsoft says to preserve configuration and evidence before making irreversible changes. Huntress recommends disabling the service principal: Do not block the ID itself, disable the service principal in your tenant. In Entra, that means opening the enterprise app's Properties and setting "Enabled for users to sign-in" to No.
3. Search by application ID, not display name, in every tenant where these apps are installed or were ever authorized:
   • 506e08f9-6e9a-4da4-942b-a099a03644ae: ConnectWise Cloud Backup
   • 24205314-2b89-4e07-a2a4-579e898a5640: ConnectWise - MS Teams
   • 0de14c77-b9b0-4137-9360-34878a929827: ConnectWise - MS Graph
   • c921256f-04a7-44e8-9b2a-69c33929ba19: SkyKick Partner Portal
   Microsoft lists four IDs; ConnectWise disabled seven identities, which are listed on its Trust Center. A Spanish-language summary from Tu Código Digital counts eight once the two lists are combined, so check both. Record the local service-principal Object ID for each tenant.
4. Export your logs now. Preserve Entra sign-in and audit logs, Purview Audit records, SIEM data and any Graph telemetry you already collect. Tu Código Digital, citing ConnectWise, notes that Entra suele guardar esos registros siete días en la versión gratuita y 30 en P1 o P2, meaning Entra typically keeps these logs for seven days on the free tier and 30 days on P1 or P2. Free-tier tenants may already have lost the October 15 logs. Microsoft also says not to hold off on containment while exports finish.
5. Look in the right logs. In the Entra admin center, go to Monitoring → Sign-in logs → Service principal sign-ins. ConnectWise warns that the default User sign-ins tab won't show this activity. It also says the app's normal traffic comes from Azure private IPv6, so a public IPv4 address from a hosting provider is a warning sign.
6. Review from October 15 at minimum, and from October 1 where your logs go back that far. Check successful and failed sign-ins separately, and don't limit the search to the published IPs.
7. Check audit logs for persistence: new app or service-principal credentials, new apps or owners, app-role assignments, consent grants, privileged role assignments, and changes to users, groups, authentication methods or Conditional Access.
8. Check for data access: unusual mail or file access, downloads, forwarding, inbox or transport rules, and delegated mailbox permissions.
9. Clean up only after preserving evidence. An authorized responder should remove confirmed unauthorized credentials, grants and identities, then revoke unneeded permissions and rotate credentials.

Indicators and hunting​

Microsoft's indicators include the IPs 144.172.64[.]60, [.]99 and [.]128. It also lists VPN addresses 187.15.88[.]186, 187.15.90[.]217 and 187.15.89[.]186, which are mainly relevant to October 15–16. User agents to look for are Python-urllib/3.12, python-requests/2.31.0, python-requests/2.34.2, curl/7.88.1 and azure-toolkit/1.0. These are leads to investigate, not proof of compromise.

Microsoft's suggested hunting process:

• Defender XDR: start with OAuthAppInfo to check whether the apps are present and what permissions they hold. Then join EntraIdSpnSignInEvents with GraphAPIAuditEvents from October 13 onward, and remove the IP filter to search more broadly.
• Sentinel: use SigninLogs to confirm whether the app authenticated, then MicrosoftGraphActivityLogs to see which Graph requests followed.

Microsoft points out that finding nothing in the Graph logs doesn't prove nothing happened. Alerts to watch for include "Application self-assigned Global Administrator role," "Unusual Microsoft Graph activity associated with Compromised ConnectWise Application," and "Suspicious addition of application role assignments by service principal to itself." Which detections you get depends on your licenses.

The service fallout​

ConnectWise's October 21 update says phased restoration is being prepared and should take several days. Cloud Backup, SaaS Security and Cloud Management remain suspended for now. ConnectWise says stored backup archives remain encrypted and isolated with no sign of compromise. It also says that tells you nothing about whether your live Microsoft 365 tenant was affected, because the service gives ConnectWise no visibility into customer environments. For MSPs, this means no backups and no restores while you investigate your clients' tenants.

The bigger lesson​

You don't have to be a ConnectWise customer to learn from this. Every third-party app with tenant-wide Graph permissions carries the same kind of risk, and attackers can now exploit that risk with automated agents. Microsoft's longer-term advice is to apply least privilege to multi-tenant app permissions and consent grants, and to monitor credential additions and unusual app-only activity on highly privileged apps. A useful question to put to your team: how many enterprise apps in your tenant hold permissions like Mail.Read on every mailbox, and who last reviewed them?

Bottom line: If ConnectWise Cloud Backup or SkyKick has ever been connected to your tenant, export your logs today, check service principal sign-ins, and look for credentials or role assignments you didn't create. Disabling the vendor's app isn't enough if the attacker has already set up another way in.