ARTEX, the open-source autonomous penetration-testing agent that CrowdStrike linked to breaches at South Korean financial firms, now has an English-language fork gathering real traction. ARTEX Global Edition, created on October 3, 2026 by the GitHub user jiwoochris, had 1,628 stars and 1,920 forks when we checked on October 18. It is written in Go, licensed AGPL-3.0, and described as a Korean-localized, then globally localized, copy of the Chinese upstream project.
This is not a new attack. It is a new, easier-to-read copy of a tool we have already covered in our South Korea AI bank hacks explainer, and the interesting part is what the fork's maintainer chose to ship with it: a long misuse warning and a defender kit of detection rules. This post covers what the fork is, what it changes, where the evidence stops, and what defenders can do.
What is ARTEX Global Edition? (TL;DR)
| Question | Short answer |
|---|---|
| What is it? | A localized fork of ARTEX, an LLM multi-agent system that runs penetration tests autonomously |
| Who made it? | The GitHub user jiwoochris; upstream is Autumn-27/ARTEX, which the fork's README says is "currently unreachable" |
| Is it the tool from the bank hacks? | It is a copy of the same upstream project; CrowdStrike's report names ARTEX, not this fork |
| License | AGPL-3.0 |
| Stack | Go backend, embedded Next.js frontend, PostgreSQL, Docker Compose quick start |
| What does the fork change? | English output by default, plus Korean, Chinese, Spanish and Japanese; the internal reasoning prompts stay in the original language |
| What do defenders get? | A defense guide, Sigma and Suricata rules, a MITRE ATT&CK layer, an indicator list and a host triage script |
| Popularity | 1,628 stars, 1,920 forks, created October 3, 2026 |
How did we get here? The ARTEX timeline
The fork makes sense only against the October story. In early October, South Korean authorities and press tied a wave of credential-stuffing breaches at several financial companies to AI-assisted tooling. On October 7, CrowdStrike published its own analysis, "Unknown Threat Actor Uses AI-Driven ARTEX to Target South Korean Finance", describing a likely financially motivated actor who ran ARTEX with DeepSeek as the main model and left Claude Code session histories and configuration files in exposed directories. Our full write-up is in the bank hacks explainer, which also tracks the later report that the Chinese developer converted the project to closed source.
The fork's own README picks up there. It says that "in October 2026, several Korean news outlets reported that investigators had found indications the upstream ARTEX was used in personal-data breaches targeting Korean financial institutions; the related investigation is ongoing." It adds that the original Docker Hub image has been taken down, and that the upstream repository and its norma agent SDK were unreachable when the maintainer checked.
That matters for the fork count. When an open-source project disappears, copies become the only way to get it. Forks outnumbering stars, 1,920 against 1,628, is consistent with people saving a copy, though GitHub's numbers cannot tell us who they are or what they plan to do with it.
What does ARTEX actually do?
The README describes ARTEX as a system in which several LLM-driven agents "break goals down on their own, execute real tools, and accumulate discovered assets and vulnerabilities into a graph." The architecture is worth understanding because it explains why the defender material focuses on behavior rather than signatures.
An autonomous pentest agent swarm coordinating many parallel workers, the ARTEX Global Edition design
Four agent roles
- Goals decomposes the objective and extracts scope.
- Planner is the only producer of "intents", the next directions to explore. It wakes whenever the graph changes and, per the README, "most wakes assign 0" intents if there is nothing new to try.
- Workers each take a single intent, run real tools (the image bundles nmap, curl and similar), and write results back.
- Mainagent is the human-in-the-loop chat, where an operator can inject hints into a running job.
Two graphs
An asset graph, shared across tasks, tracks domains, subdomains, IPs, services and endpoints. A per-task exploration graph tracks goals, intents, facts and findings. Anchors link the two, so the system can answer both "what did we try against this endpoint" and "what did this attempt prove."
Why chains do not fall apart
A shared planning todolist persists across planner wakes. Real attacks are ordered, for example find an entry point, obtain credentials, then move on, and the todolist lets the planner dispatch one step at a time once its prerequisite fact exists. Workers can also search each other's execution traces, so a later worker reuses an earlier worker's observation. This is the part the README calls the core of how ARTEX completes multi-step chains autonomously.
If you follow agent design, none of this is exotic. It is the same planner and worker pattern behind many coding agents, pointed at a different objective. We have written about that pattern's risks before in our September threat intelligence coverage, which covers how misuse of AI agents is showing up in real attack activity.
What does the Global Edition change?
The fork is mostly about language and legal framing, not new offensive capability.
| Area | Upstream (Chinese) | Global Edition |
|---|---|---|
| UI and docs | Chinese | English default; Korean, Chinese, Spanish, Japanese selectable |
| Agent output | Chinese | Findings, summaries, reports and chat forced into the chosen language through a prompt directive |
| Reasoning prompts | Original | Kept in the original language "to preserve benchmarked performance" |
| Model provider | Configurable | Anthropic or OpenAI key, or any OpenAI-compatible endpoint |
| Distribution | Docker Hub image, now taken down | Image on GitHub Container Registry built on release tags |
| Security hardening | Unspecified | Setup token on first run, loopback-only bind by default, CORS allow-list |
| Defender material | None noted | Defense guide, Sigma and Suricata rules, ATT&CK layer, MISP indicators, host triage script |
Two details stand out. First, language enforcement is a prompt instruction rather than a hard constraint, so the README admits it depends on the model. The maintainer reports that the default claude-opus-4-8 kept output in the chosen language across all four roles in a short sandbox test, gpt-4o also stayed on track, and a smaller model let reports fall back to the original language. These are the maintainer's own numbers from a short validation run, not an independent benchmark.
Second, the fork bundles hardening that a hobby offensive tool rarely has. There is a one-time setup token printed to the log, so whoever reaches a fresh instance first cannot claim it. The service binds to 127.0.0.1 by default. Changing the password invalidates all sessions. These are sensible defaults for software that holds credentials and findings about third-party systems.
Does it come with defender tools?
Yes, and this is the most unusual part. The README says the repository "aims to help the defending side understand how autonomous AI attacks work and build the capability to detect and block them", and ships:
- A Defense and Detection Guide covering how autonomous attacks differ from classic scanners, observable fingerprints, hardening and incident response.
- Sigma rules for host, log and SIEM layers, and Suricata rules for the network layer.
- A MITRE ATT&CK Navigator layer mapping each rule to techniques.
- An indicator CSV and a MISP event of strings the project says it verified in its own source.
- A read-only host triage script that runs on the Python standard library.
Defender shield and radar representing detection rules for autonomous AI attack tools
The guide is candid about the limits. It lists a few static fingerprints, such as the artex-enrich/1.0 User-Agent used by the tool's own asset enrichment, and the norma/0.4 User-Agent from its built-in WebFetch tool. It then says plainly that "the operator can change the UA, so its absence does not mean safety." It also notes that the actual attack traffic goes out through ordinary tools such as curl, so the User-Agent seen by a target is whatever that tool sends by default unless the operator customized it.
The durable signal, the guide argues, is behavior: one source or a small rotating set chaining requests of different characters, from recon through enumeration to authentication attempts and exploitation, within a coherent session; exploration that continues through hours when a human would stop; and adaptive mutation of requests based on failed responses. Fixed WAF signatures match poorly because the model varies payloads with context.
We have not run these rules, and we are not reproducing them here. If you defend a Korean or global financial service, read them at the source and test them in your own environment.
What is claimed and what is verified?
| Claim | Status |
|---|---|
| The fork has 1,628 stars and 1,920 forks, created October 3, 2026 | Verified through GitHub's public repository data on October 18 |
| The upstream ARTEX was tied to Korean bank breaches | Reported by CrowdStrike, which attributes the activity to an unknown actor and names ARTEX; see our coverage |
| This fork was used in any attack | No public evidence; the repository was created on October 3, before CrowdStrike's October 7 report, and nothing published ties it to any attack |
| The detection rules work | The maintainer says they are re-run by repository tests; we have not independently tested them |
| Upstream is unreachable and the Docker image is gone | Stated in the fork's README as of its own check in October 2026 |
| The fork's output-language results | Maintainer's short validation run, not independent |
The honest framing: a localized fork of a dual-use security tool is not evidence of wrongdoing. Penetration testing frameworks are legitimate, and defenders do need to study how autonomous attackers behave. But a polished English edition of an agent proven in the field does lower the barrier for people who could not read the original documentation, for good and for bad.
What are the risks for people who run it?
Anyone tempted to run it to "see what it does" should note a few things from the README itself.
- Authorization is the whole game. The README warns that unauthorized scanning, probing or exploitation is a crime in itself and tells users to verify only in isolated environments they own, with deliberately vulnerable targets such as OWASP Juice Shop or DVWA.
- It sends data to a model provider. Findings, responses and tool output flow to whichever LLM you configure. If you point it at anything real, that content leaves your network.
- It stores sensitive material. Tasks, assets, findings and traffic recordings sit in PostgreSQL. A weak deployment becomes a map of someone's infrastructure.
- AGPL-3.0 obligations. If you modify it and offer it as a network service, you must offer the source to its users.
- Provenance. The upstream repository and its SDK are unreachable, so you cannot compare the fork against its origin yourself. Treat any binary or image from an unaudited fork like any other untrusted code, and build in an isolated environment.
What should defenders do now?
The practical lesson from the Korean incidents is that the attack hit the unglamorous edges: broker portals, employee work-support systems, credential stuffing against side doors. An agent that never tires makes those weak points cheaper to find, not different in kind.
- Harden authentication first. Multi-factor authentication, rate limits per account and per source, and breached-password checks stop credential stuffing whether a human or an agent is behind it.
- Detect sessions, not strings. Alert on a source that moves from enumeration to login attempts to exploitation inside one coherent window, and on activity that continues around the clock.
- Inventory side doors. Partner portals, contractor accounts and mobile work-support endpoints belong in the same monitoring as your main site.
- Review the vendor-neutral fingerprints. Add the fork's published User-Agent strings to log searches as low-confidence leads, never as proof, since they are trivial to change.
- Control your own agents. If your team runs coding or ops agents, they need guardrails too. AgentBeam, the agent security platform from the explainx.ai team, has a related walkthrough on how the Korean bank hack played out with Claude Code logs left in an open directory; the platform itself stops agents before they take dangerous actions.
- Use automation on your side. The same planner and worker pattern can drive internal red-team exercises that you authorize and scope.
Why this matters beyond one repository
Three threads meet in this story. The first is the commoditization of agentic offense. Our look at DeepSeek-assisted attacks attributed to Chinese hackers showed how an open model plus a harness is enough for scale, and ARTEX is that harness packaged with a web UI. The second is legal exposure: agents that act on real third parties raise open questions we explore in our Felony Bench explainer, and incidents where lab models crossed lines during evaluations are tracked at /felony-bench. The third is the shift in defender thinking that Bill Gates described when warning about AI-enabled cyberattacks: attackers get faster, so defenders must detect behavior quickly.
There is also a quieter lesson for open-source policy. Taking a project down, as the original developer reportedly did, does not remove it. The code was already forked, and the fork responded by adding English and a defender kit. Whether that is a net positive depends on who reads which half of the README, and no star count can tell us.
For a lab-side view of agents going beyond their instructions, see our coverage of OpenAI's misalignment reports on a test wallet and a government statistics site. The common thread is not malice but autonomy: systems that chain many steps without a human reading each one.
What we will watch next
- Whether any investigator or vendor publishes indicators that specifically involve the Global Edition rather than the upstream project.
- Whether the upstream repository or the
normaSDK reappears, which would let others audit the fork against its origin. - Whether the Sigma and Suricata rules get independent testing, and whether the User-Agent strings change in later releases.
- Any Korean regulator guidance, such as from KISA, on detecting autonomous attack tools.
Related reading
- South Korea AI bank hacks: ARTEX, credential stuffing and the defender checklist
- DeepSeek and Chinese state hackers: AI-assisted cyberattacks
- Felony Bench: AI agent legal liability and the CFAA
- Anthropic threat intelligence report, September 2026
- Bill Gates on AI cyberattacks
- OpenAI misalignment reports: test wallet and government site bypass
- Primary sources: the ARTEX Global Edition repository and its defense guide; CrowdStrike's analysis on the CrowdStrike blog
Repository figures and README quotes are accurate as of October 18, 2026 and may change. This post describes defensive context only and does not include operating instructions for the tool.
