ConnectWise Cloud Backup Compromise: Storm-0940 Uses AI to Target Microsoft 365 Tenants

BlackBerry's security briefing center, which sells secure-communications products, publicized the story again this week. The facts that matter for administrators come from Microsoft Threat Intelligence and from ConnectWise's own disclosures. Here is what's known, what isn't, and what Microsoft 365 and Entra admins should be checking.

What Microsoft says happened​

On October 21, 2026, Microsoft attributed the ConnectWise compromise to Storm-0940. Microsoft has tracked the group since 2021 and describes it as focused on data theft across many industries. In the past, Storm-0940 got in through password spraying and exploited internet-facing applications. In cloud environments, it stayed in by adding credentials to existing OAuth applications, then used those apps to pull email and other data through Microsoft Graph.

What's new is the tooling. Microsoft says that since at least September 2026, the group has used ARTEX, an open-source AI penetration-testing framework, to automate attacks on hundreds of organizations. Coverage summarizing Microsoft's report says the targets span the aerospace, automotive, chemicals, defense, energy, financial services, government, legal, manufacturing, media, military, semiconductor, software, and technology sectors, as well as against non-profits and think tanks. The list is wider than the defense-heavy picture some summaries give.

Microsoft describes ARTEX this way:

• It's written in Go with a Next.js front end, and it can drive any AI model.
• Its agents run an autonomous penetration test from reconnaissance through data exfiltration with little human input.
• The agents record discovered assets and vulnerabilities in a graph as they go.
• The interface defaults to English and can switch to Korean, Mandarin, Spanish or Japanese.

Microsoft also says threat actors in several regions are using ARTEX, so it isn't one group's private tool.

Section summary: The actor and its techniques aren't new. The change is that the familiar playbook now runs at machine speed, around the clock.

The access path: an app, not a user​

The compromised product was ConnectWise Cloud Backup. Expel notes it was formerly SkyKick, which matters if your tenant's app inventory still uses the older name. The attacker took over several ConnectWise cloud application identities and signed in to customer tenants as those applications.

Microsoft states it plainly: "Storm-0940's use of ARTEX accelerated the speed of compromised application abuse to authenticate to target environments through applications that had already been granted access, allowing the threat actor to operate without requiring an interactive user sign-in."

Some coverage says the attacker "bypassed MFA." That framing is loose. Nothing about MFA was defeated. App-only authentication never involves an interactive user sign-in, so there's no MFA prompt to trigger in the first place. Your users' MFA, number matching and phishing-resistant keys can all be configured perfectly and still not matter here. The control that counts is what permissions you granted the vendor's service principal and how closely you watch it.

The attacker then went beyond signing in. In some tenants, Microsoft saw Microsoft Graph and directory activity, including:

• Reconnaissance of directories, permissions and approvals
• Changes to application credentials to keep access
• Changes to identities, groups and privileged roles
• In one Defender detection, a ConnectWise management app assigning itself Global Administrator
• Large-scale secret reads across multiple Azure Key Vaults, plus key enumeration and a key-unwrap operation

Getting the numbers right​

The figures in this story are easy to mix up, and several outlets have done it.

Phase 1: password spray, October 10–14. Infrastructure at 144.172.64[.]99 targeted 327 accounts at eight organizations:

• More than 151,000 failed logons, peaking at 2,900 failures per minute on October 11
• More than 111,000 of those failures on that single day
• 48 accounts hit more than 1,000 times
• Lockout responses made up almost 98% of the activity
• Microsoft saw no successful authentication, token issuance, Graph call or directory change

Phase 2: downstream application abuse, from October 15. Using the stolen app credentials from the same IP range, the agents attempted sign-ins to more than 2,250 tenants. Microsoft's infographic shows more than 200 sign-ins in under four minutes using four application credentials.

Some reporting merges the two phases. One summary claims one compromised ConnectWise credential unlocked 2,250 downstream M365 tenants in under three hours at 2,900 sign-in attempts per minute. Microsoft's data doesn't support that. The 2,900-per-minute figure comes from the failed password spray. Microsoft says most of the tenant targeting failed. The under-three-hours figure describes "multiple instances" across the broader ARTEX campaign, not 2,250 compromised tenants.

Microsoft also doesn't say how many organizations were actually breached. As one analysis puts it, Microsoft says privileged cloud persistence happened at "many organizations", without giving a number.

Other researchers add detail. One report cites Sophos describing a sweep of about 96 minutes from a single server, which went through tenants in ascending identifier order and included former customers of the backup service. That last detail matters: dropping the product doesn't mean the app's service principal left your tenant.

ConnectWise's response, and what's still unconfirmed​

ConnectWise published its first advisory on October 16. According to SecurityWeek, ConnectWise suspended several services, including Cloud Backup, SaaS Security, and Cloud Management. A timeline compiled from a ThaiCERT notice and vendor statements says on 17 October it disabled seven application identities, revoked their certificates and suspended Cloud Backup along with SaaS Security and Cloud Management. Microsoft's own guidance lists four application IDs to check. Use the IDs in ConnectWise's current advisory as the authoritative list for your tenant.

On data exposure, ConnectWise has said it found no evidence that partner backup data was compromised and that existing backups remain encrypted and stored separately. Microsoft's caution goes both ways: an affected app in your tenant, or even a successful attacker sign-in, doesn't prove data was accessed. Microsoft also says no Microsoft system, product or service was compromised or vulnerable.

Two caveats on attribution:

• The Storm-0940 attribution is Microsoft's assessment. Other researchers have been more careful. Expel was explicit that the shared IP is its only link to Storm-0940 and that the activity alone does not prove ARTEX was used.
• The ConnectWise CEO said the attack "appears" to be the work of such a group, and the Chinese embassy dismisses what it calls "smears".

Section summary: The app-abuse mechanics are confirmed by several parties. The attribution and the exact number of compromised tenants are less settled.

What admins should do now​

These steps follow Microsoft's published guidance and are in a sensible order.

Immediate containment​

1. Keep the affected ConnectWise app connections disabled until ConnectWise issues formal restoration instructions.
2. Don't delete the enterprise applications first. Save their configuration and evidence before making any change you can't undo.
3. Search by application ID, not display name. Record the service principal's Object ID in each tenant. Check every tenant where the apps are or ever were installed or authorized, including integrations you no longer use. This is especially important for MSPs with many customer tenants.
4. Preserve logs: Entra sign-in and audit logs, Purview Audit records, SIEM data, and any Graph activity telemetry you already collect. Don't hold up urgent containment while exports run.

Investigation​

1. Review activity from October 15 at the earliest. Where you have the retention, extend the service-principal sign-in review back to October 1, and look at failed authentications and volume spikes too.
2. Review successful and failed service-principal sign-ins separately. Don't limit the hunt to the published IP addresses. Microsoft also listed python-requests/2.31.0 and Python-urllib/3.12 user agents.
3. Check Entra audit logs for:
   • New credentials on apps or service principals
   • New apps, service principals or owners
   • App-role assignments and consent grants
   • Privileged role assignments
   • Changes to users, groups, authentication methods or Conditional Access
4. Check Microsoft 365 audit logs for:
   • Unusual mail or file access and downloads
   • Forwarding, inbox or transport rules
   • Delegated mailbox permissions
   • Directory and permission listings from unfamiliar IP addresses
5. If you run Azure workloads, check Key Vault access patterns. Microsoft observed bulk secret reads and flagged the KV_AccountVolumeAccessDeniedAnomaly alert.

Defender XDR customers get dedicated detections for this campaign. One example is "Application self-assigned Global Administrator role." Microsoft also published advanced hunting queries that start with the OAuthAppInfo table to find out whether the app is present and what permissions it has, then pivot to service-principal sign-ins and GraphAPIAuditEvents. Microsoft warns that an empty Graph log result doesn't prove nothing happened.

Remediation​

1. After evidence is preserved, an authorized responder should remove confirmed unauthorized credentials, grants, owners, role assignments and identities, then rotate secrets. Persistence is the biggest long-term risk here: Microsoft says the attacker's credential changes can keep working through other identities and services even after the original ConnectWise app is fixed.
2. Plan for losing backup and restore while the integration is disabled. A paused backup is better than one that gives an attacker access, but someone still has to tell the business.

The bigger lesson: vendor apps are privileged accounts​

General industry advice applies here. Treat every multi-tenant vendor app with high-privilege Graph permissions like a privileged account you don't control. A backup product often needs broad read access to mail and files to work, which also makes its credentials valuable to steal. Can you list every third-party service principal in your tenant with application permissions, plus who owns it and when its credentials last changed? If not, this incident is a good reason to build that list. Microsoft's broader advice is to apply least privilege to multi-tenant app permissions and consent grants, and to alert on credential additions and anomalous app-only activity.

BlackBerry raises a fair operational point, even with a sales motive behind it. If an attacker may be inside the tenant that hosts your email and Teams, discuss the incident response somewhere else. You don't need a particular vendor's product for that. You need an out-of-band channel that's agreed in advance and tested before an incident.

Speed is the other lesson. Microsoft says the volume of AI-driven activity can trigger alerts, but the pace leaves defenders little time to coordinate remediation. If your incident process assumes a day of triage, or someone on call only on weekdays, a three-hour attack path will be over before the process starts.

Bottom line: No Microsoft vulnerability was involved, and user MFA wasn't relevant. The attacker used permissions customers had already granted to a trusted vendor app, at a speed no human team could match. Admins should find the ConnectWise app by its application ID in every tenant, preserve the evidence, and check what changed while the app had access.