Key takeaways

  • GMO Cybersecurity by Ierae, the security arm of Japan's GMO Internet Group, says the attackers behind Japan's autumn breach wave used ARTEX, an open-source AI penetration testing tool developed in China.
  • On attack infrastructure it investigated, the targets were almost all Japanese: about 20 companies, 9 of them in the same industry. It found six more AI attack servers, each focused on a sector such as digital gifts, points and marketing, insurance and finance or e-commerce.
  • Eight of the companies it saw being targeted had already disclosed breaches in September and October. GMO believes one group is behind multiple incidents, and has shared its findings with law enforcement. It has not named the companies.
  • CrowdStrike found the same tool used against South Korean banks from late September, with Claude Code session histories and Chinese-language prompts left in open directories on the attacker's servers. In Japan, JPCERT/CC's screenshots of attacker servers showed similar AI agent folders.
  • GMO says AI helps attackers find flaws in software versions that vulnerability notices do not list, and get around WAFs. In our view, that makes version-based patch decisions and WAFs weaker safety nets than many Japanese companies assume. What companies can control, whatever tool the attackers use, is how they build software and how well they know what they run, including through an SBOM.

What GMO found#

GMO Cybersecurity by Ierae, which runs penetration testing and incident response in Japan, has been called in to many of this autumn's breaches. Its head of cybercrime countermeasures has published two posts.

October 15: "almost certainly" AI. From forensic logs of the cases it handled, GMO concluded that AI was used in the attacks. Its author says he studies how to tell human from AI attacks in logs, and judged AI use here to be "almost certain". The post also notes that the breach at its sister company GMO Research & AI ran on completely separate systems.

October 19: ARTEX confirmed. Investigating the attackers' infrastructure with outside organizations, GMO found ARTEX in use, confirming its earlier estimate.
Targets Within what GMO could observe, the infrastructure targeted almost only Japan: about 20 Japanese companies, 9 of them sites in the same industry
Campaign pattern Read together with CrowdStrike's Korean findings, GMO sees campaigns narrowed by country and industry, each with its own attack server
More servers Six more AI attack servers aimed mainly at Japanese companies, each with a main sector: (1) digital gifts and retail distribution; (2) education, gifts and printing; (3) point gifts and marketing; (4) insurance and finance; (5) e-commerce, media and logistics; (6) e-commerce
Known victims Of the targeted companies GMO confirmed, 8 had already published breach notices in September–October 2026. GMO says this shows one group caused multiple incidents
Shared with Law enforcement
Not stated Company names, the AI models used in Japan, indicators of compromise, and whether countries other than Japan and South Korea are targeted, which GMO is still investigating

Some overseas reports have given larger numbers of affected companies. We have not found those numbers in GMO's own posts, and use GMO's figures here.

What ARTEX is#

ARTEX is described by CrowdStrike as "a recently released open-source agentic penetration testing tool developed in China". Like other AI pentest frameworks, it is meant for authorized testing: it connects to external large language models, which plan and carry out steps such as reconnaissance, probing and exploitation with little human input. ARTEX speaks the Anthropic and OpenAI API formats. In a public fork we checked, if no provider or model is set, it defaults to the Anthropic format with a Claude model, but the endpoint can be changed to any compatible service, which is how other models can be plugged in. That is what makes it useful to attackers too. Pointed at a list of targets, it can do the repetitive work of exploring dozens of differently built sites around the clock.

Discontinued, but not gone. After the Korean attacks were reported, its developer, who publishes as Autumn-27, took the project off public GitHub around October 8. According to Korea's Digital Today, citing The Hacker News, the developer denied any link to the attacks, said ARTEX was built to check security risks within authorized assets, and announced an end to all updates, new releases and maintenance. The original repository now returns an error. But the code had been public under an open-source license, and forks and copies, including translated versions, are still available on GitHub. Ending development stops new features; it does not take back the copies already made. We do not link to them.

The South Korean campaign#

CrowdStrike's report on attacks against South Korean financial organizations, from late September to early October 2026, gives the clearest picture so far of how the tool is used:

  • At one bank, the attacker reportedly breached a loan progress inquiry service used by brokers; at another, an employee mobile work-support system. Data was taken.
  • The attacker left open directories on its servers containing Claude Code session histories, ARTEX configuration files and Claude memory files. One server published a CLAUDE.md file holding a Chinese-language pentesting prompt.
  • This attacker's ARTEX instance used DeepSeek as its main model, which CrowdStrike believes was reached through an API reseller. The attacker also ran additional Claude Code sessions on Zhipu AI's GLM and xAI's Grok models. ARTEX's own default is a Claude model (see What ARTEX is), so this was a deliberate choice.
  • In other sessions, the attacker asked Claude where Korean breach data is sold and for help finding Telegram groups that trade it.
  • CrowdStrike assesses, with moderate confidence, that the attacker is a Chinese speaker and financially motivated. It has not attributed the campaign to a known group.

CrowdStrike's report also includes personal details the attacker typed into one session. CrowdStrike says it cannot definitively link them to the attacker, and we do not repeat them.

How it fits with JPCERT/CC's findings#

This is the third independent look inside the attackers' servers, and the pieces fit.

  • JPCERT/CC, on October 15, said it confirmed AI use for scanning known vulnerabilities and attacking APIs. Its screenshots showed configuration folders for Claude Code, OpenAI Codex CLI and Qwen on the servers.
  • CrowdStrike found the same kind of Claude Code files next to ARTEX in Korea.
  • GMO now ties ARTEX to attacks on Japanese companies that went on to disclose breaches.

None of the three says the AI found new, unknown vulnerabilities. What they describe is AI agents doing the work of a penetration tester, at scale, against weaknesses that were already there.

What GMO says AI changes#

GMO's October 15 post explains why companies that thought they were doing the basics were still breached. It names three gaps:

  1. The CVE blind spot. Vulnerability notices list the affected versions. Companies check their version against the list and move on if it is not there. GMO says attackers use AI to go through the source code of every version and find versions that are vulnerable but not listed, which it calls "shadow vulnerabilities". Against that kind of automation, it says, CVSS priority scores do not matter.
  2. The ASM asymmetry. Attack surface management tools check systems from outside, and some software does not reveal its exact version that way. Attackers do not need to know: they simply send the exploit and see if it works.
  3. WAF bypass. Many companies put a WAF in front of systems they cannot patch quickly. GMO saw several bypass techniques, including spreading requests across hundreds of IP addresses so that per-IP blocking never triggers.

Its conclusion: AI has not simply let anyone attack. Skilled attackers have studied the mismatch between how companies defend and how attacks work, and use AI to exploit it fully.

What we don't know yet#

  • Which companies were targeted, and which of the eight disclosed breaches GMO links to the same group
  • Which AI models were used in the Japanese attacks
  • Whether the attacker in Japan is the same as the one CrowdStrike tracked in Korea
  • Which products or versions the "shadow vulnerabilities" were in
  • Whether GMO or the authorities will publish indicators of compromise

Our analysis#

From "could" to "did"#

A month ago, the claim that AI was behind Japan's breach wave rested on inference. In our analysis of the "frontier AI" warnings, we said the evidence pointed to old holes, possibly found by faster hands, and that nobody had yet shown AI at work. That has now changed. JPCERT/CC, CrowdStrike and GMO have each looked at the attackers' own servers and found AI agents there. In our view, it is now reasonable to say that AI-driven tooling is part of how this wave was carried out.

What has not changed is the first half of that answer. The weaknesses being exploited, exposed APIs, flaws in software that was not patched, admin functions reachable from outside, were already there. AI changes how fast and how widely they are found.

A takedown that cannot be recalled#

The ARTEX developer's decision to stop development is the only lever a single open-source author has, and it is a weak one. The forks mean the version the attackers used remains available to anyone, and ARTEX is one of several AI pentest frameworks of its kind. In our view, defenders should plan on the assumption that ARTEX-class tools stay in circulation, whatever happens to the original project, and judge their exposure by what such a tool can find on their systems, not by whether one particular tool is still maintained.

Campaigns by industry#

GMO's finding that each attack server focused on one sector helps explain a pattern Japanese readers will have noticed: breaches arriving in clusters among gift, points, e-commerce and booking services. Companies in the same industry often run the same packages, platforms and vendors. In our view, a breach at a peer in your industry should now be treated as an early warning that your systems are on the same list, and checked the same week.

Version lists and WAFs are not enough#

The CVE blind spot is the part of GMO's post that should change practice. Many Japanese companies decide whether to patch by checking their version against the affected range in a notice. If AI can find vulnerable versions the notice missed, "not listed" no longer means "not affected". The safer rule is to move to the fixed release when a flaw is announced in software you run, whatever your version, and to treat a WAF as time bought, not as a fix. Rate limits keyed only to IP addresses will not stop an attacker spreading requests across hundreds of them; limits tied to accounts, sessions and API keys, and alerts on unusual volumes, are harder to evade.

What companies can control#

The tools will keep changing. ARTEX has forks, and there will be others. In our view, that leaves two things that are fully in a company's own hands, and both matter more now that probing is cheap and continuous.

How it builds. Most of this wave's breaches came through weaknesses created in development: APIs that return more than they should, authorization checked in the app instead of on the server, admin functions left reachable, secrets left in app code. An AI agent finds these faster, but it does not create them. A secure development process, with security involved from design, not only in a test shortly before release, is what stops them from reaching production. As we argued in our analysis of app breaches, that includes deciding what an app should collect and expose at all.

What it runs. The CVE blind spot is a problem of knowledge. A company that knows exactly which products, components and libraries it runs, at which versions, on which systems, including those run by vendors on its behalf, can act the day a flaw is announced: update to the fixed release, without depending on whether the notice listed its version. A company that does not know cannot even ask the question. That is the case for proper asset management, including a software bill of materials (SBOM) for the software it builds and buys, which Japan's Ministry of Economy, Trade and Industry has published guidance on. It is unglamorous work, and in our view it is the best answer to an attacker who reads every version's source code with AI.

Publish more#

CrowdStrike published its indicators, and JPCERT/CC has published IoCs for the servers it examined. GMO has shared its findings with law enforcement but published none, and has not named the eight companies. There may be good reasons for that. But the attackers are working through Japanese companies sector by sector, and the companies next in line are the ones who most need to know what to look for. In our view, the bodies that now hold this information, security firms and public agencies alike, should publish as much of it as they can.

What this means for readers#

  • Know what you run. Keep an asset inventory and SBOMs for the software you build and buy, including what vendors run for you, so you can act on a new flaw the same day.
  • Build security into development, from design onward: server-side authorization, APIs that return only what is needed, no secrets in apps, and admin functions closed to the internet.
  • Do not rely on the affected-version list in a vulnerability notice. If a flaw is announced in software you run, plan to update to the fixed release.
  • Treat a WAF as a stopgap. Check whether your rate limits work per account, session or API key, not only per IP address.
  • If a company in your industry discloses a breach, check your own exposed APIs, admin functions and third-party platforms that week.
  • Watch for automated probing: large numbers of requests exploring paths, parameters and API endpoints, especially spread across many IP addresses.
  • If you run threat intelligence, add ARTEX and its forks to your watch list, and use CrowdStrike's and JPCERT/CC's published indicators.

Japanese terms at a glance#

Japanese Reading Meaning
自律型ペネトレーションテスト jiritsu-gata peneterēshon tesuto Autonomous penetration testing
攻撃元インフラ kōgeki-moto infura Attacker infrastructure
シャドー脆弱性 shadō zeijakusei "Shadow vulnerability" (an affected version not listed in a notice)
同業種 dōgyōshu The same industry
法執行機関 hōshikkō kikan Law enforcement agencies
攻撃キャンペーン kōgeki kyanpēn Attack campaign