A Nation State Used AI Agents To Move Through 2,250 Cloud Tenants: What Microsoft Found

Posted on by
Contents show
A flat vector illustration of a large open padlock with three small thin-line robot figures walking through the open shackle, representing AI agents abusing trusted application access

Microsoft published a threat intelligence report on 21 October 2026 attributing the ConnectWise supply chain compromise to Storm-0940, a China-state aligned actor, and documenting something security teams have been bracing for since agentic tooling went mainstream: a state-aligned group using an open-source agentic AI penetration testing framework to automate attacks at machine speed, with AI agents doing the reconnaissance, the credential abuse and the persistence work inside victim tenants. The actors reached privileged access in some cloud environments in less than three hours from initial targeting, and the framework's AI agents attempted sign-ins at more than 2,250 Microsoft 365 tenants using stolen application credentials from a trusted vendor. For a small team reading the headlines, the practical question is narrower than the geopolitics: which of the applications your organisation has trusted holds credentials that would matter if its vendor were compromised, and would anyone notice within three hours if AI agents were abusing them.

The report is dense, careful about what it does and does not claim, and publicly readable, which is more than can be said for most incident coverage; the primary sources for state-linked incidents are usually press summaries, and here the actual report answers most of the questions the summaries raise. This article walks through what Microsoft found, what ConnectWise's own advisory adds, why the three-hour figure matters even though most of the targeting failed, and what an organisation that uses any third-party cloud application should actually do, based on the guidance both vendors published. Everything comes from Microsoft's report and ConnectWise's advisory, read directly.

What happened, in order

The sequence Microsoft reconstructed starts before the vendor incident itself. Between 10 and 14 October 2026, Storm-0940 infrastructure ran an automated cross-tenant password-spray campaign against 327 accounts across eight organisations, generating more than 151,000 failed sign-in events, peaking at 2,900 failures per minute, with lockout responses representing nearly 98 percent of all activity. Despite that volume, Microsoft observed no successful authentication, token issuance or directory change from that campaign. The spray campaign is also where the AI agents were visible first: automation of this tempo is not something a human operator working by hand produces, and the report treats the framework's use as the explanation for both the volume and the timing.

On 15 October, public reports of the ConnectWise Cloud Backup compromise began surfacing, with indicators matching the same network range as the password-spray infrastructure. One IP address in ConnectWise's advisory matched exactly the infrastructure from the earlier campaign. After acquiring control of the identities of multiple ConnectWise cloud applications, the AI agents continued using the same IP range to authenticate to customer environments, taking advantage of trust those applications had already been granted. In some environments the AI agents went beyond authentication into Microsoft Graph and directory operations: reconnaissance, application credential modifications to establish persistence, and changes involving identities, groups and privileged roles. That last category is the one that outlives the incident, because a credential the AI agents added to an application keeps working after the compromised application itself has been shut off.

ConnectWise, for its part, published its first advisory on 16 October, disabled seven of its application identities on 17 October, suspended Cloud Backup, SaaS Security and Cloud Management, reset all accounts and credentials in the affected environment by 19 October, and has been publishing near-daily updates through its Trust Center. Its standing guidance is unchanged at the time of writing: keep affected application connections disabled until formal restoration instructions are issued, and review every tenant individually.

Microsoft's most important caveat deserves quoting in substance: the presence of an affected application, or even a successful authentication, does not necessarily indicate that customer data was accessed or exfiltrated. And the activity did not result from any compromise of or vulnerability in Microsoft's own systems. This was a vendor's application identities being abused, which is a different failure and a different fix. The distinction matters for readers who saw the incident described as a Microsoft breach: the cloud platform was the highway, not the target, and the guidance that follows applies to any tenant that trusted the affected applications.

The three hours that should change your assumptions

The number that will be quoted from this report is the time from initial targeting to privileged access: less than three hours, in multiple instances. Microsoft is explicit about why. AI agents are not constrained by factors affecting humans. They work around the clock, on weekends and holidays, and attempt multiple breach paths simultaneously. The speed compresses the window between selecting a target and achieving objectives, and it removes the natural pauses, working hours and fatigue that historically gave defenders hours or days between an intruder's steps.

But the report also documents the defence-side consequence, and it is the more actionable half: automated activity generates a large volume of traffic and log data that may generate alerts, and the speed of the AI agents allows very little time for defenders to respond to those alerts and remediate access in a coordinated fashion. Read together, the two halves describe a new detection budget. The organisation's incident response no longer has hours of quiet reconnaissance to work with. If the alert fires at hour two, the response process has maybe an hour to act before the adversary has privileged persistence.

One more detail makes the point sharper, and it concerns where AI agents showed up in the sequence. The password-spray campaign that preceded the ConnectWise abuse was a failure: 151,000 failed attempts, no success, alerts presumably firing throughout. The campaigns are not separated by whether defences made noise. They are separated by whether someone could act on the noise inside the compressed window. Volume alone stopped nothing, and the failed campaign is itself informative: AI agents spraying credentials generate enormous telemetry, and organisations that baseline their service-principal sign-in volumes would have seen the anomaly immediately.

The actor behind it, and the breadth of the target list

Storm-0940 is not a new name, and that matters for interpreting the AI angle. Microsoft has tracked the actor since 2021, historically using password spraying and exploitation of internet-facing applications for initial access, then moving through environments with compromised accounts and establishing persistence by adding credentials to existing OAuth applications to reach email and other data through Microsoft Graph. The AI framework did not change the playbook. It changed the tempo at which the playbook runs, and it moved the tempo decisions from human operators to AI agents that do not pause between steps.

The target list Microsoft publishes is worth reading in full, because it is not a niche: aerospace and defense, automotive, chemicals, energy, financial services, government, legal, manufacturing, media, military, semiconductor, software, technology, and think tanks and non-profits. Several of the ARTEX-driven attacks achieved privileged access to cloud infrastructure. The actor has no known industry aliases, and Microsoft's attribution is an assessment rather than a court record, but the breadth of industries named in its own telemetry shows the framework being aimed at ordinary enterprises, not only at defence contractors.

That breadth should adjust how the average organisation reads this incident. The lesson is not that a specific vendor product was hit. It is that a state-aligned actor now runs AI agents against a portfolio of targets spanning every sector, and any organisation that has granted a high-privilege third-party application standing access to its cloud environment is part of that portfolio's addressable surface. The industries named cover essentially every reader of this site, and the automation makes the cost of adding one more target effectively zero.

What ARTEX is, and what its use says

ARTEX is an open-source penetration testing framework that can use any AI model to automate offensive security workflows, a multi-agent LLM system written in Go with a Next.js frontend. Microsoft describes AI agents that run an autonomous penetration test from reconnaissance through data exfiltration with little human interaction, accumulating discovered assets and vulnerabilities into a graph as they work. Public reporting in October 2026 had already noted threat actor use of the framework, including data breaches at Korean financial institutions, and Microsoft has identified threat actors across multiple geographic regions using it.

The report stops short of moralising, but the implication is plain and worth stating carefully. A capable offensive automation framework is now publicly available, model-agnostic, and demonstrably adopted by a state-aligned actor within months, with AI agents carrying out the full intrusion chain rather than assisting individual steps. The tool is not the vulnerability; the vulnerabilities are the same ones security teams have always had, exposed credentials, over-permissive applications, weak MFA coverage, and AI agents simply find and chain them faster than any previous tooling. What changed is the pace at which those weaknesses can be found and chained. The CERT-In advisory on AI agents reached the same conclusion from the defender's side: conventional weaknesses, new economics. The two reports, one about criminal abuse of agentic tools and one about state use, triangulate the same operating environment.

There is also a supply chain lesson specific to this incident, and it pairs with the LiteLLM supply chain attack: one incident poisoned a package that developers installed deliberately, the other abused credentials of an application that tenants had authorised deliberately, and in both cases AI agents did the follow-on work. The entry point was not a vulnerability in ConnectWise's software. It was unauthorised access to application identities, the credentials of a multi-tenant application that customer tenants had already trusted. When a tenant grants a third-party application permissions, it inherits the security of that application's credentials for as long as the grant stands. That inheritance is invisible in most tenants' risk models.

What both vendors actually recommend

Microsoft's immediate actions and ConnectWise's guidance overlap heavily, and the combined list is practical.

Contain without destroying. Keep affected ConnectWise application connections disabled until formal restoration instructions arrive, and do not delete enterprise applications as a first response. Microsoft is explicit that irreversible changes should wait until configuration and evidence are preserved, because the sign-in records, audit trails and Graph telemetry are what let an organisation reconstruct what the AI agents touched. Deleting the application destroys the audit trail that tells you what happened inside your tenant.

Search by application ID, not display name. Review every tenant where the affected applications are or were installed or authorised, even if the integration is no longer in use, searching by application ID rather than display name. Display names are spoofable and inconsistent; application IDs are not. ConnectWise's advisory publishes the legitimate application IDs for exactly this purpose.

Review the right window. Microsoft advises reviewing activity from at least 15 October 2026, and, where records allow, extending service-principal sign-in review back to 1 October, because the AI agents reused infrastructure across campaigns and earlier activity may connect to the same operation. Review successful and failed service-principal sign-ins separately, and do not limit review to the published IPs, since the actors reused their infrastructure across campaigns and other identities and addresses may appear.

Hunt the persistence, not just the entry. The credential modifications the AI agents made inside victim tenants can remain active as a backdoor even after the original compromised application is mediated. Microsoft directs administrators to review audit records for application credential additions, new applications, service principals or owners, app-role assignments and consent grants, privileged role assignments, and changes to users, groups, authentication methods or Conditional Access. One of its detection tables documents an application self-assigning the Global Administrator role, which is the kind of persistence that survives cleanup of everything else, and the kind of step AI agents take without the hesitation a human operator might show before granting itself the highest role in the tenant.

Assume the mailbox was the target. The report lists reconnaissance through Microsoft 365 audit records: unusual mail or file access, downloads, forwarding, inbox and transport rules, delegated mailbox permissions. Email data theft has been Storm-0940's documented objective since 2021, and it is the objective AI agents execute fastest once they hold application access. An organisation that reviews application sign-ins but never checks for a new forwarding rule has looked at the door and missed the open window.

Fix the standing risk. Beyond this incident: least privilege for multi-tenant application permissions and consent grants, monitoring of credential additions and anomalous app-only activity on high-privilege applications, and verification that vendor credential rotation actually eliminated unauthorised access. This is the same closing move as the OpenCode MCP flaw and the AI agents campaign coverage: the boundary cannot live in trust, and trusted tools need the same monitoring as untrusted ones. The most durable control against AI agents abusing legitimate credentials is an identity system where every application's permissions are as small as its job allows. For organisations that consume managed services, the assurance guidance published alongside this incident adds the contract-level version: ask your provider whether it checked your environment, require least privilege and two-step verification on its access, and agree in advance on incident reporting terms.

Where the numbers stop

  • The 2,250-plus tenant figure counts sign-in attempts by the AI agents, not successful compromises. Microsoft states that most of the targeting was not successful and does not publish a count of tenants where privileged access was achieved.
  • The less-than-three-hours figure applies to multiple instances, not a median or a maximum. It is a floor on attacker speed, not a schedule.
  • The password-spray campaign produced no successful authentication, token issuance, Graph call or directory change in Microsoft's telemetry. Its relevance is the infrastructure linkage and the tempo, not a breach.
  • Whether customer data was accessed or exfiltrated in any specific tenant is not established by either vendor's public material. Microsoft says explicitly that authentication or application presence does not prove data access, and ConnectWise says its findings about stored archives do not establish whether individual live tenants were affected. Tenant-level review remains the only way to know.
  • Attribution is Microsoft's assessment, stated as such. The actor has no known industry aliases, and independent confirmation of the attribution is not available in the material reviewed.
  • ConnectWise's restoration timeline is still moving as of its late-October updates. Service status quoted here reflects the advisories read for this article, not the moment you are reading it.

FAQ

What is the ConnectWise Cloud Backup compromise?

An unauthorised access incident, first disclosed by ConnectWise on 16 October 2026, involving application identities associated with its Cloud Backup service, formerly SkyKick. Because that application is multi-tenant and was trusted inside many customer Microsoft 365 environments, control of its identities allowed sign-ins to customer tenants. Microsoft attributed the incident on 21 October to Storm-0940, a China-state aligned actor, which used the open-source ARTEX agentic AI framework to automate the abuse, attempting sign-ins at more than 2,250 tenants.

How fast was the attack?

In multiple instances, less than three hours elapsed from initial targeting to privileged access in a cloud environment. Microsoft attributes that speed to agentic automation: AI agents that work continuously, attempt multiple paths in parallel, and compress the time between target selection and objective. The same speed compresses the defender's window, because automated activity generates alerts faster than a coordinated human response can act on them.

What should an organisation that used ConnectWise Cloud Backup do first?

Follow the vendor and Microsoft guidance in this order: keep the affected application connections disabled until ConnectWise issues formal restoration instructions, and do not delete the enterprise applications, because preserving them preserves evidence. Then search your tenant for the published application IDs, review service-principal sign-ins from at least 15 October, check audit logs for application credential additions, role assignments and consent grants, and review mail audit logs for forwarding rules and unusual access. Those are the exact fingerprints the AI agents leave, and each check maps to a documented step in the campaign. If your IT provider used the service, ask them directly whether they reviewed your tenant.

The short version

Microsoft attributed the ConnectWise Cloud Backup compromise to Storm-0940 and documented the actor's use of ARTEX, an open-source agentic AI penetration framework, to automate the abuse of stolen multi-tenant application identities across more than 2,250 Microsoft 365 tenants, reaching privileged access in some environments in under three hours. The password-spray campaign that preceded it failed entirely, which shows the difference between alerting and responding. The persistence the AI agents established through credential modifications survives cleanup of the original application, so the response list runs from containment through tenant-by-tenant review of sign-ins, credential changes and mail rules. The standing lessons predate AI: least privilege on third-party application grants, monitoring of app-only activity, and treating every trusted vendor application as part of your own attack surface.

Sources
Subscription Form