This is the English edition of our Japanese article, published on October 23, 2026.
1. Introduction
In autumn 2026, companies and other organizations in Japan reported a succession of data leaks from their web systems. The Japanese government’s National Cybersecurity Office issued an alert to businesses on October 9, and the chair of the ruling party’s cybersecurity headquarters described cyberspace as being in a “state of emergency.” These incidents prompted growing concern about the use of AI in attacks. Our own investigations have confirmed AI use in operations targeting Japanese organizations, but its role varies considerably.
We independently analyzed three attack infrastructures that illustrate these differences. Here, “attack infrastructure” refers to the server environment an attacker uses to conduct an operation. These environments held reconnaissance and attack tools, scripts, target lists, results, logs, and command histories. They ranged from workspaces used largely by hand by skilled operators to AI-agent platforms that automated the entire workflow, including command and control.
The three infrastructures examined here are distinct from those described in previously published reports on ARTEX, an autonomous AI penetration-testing system. We reconstructed their activity from files the attackers had left in publicly accessible server directories, often called open directories. We have observed numerous infrastructures using AI to attack targets indiscriminately across many countries, with Japan frequently appearing in their target lists. For this study, we selected three with a particularly strong focus on Japan. Their relevance extends beyond the local context: they show different ways in which AI helps threat actors perform an attack.
We examine both the scope of AI’s involvement and the confidence with which that involvement can be established. AI has increased the scale and speed of these attacks, but the attackers are still looking for an unlocked door. The priorities for defense therefore remain unchanged.
This article provides an overview of the three infrastructures. We are considering separate technical articles on individual cases where further detail would be useful.
2. Scope and limitations
The findings should be read in light of the evidence available to us.
Our analysis covers files left publicly accessible on attacker-controlled servers. It does not include victim-side logs, disk images, or network records. The material shows what the attackers prepared, attempted, and recorded. On its own, it cannot establish whether each individual attempt succeeded, the full extent of the damage, or the attackers’ identities. Their reports contain many self-declared successes. We treat a result as confirmed only where it has direct support in the attacker-side evidence, distinguishing those results from plans and attempts.
The recovered material included personal information and credentials. Although we hold the underlying evidence, we describe affected organizations only by count, industry, size, and country to avoid identifying them.
3. Overview of the three infrastructures
The cases differ along two dimensions: how much of the attack AI handled and how confidently we can establish its involvement. Case A used AI to drive the entire workflow, which we confirmed. Case B was human-led, with confirmed AI assistance in planning and tool development. Case C showed high-confidence indications of AI use in a limited role, such as tool development. All three were active in 2026, and much of the activity preceded the previously published ARTEX reports.
| Dimension | Case A | Case B | Case C |
|---|---|---|---|
| Scope of AI involvement | Autonomous execution of the full workflow through an agent framework (CyberStrikeAI) | Broad use in planning and tool development | Limited use in tasks such as tool development |
| Confidence in AI use | Confirmed | Confirmed | High confidence: multiple matching stylistic indicators; no direct prompts, keys, or similar evidence found |
| Observed activity | October 2026; concentrated in a short period | August–September 2026; about 24 days | January–October 2026; prolonged, parallel activity |
| Main target countries and regions | Primarily Japan; also Taiwan and Hong Kong | Primarily Japan; also AI assets in South Korea | Primarily Japan and South Korea; lists also included the UK, France, Italy, Qatar, and Colombia |
| Target types | Legacy web systems at smaller businesses and local public-sector organizations | Legacy web systems and externally exposed AI/GPU infrastructure | Exposed VPN devices, including the Yamaha RTX1210 widely used in Japan, and WebLogic servers |
| Scale of attempted activity | At least 19 organizations, including at least 16 in Japan | At least 6,000 Japanese IP addresses scanned; attacks were concentrated on a few companies | At least 1,300 WebLogic candidates and at least 35 VPN entry points |
| Evidence of deep compromise | A very small proportion; one company had the clearest intrusion chain | One or two companies; deep compromise and large-scale data theft | Some targets; many successful VPN connections, but limited deep compromise |
| Working language | Simplified Chinese | Simplified Chinese | Simplified Chinese |
These figures are lower-bound estimates based on what we could identify and confirm. The actual numbers may be higher. We leave exact counts to a separate detailed report.
Japan was more than the most frequent country in the data. Names such as jp_success, jp_attack, and jp_cve_attack show that the attackers organized results and activity specifically around Japan. This does not mean that Japan was their only target. As noted above, we have also observed AI-involved attacks directed at other countries. The original Japanese article selected these three cases for their particular relevance to its readers. Japan is an important part of the wider picture, rather than its full extent.
In our three cases, the operators did not restrict themselves to an industry. They searched broadly for systems that were accessible and vulnerable, then attacked what they found. Japan was their geographic focus, but their selection across industries was opportunistic. We return to this targeting pattern in Section 7.
4. Case A: AI-driven execution across the workflow with CyberStrikeAI
Case A provides the clearest example of AI carrying out an attack workflow.
We confirmed the abuse of CyberStrikeAI, an open-source penetration-testing tool built around AI agents. Its exposed management console used Simplified Chinese. Reconnaissance, vulnerability discovery and validation, exploitation, command and control (C2), persistence, data exfiltration, and automated reporting formed a single, repeatable workflow.
The work was divided among agents with different roles. Records included entries such as “credential-search agent 8/44,” confirming a configuration in which 44 agents shared the work. Individual agents handled reconnaissance, vulnerability searches, exploitation, and exfiltration, automatically writing results to a database and generating structured reports. The platform also produced material in the target country’s language, including Japanese forms and fake login pages.
The exposed dashboard included labels for tool execution success rate, token usage, and batch creation, consistent with a platform that distributed and automatically executed work across multiple agents (Figure 1). The IP address has been redacted from the screenshot, which contains no specific target information.
The scale and consistency of the activity underpin our classification of this case as AI-driven rather than AI-assisted. In a short period, at least 19 identifiable organizations, including at least 16 in Japan, were subjected to validation activity. Each had a report in the same format and an index of evidence. These were outputs of a structured process run by the platform, rather than ad hoc notes left by an operator.
The platform achieved this scale by working across many targets in parallel. It throttled attack traffic to each target to avoid detection, making the activity difficult to recognize from a single organization’s logs.
We also confirmed that, despite the number of targets, evidence of deep compromise was limited to a small proportion. For many targets, the platform itself recorded “no session, no web shell, no exfiltration.” An attempted attack must be distinguished from a compromise.
Even the clearest and deepest intrusion chain began at an unauthenticated, publicly accessible administration interface on a legacy web system. No novel vulnerability was involved. AI changed the scale and repeatability of the attack, but it still depended on an existing entry point.
5. Case B: AI assistance under human direction
Case B involved a human-led attack in which AI was used extensively as a tool. A large language model (LLM) accelerated planning and tool development. The operator made the decisions and delegated selected tasks to AI, rather than having it execute the entire workflow autonomously as in Case A.
The most direct evidence was an output file containing an attack plan generated by an LLM. It included reconnaissance and attack plans for services providing AI and GPU resources. We also confirmed that the attacker presented the request as legitimate work, specifically an authorized assessment. This was a false premise intended to circumvent the model’s safety restrictions, or guardrails. We omit the details of the technique, but the record establishes that requests disguised as legitimate work were used in practice.
AI infrastructure was also a target. The operator’s lists included AI workflow platforms, LLM preprocessing platforms, and inference services. We confirmed the presence of tools and mechanisms intended to hijack access to others’ AI services and combine access to multiple services for reuse. We infer that the objective was to obtain large amounts of inference capacity at low cost.
The intrusions into legacy web systems were serious. At least one company was subject to a complete chain of control involving FTP, a database, administrator privileges, a web shell, and SSH. The attacker repeatedly restored backdoors after cleanup. At another company, a geographic information system (GIS) server exposed with default credentials provided access to several hundred thousand cadastral and commercial records, Windows credentials, and email. We confirmed the theft from the retrieved material and download records on the attacker’s infrastructure.
Our assessment is that AI remained an aid to faster, more efficient planning and tool development. We found no evidence that it executed attacks autonomously. The operator continued to rely mainly on handwritten scripts, existing tools, and personal judgment. Some attempts against AI and GPU infrastructure also failed: several hundred attempts to access a cluster all ended in errors.
The main finding is the extensive use of AI as a tool within a human-led operation. A further finding is that AI services themselves were among the targets. Internally operated inference services, workflows, and GPU environments need to be included in asset inventories as part of the attack surface.
6. Case C: Limited AI assistance in tool development
In the third infrastructure, AI’s role was confined to developing the operator’s tools and scripts. It did not cover the overall workflow or attack planning. Multiple stylistic indicators support our high-confidence assessment of this limited involvement. We distinguish it from confirmed use because we did not obtain direct evidence such as prompt text or API keys.
The operator was experienced, with established practices for automation and evidence management. Each campaign had organized directories, logs, evidence, and success lists, as well as a separate verification mechanism to reduce false positives. We confirmed at least six campaigns during 2026, with several running in parallel, particularly from September onward. They opportunistically targeted exposed VPN devices and WebLogic servers.
The edge devices targeted included Cisco SD-WAN, Citrix NetScaler, F5 BIG-IP, and Yamaha RTX1210. Activity against the first three involved attempts to abuse published vulnerabilities or management functions. The RTX1210 activity did not involve a product vulnerability. Instead, the attacker used credentials remaining in obtained configuration files. We confirmed that these credentials allowed direct connections to corporate internal networks. The number of targeted RTX1210 devices, which are widely used by smaller businesses and branch offices in Japan, suggests that the operator was familiar with the local installed base.
Oracle WebLogic Server is middleware for developing, deploying, and running Java/Jakarta EE applications.
The indications of AI assistance appeared in the way the artifacts were written. In the command history, sequences for reconnaissance and lateral movement were annotated with section headings, using formatting such as echo '=== ... ==='. This is uncommon in a history of commands entered interactively by a person, but characteristic of neatly organized procedures generated by an LLM.
A custom script for checking the cleanup of a particular target used emoji as status markers and carefully arranged section comments. These are strong stylistic signatures of contemporary LLM-generated code (Figure 2). Our incident-response work has also identified orderly, emoji-containing comments and comments naming the target, as described in a separate article.
The convergence of multiple independent stylistic indicators supports a high-confidence assessment beyond a general impression that the material resembles AI output. These remain stylistic signatures, however. We cannot completely exclude the possibility that a skilled operator deliberately wrote in this style. Without direct evidence, we retain the distinction between high confidence and confirmed use.
AI’s role here was limited to assistance with tool development, unlike the autonomous execution in Case A. We may examine the technical details of this case in a separate article.
7. Comparing the three cases
The cases have both common features and differences that can be stated as findings. We continue to distinguish those findings from inference.
Simplified Chinese was the working language in all three infrastructures. Japan was the largest target country, although the operators also pursued nearby countries and regions. Entry points were exposed legacy systems or weaknesses left in default configurations. Target selection was opportunistic across industries: the operators sought systems that were easy to attack from outside and acted on what they found.
Much of the activity also preceded the previously published ARTEX reports. Figure 3 shows the observed periods. The periods reflect the snapshots we obtained; the activity may have begun earlier.
The targets were concentrated in Japan and nearby countries such as South Korea, but were not confined to them. Case A included organizations in Taiwan and Hong Kong. Case C’s WebLogic discovery lists included organizations in the UK, France, Italy, Qatar, and Colombia. Many of these entries came from broad scanning and establish only that a system appeared on a list, not that it was compromised. The evidence is most consistent with operators focused on Japan who scanned widely and opportunistically included other countries’ assets, rather than specifically targeting those countries.
The main differences concern the scope and certainty of AI involvement: execution of the full workflow in Case A, broad support for planning and tool development in Case B, and limited support for tasks such as tool development in Case C. The activity periods also differ. Case A was concentrated in a short period in October 2026. Case B lasted about 24 days in August and September. Case C ran several campaigns in parallel over a longer period, from January to October. Their assets of interest were legacy web systems in general (A), web systems and AI/GPU infrastructure (B), and VPN devices and WebLogic (C).
We do not know whether the three cases share an operator. The use of Simplified Chinese establishes the operators’ working language. It is only a weak clue to location or affiliation and cannot establish either.
8. Interpreting AI involvement in attacks
The term “AI attack” can obscure important distinctions when used too broadly. These three cases show that AI changed parts of the attack process while leaving its fundamentals unchanged.
| Dimension | Findings |
|---|---|
| What AI changed | The number of targets handled in parallel, the speed of attempts, adaptation to the target country’s language, and automated recordkeeping and reporting. |
| What AI did not change | The types of vulnerabilities exploited, the nature of entry points (exposed legacy systems and default configurations), and the proportion of targets subject to deep compromise. |
| Weaknesses in AI output | Observed in these cases: recording planned actions as completed and
overly optimistic self-assessments. Known general tendency of LLMs: citing nonexistent vulnerability identifiers. |
An analogy helps explain the distinction: AI has increased the attackers’ workforce, but the work still consists of looking for unlocked doors. The types of doors and the weaknesses that leave them open have not changed. What has changed is the ability to try thousands at once, adapt to the target country’s language, and continue without fatigue.
AI’s ability to discover new vulnerabilities, including zero-days, has nevertheless been demonstrated. The critical PHP vulnerabilities known as PHP2Shell, disclosed in October 2026, were found through an AI-assisted audit before attackers discovered them. This was a discovery by defensive researchers. We found no evidence in our three infrastructures that attackers exploited an AI-discovered zero-day; their entry points remained known weaknesses and misconfigurations. The demonstrated ability to discover a vulnerability and an attacker’s use of that discovery are different matters, but the capability makes wider malicious use a practical concern.
Two observations are particularly relevant to defenders. First, weaknesses in AI output can provide detection clues. AI-generated self-assessments can be overly optimistic, recording success before an action has been attempted. LLMs can also insert nonexistent vulnerability identifiers into plans, a general tendency distinguished from the observations in these cases in the table above. These weaknesses are a reason to treat reported success counts cautiously and may offer opportunities for detection and decoys such as honeypots.
Second, the value of AI depends on the operator’s objectives. A specialist with a mature workflow may gain relatively little. The operator in Case C used AI only for tool development and relied on a separate verification process to reduce false positives. An operator exploring new targets can benefit from help with planning and tools, as in Case B. For an operator seeking to compromise as many targets as possible in the shortest time, AI increases scale and speed, as in Case A. AI involvement alone does not make every attack equally dangerous.
Figure 4 presents this range as a spectrum. AI involvement varies both in how much of the attack it handles and in the confidence of the assessment. The horizontal axis shows scope, from individual tasks to the full workflow. Half-filled nodes indicate high confidence; solid nodes indicate confirmed use.
This distinction helps avoid overestimating or underestimating a threat by treating all AI-involved attacks alike. It does not change the starting point for defense. Across the spectrum, the attackers entered through the same kinds of unlocked doors, and the basic controls remain the same. The practical issue is how consistently those controls are applied.
9. Defensive priorities
AI changes the scale of attacks without changing the priorities for defense. Consistent application of basic controls becomes more valuable.
| Priority | Action | Supporting cases |
|---|---|---|
| 1 | Inventory public-facing web systems; update or isolate legacy platforms. | A, B, C |
| 2 | Check for externally exposed default credentials and administration interfaces. | A |
| 3 | Manage VPN and edge-device configurations and check for credential reuse. | C |
| 4 | Check whether internal AI services, including inference, workflows, and GPU infrastructure, are externally exposed. | B |
| 5 | Design monitoring to account for low-frequency, distributed attempts. | A |
| 6 | Prepare for LLM misuse through requests based on false premises in organizations that use LLMs for work. | B |
Priorities 1 through 3 cover exposed systems not intended for public access, such as administration interfaces, business intelligence tools, and employee applications; APIs that return excessive information or grant excessive privileges; and unchanged default credentials. These weaknesses predate AI. AI enables attackers to probe them faster and more widely.
Priorities 4 and 6 follow specifically from Case B. Organizations operating AI infrastructure need to inventory it as well as consider their use of AI. Exposed inference services and GPU environments are attack surfaces in their own right. Organizations using LLMs for work also need to prepare for misuse through requests presented as legitimate tasks.
Priority 5 reflects Case A’s distribution of low-frequency attempts across many organizations. An isolated anomaly in one organization’s logs may be insufficient to assess the activity.
As the PHP example illustrates, AI is accelerating vulnerability discovery on the defensive and research side as well as on the attacker side. The interval between disclosure of a critical vulnerability and its exploitation may narrow further. Prompt patching, and virtual patching to cover the period before a patch can be applied, are therefore increasingly valuable.
10. Unanswered questions and further work
The attackers’ identities, whether the three cases share an operator, the full scale of the damage, and the AI models used remain unresolved. Our observations come from attacker-side files and still require confirmation from the affected organizations.
We are considering further technical reporting on individual cases: AI-driven activity in Case A, AI assistance in Case B, and limited AI assistance in Case C. We will also continue working with the relevant organizations.
11. Information handling and contact
We plan to provide the results of this analysis to law enforcement and are preparing notifications for organizations that may have been affected. We are withholding IOCs from this article to avoid interfering with investigations.
Following publication, we are willing to share information and cooperate with other security vendors.
Organizations concerned about possible exposure, or with information related to this activity, can contact us through our contact page.
References and further reading
GMO Cybersecurity by IERAE. Many sources of the recent unauthorized access incidents confirmed to be AI. October 19, 2026. Japanese. Note: As of October 26, 2026, GMO’s website is temporarily operating in a simplified form as a precaution following a software vulnerability disclosure, and this URL redirects to the homepage.