Tracking ARTEX Infrastructure: Signs of Real-World Cyberattacks

ARTEX Infrastructure Analysis: From AI-Powered Tools to Attack Traces

ASEC has tracked ARTEX-related infrastructure and published its findings since October 1.

The first analysis examined the characteristics of ARTEX, an LLM-based autonomous penetration testing framework, and identified approximately 600 additional IP addresses. Some infrastructure was also found to be running CyberStrikeAI, another AI-powered offensive and defensive security platform.

The second analysis also identified ARTEX v2, which uses a central Planner to coordinate multiple Worker Agents, and described how AI-powered penetration testing tools are evolving into integrated multi-agent environments.

Previous Analysis

• AI Lowers the Barrier to Cyberattacks: Our Tracking of ARTEX Infrastructure
• ARTEX v2: AI Penetration Testing and Infrastructure Analysis

The third analysis took a closer look at possible real-world attack activity by examining files and execution traces left in the related working directories.

Case 1. Web Shell Activity and Pass-the-Hash RDP Access Attempts

The first case involved 37 files stored in an ARTEX-related working directory. The analyzed materials included an ASPX web shell, a Reverse TCP Relay, attempts to gain remote access using Pass-the-Hash, a technique that uses an account’s authentication hash instead of its password, a PowerShell command agent, and internal network discovery scripts.

The web shell scripts appeared to be configured to run commands through a web server. The evidence also indicated attempts to use a Reverse TCP Relay to forward an external connection to an internal RDP service, along with an attempt to establish a Pass-the-Hash RDP connection using an administrator account's NTLM hash.

The materials also included a PowerShell agent for receiving and executing remote commands and a script designed to check whether services on internal systems were accessible, including SMB, RPC, SQL Server, RDP, and WinRM.

The artifacts suggest the following possible sequence:

Based on the materials, ASEC assessed with medium-to-high confidence that the Reverse RDP Relay may have been executed. It confirmed with high confidence that a Pass-the-Hash RDP connection was attempted.

However, ASEC could not determine whether remote access succeeded or whether the PowerShell command agent received and executed commands. No actual results from the internal network discovery script were obtained, so it was not possible to determine whether the target services were accessed.

The files suggest a possible sequence involving web shell activity, attempts to access internal systems, and further network discovery within a single working environment.

Case 2. Internal Network Scanning, Credential Collection, and Windows/Linux Implants

The second case involved 14 files.

The materials included internal network scan results, attempts to access systems through SSH with the root account, a credential collection script that used JVM heap dumps, a Java-based executable, implants for Windows and Linux, and a Reverse SOCKS worker.

Internal Network Scanning and Root SSH Access Attempts

The scan results contained information about systems and services on a Kubernetes Pod network and a separate private network.

Various services were identified, including SSH, HTTP, MySQL, Redis, MongoDB, and Memcached. Some were recorded as being accessible without authentication. A script was also found that attempted to establish SSH connections using the root account and restart Docker-related processes.

The scan results and SSH script indicate attempts to examine internal services and obtain administrator access.

However, it was not possible to confirm whether SSH authentication succeeded or whether elevated privileges were obtained.

Credential Extraction Scripts Targeting JVM Heap Dumps

The second case also included a Python script designed to extract authentication information from JVM heap dumps.

The script was configured to search Redis databases and related files for access information and extract access keys, secret keys, passwords, and other data from Java application heap dumps. The script was designed to collect stored access information as well as credentials present in application memory.

However, neither the actual heap dump files nor the results of the credential extraction were obtained, so it was not possible to determine whether any information was exfiltrated.

Windows and Linux Implants with Remote Control Capabilities

The second case also included executables and scripts written in several languages, including Java, Rust, and Go.

An implant is malware or a software agent that an attacker places on a compromised system to execute remote commands, collect information, or carry out further attack activity. Some implants can also be used to maintain persistent access to the system.

The Rust-based implants for Linux and Windows supported command execution, file uploads and downloads, process management, proxying, and tunneling.

The Go-based Linux implant also supported remote command execution, system information collection, file operations, and credential discovery.

The Reverse SOCKS worker was designed to establish a communication path between internal systems and an external C2 server.

Together, the implants and Reverse SOCKS worker could support remote control, lateral movement, and information collection across different operating systems and runtime environments.

However, these capabilities do not establish that the implants were used in an attack. Some execution traces were found, but the evidence was insufficient to conclude that every implant had been deployed or executed.

Key Findings from ARTEX Infrastructure Analysis

1. Evidence of Potential Real-World Attack Activity

Earlier analyses focused on ARTEX-related infrastructure and operational tools. The two working directories examined in this analysis contained evidence of attempted remote access, internal network reconnaissance, and tools capable of supporting further attack activity.

2. Multistage Attack Techniques Identified in ARTEX-Related Infrastructure

Across the two cases, the artifacts covered possible initial access, internal network discovery, remote access attempts, credential collection tooling, and remote-control capabilities. Examining these artifacts together can help reconstruct the possible attack sequence without treating every stage as confirmed execution.

3. Distinguishing Attack Execution Evidence from Threat Actor Attribution

Although the artifacts suggest attack activity, the analysis did not establish that ARTEX autonomously executed every action or that a single operator conducted them all. A tool's presence, evidence of its execution, attack success, and attribution must be assessed separately.

Threat Hunting for Pass-the-Hash, PowerShell, and C2 Activity

ASEC's findings suggest several areas for security teams to investigate during threat hunting.

ASEC identified PowerShell execution policy bypasses, encoded command execution, the creation of abnormal script files, Pass-the-Hash remote access attempts, and PowerShell execution through CIM or WMI as key hunting targets.

Security teams should also investigate external network connections initiated by suspicious processes, tunneling activity, and files and process behavior associated with remote-control malware.

Correlating endpoint processes and file activity with network connections and signs of credential misuse can help analysts determine whether separate events belong to the same attack sequence.

AhnLab EDR can be used to investigate suspicious endpoint activity, while AhnLab XDR can correlate security events from multiple sources. Combining these products with threat intelligence from AhnLab TIP can help security teams understand the context surrounding related IOCs and threat activity.

Tracking AI-Powered Penetration Testing Infrastructure and Attack Activity