ARTEX: Attackers Adopted This AI Pentesting Tool in Three Months. Leaked Secrets Are Its Fastest Way In.

ARTEX hands a penetration test to a team of AI agents. You give ARTEX a target and a goal, such as "get admin access to the web portal". The agents plan the attack, run scanning and exploit tools, and record each finding. A person only steers.

ARTEX appeared on GitHub on July 26, 2026. Three months later, attackers had used ARTEX against hundreds of organizations:

• A Chinese state-aligned group used ARTEX against hundreds of organizations in a few weeks.
• Criminal crews used ARTEX against banks in South Korea, Southeast Asia and India.
• A security researcher's agent escaped its test environment and pulled customer data from a company's internal sales tool.

We read this week's reporting on ARTEX. Our sources: research from Microsoft, Google, CrowdStrike, Wiz, Censys, GitGuardian and Palo Alto Networks' Unit 42, advisories from India's CERT-In and the EU's CERT-EU, and incident reports from the affected companies. We also read the ARTEX source code in a surviving copy on GitHub.

One pattern runs through the reports. The agents get in fastest with a credential someone left in the open.

• Secrets on GitHub. Microsoft watched an AI agent search public GitHub repositories for secrets, then steal data from a customer's Azure Key Vault five minutes later. Key Vault is the Azure service for keys and passwords.
• A guessable development password. The agent in the WorkOS breach logged in with a predictable credential meant for local development. The credential had reached production.
• A backdoored copy of ARTEX. After the original came down, a copy on GitHub changed one line. Installs then pulled a Docker image with a hidden back door. Users downloaded the image more than 9,000 times.

What ARTEX Is

The developer Autumn-27 published ARTEX on GitHub as Autumn-27/ARTEX under the AGPL-3.0 open-source license. The same developer wrote ScopeSentry, a Chinese asset-discovery and vulnerability-scanning platform. Censys describes ARTEX as an AI layer on top of ScopeSentry. The project and its documentation use Chinese, so some outlets call ARTEX "Chinese-made". No source we read establishes more about the developer. People of several nationalities use the tool, including a South Korean former penetration tester whom Seoul police arrested in October.

Version 0.3.15, the last open-source release, works like this:

• One program with a web console. A Go server, a Next.js web interface and a PostgreSQL database run together, usually in Docker. The console and its API listen on port 8787. The supplied Docker Compose file opens port 8787 on every network interface. On a rented server, the console faces the internet the moment you start ARTEX.
• A team of agents. One agent turns the operator's goal into objectives and sets the scope. A planner agent breaks the objectives into attack steps. Worker agents, three per task by default, each take one step and run real tools such as nmap, a shell and an HTTP client. The workers write back their results. A chat agent lets the operator steer. A retest agent checks findings a second time. ARTEX keeps two maps as the work runs: one of the target's assets, one of the steps already tried.
• No AI model of its own. The operator connects ARTEX to Anthropic, OpenAI, or any service with the same interface. CrowdStrike and others found attackers running ARTEX mostly on DeepSeek models from resellers.
• Soft safety limits. The original blocks .gov and .edu targets by default and holds risky actions for approval. CERT-EU found "no hard technical enforcement" of scope. At least one fork advertises the removal of the blocklist.

On October 7, CrowdStrike linked ARTEX to the breach of a South Korean finance company. At 10:50 UTC on October 8, the author posted a notice. The notice said attackers had abused the tool, ARTEX would go closed-source, and no new releases would follow. The repository came down the same day.

The takedown came too late. GitGuardian counted 102 forks and ARTEX-named repositories in the takedown week alone. The largest surviving copies each have thousands of stars. Several outlets wrote this week about a deletion "at the end of October". The primary sources all give October 8.

Timeline

Who Uses ARTEX

No single group owns ARTEX. Researchers and victims have published these cases:

Google's threat intelligence team lists ARTEX among several frameworks of this kind, with PentAGI, HexStrike and Cairn. Both extortion gangs and espionage groups use them. In one case, Google saw attackers go from one compromised account to deep access in 15 minutes. GitGuardian counts about 45 open-source tools in the same category.

Why Leaked Secrets Are the Fastest Way In

Most ARTEX techniques are old: scanning, password guessing, exploits for known web flaws. The agents add speed and persistence. They work around the clock, try several paths at once, and fix their own mistakes. Microsoft watched one agent send a malformed request to Azure, get an error, and send a corrected request about 28 seconds later.

Speed matters most when the attacker breaks nothing at all. A working credential sitting in the open gives the agent everything.

Secrets in public code

Microsoft's November 5 report shows the pattern:

• Since August, attackers have used an AI attack framework to send large volumes of searches to GitHub.
• The searches combine a target company's name with words such as "secret" and the names of cloud and AI providers.
• The agents look for an application's client secret, the password an app uses to sign in to Microsoft Entra ID.
• With the secret, the agents sign in as the application and go straight for anything holding more credentials: storage account keys, connection strings, Kubernetes credentials and Key Vault contents.
• In at least one case, the agent went from a GitHub search to data theft from Azure Key Vault in five minutes.

Microsoft's advice: "removing the original disclosure alone does not remediate the exposure." Treat every secret you ever exposed as stolen, and rotate the secret.

GitGuardian adds a detail with direct impact on your defense. GitGuardian read the ARTEX code and found no secret-hunting feature. Its only call to the GitHub API checks for updates. GitGuardian then ran ARTEX in a sealed lab with nine planted secrets. In every run where ARTEX acted, the agents found eight of the nine, including an AWS key from git history. The AI model decided by itself to search code and history for credentials, with the shell and web access every such tool gives its agents.

Blocking one tool's features will not stop this. Leave nothing to find.

Development credentials in production

No nation-state hit WorkOS. A researcher's agent wandered onto an internal tool with no reason to face the internet. The tool accepted "a weak credential intended for local development". The WorkOS incident report lists four failures:

• The tool faced the internet.
• The tool accepted a predictable credential.
• The tool had no rate limits.
• Nobody noticed the access for five days.

The first open item on the WorkOS fix list: "controls to stop weak or development-only secrets from being deployed to production systems."

The CERT-In advisory on Crafty Falcon describes the same pattern at scale. Attackers enter a test or staging environment, find credentials valid in production, and move across. The first CERT-In recommendation: share no credentials, tokens or API keys between test and production.

Trusted application credentials

The ConnectWise case shows the same pattern one level up. Storm-0940 did not breach 2,250 customers one at a time. The group stole the credentials of one application all of them already trusted, then used ARTEX to try those credentials everywhere at once.

Google's guidance for ARTEX-style attacks names code repositories and CI/CD pipelines as targets. Google recommends you move from classic GitHub personal access tokens to fine-grained tokens, or to short-lived GitHub Actions sign-in tokens, wherever possible.

A Backdoored Copy of the Attack Tool

The takedown created a supply chain problem of its own. People still wanted ARTEX after the original disappeared. Someone stepped in to supply a copy.

BadByte researchers traced the sequence:

• On the evening of October 8, eight hours after the author's notice, a new Docker Hub account called tomicdd pushed an ARTEX image.
• Less than an hour later, a GitHub account uploaded a copy of the ARTEX source with one line changed. The Docker Compose file now pulled tomicdd/artex instead of the official image.
• The new README called the copy the maintained successor and recommended a Docker install.
• The repository gained about 1,100 stars in two days. Roughly as many later disappeared. GitHub most likely removed them as fake.

The source code in the repository matched the original, so a code review found nothing. The back door lived only in the prebuilt image. An extra function runs any command sent in the login form, as root, before ARTEX checks the password.

• Users pulled the backdoored image about 9,131 times. Docker removed the image on November 5, along with an identical second image, congdonglinux/artex.
• BadByte found 62 internet-facing consoles running the backdoored build. 637 GitHub repositories still point their Compose files at the image. Copies already pulled or cached on mirrors still carry the back door.
• A package in a third-party app store kept republishing the backdoored image through a daily update job. The job pinned the backdoored image's exact digest.

Most people who installed the copy wanted to attack others. The lesson still applies to every team running open-source security tools:

• A clean repository will happily point at a malicious image.
• Anyone with money buys stars.
• A pinned dependency protects you only if the version you pinned was safe.

How to Spot ARTEX Activity

Traffic against your systems. Unit 42's November 11 report describes a distinct rhythm. The agents send bursts of 1 to 14 requests about a second apart, then pause for 25 to 31 seconds while the model decides the next step. Unit 42 lists other signs:

• More than 200 application client secrets tested in about three minutes.
• Test inputs such as evil[.]com and test@example[.]com.
• Storage tests where the agent writes a file and deletes the file at once.

Unit 42 also saw campaigns reach cloud access through password reset pages and exposed APIs "without exploiting a single software vulnerability." The user agents artex-enrich/1.0 and norma/0.4 appear in both the WorkOS and Wiz indicators. Norma is the agent toolkit under ARTEX.

Consoles on the internet. You find an ARTEX console on port 8787. The page title starts with "ARTEX" or ends in "自主渗透测试控制台" ("autonomous penetration testing console"). This week's counts:

• Unit 42: 609 hosts, as of October.
• Censys: 1,465 hosts, November 4.
• BadByte: 1,645 hosts, November 4.
• SOCRadar: 916 hosts in the United States alone, November 11.

Each team used a different method and date, so the counts differ. Some exposed consoles belong to legitimate testers. Censys found 155 running next to other attack tools such as Cobalt Strike, and 32 with open directories serving exploit kits and implants.

Inside your own network. CERT-In flags AI model API traffic from servers and other non-development machines as a sign of attack infrastructure or a planted operator console. If one of your servers starts calling an AI provider's API with no business reason, investigate.

Indicators of Compromise

These indicators come from the primary reports. ARTEX infrastructure changes fast. Use the IP addresses to start a search, not as a complete list. We write addresses with [.] to stop them from turning into links.

Microsoft lists two Entra ID sign-in errors as early warnings:

• AADSTS7000215: wrong client secret.
• AADSTS7000222: expired client secret.

Either error means someone holds a credential for your application. Treat a failure followed by a success as urgent.

How StepSecurity Helps

ARTEX agents get in fastest with long-lived credentials. StepSecurity helps you find and remove those credentials in your GitHub organization and CI/CD pipelines, and alerts you when someone abuses a personal access token.

1. Fewer long-lived secrets in GitHub Actions

Google recommends short-lived GitHub Actions sign-in tokens (OIDC) in place of stored keys. With OIDC, a workflow signs in to your cloud provider with a short-lived token. You store no key, so no key leaks.

The Actions Secrets page lists your organization, repository and environment secrets with the days since each secret's last rotation. For repository and environment secrets, you also see:

• Whether any workflow still uses the secret.
• Whether OIDC would replace the secret.

StepSecurity reads secret names and dates only, never secret values. Start with unused secrets and with cloud keys ready to move to OIDC.

2. Personal access tokens: govern them and catch abuse

Google recommends you move from classic personal access tokens (PATs) to fine-grained tokens. CERT-In lists stolen long-lived API tokens among the Crafty Falcon ways in. The Apps & PATs page shows the GitHub Apps and fine-grained tokens with access to your organization, plus classic tokens authorized through SAML single sign-on, with the permissions or scopes of each. PAT governance checks flag:

• Classic tokens with broad scopes such as repo or admin:org, and fine-grained tokens with write access to all repositories.
• Tokens with no expiry.
• Tokens older than your maximum age.
• Tokens nobody has used recently.

For GitHub Enterprise customers, the PAT Abuse detection reads your enterprise audit log every 15 minutes. Each token learns its own normal behavior, and the detection alerts you when:

• A token appears from a new country.
• A token's activity jumps far above its own normal level.
• A token already flagged by your PAT governance policy stays in use.

An agent with a stolen token works from new places and at machine speed. These detections flag both and name the token, so you know which one to revoke.

3. Harden-Runner: secrets in logs, and unexpected outbound calls

Google also recommends you scan pipelines and build artifacts for secrets. Harden-Runner flags secrets printed in GitHub Actions build logs or packed into uploaded artifacts. Anyone with read access to the run reads both. On a public repository, anyone means everyone.

Harden-Runner also learns the network destinations each job normally contacts and flags new ones. CERT-In flags AI model traffic from machines with no reason to send such traffic. Harden-Runner applies the same check to your CI runners. Suppose a build job suddenly calls an AI provider or an attacker's upload server. In audit mode, Harden-Runner flags the call as an anomalous network call. In block mode, you give each job a list of allowed destinations, and Harden-Runner blocks the call.

What to Do Now

1. Remove the easy credentials

• Scan your repositories for secrets, including forks you control and full git history. Turn on GitHub secret scanning and push protection.
• Rotate every secret anyone ever committed or printed to a log, even after deleting the commit.
• Move cloud access in CI from stored keys to OIDC. Set an expiry on every personal access token, prefer fine-grained tokens, and revoke unused ones.
• Move Microsoft Entra ID applications from client secrets to managed identities or certificates wherever possible.
• Check every internet-facing system, especially internal tools and test or staging environments. None should accept a default, development or shared credential.

2. Hunt for ARTEX activity

• Search web, proxy and API gateway logs for the user agents and IP addresses in the table above, and for the request rhythm Unit 42 describes.
• Review application (service principal) sign-ins in Entra ID. Look for the AADSTS7000215 and AADSTS7000222 errors, and for one IP address signing in as several applications.
• Look for servers in your environment calling AI model APIs with no reason to.

3. If your team runs ARTEX

Some security teams now test their own systems with ARTEX. WorkOS does. If your team does too:

• Check which copy and which Docker image your team installed. An install from tomicdd/artex or congdonglinux/artex, or from a Compose file pointing to either image, has a back door giving anyone root on the host. Rebuild the host and rotate every AI provider key and credential stored in the console.
• Keep the console off the internet. Bind port 8787 to localhost and reach the console over a VPN or SSH tunnel. Finish the admin setup before the console accepts connections from anywhere else.
• Enforce the scope with network controls, not only with the tool's own settings. The WorkOS breach started when a researcher's agent left its test environment.