Offensive AI agents targeted more than 2,250 Microsoft 365 customers: what a CIO should check

What happened

On 15 October 2026, public reports flagged an incident at ConnectWise, an IT management software vendor widely used by service providers. On the 16th, ConnectWise published a first advisory. On the 21st, Microsoft published its analysis: the actor it calls Storm-0940, which it describes as China-state aligned, used unauthorised access to the ConnectWise Cloud Backup service to attempt sign-ins to more than 2,250 Microsoft 365 tenants, using the identities of ConnectWise applications those customers had authorised. The attribution is Microsoft's assessment.

The tool used is called ARTEX: an open-source, multi-agent penetration testing framework that can run on any AI model to automate reconnaissance, password attacks and application abuse. According to Microsoft, several attacks led to privileged cloud access, in some cases less than three hours after first targeting.

What is established, and what is not

Established by Microsoft. In several environments, the attacker ran reconnaissance through Microsoft Graph, added credentials to applications to keep access, and attempted to change identities, groups and privileged roles. One ConnectWise application assigned itself the Global Administrator role. Bulk secret reads across several Key Vaults were observed.

Not established. A data breach. Microsoft writes that the presence of an affected application or a successful sign-in "does not necessarily indicate" that data was accessed or exfiltrated, and that most of the targeting failed. Microsoft's own systems were not compromised.

Why this is a leadership issue

Two things change. Speed, first: when agents chain reconnaissance and privilege escalation within hours, a monthly access review arrives after the battle. The door, second: no Microsoft vulnerability was exploited. The attacker came in through trust already granted, a third-party application authorised in the directory with broad permissions, acting without any human sign-in and therefore without multi-factor authentication.

Most companies know how many employees they have. Few know how many applications and agents are allowed to act in their environment, with which permissions, and who authorised them.

What Microsoft asks customers to check

• Search for the affected applications by application ID, not by display name, in every tenant where they are or were authorised.
• Preserve Entra sign-in and audit logs, Purview records and SIEM data before making changes.
• Review service principal sign-ins from at least 15 October 2026, and from 1 October where logs exist, without limiting the review to the published IP addresses.
• Audit credential additions, new applications or owners, consent grants, privileged role assignments and Conditional Access changes.
• Do not delete the enterprise application as a first response: Microsoft asks customers to preserve configuration and evidence before any irreversible change.

What a well-equipped team does differently

It keeps a living register of the applications and agents that act in its environment, with their permissions and a named owner. It continuously monitors high-privilege application sign-ins and credential additions. And it can prove after the fact what was seen, when and by whom, because its logs were kept and dated before the incident, not rebuilt afterwards.

That is the logic of Cockpit: the AI register, with the risk class of each system and the history of its changes, and dated evidence that an auditor or an insurer can verify.

The danger	The advice
Third-party applications authorised in your directory are inventoried nowhere, or only by name.	Keep a register of authorised applications and agents, by application ID, with their permissions and a named owner.
Application sign-ins, with no user and no multi-factor authentication, are only reviewed after an incident.	Continuously monitor high-privilege application sign-ins and credential additions, with an alert.
The first reflex on an alert is to delete the suspicious application.	Preserve configuration and logs first: without them, you can prove neither the extent nor the absence of impact.