When Storm-0940 used ARTEX to attempt 2,900 sign-ins per minute across more than 2,250 tenants, most defenders were unaware until it was too late. In some cases, the time from initial targeting to privileged cloud access was under three hours.
These aren't isolated failures. They're the result of five structural mistakes that turn AI-driven reconnaissance from a theoretical risk into a supply chain breach. Here's why these errors persist, what they cost you, and how to fix them before the next automated campaign hits your OAuth perimeter.
Why These Mistakes Keep Happening
AI agent frameworks like ARTEX exploit the gap between your policy and runtime enforcement at machine speed. Traditional defenses assume human-paced attacks, but AI agents work continuously, testing multiple breach paths simultaneously and iterating faster than your quarterly security reviews.
The result: controls that worked against manual intrusion fail when an adversary operates 24 hours straight, rotates IPs in minutes, and completes reconnaissance faster than your SOC can triage an alert queue.
Mistake 1: Treating OAuth Applications Like Static Trust Anchors
Why it happens: You granted OAuth access to a vendor's cloud application during onboarding. That app sits in your tenant with delegated permissions to Microsoft 365 or Exchange Online. You assume the vendor controls the app identity, so you don't monitor its authentication behavior post-deployment.
The consequence: When Storm-0940 compromised ConnectWise cloud application identities, those apps became persistent backdoors. The agents authenticated to customer environments using stolen app credentials, exploiting the trust you'd already granted. Microsoft observed the adversary modifying application credentials to establish persistence across identities, groups, and privileged roles. Those changes can remain active even after you revoke the original compromised app.
The fix: Implement continuous authentication monitoring for all OAuth applications with delegated permissions. Set thresholds for sign-in velocity, geographic anomalies, and credential modification events. When an app that normally authenticates 50 times per day suddenly attempts 2,900 sign-ins per minute from a new IP range, that's an intrusion. Your SIEM should trigger an automated response: suspend the app's token issuance, alert the vendor, and require re-verification before restoring access.
Mistake 2: Relying on IP Reputation Without Behavioral Context
Why it happens: Your perimeter controls block known-bad IPs and rate-limit requests from single sources. You assume that's enough to stop password spraying.
The consequence: AI agents rotate infrastructure faster than your threat intelligence feeds update. During the ConnectWise incident, when defenders blocked one IP address, new addresses appeared within minutes. Storm-0940 used a consistent IP range but could pivot as needed. Over four days in October 2026, Microsoft captured more than 151,000 failed logon events, peaking at 2,900 failures per minute on October 11. Blocking individual IPs didn't stop the campaign; it just forced the adversary to shift infrastructure mid-attack.
The fix: Layer behavioral detection on top of IP reputation. Monitor for cross-tenant authentication patterns: when a single source attempts sign-ins across hundreds of organizations in a short window, that's reconnaissance, not legitimate business activity. Set alerts for sustained high-velocity failures against multiple accounts, even if the source IP changes. Storm-0940 targeted 327 accounts across eight organizations in one four-day window. Your controls should flag that as a coordinated campaign, not eight unrelated incidents.
Mistake 3: Assuming Vendor Compromise Ends at the Vendor's Perimeter
Why it happens: Your contract includes breach notification terms. You expect the vendor to tell you if they're compromised. Until then, you treat their application as trusted.
The consequence: When ConnectWise was compromised, the attack didn't stop at ConnectWise's infrastructure. Storm-0940 used the compromised application identities to authenticate to downstream customer environments. The adversary progressed beyond authentication to Microsoft Graph and directory operations: reconnaissance, credential modifications, and privilege escalation. You didn't lose data because ConnectWise was breached; you lost data because the breach gave the adversary a trusted path into your tenant.
The fix: Rewrite your vendor contracts to include real-time incident disclosure for any compromise of application identities with access to your environment. Require vendors to notify you within four hours of detecting unauthorized access to OAuth apps, API keys, or service principals that touch your tenant. Deploy canary accounts in your directory: low-privilege identities with no business function. If a vendor's app suddenly queries or modifies a canary account, you know reconnaissance is underway, even if the vendor hasn't notified you yet.
Mistake 4: Running Quarterly Access Reviews Against Real-Time Threats
Why it happens: Your governance framework requires periodic reviews of vendor access. You recertify OAuth permissions every 90 or 180 days. Between reviews, you assume the permissions remain appropriate.
The consequence: AI agents don't wait for your review cycle. Storm-0940 modified application credentials and privilege assignments during active intrusions. In several cases, the adversary achieved privileged access in under three hours. Your quarterly review will eventually catch the unauthorized changes, months after the adversary has exfiltrated data, established persistence, and moved laterally.
The fix: Automate privilege monitoring for all vendor-controlled identities. Deploy alerts for any modification to application credentials, group memberships, or role assignments outside your change control window. If a vendor's app adds a new credential or joins a privileged group, your system should require human approval before the change takes effect. This isn't a quarterly audit; it's runtime enforcement. Storm-0940's persistence mechanism relied on making changes that would survive the original app's revocation. If you catch and block those changes in real time, you break the persistence chain.
Mistake 5: Treating AI-Driven Attacks as a Future Problem
Why it happens: You've read about agentic AI in security research, but you haven't seen it in your environment. You assume you'll adapt when the threat becomes material.
The consequence: The threat is already material. Microsoft reported that Storm-0940 has been active since at least 2021 and targeted hundreds of organizations across aerospace, defense, automotive, chemicals, energy, financial services, government, legal, manufacturing, media, military, semiconductor, software, technology, and think tanks since September 2026. Other threat actors across multiple geographic regions are also weaponizing ARTEX. The framework uses models like DeepSeek, GLM, and Grok to divide investigation tasks and review findings. One custom deployment included prompts for extracting payment gateway API keys, exploiting NFT minting workflows, and gaining unauthorized administrative privileges. You're not preparing for a future threat; you're catching up to an adversary who's been using AI agents for years.
The fix: Audit your detection rules against machine-speed attack profiles. Can your SIEM distinguish between a human operator testing 10 passwords per minute and an AI agent testing 2,900 sign-ins per minute? If your rate limits are set for human behavior, you're blind to automated campaigns. Recalibrate your thresholds: any authentication source attempting more than 500 sign-ins per minute across multiple accounts should trigger an immediate block and investigation. Pressure your vendors to disclose whether they've implemented runtime protections against automated OAuth abuse. If they can't answer that question, they're not ready for AI-driven threats.
Prevention Checklist
- Deploy real-time monitoring for OAuth application authentication velocity and credential modifications
- Set alerts for cross-tenant authentication patterns and sustained high-velocity failures
- Require vendors to notify you within four hours of any compromise affecting application identities with access to your environment
- Implement canary accounts to detect unauthorized reconnaissance before vendor notification
- Automate privilege monitoring and require human approval for any runtime changes to vendor-controlled identities
- Audit detection rules against machine-speed attack profiles; recalibrate rate limits above 500 sign-ins per minute
- Verify that vendors have implemented runtime protections against automated OAuth abuse
- Review and revoke OAuth permissions for any application that hasn't authenticated in 90 days
- Test your incident response plan against a scenario where privileged access is achieved in under three hours
