The Attackers Have Agentic Pentest Tools Now

The same kind of tool a security team uses to find its own weaknesses, an agentic framework that scans, probes, and chains steps on its own, just turned up on the other side of a real nation-state attack.

On October 21, 2026, Microsoft Threat Intelligence said a China state-aligned group it tracks as Storm-0940 ran a supply chain compromise through an agentic AI penetration testing framework called ARTEX. This was no lab demo. It hit hundreds of organizations.

If you manage a Microsoft 365 tenant, or you rely on a SaaS vendor whose app has access into your tenant, this one is worth your attention for reasons I will get to.

What Actually Happened

ARTEX is a Go-based agentic pentest framework. It started out open source and was pushed closed-source after it got abused in attacks on South Korean financial institutions, which tells you where it had already been pointed before this. Microsoft says Storm-0940 has been using it since at least September 2026 to automate attacks across a wide spread of industries.

The piece that matters is how the ConnectWise part worked. Microsoft assesses that Storm-0940 was behind the ConnectWise Cloud Backup compromise, a multi-tenant application that a lot of downstream customers had already granted access to. ConnectWise disclosed the unauthorized access on October 16 and suspended its Cloud Backup, SaaS Security, and Cloud Management services while it investigated. Once the attacker held the application's credentials, ARTEX-driven agents used them to authenticate straight into customer environments, with no interactive user sign-in required. That is the quiet part of a supply chain attack. The attacker does not pick your lock, it walks in on a key you already handed to a vendor.

The numbers give you the speed. Microsoft says the agents attempted to sign in to more than 2,250 downstream tenants, at up to 2,900 sign-in attempts per minute, and reached privileged cloud access at some organizations in under 3 hours. After getting in, the follow-on work included reconnaissance, changing application credentials, and attempts to modify privileges so the access would stick around.

One detail I want to be straight about, because the reporting splits here. There was an earlier password-spraying phase, and BankInfoSecurity reports that Microsoft's own telemetry showed that spray did not land. The part that worked was the OAuth application credential abuse, where the stolen app identity let the attacker skip the login. So "they sprayed thousands of accounts and walked in" is the wrong read. The spray mostly failed, and the stolen application trust is what paid off. [RE-VERIFY both the phase breakdown and the tenant and sign-in figures before publishing, since this disclosure is days old and may be updated.]

Microsoft also made a point of saying the activity did not come from any compromise of, or flaw in, its own corporate systems, products, or services.

Why This One Is Different

Offensive automation is not new. Password-spraying scripts and scanners have existed forever. What changed is that the orchestration between steps is now autonomous, so recon, credential abuse, and privilege changes run one after another at machine speed with nobody steering each move. Zscaler reportedly found ARTEX wired up to run on several commodity models through OpenAI-compatible gateways, which is to say the inference behind it is cheap and swappable. [RE-VERIFY the Zscaler model-configuration detail, which comes from one vendor's analysis.]

The practical problem for defenders is the clock. If an attacker can go from stolen application credential to privileged access in under 3 hours, then an incident response process built around a human noticing something the next morning is already behind.

There is a second lesson underneath the AI story, and it is older than any of this. The attacker never needed your password. It needed an application you trusted that had broad access across tenants. Every OAuth app with cross-tenant permissions is a door you already propped open for someone else, and this is the week to go count how many of those doors you have.

What To Check This Week

Start with your service principal and application sign-ins in Microsoft 365, since that is where this attack lived. Look for app-based authentication you cannot explain, especially sign-ins tied to third-party backup or management tools. Review which OAuth applications hold broad or cross-tenant permissions in your tenant, and ask for each one whether it still needs that much reach. Watch for unexpected application credential changes or new privileges granted to an existing app, which is the persistence move Microsoft described. If you use ConnectWise Cloud Backup, check their advisories directly and follow their guidance on credentials and restoration.

Microsoft's blog has the full indicators of compromise and Defender detection details, so pull those for your SOC rather than working from a summary.

Where This Leaves You

The uncomfortable part is that the tooling has evened out. The automation that lets a defender test an estate quickly is the same shape of automation an attacker can now point at yours, and the attacker is already running it against real companies. The response is not to fear the tools. It is to make sure someone is testing your own exposure at the speed the attackers now move, starting with the trust you have handed to third-party applications.

If you want help mapping which of your connected applications could be abused this way and proving whether that path is actually reachable, a CredShields researcher can walk you through testing your OAuth and application-trust exposure and confirming what an attacker could reach from a compromised vendor app. Scope is set per engagement around the size of your estate. You can start at credshields, or look at a sample report to see how we prove and document each finding.