Identity
Microsoft ties ConnectWise tenant hack to AI-run Storm-0940
Microsoft says China-aligned Storm-0940 used the ARTEX AI agent framework in the ConnectWise Cloud Backup attack. What the agents did and what to hunt in Entra.
On October 21, Microsoft Threat Intelligence attributed the compromise of ConnectWise Cloud Backup, the Microsoft 365 backup service formerly sold as SkyKick, to Storm-0940. Microsoft describes the group as China state-aligned, active since 2021 and focused on data theft. It says the group ran the campaign through ARTEX, an open-source framework of AI agents built for penetration testing, and used it to attempt sign-ins to more than 2,250 Microsoft 365 tenants after it got hold of ConnectWise's application credentials. In several tenants, less than three hours passed between first targeting and privileged access.
ConnectWise chief executive Manny Rivelo told Reuters that Microsoft's analysis and ConnectWise's own evidence point to a China state-aligned group, and that containing the vendor's app connections does not remove access an attacker may already have set up inside a customer tenant. That clean-up falls to each tenant owner. If you run, or your managed service provider (MSP) runs, a tenant that ever consented to Cloud Backup or Cloud Management, Microsoft's report adds a third application ID, a longer log window and Azure Key Vault to the checks we covered in our first post on this incident.
What ARTEX is and what the agents did
ARTEX is a multi-agent system: several large language model (LLM) agents, each given a task, coordinated by a program written in Go with a Next.js web console. It can be pointed at any AI model, and Microsoft says it can run a test from reconnaissance through to data exfiltration with little human input. Microsoft did not say which model Storm-0940 used. We wrote about the same tool in the Korean bank breaches, where CrowdStrike linked it to a Chinese-speaking actor. SecurityWeek reports that Microsoft saw Storm-0940 using ARTEX from early September 2026.
In this campaign, Microsoft says the agents handled three jobs: scanning cloud resources for targets, password spraying, and abusing OAuth applications in downstream tenants. They ran continuously and followed several intrusion paths in parallel. The spray came first. Between October 10 and 14, it hit 327 accounts in eight organizations running Microsoft 365 or Exchange Online and produced more than 151,000 failed logons. Failures peaked on October 11 at more than 111,000 for the day and 2,900 a minute. Microsoft saw no successful sign-in, token or directory change from the spray. (Cybersecurity Dive and The Next Web attach the 2,900 a minute figure to the later tenant sign-ins instead; Microsoft's report ties it to the spray.)
When spraying failed, the operation moved to ConnectWise's own application credentials. From October 15, the agents used four of them to request tokens in customer tenants as the app itself, with no user sign-in and therefore no MFA prompt. Jon Semon of Huntress, whose detection started the public response, told Cybersecurity Dive the firm's working hypothesis is "an AI agent leveraging scripted tooling" with occasional human intervention, based in part on scripted user agents such as Python-urllib/3.12 on the traffic.
What happened after sign-in
Once the agents held a Microsoft Graph token, Microsoft says they ran reconnaissance of the directory and its privileged accounts. For persistence they added credentials to existing OAuth applications and service principals, so access would survive ConnectWise revoking its own credential. One ConnectWise management app gave itself Global Administrator. They also tried to change users, groups and privileged roles.
The step the first reports did not cover is Azure. The agents also enumerated cloud resources and read secrets in bulk from several Azure Key Vaults. A Key Vault often holds connection strings, API keys and storage keys, so a tenant that ran this app and also hosts Azure workloads has a second set of credentials to review.
Microsoft says the activity did not come from a flaw in its own products, and that an affected app or a successful sign-in does not by itself prove data was taken. Most of the targeting failed. ConnectWise disabled seven application identities on October 17 and began a phased restoration on October 21. It has still not said how the attacker obtained the credentials.
What to hunt in Entra and Azure
Keep the ConnectWise apps disabled, not deleted, until ConnectWise sends formal restoration instructions; deleting them throws away configuration you need as evidence. Export Entra sign-in and audit logs, Purview audit records and Graph activity logs before you remove anything. Then work through these:
Search Enterprise applications by application ID, not display name, and include tenants that stopped using the service, since their consent may still be live. Microsoft lists three IDs: Cloud Backup
506e08f9-6e9a-4da4-942b-a099a03644ae, the Teams app24205314-2b89-4e07-a2a4-579e898a5640, and Cloud Management MS Graph0de14c77-b9b0-4137-9360-34878a929827. Note each one's local service principal object ID; you will filter audit records by it.Pull service principal sign-ins for those apps from October 1 where your retention allows, and at minimum from October 15. Review successes and failures separately, and treat any source outside Microsoft's own address space as suspect. The published addresses are 144.172.64.128, 144.172.64.99 and 144.172.64.60, plus three short-lived VPN addresses Microsoft lists for October 15 and 16.
Compare those sign-ins with Graph activity. In Microsoft Sentinel, with Graph activity logging turned on:
let apps = dynamic(["506e08f9-6e9a-4da4-942b-a099a03644ae","24205314-2b89-4e07-a2a4-579e898a5640","0de14c77-b9b0-4137-9360-34878a929827"]); MicrosoftGraphActivityLogs | where TimeGenerated >= datetime(2026-10-13) | where AppId in (apps) | summarize calls = count(), uris = make_set(RequestUri, 50) by AppId, IPAddress, UserAgent | order by calls descGraph activity logging is off by default, and directory reads leave no Entra audit record, so empty results here do not clear the tenant.
In the Entra audit log, look for anything a service principal did to identities: added credentials, new applications or owners, app role assignments and consent grants, role assignments, and changes to users, groups, authentication methods or Conditional Access. In Sentinel,
AuditLogs | where TimeGenerated >= datetime(2026-10-13) | where isnotempty(tostring(InitiatedBy.app.servicePrincipalId))lists every app-initiated change; Global Administrator and Privileged Authentication Administrator assignments come first.If the tenant has Azure subscriptions, check Key Vault diagnostic logs for one identity reading many secrets across several vaults in a short window. With logs sent to Log Analytics,
AzureDiagnostics | where ResourceProvider == "MICROSOFT.KEYVAULT" and OperationName == "SecretGet", summarised by caller identity and 15-minute bin with a distinct count of vaults, surfaces that pattern. Rotate every secret those identities read.
Finish with Microsoft 365 audit records: unusual mail and file access, downloads, forwarding, inbox and transport rules, and delegated mailbox permissions. Once evidence is saved, remove credentials, grants, owners and role assignments you cannot account for. If you use Defender XDR, the alert "Application self-assigned Global Administrator role" fires on the persistence step seen here.
AI speed and app-only access
Each step in this campaign, from spraying to adding a client secret, is ordinary attacker tradecraft. The agents ran those steps around the clock and along several paths at once, against trusted application identities that act outside the MFA and Conditional Access rules built for users. Rivelo put it as AI letting attackers test vendor connections at "machine speed." Two controls act without waiting for a person: an automated response to an app adding itself to a directory role or gaining a new client secret, and an Entra application management policy that blocks new secrets on high-privilege apps.
Our security operations team runs these service principal, Graph and Key Vault hunts, and our cloud and Kubernetes security work reviews which third-party apps and identities can reach your Azure secrets. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.
Sources: Microsoft Threat Intelligence, Reuters via WHTC, SecurityWeek, Cybersecurity Dive, The Next Web, Petri, Huntress, aicybr.