Three Hours to Privileged Access: Agentic AI Attackers and Why Your Risk Ratings Are Out of Date

On October 21, 2026, Microsoft published details of a campaign by a group it tracks as Storm-0940, which it assesses as China-state aligned. The group used ARTEX, an open-source multi-agent framework that uses large language models to run offensive security work "from reconnaissance through data exfiltration with little needed human interaction."

After gaining control of the identities of several ConnectWise cloud applications, the agents used the trust those applications already held inside customer environments to attempt sign-ins to more than 2,250 Microsoft cloud tenants. Targets spanned aerospace and defense, manufacturing, financial services, government, healthcare-adjacent industries and technology. Microsoft reports that in some cases the time from initial targeting to privileged access was less than three hours, and that the agents read secrets at scale across multiple key vaults.

Microsoft is careful to note that most of the targeting was not successful, and that an authenticated sign-in does not by itself mean data was taken. But the campaign changes an assumption that sits, usually unexamined, in almost every risk analysis.

The Case Study: A Trusted Application, Turned

The detail that matters most for engineering organisations is the route in. The attackers did not need to break each victim's defenses one by one. They took over an application that customers had already granted access to their environments, a cloud backup service, and used that standing permission everywhere it existed.

Microsoft's timeline shows the agentic approach at work:

1. October 10–14: a password-spray campaign against 327 accounts at eight organisations, with more than 151,000 failed sign-ins, peaking at around 2,900 attempts a minute. None succeeded
2. Mid-October: activity through the compromised ConnectWise application identities began to surface publicly, and ConnectWise published an advisory
3. Inside affected tenants: directory reconnaissance, new credentials added to applications for persistence, attempts to change privileged roles, and bulk reads of stored secrets

Microsoft notes the agents worked "around the clock, on weekends, and on holidays," trying several paths at once.

What Changed: Occurrence Was Never a Fixed Number

Every risk method has a likelihood term. In FMEA it is Occurrence. In cybersecurity engineering under ISO/SAE 21434, it is attack feasibility, assessed through factors such as elapsed time, specialist expertise, knowledge of the item, window of opportunity and equipment.

Look at those factors again with this campaign in mind:

• Elapsed time — an agent that never sleeps compresses weeks of effort into hours
• Specialist expertise — the framework packages the expertise; the operator supplies a target
• Window of opportunity — weekends and holidays, when human defenders are thinnest, are no longer quiet for the attacker
• Equipment — an open-source framework and commodity AI models

Many attack paths were rated "unlikely" because they required a skilled person to spend a long time on them. That reasoning was sound when it was written. It is now out of date, and nothing in most risk registers forces anyone to notice.

How FMEA Could Have Prevented This

FMEA's value here is not a new technique. It is the discipline of re-rating when the world changes, and of recording why each rating was chosen so that a reviewer can see which ones depended on the old assumption.

Two analyses would have changed outcomes for affected organisations:

• Interface analysis of third-party applications. A backup tool with standing access to email and files is an interface with the same authority as an administrator. It belongs in the structure analysis, with its permissions as part of its function statement
• Detection measured against attacker speed. If an attacker can reach privileged access in under three hours, a control that is reviewed weekly is not a detection control for that failure mode. Rate it accordingly

Applying the AIAG-VDA 7-Step FMEA Process

1. Step 1: Planning and Preparation – Add a recurring trigger: "re-rate occurrence when the threat landscape changes materially." This campaign qualifies.
2. Step 2: Structure Analysis – Include every third-party application that holds consent in your cloud tenant, with the permissions it holds. Most organisations will find applications nobody remembers approving.
3. Step 3: Function Analysis – Describe each application's function in terms of authority: "reads all mailboxes," "can add credentials to other applications." That is what an attacker inherits.
4. Step 4: Failure Analysis – Model "supplier application identity controlled by an attacker" as a failure mode in its own right, separate from "our own accounts compromised."
5. Step 5: Risk Analysis – Revisit occurrence for any attack path whose rating relied on effort, time or expertise. Revisit detection for any control slower than a few hours.
6. Step 6: Optimization – Reduce standing third-party permissions, alert on new credentials added to applications, and rehearse response.
7. Step 7: Results Documentation – Record the re-rating and its reason. Next year, someone will need to know why the numbers moved.

Key Failure Modes to Document

Trusted Third-Party Application Abused

• Function: Back up or synchronise data on your behalf, using permissions granted in your cloud tenant
• Failure Mode: The supplier's application identity is controlled by an attacker
• Effects: Attacker inherits every permission the application holds, across every customer that granted them, without breaching your own accounts
• Causes: Broad, standing consent granted at onboarding and never reviewed; supplier credential theft
• Current Controls: Supplier's own security; annual access review, if any
• Recommended Actions: Inventory and minimise third-party consents; alert on unusual application-only activity and on credentials added to applications; require suppliers to disclose how their application credentials are protected

Detection Slower Than the Attacker

• Function: Identify unauthorised privileged activity in time to contain it
• Failure Mode: Detection and response take longer than the attacker's time to privileged access
• Effects: By the time anyone looks, persistence is established and secrets have been read
• Causes: Reviews scheduled for business hours; alerts routed to people who are off shift; detection rated as if attackers were human-paced
• Current Controls: Periodic log review
• Recommended Actions: Rate detection against a time-to-privilege of hours, not days; automate containment for high-confidence signals; make sure someone receives critical alerts at weekends

Response That Destroys the Evidence

• Function: Contain a compromise while preserving what investigators and regulators will need
• Failure Mode: Responders delete the affected application or reset everything before capturing records
• Effects: Scope cannot be established; customers and regulators cannot be told with confidence what was accessed
• Causes: No documented response order; pressure to "make it stop"
• Current Controls: Ad-hoc response by whoever is available
• Recommended Actions: Write the response order down: disable, preserve sign-in and audit records, then remove. Microsoft's own guidance for this campaign is explicit that deleting the enterprise applications should not be the first step

From Failure Modes to Requirements

As with every FMEA, the actions become requirements with owners and tests:

• "Third-party applications shall hold only the permissions their documented function requires, reviewed quarterly." Verified by access review records.
• "Credential additions to any application shall raise an alert within fifteen minutes, at any hour." Verified by a periodic alert test.
• "Incident response shall preserve identity and audit records before removing any compromised application." Verified by a tabletop exercise.

Conclusion

For aerospace, defense and manufacturing organisations, this is not someone else's problem. They were named among the targets. And the analytical habits they already use for product safety, structured decomposition, honest likelihood ratings and traceable actions, are precisely what this kind of threat demands of their IT and engineering systems too.

The lesson is not that AI makes attackers unstoppable. Most of this campaign failed. The lesson is that risk ratings carry assumptions, and the assumption that an attacker is a person working office hours just expired.

NirmIQ keeps FMEA, requirements and verification in one traceable model, so when an assumption changes you can find every rating that depended on it, re-rate it, and show your auditors and customers exactly what you did. NirmIQ also tracks ISO/SAE 21434 compliance alongside ISO 26262, DO-178C and IEC 62304. See how it works.

Further reading:

• Hyundai's $900 Million Recall and the OEM-Supplier Disconnect That Caused It
• One Upgrade Away: What the LiteLLM Compromise Teaches About Common-Cause Failure

Sources: Microsoft Security Blog, "AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise" (October 21, 2026); ConnectWise advisory (October 16, 2026). Figures are as reported at the time of writing and may change as investigations continue.