AI-Driven Supply Chain Attacks: The Critical Risk Is Trusted Third-Party Identity

When a third-party cloud application identity can enter customer tenants, an attacker may not need to breach every organization one by one. The ConnectWise Cloud Backup incident illustrates this supply-chain exposure. Microsoft says the threat actor Storm-0940 used ARTEX, a multi-agent penetration-testing framework, to accelerate reconnaissance, password spraying and OAuth application abuse against downstream environments. AI did not create the underlying access path; it helped attackers use existing trust and permissions faster and at greater scale.

For organizations, the practical questions are specific: which identity does each third-party application use, what permissions has the tenant granted, and what can that identity reach? After an incident, disabling an integration may be necessary, but responders must also check credentials, consent grants, role changes and subsequent resource access for signs of persistence.

Diagram of a third-party application identity and its supply-chain trust path into customer cloud tenants

What Microsoft disclosed—and what the figures do not mean

In a threat-intelligence post dated October 21, 2026, Microsoft said Storm-0940 had used ARTEX since at least September to automate activity against hundreds of organizations across multiple industries. Microsoft assesses that Storm-0940 was responsible for the recently disclosed compromise of a ConnectWise multi-tenant application. On October 16, ConnectWise publicly reported unauthorized access to customer tenants involving multiple OAuth application identities.

The reported sequence is not that “AI hacked Microsoft.” Microsoft says the actor used affected third-party application identities to authenticate into Microsoft 365 customer environments where those applications had already been granted access, then used automation to accelerate reconnaissance and follow-on activity. Microsoft explicitly stated that this activity did not result from a compromise of, or vulnerability in, Microsoft corporate systems, products or services.

Stage	Publicly reported information	How to interpret it
Third-party application identities were misused	ConnectWise disclosed unauthorized use involving multiple OAuth application identities	Review applications installed or previously authorized in your own tenants, not just integrations currently in use
Automation accelerated activity across tenants	Microsoft reported activity reaching more than 2,250 tenants, with over 2,900 sign-in attempts per minute	These describe scale and pace; they do not mean every tenant was compromised
Follow-on identity and permission activity	Microsoft observed reconnaissance, application credential changes and permission-related operations in multiple customer environments	An application being present—or even a successful authentication—does not by itself prove data access or exfiltration
Some environments saw rapid privilege access	In several cases, Microsoft said the time from initial targeting to privileged cloud access was under three hours	Response windows can be short, but this outcome should not be attributed to every environment

A separate set of figures is easy to conflate with the downstream application activity. Microsoft observed a password-spray campaign from October 10–14 that generated more than 151,000 failed sign-in events against 327 accounts across eight organizations, peaking at about 2,900 failures per minute. Microsoft said it saw no successful authentication, token issuance, Graph call or directory change from that activity. Those failed attempts should not be combined with later activity involving compromised ConnectWise application identities to create an unsupported “successful breach count.”

AI changes speed and concurrency; the trust boundary remains central

Microsoft describes ARTEX as an open-source penetration-testing framework that can use different AI models and coordinate multiple large-language-model-driven agents. The activities Microsoft observed included faster scanning and reconnaissance, password spraying and OAuth application abuse. Security practitioners have also warned that agents can run multiple stages in parallel, compressing work that previously required sequential human effort.

Yet describing this incident simply as “AI hackers broke into the cloud” points defenders in the wrong direction. The critical conditions remain third-party application credentials and the permissions and trust relationships those identities hold in customer tenants. AI can shorten the time needed to probe, attempt and pursue access across targets; it does not replace the attacker’s use of identity material and authorization paths. Persistent high privileges for non-human identities, weak monitoring of credential changes and stale third-party grants make that existing weakness easier to exploit at machine speed.

That is why supply-chain risk cannot be reduced to contract reviews or annual vendor questionnaires. One integration may span many tenants, and its permissions can change long after deployment. Risk management needs a runtime view: which service principals are active, what they are authorized to do, what changed recently and which data or administrative actions they could reach.

Investigation map connecting application identity, sign-ins, Microsoft Graph activity, credential changes and privilege changes

Investigate the identity trail before removing evidence

Microsoft recommends reviewing every Microsoft 365 tenant where the affected applications are or were installed, and searching by application ID rather than relying on display names that can change. The review should include historical authorizations, not only active integrations. Record the tenant-specific service-principal object ID for each application so investigators can connect the application to the identity that actually exists in the tenant.

A practical evidence sequence is:

Service-principal sign-ins: Review successful and failed application-identity sign-ins separately. Compare source, time, target resource and expected business patterns. Do not restrict the hunt to a short list of published IP addresses.
Application and consent changes: Look for added or modified application credentials and owners, consent grants, app-role assignments and privileged role changes. Investigate unexpected self-assignment or privilege escalation by a service principal.
Microsoft Graph and resource activity: Correlate authentication with subsequent Graph operations. Review directory enumeration, credential changes, group or role changes, and unusual access to email, files or downloads.
Time range and evidence preservation: Microsoft recommends reviewing activity from at least October 15, 2026; where logs are available, extend service-principal sign-in review to October 1 and examine earlier failed authentications or volume anomalies. Preserve Entra, Purview, SIEM and existing Graph telemetry. Authorized incident responders should remove confirmed unauthorized credentials, grants and identities after preserving evidence.

Containment order matters. Microsoft advises keeping affected ConnectWise application connections disabled until the vendor issues formal restoration guidance. It also cautions against deleting enterprise applications as the first response, because doing so can remove configuration and investigative context. Assess the effect on backup and restore operations against current vendor guidance, preserve evidence, then contain and rotate credentials as appropriate. The authorized incident-response lead should base specific actions on evidence from the tenant.

Repeatable third-party application governance loop: inventory, least privilege, monitoring, evidence preservation and recovery

Turn vendor trust into auditable controls

Organizations can turn this incident into ongoing controls rather than a one-time review:

Maintain a third-party application inventory. Record application IDs, tenant-specific service-principal object IDs, business owners, vendors, authorization dates, permission scopes, linked tenants and shutdown procedures. Retain visibility into old integrations that may still have grants.
Reassess permissions against least privilege. Confirm that permissions match the application’s business purpose. Avoid broad, long-lived privileges granted merely for convenience, and assign clear ownership and approval for revoking access that is no longer needed.
Monitor non-human identity lifecycles. Alert on new credentials, rotations, anomalous authentication, permission grants and service-principal ownership changes. Ensure every alert has an accountable responder and a pre-agreed emergency containment path.
Include vendor incidents in your own response plan. Define how the organization will enumerate tenants, preserve logs, temporarily disable integrations, assess business continuity and restore service. A vendor notice is an input to the investigation, not a substitute for tenant-side validation.
Exercise response time. Simulate suspected compromise of a third-party application credential. Can the team identify every related identity, establish the potential access scope and revoke access safely within a business-acceptable window?

AI-driven supply-chain attacks do not mean every organization will be breached, nor that security tools using AI are inherently malicious. The operational change is that defenders may have less time for identity detection, permission review and coordinated response. Organizations relying on annual questionnaires instead of runtime governance—or treating “approved application” as a substitute for continuous audit—may miss when a trusted relationship is being abused.

DELine can help organizations review cloud identities and OAuth application permissions, design third-party access and least-privilege controls, and improve security monitoring and incident-response processes in their existing Microsoft environments. Visit DELine or contact DELine to discuss cloud identity and enterprise security governance.