What Happened
Microsoft assesses that Storm-0940, a China-state-aligned actor, used the ARTEX AI penetration-testing framework to accelerate attacks and was responsible for a ConnectWise Cloud Backup supply-chain compromise. In one October 10–14 campaign, Microsoft observed more than 151,000 failed logons against 327 accounts at eight organizations, with no successful authentication in that campaign. Following the ConnectWise compromise, stolen application credentials were used in attempted sign-ins to more than 2,250 tenants. Some environments showed subsequent Microsoft Graph activity and changes that could establish persistence. Microsoft says the activity did not result from a vulnerability in its products or services. [3]
Separately, eight eMudhra intermediate certificate-authority private keys were compromised. Those keys could be used to sign unauthorized TLS certificates, creating a potential path to man-in-the-middle interception. Unit 42 has also examined the current landscape of OAuth attacks and published protective guidance. [1][2]
Why It Matters to Businesses
These cases expose three distinct trust boundaries: a vendor application’s access to a customer tenant, the credentials and permissions behind OAuth integrations, and the certificate authorities trusted by TLS clients. AI-assisted tooling may increase an attacker’s operating speed, but the business impact still depends on where access is granted and what defenders can observe. An attempted or successful sign-in alone does not prove customer data was accessed or exfiltrated; Graph activity, permission changes and data-access evidence require separate investigation. [1][2][3]
Kimbodo Engineering Perspective
For production AI applications and agents, the practical priority is to limit the authority of every integration. An agent with a broadly privileged service principal can turn a compromised credential into a tenant-wide problem, regardless of whether the initial attack used AI. Narrow permissions, short-lived credentials where supported, and explicit approval for sensitive actions reduce that exposure. Detection must cover application identities and Graph operations, not just human logons or known attacker IP addresses. [3]
How We Would Implement It
- Contain affected vendor access: follow ConnectWise guidance, keep affected connections disabled until instructed otherwise, and preserve evidence before removing unauthorized access. [3]
- Investigate identity activity: inventory all four relevant application IDs; review service-principal sign-ins, application credentials, granted permissions, Graph activity, and unexpected credential or privilege changes. Investigate beyond published IP indicators. [3]
- Reduce standing access: apply least privilege, rotate affected credentials, and verify that vendor and tenant remediation actually ended unauthorized access. Use available Defender XDR detections and advanced-hunting guidance to support the investigation. [3]
- Check certificate exposure: use Unit 42’s containment guidance to assess whether systems trust the affected eMudhra intermediates and whether certificate-related controls need updating. [1]
Risks, Costs and Security
Disabling integrations can interrupt backups or dependent workflows; rotating credentials and reducing permissions can break legitimate automation. Plan those changes with service owners, test restored access, and retain investigation records. Conversely, restoring a vendor connection before verifying its credentials, permissions and activity leaves the original trust path open. For the eMudhra incident, treat the compromised keys as a certificate-trust risk, not as proof that any particular connection was intercepted. [1][3]
Where Kimbodo Comes In
Kimbodo builds and operates this in production for businesses — see our AI Security & Guardrails practice, or Request a Security Review.
