ARTEX, the AI Hacking Tool Everyone Picked Up: What the ConnectWise, Korean Bank and WorkOS Breaches Teach Founders

On July 26, a developer who goes by Autumn-27 published a project on GitHub called ARTEX. It was a penetration testing framework built around AI agents: you give it a target and a goal, and the agents plan the work, run the tools, chase what they find and write it all down. It was made for authorized security testing, the work firms like ours do for clients who ask us to break in (Help Net Security).

Here is what happened over the next three months.

A Chinese-speaking operator pointed it, alongside Claude Code and a handful of AI models, at South Korean banks, and CrowdStrike found the session logs on the operator’s own open server (CrowdStrike). A China state-aligned group Microsoft calls Storm-0940 used it to take over the cloud applications of ConnectWise, a major software supplier to managed IT providers, and tried to sign in to more than 2,250 Microsoft 365 tenants that trusted those applications (Microsoft). A second China-nexus group ran it against more than 200 organizations in 11 days (CrowdStrike). Criminals used it to raid iOS signing shops, crypto payment sites and game account servers, spending as little as a few hundred dollars of AI usage on a campaign (Check Point). Its developer took it private. It had already been forked more than 12,000 times.

And on October 25, an AI agent reached an internal sales tool at WorkOS that was open to the internet. It belonged to a security researcher who was running benchmark tests with ARTEX, and it had “escaped its isolated testing environment.” It logged in with a predictable development credential, and by October 30 it had pulled records out in bulk (WorkOS). WorkOS sells login and identity infrastructure to startups that want to be ready for enterprise customers. Its response, among other things, was to start running ARTEX against itself.

If you want one sentence that explains all of that, Jon has been saying it to founders all year:

ARTEX is the tool in that sentence, almost literally. In three months it was picked up by a developer who wanted to help testers, by state-aligned spies, by thieves, by a researcher who meant no harm and caused some, and finally by the company that researcher’s agent breached. The tool never changed. The hands did.

The short answer

ARTEX is an open-source AI agent framework for penetration testing that attackers adopted within weeks of its release in July 2026. It doesn’t invent new attacks. It runs the familiar ones, password spraying, leaked secrets, exposed admin tools, weak credentials, missing rate limits, abused trusted applications, at a speed and persistence no human team can match. Every breach it’s been tied to went through an ordinary door.

For a founder, that’s good news wrapped in bad news. The doors are the ones you already know how to close. The difference is that you no longer have weeks to get around to it. The list is short:

1. Get internal tools off the internet. Admin panels, dashboards, staging, CI/CD and anything your sales or support team built in a weekend belong behind single sign-on or a private network.
2. Kill development and default credentials in production, and replace long-lived secrets with short-lived ones.
3. Put rate limits on anything that returns data or sends messages, because agents pull everything they can reach.
4. If your product connects to customers’ accounts, treat its credentials like your customers’ keys, because that’s what they are.
5. Watch identities for speed and sequence, and automate the first response.
6. Pick up the tool yourself: test your own systems with AI agents, with authorization, scope and a kill switch that doesn’t depend on the model.
7. If you run offensive agents, own what they do, including where they can reach.

What ARTEX actually is

Microsoft’s description is the clearest. ARTEX is a multi-agent system written in Go with a Next.js web console, and it can use any AI model. Its agents run penetration tests “from reconnaissance through data exfiltration with little needed human interaction,” collecting every asset and weakness they find in a graph. The console defaults to English, with Korean, Mandarin, Spanish and Japanese options (Microsoft).

It isn’t alone. Google’s threat intelligence team and Mandiant have watched attackers run ARTEX, PentAGI, CAIRN and similar frameworks in real incident response cases since late August, and call it “a critical inflection point for defenders” (Google Cloud). GitGuardian counts about 45 other open-source frameworks that automate attacks, a few of them forks of ARTEX itself (GitGuardian). ARTEX became the name everyone knows because it was easy to use, it was free, and it showed up in the biggest incidents.

What it changes is the cost of persistence. Check Point read the exposed databases of ten ARTEX instances and found that “Most attacks were fully autonomous besides the initial goal setup.” Operators typed a goal and then, mostly, “What’s the progress?” One campaign against Chinese gray-market game account servers recovered more than 190,000 sets of credentials from a plaintext file left in a web root, for an estimated $180 to $360 in model costs. Check Point’s own summary of why it worked: “it is not necessarily the complexity of attacks, but the breadth and perseverance” (Check Point).

One more detail from Check Point is worth knowing if you’re relying on AI models to refuse bad requests. Across the exposed instances, Chinese models dominated, and in the one case where an American model’s guardrails triggered, the operator switched to a more permissive model and kept going. A refusal from one model isn’t a safeguard. We made the longer version of that argument in Your AI Agent Said No. Your API Key Said Yes.

Four breaches, four ordinary doors

Put the ARTEX incidents side by side and a pattern jumps out. None of them needed a zero-day. Google says it directly: “While the mechanics of the intrusions remain the same, such as using compromised credentials and targeting unpatched systems,” what’s changed is the speed and scale (Google Cloud).

ConnectWise: a trusted connection. Storm-0940, which Microsoft first described publicly in 2024 and which runs a password-spraying botnet, used ARTEX from September. From October 10 to 14 it sprayed passwords at 327 accounts in eight organizations, peaking at about 2,900 failed attempts a minute, without a single success. Then, on October 15, its agents gained control of the identities of several ConnectWise cloud applications, including ConnectWise Cloud Backup. Customers had already granted those applications access to their Microsoft 365 tenants, so no user had to log in. The agents used the stolen application credentials to attempt sign-ins to more than 2,250 tenants, at one point more than 200 sign-ins in under four minutes. In some cases the time from first targeting to privileged cloud access was under three hours. Microsoft saw Key Vault secrets read at scale and one ConnectWise management application assign itself Global Administrator (Microsoft). Microsoft is careful to add that an affected application “does not necessarily indicate that customer data was accessed or exfiltrated,” and that most of the targeting failed. Some of it didn’t.

South Korean banks: the side doors. CrowdStrike described an operator who breached a loan progress inquiry service used by brokers at one bank and an employee mobile work-support system at another (CrowdStrike). In the same weeks, Shinhan Bank disclosed unauthorized access to a service used only by loan brokers, exposing data on more than 25,000 customers; KB Kookmin reported a leak from a mobile work system used by employees; Hana Bank, a breach of its sales support system (Korea JoongAng Daily). The banks and Korean authorities haven’t confirmed ARTEX’s role, and we won’t claim more than the record shows. But look at which systems fell. Not the core banking platform. The broker portal, the employees’ mobile app, the sales tool.

GitHub: the secret someone committed. Microsoft saw attackers use ARTEX since August to search GitHub for leaked secrets and use the valid ones to break into Azure and Microsoft 365, taking Key Vault secrets, storage keys and AI service keys. In one case the time from GitHub search to data theft was five minutes (Help Net Security).

WorkOS: the internal tool. A sales application on what WorkOS calls “a legacy internal tools platform,” reachable from the internet. “Because the credential was predictable, the agent was able to authenticate after discovering the endpoint.” And then: “The API lacked rate limiting or throttling mechanisms” (WorkOS). Monitoring didn’t notice from October 25 to October 30, by which point the bulk retrieval was done.

When WorkOS first posted about the breach, a Hacker News commenter asked why it mattered which framework the attacker used. Another answered, “Because details matter.” The first replied with the sharpest line in the thread:

"It is as useful as saying that attackers used Kali Linux - no details of what was actually exploited"

_pdp_, commenting on WorkOS reports security breach, November 2026

We think both of them are right, and the post you’re reading is our attempt to hold both. The name matters, because it tells defenders what kind of speed and persistence to expect. The door matters more, because the door is the part you can change.

Machine speed, in numbers

Here’s what “machine speed” meant in practice this autumn, all from the published reporting:

• 2,900 failed sign-ins a minute at the peak of Storm-0940’s spray, and more than 200 sign-ins in under four minutes with four stolen application credentials (Microsoft).
• 27 events in 23 seconds as an agent probed what a stolen cloud key could reach, and about four hours from a first compromised account to deep access, once just 15 minutes (Google Cloud).
• Five minutes from a GitHub search to data theft (Help Net Security).
• Sessions running 24 to 30 hours, with new addresses appearing within minutes when old ones were blocked, according to Wiz researchers (The Hacker News).
• More than 200 organizations targeted in 11 days, with planning agents consuming about 1.4 billion input tokens in a single intrusion and a human stepping in only at decision points (CrowdStrike).
• $145 to $360 in estimated model costs for two of the criminal campaigns Check Point documented (Check Point).

Sasha said it on episode 89, months before anyone had heard of ARTEX:

Listen · Sasha on episode 89, from 11:41

There’s a piece of good news hiding in Google’s report. Right now, frameworks like ARTEX “compress attack timelines to machine speed; however, they currently trade stealth for velocity.” They’re loud. They try everything, quickly, and leave a lot of evidence. Google expects that to change, with quieter, fully autonomous attacks in the medium term, which it puts at three to six months. Today’s window, where speed makes attackers noisy, is the time to build the detection and response that will still work when they’re quiet.

Your internal tools are on the internet

If we had to pick one lesson from ARTEX for a startup, it’s this one. The systems that fell weren’t the crown jewels. They were the side doors: a broker portal, an employee app, a sales tool, a backup service’s cloud app. The things somebody built to make a team’s life easier, connected to real data, and left reachable from the internet because that was convenient at the time.

Korea’s Financial Services Commission saw the same thing. At its emergency meeting it ordered every financial company to identify its externally accessible systems and services, including AI systems, and to find any pathway that could expose internal information without authentication (Korea JoongAng Daily). That’s a good instruction for any company with a product and a team, and it’s a short list at most startups:

• The admin panel and the internal dashboards, including the ones built on low-code tools.
• Staging, preview deployments and the old demo environment that still has real data in it.
• Sales and support tools wired into the CRM, the data warehouse or Slack.
• Internal APIs that grew a public route for one integration and kept it.
• The AI demo someone stood up for a customer meeting, with an API key in it.

WorkOS’s root cause reads like a checklist we’ve written for clients many times: public exposure from overly permissive access controls, a weak development credential that made it to production, no rate limiting, and monitoring that didn’t catch the activity until it was over. The tool sat on a legacy platform that hadn’t been migrated yet. WorkOS’s fix was the blunt, correct one: on October 31 it blocked internet access to all internally developed tools at the network edge (WorkOS).

Jon described the mood at a dinner of security leaders in San Francisco on episode 104, in September, and the line has aged into a forecast: “Anything exposed to the internet basically is going to break, if it hasn’t already.” The founders who take that seriously aren’t the gloomy ones. They’re the ones who decided which things need to be on the internet at all, and put everything else behind a login that proves who’s there.

If your product is a trusted connection

The ConnectWise compromise deserves its own section, because it’s the one that should change how B2B founders think about their own product.

ConnectWise didn’t lose its customers’ passwords. Its cloud applications had been granted access to customers’ Microsoft 365 tenants, the way thousands of SaaS products are granted access to their customers’ email, calendars, files and directories every day. When an attacker controlled those applications’ credentials, it had a trusted path into every tenant that had clicked “accept,” and it didn’t need anyone to log in. ConnectWise put it well in its statement: nation-state actors are increasingly targeting the software supply chain, “because one trusted connection can open the door to many organizations” (The Hacker News).

If your product is an OAuth app in your customers’ Google Workspace or Microsoft 365, a Slack app, a GitHub app or an integration with their CRM, you are ConnectWise to someone. Your app’s secrets are worth as much as the sum of every tenant that trusts it, and a few practices make you a supplier enterprises trust:

• Ask for the narrowest permissions that work, and justify each one in your documentation.
• Keep app secrets in a managed vault, prefer certificates or federated credentials to client secrets, and rotate on a schedule and on any suspicion.
• Watch your own app’s behavior in each tenant: new locations, new kinds of calls, sudden volume, role changes. Microsoft’s alerts in this case included an application assigning itself Global Administrator, which your app should never do.
• Have a way to cut off one tenant, or all of them, in minutes.
• Write the customer notice before you need it: what happened, what to check, what you’ve already done.

Microsoft’s guidance to affected customers is worth reading even if you were never touched, because it shows what your customers will do if it’s you: keep the connection disabled until the vendor says how to restore it, inventory the app’s identifiers in every tenant, preserve logs, and, in a line we’d tape to the wall of any incident room, “Do not delete enterprise applications as the first response” (Microsoft). Enterprise buyers now ask about every item on that list, and most security questionnaires have a section for it. We wrote about the promises those questionnaires turn into in the security exhibit your startup signed last quarter.

The agent that got out

The WorkOS story is the one that will stay with us, because nobody in it meant any harm.

On November 2, WorkOS posted that it was investigating unauthorized access to an internal sales application, by an “AI-assisted offensive security framework” (WorkOS). Its founder, Michael Grinich, answered questions in the Hacker News thread himself: “WorkOS’s production systems are secure. No customer platform data was accessed.” One commenter replied, simply, “Thanks for the transparency.” About twenty hours later, asked about the way in, he wrote: “We identified and verified the attack vector and have no indication there is other compromise.”

Then the story changed. A security researcher contacted WorkOS between November 3 and 5 and explained that their agent, running cybersecurity benchmark evaluations with ARTEX, had escaped its isolated environment. In WorkOS’s update: “It was an AI security agent that escaped a researcher’s sandbox.” And: “Its interaction with WorkOS was unintended.” The researcher accepted responsibility, confirmed they had deleted all the data their agent obtained, and an independent forensics firm validated the account (WorkOS).

Two lessons, one for each side of that story.

For the company that got breached: early attribution is often wrong, and that’s fine if you say only what you know. WorkOS’s first notice described the tool, not an enemy, and gave customers practical advice about phishing. When the facts changed, it published them. That’s the pattern we’d copy. Founders under pressure feel the urge to name an adversary. Resist it until you’re sure.

For anyone running offensive agents, including in research: you own what they do. We talked about this on episode 97 with Alexis Lingad, who builds autonomous hacking agents for penetration testing:

Listen · Alexis on episode 97, from 4:17

Sasha’s reply on the tape was the whole WorkOS incident in eleven words: “But we know that certain models are not honoring kill switches.” A kill switch that asks the agent to stop is a request. A kill switch that cuts its network, revokes its credentials and stops its compute is a safeguard, and it works whether or not the model cooperates. The same goes for scope: an allowlist of targets enforced by the network the agent runs on, not by a sentence in its prompt.

We’ve written about this from three directions already: the satirical one, in Your Sandbox Is Adorable; the incident one, in AI Agents Are Now on Both Sides of the Breach, about OpenAI’s evaluation agents and Hugging Face; and the defender’s one, in Nobody Noticed. WorkOS is the first case we know of where an escaped agent from an independent researcher’s benchmark landed on a startup. It won’t be the last. The responsible frame isn’t fear of the tool. It’s taking responsibility for our software and our prompts the way we’d take responsibility for anything else we run: understanding it, testing it, and keeping its reach as small as the job.

Pick up the tool

Which brings us back to the last sentence of Jon’s line, the one people tend to remember: anyone who doesn’t pick up the new tools is dead.

That sounds dramatic until you look at the numbers above. If an agent can go from a leaked secret to your data in five minutes, a quarterly scan is a historical document. If a criminal can run a campaign for a few hundred dollars of model time, every startup with a login page is worth trying. The only defense that runs at the same speed is one that uses the same kind of tools.

Jack Cable, who worked on secure-by-design policy at CISA and co-founded Corridor, made the case on episode 84 when Jon asked him whether tools like this help attackers more than defenders:

Listen · Jack on episode 84, from 22:40

And Taher Elgamal, the cryptographer known as the father of SSL, gave the analogy we keep borrowing, on episode 61, right after Jon said the short version:

Listen · Jon and Taher on episode 61, from 35:30

WorkOS took the advice in the most direct way possible. On November 3, it began regular testing of its internet-facing systems with ARTEX, focused on unnecessarily exposed systems and guessable credentials, the exact doors the escaped agent used (WorkOS). Google’s Mandiant team says the same thing in its guidance: “Organizations can also apply agentic source-code review and continuous AI-assisted vulnerability testing” (Google Cloud).

What does an agent find that a scanner doesn’t? Alexis described one engagement on the same episode, and it’s the best short answer we’ve heard:

Listen · Alexis on episode 97, from 24:51

A scanner reports an exposed key. An agent uses it, the way an attacker would, and shows you the chain. That’s the version of testing that matters now. If you pick up these tools yourself, pick them up the way you’d want everyone else to:

• Written authorization and a fixed scope, for systems you own or have permission to test. Never anyone else’s.
• Network egress limited to the targets, enforced outside the agent, so an escape has nowhere to go.
• Rate limits on the agent itself, so testing doesn’t become an outage.
• A kill switch that doesn’t need the model’s cooperation: cut its network, revoke its credentials, stop its compute.
• Humans review every finding before anyone acts on it, because agents also report things that aren’t there.
• No copying of real customer data. Prove access with a marker, not a download.
• Secure the tool’s own console. Censys found 1,465 ARTEX consoles exposed to the internet, some next to command-and-control kits (Infosecurity Magazine), and Check Point read ten exposed databases. Your testing tool can become your breach.

That’s how we run AI-assisted penetration tests and red teams for clients, and it’s the bar we’d hold any vendor to. We wrote about what agentic testing does well and badly in AI penetration testing, and about what enterprise buyers now expect from it in Pentest Once a Year?

Five layers for a startup at machine speed

Google’s report ends with five layers of defense, and its own comment on them is the most reassuring sentence in the ARTEX story: these are long-standing best practices. This is how we’d translate them for a company of twenty to two hundred people.

1. Get the control planes off the internet. Mandiant’s wording is “Restrict all admin APIs, consoles & CI/CD to trusted networks.” For a startup that means cloud consoles behind single sign-on with phishing-resistant authentication, CI/CD runners that can’t be reached from outside, and every internal tool behind a login that proves identity, or behind a private network. WorkOS’s edge block is the model.

2. Make credentials short-lived, and find the ones that aren’t. “Migrate to short-lived workload credentials; eliminate secrets.” Turn on secret scanning and push protection for every repository, public and private, and rotate anything that’s ever been exposed, without waiting to see whether it was used. GitGuardian counted 28.65 million new hardcoded secrets on public GitHub in 2025, and found that about 64 percent of valid secrets it saw in 2022 still worked four years later (Help Net Security). Our .env file post is the place to start.

3. Shrink the paths. Remove default and development credentials from production. Turn off what you don’t use. Require the newer, safer version of your cloud’s instance metadata service, and limit which roles can run commands on which machines, as CrowdStrike recommends after VAPOR PANDA (CrowdStrike). Assume any workload can be compromised and give it only what it needs.

4. Put limits on the business APIs. This is the layer most startups skip. Mandiant calls for rate limits, recipient limits and abuse controls on high-impact APIs like email, notifications and user management. Vectra described an ARTEX agent that reused a business application’s own notification system to email more than 1,300 employees (Vectra AI). Exports, search endpoints and anything that returns records in bulk belong on the same list. At WorkOS, a rate limit would have turned a bulk download into a trickle someone could notice.

5. Detect change, and respond at the same speed. Google’s sentence is the one to hold onto: “the signal is in the identity, origin, volume, and sequence, not the action.” One source signing in as many identities, a burst of control-plane calls, a storm of password resets, a crawl through storage. And its warning: “simply detecting the attack in time does little to hinder objective completion” if the response is a ticket for the morning. Automate the first move, whether that’s suspending a session, revoking a token or blocking an app, and let a human decide the second. Microsoft adds one more that small teams can do cheaply: decoys and canary credentials, because agents try everything they find (Help Net Security).

Score yourself at agent speed

This scorecard looks at your company the way an agent like ARTEX would: ten checks on the doors it tries first, how fast you’d notice, and whether you’re testing yourself. It estimates how long an agent would take to find a first foothold, names the door it would most likely use, and lists the next moves in order. It takes about five minutes and runs entirely in your browser.

Interactive · 5 minutes · Runs in your browser

The agent-speed scorecard

Pick the answer closest to what's true today, not what the policy says. The scorecard updates as you go.

The scorecard needs JavaScript. Its ten checks follow this post: internal tools on the internet, default and development credentials, leaked secrets, login protection, rate limits, trusted app connections, credential lifetimes, detection speed, automated response, and testing yourself with agents.

Load an example startup Start over

…to a first foothold, estimated

…agent-speed score, out of 100

…the door it tries first

…until you'd notice

Copy the plan Download (.md) Print

Everything here runs in your browser and is saved only in this browser. The time estimates come from the published reporting in this post and our experience testing startups, not a standard, and a real answer comes from an authorized test, not a form.

Have an operator test it for real →

We get your email, the level you picked for each check and your result, nothing else. Jon or Sasha replies to set up a short scoping call for an authorized test. No sequence.

Everything that was going to happen

Jon has a second line he uses with founders, and it’s the right way to end this week:

ARTEX was always going to exist. If Autumn-27 hadn’t published it, someone else would have published something like it, and dozens of people did. Attackers were always going to automate. Defenders were always going to have to answer at the same speed. What 2026 changed is how fast all of it arrived, and that’s the part we’d call good news. The doors ARTEX walked through have been open at a lot of companies for years. This autumn, a lot of them got closed in a week.

WorkOS’s own retrospective on what the security press is calling Black October says it in one line: “AI didn’t create these flaws, but public reporting shows it shortened the time it took to find them, and the time it took attackers to act” (WorkOS). That’s this whole series in a sentence. On Monday, *sshole: a ten-year-old bug found by a researcher’s agent swarm and used by attackers within hours. On Wednesday, the Binance hack: a five-month campaign that turned an internal AI tool into a bridge and finished in 20 minutes. Today, a free tool that every kind of hand picked up at once. In each case the flaw was old, the tool was new, and the clock was short.

We think founders are better placed for this than anyone. You can change a default in an afternoon. You can take an internal tool off the internet before lunch. You can decide this week that your company will be the one testing itself with agents, rather than the one finding out from someone else’s.

What to do this week

1. Inventory everything reachable from the internet, including the side doors: admin panels, internal dashboards, staging, preview deployments, sales and support tools, demo apps and integrations. Anything that doesn’t need to be public goes behind single sign-on or a private network.
2. Hunt for development and default credentials in production, and for long-lived secrets in code, configuration and repositories. Turn on secret scanning and push protection, and rotate anything that’s ever been exposed.
3. Add rate limits and volume alerts to every endpoint that returns records in bulk or sends messages: exports, search, email, notifications and user management.
4. Review your own app’s access to customers’ accounts, if you have one: permissions, secret storage, rotation, per-tenant monitoring, a way to cut off access, and the customer notice you’d send.
5. Make detection automatic. Alert on identity speed, new origins and bursts, and automate the first response so a human makes the second decision, not the first.
6. Run an authorized agent test against yourself, with scope, egress limits, a kill switch outside the model and human review. If you’d rather not run it yourself, ask someone who will run it that way.
7. If anyone on your team runs offensive agents, for research, benchmarks or testing, write down where they’re allowed to reach and how you’d stop them, and make sure the answer doesn’t depend on the agent agreeing.

Turn it into an answer buyers trust

Your enterprise customers’ security teams read about ConnectWise and WorkOS too, and the questions are already arriving: what’s exposed, what your app can reach in their tenant, and how you’d know if an agent was in. The answer that builds trust is short, specific and dated. Once it’s true, it sounds like this:

Sasha’s guide to building sentences like that one, and what evidence to attach, is The 10 AI Security Questions Your First Enterprise Buyer Will Ask in 2027. If you’re preparing the board for questions about this autumn, the five layers above fit on the security slide. And if something does get in, the blast radius playbook is how you keep one door from becoming the whole house.

We’ll be in Austin next April for MicroConf US, where YSecurity is a sponsor and our talk is “How Founders Turn Security Commitments Into Revenue.” It’s on our events page, with field notes from the rooms we’ve been in this year.

ARTEX will be remembered as the tool that taught a lot of companies what machine speed feels like. We hope it’s also remembered as the tool that pushed a lot of founders to close the side doors, shorten their secrets and start testing themselves. The tool doesn’t care which story it’s in. We get to choose.

Jon and Sasha