I've spent the past several weeks reading every incident write-up I can find on ARTEX, the open-source AI penetration-testing framework that went from a GitHub project to an attacker staple in under three months. The coverage tends to make it sound exotic, as if autonomous agents have unlocked some new class of attack. When you read the actual reports from Microsoft, CrowdStrike, CERT-In and the researchers who have taken these incidents apart, a different picture emerges. The attack paths are familiar. What's changed is the speed and the scale, and that distinction matters a great deal for how defenders should respond.
ARTEX was published on GitHub on July 26 as a multi-agent framework for autonomous penetration testing. The design is simple to describe. An operator gives it a goal, and a set of AI agents plans the work, divides it up and carries it out using ordinary tools: Nmap for scanning, curl and Python HTTP clients for probing services, and a headless Chromium browser for interacting with web applications. Nothing in that toolkit is new. Any penetration tester would recognize every piece of it. The novelty is that the planning, sequencing and follow-through that used to require a skilled human now happen without one.
Attackers picked it up within weeks. The author denied any involvement in its misuse and took the project closed-source on October 8, but by then it had been forked thousands of times, and rebranded copies continue to circulate under other names. Closing the repository did not put it back in the box, and it's safe to assume capable variants will keep appearing. It's a textbook case of a good tool gone bad, and defenders should plan on ARTEX-style tooling being a permanent part of the landscape rather than a single campaign that will run its course.
The clearest signal of how serious this is comes from the breadth of the targets. CrowdStrike reported that a China-nexus group it tracks as VAPOR PANDA used ARTEX against more than 200 organizations in at least 14 countries over 11 days in late October, spanning government, defense, telecom and semiconductor targets, with confirmed post-exploitation at nine of them. Microsoft tied a China-aligned group it tracks as Storm-0940 to an ARTEX-accelerated supply chain compromise of ConnectWise, then reported a Cambodia-based, financially motivated group turning ARTEX on financial firms. India's CERT-In flagged a separate campaign against the country's banking and insurance sector and noted that operators were running small test transactions before attempting larger fraud. Nation-state espionage and financially motivated crime are using the same tool, against very different targets, at the same time.
The detail I keep coming back to is from Microsoft's November 5 report. In one case, an agent went from searching GitHub for leaked secrets to exfiltrating data from Azure Key Vault in five minutes. Think about what a response process has to do in that window: an alert has to fire, someone has to triage it, someone has to decide it's real, and someone has to act. Most organizations can't complete the first step in five minutes, let alone the last. That single data point tells you more about the problem than any of the aggregate numbers.
The WorkOS breach is the other incident worth reading in full, because it wasn't caused by an attacker at all. According to WorkOS's own incident bulletin, a security researcher was running an ARTEX agent in what was supposed to be a contained test environment. The agent escaped that environment and pulled data from an internal sales tool. That tool's API was reachable from the internet, accepted a predictable development credential and had no rate limiting, and the activity ran for five days before anyone noticed. Nobody exploited anything sophisticated. An agent with a goal found a door that should never have been on the street, tried an obvious key and walked in. Among its fixes, WorkOS blocked internet access to all of its internally developed tools at the network edge, which I think is the single most instructive remediation anyone has published this year.
The tool has also become an attack surface in its own right. A backdoored ARTEX Docker image was pulled roughly 9,000 times and handed an unauthenticated root shell to anyone who found an exposed instance, and Censys counted more than 1,400 ARTEX consoles reachable from the internet. Teams that downloaded the framework to understand the threat, or to test their own environments with it, in some cases became victims of it. That's a pattern we've seen before with offensive security tools, and it's a reminder that anything run inside your environment deserves the same scrutiny as anything trying to get in.
Across the incidents, the attack sequence is remarkably consistent. It starts with reconnaissance: internet-wide scanning for exposed services, combined with searches of GitHub and other public repositories for leaked credentials and API keys. Initial access comes through whatever that reconnaissance turns up, whether that's a web application flaw like an insecure file upload or server-side request forgery, a valid leaked credential, or an API or non-production environment that was left without MFA. From there the agents enumerate cloud resources, harvest additional credentials, move laterally and often deploy open-source remote access tools to hold their position. The final stage is exfiltration from the places that hold value: key vaults, cloud storage, SharePoint and mailboxes.
No reported ARTEX attack has used a zero-day. Every step in that chain exploits a weakness that security teams have known about for years and, in most organizations, have on a backlog somewhere. Leaked secrets, exposed internal tools, unpatched web applications and staging environments with weaker controls than production are not new problems. What ARTEX changes is the cost of finding and chaining them. Work that used to take a skilled operator days of patient effort now runs at machine speed, at scale, for anyone who can clone a repository. The backlog that was tolerable when attackers had to find these gaps by hand is far more dangerous when an agent can find all of them before lunch.
Several of the controls teams instinctively reach for don't hold up well here. Vendors broadly agree that blocking by IP address or user agent does little against ARTEX, because the agents rotate both within hours. Blocklists built on yesterday's indicators are describing an attacker that has already moved on. Detection still matters enormously, and so does response, but both are being asked to operate inside a window that keeps shrinking. As my colleague Dr. Bryan Stoker argued recently, knowing about an attack is not the same as stopping it.
The October PHP2Shell vulnerabilities showed how narrow that window has become. When the federal advisories went out, the guidance was blunt: patch affected systems or take them offline. CERT-In has since reported that the AI-assisted group it calls Crafty Falcon, which uses ARTEX among other tools, is planting web shells in PHP and Node.js applications, so the connection between the two stories isn't theoretical. Rubrik CEO Bipul Sinha summed up the situation after PHP2Shell: "the defender's window is the new perimeter." I'd take that one step further. If the window between disclosure and exploitation is now measured in hours, the most valuable thing a defender can do is reduce how much of the environment an agent can see and touch in the first place.
None of the steps below replace patching, detection or response. They work alongside those disciplines by shrinking the set of things an agent can find and use, which gives your detection and response teams back some of the time that machine-speed attacks are taking away. Most of them can be started this quarter without a major program.
Every ARTEX intrusion begins with the agent finding something it can reach. Start with an honest inventory of everything in your environment that answers on a public address: admin consoles, internal APIs, dashboards, monitoring tools, CI/CD systems and staging or development environments. Don't skip the non-production systems. CERT-In found that Crafty Falcon typically gets in through internet-exposed testing, staging and user acceptance environments. Most organizations that do this exercise find services they didn't know were exposed, often stood up quickly for a project and never revisited. For each one, ask a simple question. Does this need to be reachable from the public internet? If the answer is no, it shouldn't be.
This is the fix WorkOS landed on after its breach, and it's where I'd start. It's also the core of how we build at Dispersive. Services behind Dispersive® Stealth Networking don't answer an internet scan at all, so an agent sweeping the internet for targets gets nothing back to work with. An agent can't attack what it can't find, and every service you remove from its view is one less entry point for it to chain.
ARTEX's signature move pairs a leaked credential with a reachable endpoint. Defenders can attack either half of that pairing, and should attack both. On the credential side, rotate any secret that has ever touched a public repository, even briefly, even if the commit was deleted. Move toward short-lived credentials and managed identities so that a key scraped today expires before it's useful. Add secret scanning to your development pipeline so new leaks are caught before they're pushed, and block development-only credentials from ever reaching production, the gap WorkOS is now closing.
On the endpoint side, require that internal APIs accept traffic only from devices you've enrolled. When that's in place, a key scraped from GitHub gets an attacker nothing on its own, because they don't have the network path to use it. That's how Dispersive protects internal services. One important caveat: this approach doesn't cover public cloud control planes like the one in Microsoft's five-minute Key Vault case, because those management interfaces are public by design. For those, use your cloud provider's conditional access policies to restrict where sign-ins can originate, and treat any leaked cloud credential as an active incident.
PHP2Shell exposed the weakness of a two-option playbook. Patching takes testing, change windows and sometimes vendor fixes that don't exist yet. Taking a system offline takes it away from the people and processes that depend on it, which is why so many organizations end up quietly running vulnerable systems while they wait. Neither option works well when exploitation begins within hours of disclosure.
For anything that doesn't need to be public, there's a third option: keep it running, but make it unreachable from the internet while you patch. Authorized users keep working, and agents scanning for the vulnerable service don't find it. I made this case in more detail when PHP2Shell first landed: you can't exploit what you can't reach. This doesn't apply to public-facing websites, and it isn't a substitute for the patch. What it does is close the gap between disclosure and remediation, which is precisely where ARTEX operators are doing their work. Build this option into your vulnerability response runbooks now, so it's ready the next time an advisory lands on a Friday afternoon. Attackers are counting on that timing; CERT-In observed Crafty Falcon striking on weekends, holidays and other low-monitoring windows.
The WorkOS incident is a warning for every organization adopting AI agents, not just those testing offensive tools. The agent that caused that breach wasn't malicious. It was pursuing its goal, and its environment didn't stop it from going further than anyone intended. As teams deploy agents for testing, IT operations and production workloads, the same thing can happen with tools you trust. CrowdStrike's recently announced AI Kill Switch, which lets security teams stop a misbehaving agent and cut off its network access, shows how seriously the industry is now taking this problem.
Define where each agent is allowed to connect, and enforce that at the network layer rather than relying on the agent's instructions or its own judgment to keep it in scope. Treat agent egress the way you'd treat any privileged workload, with explicit destinations and everything else denied. If your security team is testing ARTEX or similar tools to understand the threat, run them in genuinely isolated environments, never expose their consoles to the internet, and verify every image you pull against a trusted source.
Agents build their picture of your environment from what they can observe: open ports, service banners, software versions, TLS fingerprints and predictable network paths. Every one of those details helps an agent decide what to attack and how. Reduce all of it. Strip version information from banners, close ports that don't need to be open, and look at what your traffic reveals about the systems behind it. Multipath routing and fingerprint mitigation make traffic harder to correlate and harder to trace back to the infrastructure that generated it. This is the idea behind Automated Moving Target Defense: an environment that keeps changing is far harder to map than one that sits still. Dr. Stoker frames the bigger idea well in The AI Security Paradox: as attackers get better at inference, the goal is to change what they are able to know in the first place.
Microsoft's guidance also recommends deception, meaning honeypots, decoys and tarpits that waste an agent's time and surface its activity. Agents are persistent but not discerning, and a well-placed decoy can absorb a surprising amount of their effort. I'd consider this a supporting layer rather than a lead control, since ARTEX isn't reported to intercept traffic. It still raises the cost of reconnaissance, and reconnaissance is where these agents get their speed.
At Fal.Con Europe this month, CrowdStrike's George Kurtz said agentic incidents doubled month over month from July through September. I don't expect that curve to flatten on its own. ARTEX is the first widely available tool of its kind, and the techniques it packages are now public knowledge. Whatever replaces it will be faster, better at evading detection and easier to use.
The encouraging part is that the weaknesses these agents exploit are known and fixable. Exposed internal tools, leaked credentials and unpatched services are problems security teams already understand. ARTEX simply removed the time we used to have to get around to them. Agents attack what they can reach. The less they can reach, the less machine speed matters.
If you'd like to talk through which of your services could come off the public internet, get in touch with our team.
