Overview

AI is being used for various tasks that were previously performed manually by humans, such as research, document writing, and code analysis. A 2026 corporate survey also showed that the scope of AI adoption among organizations had expanded compared to the previous year. Recently, there has been a trend toward automating a significant portion of work by moving beyond simply assisting with individual tasks to entrusting AI with performing a sequence of steps.

The same is true in the security field. Notable examples include Vulnhuntr, which uses a large language model (LLM) to detect code vulnerabilities, and GhidraMCP, which connects Ghidra to an LLM to assist with reverse engineering—both of which are publicly available on GitHub. In the penetration testing field, there are also open-source projects—such as PentestGPT and CyberStrikeAI—that link multi-stage processes using agents and security tools.

ARTEX is one such autonomous penetration testing tool. When a user inputs a target and objectives, multiple agents investigate the assets, select the appropriate tools, and carry out the tasks. Rather than simply repeating predetermined procedures, they determine their next actions based on the results of previous tasks. What drew our attention to ARTEX was a web console exposed on the internet. When we traced the related infrastructure using the web console as a clue, we also discovered operational data on some hosts that matched activities consistent with a threat actor.

Since evidence suggesting the tool may have been used in actual attacks was confirmed, we installed ARTEX—which is available as open source—in a separate Test Environment to examine the possibility of autonomous penetration testing. In each test conducted across different environments, we provided the Attack Target, objectives, and permitted scope but did not disclose service names, vulnerabilities, or specific attack procedures. As a result, on a web server with a file upload vulnerability, the system executed a program through a web shell; in an environment exposing Apache ActiveMQ, following initial access, it executed remote commands on four internal hosts. This demonstrates that, even without detailed instructions from the user, a vulnerable environment can lead to command execution and lateral movement within the internal network.

This article examines the circumstances under which we identified the attack activity while tracking an internet-exposed ARTEX instance, as well as the operational structure of the tool, and presents the scope of the attack and response strategies confirmed through two reproduction experiments.

 

Externally Exposed ARTEX and Circumstances of Attack Activity

Distribution of ARTEX Operating Systems

It is not possible to categorize all ARTEX-related IP addresses exposed to the Internet solely as threat actor addresses, nor can they be interpreted solely as the IP addresses of users who downloaded the tool or targets investigated by ARTEX. AhnLab tracked the exposed infrastructure using the characteristics of the ARTEX web console as clues and identified 600 public IP addresses hosting ARTEX instances. Details on this can be found in “AI Lowers the Barrier to Attack: ARTEX Infrastructure Tracked by AhnLab | AhnLab.” The discovered IP addresses illustrate the distribution of ARTEX operating systems exposed to the internet.

Region and Country	Number of IPs	Share
US	322	53.7%
China	119	19.8%
Hong Kong	67	11.2%
Singapore	33	5.5%
17 Others	59	9.8%
Total	600	100.0%

Table 1. Regions and countries are estimates of the location of IP addresses. Data provided by: DB-IP.Com Country Lite, October 2026 edition, CC BY 4.0.

While it is not possible to determine an operator’s nationality or the origin of an attack based solely on IP region and country information, a comparison of 600 hosting IPs with the DB-IP Country Lite October 2026 edition revealed that 541 (90.2%) Were distributed across the US, China, Hong Kong, and Singapore. Additionally, as of October 14, 2026, it was confirmed that there were approximately 900 IP addresses associated with the ARTEX operating system publicly accessible on the Internet.

Upon further investigation by ASEC into exposed web services related to ARTEX infrastructure,(The Evolution of ARTEX: AI-Based Penetration Testing Infrastructure Tracked by AhnLab | AhnLab), 252 instances of Sub2API (an AI API gateway), 22 instances of Scope Sentry (an attack surface management tool), and 15 instances of CyberStrikeAI (an AI penetration testing platform) were identified. Although the criteria for aggregating and the region distribution of these findings differ from those of the previously mentioned 600 IP addresses, it is evident that other AI and security tools were also exposed in some of the environments hosting ARTEX.

ARTEX Environments Exposed to the Outside

Tracking ARTEX Infrastructure: Evidence of Actual Attack Activity | As reported by AhnLab, a follow-up investigation into which tools and files were exposed on the identified IPs revealed files related to internal network exploration, access, pivoting, and the deployment of follow-up payloads in two operational directories on hosts where ARTEX was deployed or related content was found.

In the first directory, alongside a file specifying the ARTEX operation path, a web shell command channel, a reverse RDP relay, commands for Pass-the-Hash-style RDP connections, and a PowerShell command agent were found. Relay logs and listener connection records support the possibility that a reverse RDP relay was executed, while records of RDP process execution and FreeRDP window identification show evidence of “pass-the-hash” connection attempts. However, it could not be confirmed whether a stable RDP authentication session was maintained.

The second directory contained scan results for the Kubernetes Pod network and a separate internal network, code to automate SSH connections to the root account, a script to extract secrets from JVM heap dumps, as well as a downloader and Linux and Windows implants. The scan results are interpreted as activities aimed at identifying internal assets, while the remaining files suggest they may have been used to maintain privileges or prepare for follow-up actions.

It is not possible to classify all of the more than 900 previously identified IP addresses as threat actor infrastructure or link them to specific threat groups or campaigns. However, the IoCs related to the two operational directories contained two IP addresses and 18 file MD5 hashes included among the 600 addresses identified earlier; when viewed alongside the data in the operational directories, it is estimated that some of the hosts identified as ARTEX were used for attack-related activities or preparations for such activities. In particular, the first directory contained both ARTEX working paths and attack-related files. Detailed information on tools that left attack traces or were prepared for follow-up activities, as well as the detailed flow of the two incident cases, can be found in “Analysis of the China AI Penetration Testing Tool ARTEX Infrastructure #3 – AhnLab TIP.”

 

ARTEX’s Operation and Structure

When a user registers assets and tasks in the ARTEX web UI and connects an LLM, the server manages the execution status of the agents, and the collected asset information and task history are stored in PostgreSQL. Users can check progress and results on the same screen; ARTEX controls tasks through an approval process and logs the communications of certain tools used by Workers via a proxy for record-keeping purposes.

ARTEX manages information about the target itself and decisions made during the task in the Asset Graph and Exploration Graph, respectively. Domain, IP address, Service, application, and endpoint information stored in the asset graph is shared across multiple tasks, while the exploration graph records how objectives, verified facts, discovered vulnerabilities, and follow-up decisions were linked. By linking these two records, users can verify the rationale for subsequent tasks and reduce the need to repeatedly investigate the same assets.

When a user enters objectives and acceptable limits, Goals organizes this information, and Planner creates the next exploration task—Intent—based on the acquired asset information and observation results. When Worker runs tools according to that task and records newly verified information, Planner reviews the returned results to determine follow-up actions.

Agent	Roles in the Workflow
Goals	Organizes objectives and test scope
Planner	Reviews the information gathered and determines the next steps
Worker	Execute tools and record the verified results

Once the LLM determines the test direction, the Skill guides the tool usage procedure, and the Tool interacts with the target through command execution or HTTP requests. Results may vary even when the same objective is entered, depending on the available tools, permissions, and network access scope; on the target system, it is the actual requests sent by the tool and the subsequent behavior that are logged, rather than the agent’s name.

 

ARTEX Penetration Test

To verify whether ARTEX could actually achieve penetration, we conducted a penetration test using ARTEX. In the tests, we provided the target, objective, and permitted scope, then observed how far ARTEX proceeded by investigating the exposed capabilities. A total of two tests were conducted, each targeting different environments and objectives. In the experiment targeting a web server, the goal was to execute arbitrary programs using the file upload feature on a web page. In the ActiveMQ experiment—which simulated the initial exposure conditions described in *The DFIR Report* on a separate test network—the final goal was set as lateral movement into the internal network following the Initial Breach. The attack flow is as follows.

In both experiments, the user provided only the target, objective, and permitted scope, and ARTEX selected different entry points based on the Service discovery results. The prompt provided was very simple—it was at a level where even a user without specialized knowledge in the security field could enter it, such as “Penetrate the Attack Target. “Please attack only the specified target.” Nevertheless, with just a single brief request from the user and without any human intervention, ARTEX achieved its objectives: on the web server, it executed a program on a single host through the upload function; and on ActiveMQ, it used initial access to an external server as a stepping stone for remote command execution on four internal hosts. Details regarding ARTEX’s structure, operating principles, Test Environment, and attack process can be found in “Analysis of the Structure and Operation of ARTEX, an AI-Based Autonomous Penetration Testing Tool.”

 

The following table summarizes the test procedures and final results for both tests as follows.

Scope of Autonomous Penetration Testing Confirmed in Both Tests

Multi-Stage Test Phase	Penetration Testing Targeting Web Vulnerabilities	Penetration Test Targeting Software Vulnerabilities
User-submitted request	Investigated a single IP address; after confirming command execution, executed calc.Exe	Lateral movement to internal hosts accessible after penetrating an external target
Entry points identified by ARTEX	File upload feature on a web page	OpenWire on TCP port 61616, ActiveMQ 5.15.15, And CVE-2023-46604
Confirmed initial execution	Execution of the Calculator program on Windows 11 after uploading a web shell	Confirmation of command output after modifying XML, establishing a PowerShell shell, and creating a test file
Subsequent Steps	After discovering the SMB service, installed and assessed Impacket	After investigating internal assets and accounts, remote command execution occurred on four hosts
User intervention	X	X
Final Reach	Program executed on one web server	Initial access to the boundary server BEACHHEAD01; remote command execution on four internal hosts

Table 2. Test Procedures and Results

 

ARTEX Attack Flow and Limitations of User-Agent-Based Detection

ASEC’s testing confirmed that ARTEX scans for publicly exposed services and functions and attempts various attacks targeting environments with inadequate security configurations or vulnerabilities. 

During this process, requests sent directly by ARTEX or through external tools may contain different User-Agent values; however, not all operations generate requests, and this value is absent in non-HTTP communications. Even in HTTP requests, the value may not be recorded or may be altered by the threat actor depending on tool settings or log collection methods; therefore, it is difficult to detect or block ARTEX’s activities based solely on a specific User-Agent.

The figure below illustrates the attack flow based on a “file upload attack case” and distinguishes between requests actually observed in the PoC and those identified only in code and documentation.

Results of User-Agent Analysis by Function

PoC test results showed that different User-Agents were recorded depending on ARTEX’s functionality and the calling tool. When the ARTEX execution host checked for updates on GitHub, “artex-selfupdate” was observed; when it accessed the Attack Target’s web page, “norma/0.4” Was observed; and when it uploaded a file, “curl/<VERSION>” was observed. Among these, “artex-selfupdate” refers to a request sent to GitHub and therefore does not appear in the access logs of the Attack Target web server.

External tools such as nmap, nxc, and Impacket may be used for network reconnaissance and propagation. While the User-Agent of each tool may be logged when an HTTP request is made, non-HTTP communications do not leave a User-Agent trace. Therefore, to detect related activity, it is necessary to examine not only web access logs but also firewall logs, network connection logs, and Service access logs.

The ARTEX source code specifies ‘artex-enrich/1.0’, While the api-recon reference script specifies ‘Mozilla/5.0 (Spa-api-recon)’ and ‘Mozilla/5.0 (Spa-api-recon spider)’ are set as the User-Agent. However, in the analyzed version of ARTEX, the section calling the artex-enrich functionality was not connected, and the api-recon script was not executed in this PoC. Consequently, these values should be classified as information that may be logged depending on the functionality or version, rather than traces observed in actual communications.

Detection Limitations and Response Strategies

When investigating ARTEX’s activities, it is difficult to identify the full scope of attack behavior based on a single User-Agent. This is because ARTEX and external tools may use different values, and the User-Agent may not be logged depending on the feature or communication method. Furthermore, threat actors can modify or remove these values, and tools such as curl are also used for legitimate administrative tasks. Therefore, while the User-Agent should be used as a clue to track attack activities, the presence of a specific value alone should not be taken as definitive proof of ARTEX usage or a successful intrusion.

AI-powered attacks can automate reconnaissance, service discovery, file uploading, command execution, and internal network access as a single, continuous process. To counter this, rather than relying on the detection of specific User-Agents or individual tools, it is necessary to analyze the sequence and relationships between each behavior from the perspective of the overall attack process.

To achieve this, organizations need to deploy EDR capable of monitoring file and process execution on servers and PCs, and establish an XDR-based analysis framework that correlates web, network, and authentication logs with endpoint detection results. Only by analyzing multiple security logs together can we identify signs of Initial Breach, command execution, and lateral movement within the internal network—even when the User-Agent has changed or left no trace.

 

Conclusion

In two experiments, ARTEX broke down the user-specified objectives into detailed tasks and continued the intrusion by autonomously adjusting its attack methods and subsequent actions based on the results of each tool’s execution. In the web server environment, it located a file upload path and executed a program; in the ActiveMQ environment, it progressed from initial access to the stage of remote command execution on four internal hosts.

An investigation of the ARTEX hosting infrastructure exposed to the Internet revealed that some servers contained both ARTEX operation paths and materials that appeared to have been used in attack operations. On other servers, various AI-related tools, such as CyberStrikeAI and an AI API gateway, were also discovered. This demonstrates that publicly available AI-based attack tools have the potential to be utilized in environments where actual attacks are prepared or executed, going beyond mere experimentation or proof-of-concept.

Through this experiment, we confirmed that ARTEX can exploit vulnerabilities and misconfigurations in publicly available services to expand its penetration scope—from initial access to command execution and access to internal networks. This demonstrates that AI-based autonomous penetration tools have already become a real-world threat and that their impact is likely to grow even further in the future.

Attempts at AI-powered attacks are highly likely to increase in the future. However, the fundamental principles of defense remain unchanged. Organizations must identify publicly exposed services and management functions to reduce unnecessary exposure, and promptly address vulnerabilities and misconfigurations. Account privileges and access to internal networks must also be restricted to the minimum necessary scope. Additionally, organizations should use EDR to monitor file and process execution on servers and PCs, and leverage XDR to correlate web, network, and authentication logs with endpoint detection results. This enables the early identification of and response to the attack chain—from Initial Breach to command execution, internal reconnaissance, and lateral movement within the internal network.