Introduction
Five Cents AI Agents in Cyberattacks examines what ARTEX reportedly did in the Storm-0940 campaign, what the evidence actually proves, and how organizations can reduce their exposure. We’ll separate automated attack attempts from successful access, then look at the permissions and records that matter. The best starting point is the trusted application, not the AI.
A cloud integration can have its own identity and credentials
A cloud integration can have its own identity and credentials, separate from the people using it. When an organization authorizes a backup application, that application receives permissions to perform particular tasks. If attackers steal its credentials, they may be able to use permissions the customer has already granted. They don’t necessarily need to compromise a customer’s individual user account first.
That is the central mechanism in this case. ConnectWise disclosed unauthorized access to application identities associated with Cloud Backup. The attackers then tried to use those identities to enter customer Microsoft 365 environments where the applications were already authorized. The supply-chain risk came from an existing relationship with a trusted provider.
ARTEX reportedly accelerated work along that route. It is an open-source, multi-agent penetration-testing framework: software designed to coordinate AI agents carrying out security tasks. In legitimate testing, those tasks help assess defenses. Here, the reported activities included reconnaissance, password spraying, and abuse of application access through OAuth, the authorization system behind many cloud integrations.
The actor identified as Storm-0940 is described as China-state-aligned. In the account published on October twenty-first, twenty twenty-six, agents used compromised application access to authenticate to customer environments. Some then interacted with Microsoft Graph, an interface for accessing cloud resources and managing parts of an organization’s directory.
Those follow-on actions matter more than the mere presence of an AI tool. Observed activity included reconnaissance and changes involving application credentials, identities, groups, and privileged roles. Adding an application credential, for example, could give an attacker another way to return. Disabling the original integration would not necessarily remove that additional access.
But the numbers describe different outcomes
But the numbers describe different outcomes, and combining them would exaggerate the evidence. More than two thousand two hundred and fifty customer tenants were targeted with attempted sign-ins after the provider compromise. A tenant is an organization’s cloud environment. That figure measures attempted reach, not confirmed breaches.
A separately described password-spray campaign generated more than one hundred and fifty-one thousand failed sign-ins over five days. Password spraying means trying likely passwords across many accounts. In that particular subset, there was no successful authentication, no token issuance, no Graph call, and no directory change. Its scale should not be mistaken for success.
Elsewhere in the downstream activity, successful access and subsequent actions were observed in multiple customer environments. Some attacks reportedly reached privileged cloud access in under three hours. Most targeting, however, was unsuccessful. These findings can coexist because they describe different parts of the campaign.
There’s another distinction: successful authentication does not automatically establish data theft. It shows that an identity was accepted. Investigators must then determine what permissions it had, what actions followed, which resources were accessed, and whether information was actually removed. Even privileged access is not, by itself, proof of exfiltration.
What does this establish about AI? The supported claim is acceleration within an intrusion workflow. It does not establish that ARTEX invented the campaign, discovered the original route into ConnectWise, or operated throughout without human direction. The provider’s initial root cause remained under investigation in the published updates. A framework’s ability to automate a broad workflow is not proof that every stage occurred at every target.
Why it matters
For defenders, that points to a focused response rather than a search for something uniquely identifiable as AI. First, establish which third-party applications have access, why they need it, and who owns them. Review actual application identifiers, not just familiar display names. Include previously authorized integrations, and remove unnecessary access.
Then connect service-principal sign-in records with subsequent activity. A service principal is the application’s identity inside a customer tenant. Check credential additions, consent changes, privileged-role assignments, directory changes, and resource access. An unusual sign-in is an investigative lead. The actions around it help establish the consequences.
Preserve relevant logs before making changes, follow current vendor containment instructions, and check for persistence beyond the original application before restoring access. Multifactor authentication remains important for user accounts, but it does not replace reviewing application credentials and permissions.
The central findings are specific: AI reportedly increased operational speed, existing application trust enabled the access route, and attempted reach must remain separate from confirmed compromise or theft. To explore this further, you can generate two new Five Cents episodes: Auditing Third-Party Cloud Permissions, or Investigating Cloud Identity Persistence. And with that, you're up to speed in a few minutes.