ARTEX Exposed: Mapping the Infrastructure Behind the South Korean Bank Breaches

Disclosure note: Hunt.io notified the relevant national CERT prior to publication. No personal records or credentials from the affected systems appear in this report.

Open directories are among the most valuable sources of insight into active threat actor operations. When an attacker misconfigures a staging server, the exposure can reveal far more than the final payload. In early October 2026, CrowdStrike reported that an unknown, financially motivated threat actor had used ARTEX, an AI-driven autonomous penetration testing framework, in intrusions targeting South Korean financial organizations. The Hacker News and Security Affairs subsequently covered the campaign, bringing wider attention to the use of AI-driven offensive tooling in real-world intrusions.

The public reporting identified a key server at 38.244.50[.]120, nine additional IP addresses described as proxies, and the LLM reseller domain xcai[.]pro.

But the public indicators were only part of the story.

Our investigation examines another infrastructure at 23.248.226[.]250 associated with the reported campaign. The findings reveal a broader operational environment that includes AI model-routing components, proxy infrastructure, exploitation tooling, credential-handling scripts, and mobile-device utilities.

This research walks through the evidence, the infrastructure pivots, and the artifacts recovered from the exposed directories to show what can be learned when an investigation goes beyond the initial indicators of compromise.

Key Takeaways

• Our investigation revealed a new open directory at 23.248.226[.]250 which acts as a Hong Kong-based jump server.

• The analysis found Claude Code configurations, custom model-routing shims, and 19 agent skills that supported reconnaissance, web testing, payment logic analysis, and mobile operations.

• The recovered configuration and routing scripts reference DeepSeek, GLM, and Grok-related components, providing evidence of a multi-model setup consistent with the reported use of alternative AI services.

• FOFA-related tooling and a proxy service at 154.201.79[.]246:443 provided additional infrastructure pivots, with 79 unique exit IPs observed in an initial sample of 100 identities.

• Cryptocurrency, Linux exploitation, and mobile-device artifacts were also recovered, but their direct relationship to the reported South Korean breaches remains unconfirmed.

• The recovered tooling includes reconnaissance scripts, proxy enumeration utilities, reverse SSH tunnel management, a staged JNDI/LDAP exploitation setup, Linux privilege-escalation exploits, and mobile-device tooling.

• Hunt.io pivoting expanded the set of candidates for ARTEX infrastructure through certificate metadata, ARTEX malware classification, and HTTP title matching, providing complementary hunting methods.

Background and Campaign Overview

Between late September and early October 2026, seven South Korean financial institutions experienced data breaches involving internet-facing peripheral systems. Approximately 66,000 to 67,000 individuals and around 2,200 corporations were affected, with personal, employment, income, and loan-related information exposed.

CrowdStrike published its findings on October 7, 2026, followed by the Genians Security Center (GSC) on October 12. Both reports attributed the activity to ARTEX, an open-source autonomous penetration testing framework developed in China and licensed under the GNU Affero General Public License version 3.0 (AGPL-3.0).

CrowdStrike assessed with moderate confidence that the operator was a single Chinese-speaking individual motivated by financial gain rather than an established threat group. The assessment identified DeepSeek v4.1 Flash as the primary model, with GLM 5.3 from Zhipu AI and Grok 4.6 serving as backup models.

The infrastructure reportedly accessed these services in part through the reseller domain xcai[.]pro. Both reports described a two-server configuration, consisting of a Hong Kong-based IP address used as primary infrastructure and 38.244.50[.]120, which hosted the ARTEX console.

GSC also reported that the original ARTEX GitHub repository and Docker image were removed on October 11, although forks and mirrors remained available.

Infrastructure Discovery and Initial Pivoting

Our intelligence for 38.244.50[.]120 provides a more detailed view of the infrastructure associated with the ARTEX campaign. The address falls within the 38.244.48.0/21 network and is attributed to AS174, operated by Cogent Communications, LLC. Hunt.io identifies its location as Los Angeles, California, United States. The record shows seven warnings, 73 associations, 17 pivots, and 13 code search results.

Our solution lists 15 open ports, including SSH on ports 22 and 8443, HTTPS on port 443, and several HTTP services on nonstandard ports. The ARTEX login interface appears on ports 443 and 8090, with the page title displaying "ARTEX - 自主渗透测试控制台". Port 5918 hosts a web interface titled "Gemini2API - 管理控制台", served by Uvicorn, while ports 9003, 18080, and 18098 expose HTTP services identified as Python BaseHTTP servers. A Tinyproxy service is also identified on port 18888.

Our AttackCapture™ platform reports 23 files totaling 6.69 MB, with no subdirectories. The captured data is associated with the host 38.244.50[.]120:8000, geolocated to Los Angeles, California, United States, and includes a recorded timestamp of August 22, 2026.

We have expanded the infrastructure by searching "38.244.50[.]120" in AttackCapture and found another open directory at 23.248.226[.]250 acting as a jump server. The code search returned 13 matching results, including configuration files containing hardcoded credential references, scripts suggesting remote file synchronization, and commands designed to download and execute remote scripts.

The second IP address, 23.248.226[.]250, is associated with AS138415 (Yancy Limited) and the network range 23.248.224.0/20. The IP is geolocated to Tung Chung, Islands, Hong Kong, and is associated with RedLuff, LLC (redluff.com). AttackCapture reports revealed three AttackCapture warnings for potentially malicious open directories, recorded on September 5, September 26, and October 5, 2026.

The AttackCapture associated with the second IP, 23.248.226[.]250, exposes a directory containing 42 files across 2 subdirectories, with a total reported size of 105 MB. The directory was last recorded on September 26, 2026, at 14:47 and is accessible via HTTP on port 18099.

Evidence Linking the Exposed Infrastructure to ARTEX

The most direct link between 23.248.226[.]250 and the published ARTEX IOC is the jump-host configuration recovered from the exposed directory at 23.248.226[.]250:18099.

The directory contains a file named .secrets and a corresponding backup named .secrets.bak-20260911. These files reportedly use Unix permission mode 600, which restricts access to the file owner under standard Unix permission semantics. It also contains the same Chinese-language operational comment, which translates to: "Sole source of credentials; permission 600; never paste plaintext into a session; read only the specific line when needed."

The additional credential fields identify other configured services, including a Zhipu AI API key, an OpenAI-compatible relay key, and Webshare credentials.

# sole source of credentials, chmod 600, never paste plaintext in a session
JUMPHOST=38.244.50.120
JUMPHOST_USER=root
JUMPHOST_PASS=[REDACTED]
ZAI_KEY=[REDACTED, Zhipu AI / GLM API key]
RELAY_KEY=sk-[REDACTED, OpenAI compatible relay key]
WEBSHARE_USER=[REDACTED]
WEBSHARE_PASS=[REDACTED]

                
Copy

The credential-file evidence is corroborated by three shell scripts (local-boot.sh, tunnel-watchdog.sh, and sync-memory.sh) recovered from the same host. All three reference 38.244.50[.]120 and use sshpass to supply a password for SSH-based operations targeting the remote root account.

The scripts reveal three complementary functions.

• local-boot.sh restores a reverse SSH tunnel after startup, forwarding the local service on port 8100 to the jump host, and launches a local sing-box relay configured to listen on port 11050.

• tunnel-watchdog.sh checks for an existing reverse tunnel associated with port 22222 and starts it if the expected process is absent. The accompanying comment identifies the remote forwarding target as local port 48989, associated with a read-only Dufs service.

• sync-memory.sh copies Markdown files from a local memory directory to five destination paths on the jump host and then attempts ownership adjustments for directories associated with the grok and gemini accounts.

A ZAI_KEY entry in the available file provides access to Zhipu AI's GLM models, while a tunnel defined in local-boot.sh is explicitly named grok2api. This architecture offers a plausible explanation for CrowdStrike's observation that multiple LLM backends were active within the same campaign.

AI Model Routing and Runtime Configuration

A state file named .claude.json confirms that the harness is Claude Code itself, running base version 2.1.221, with 510 recorded startups since August 4, 2026. However, the installation is not communicating directly with Anthropic's API.

A small local proxy, ds-models-shim.py, addresses a compatibility issue: the official /v1/models endpoint returns a 404 response when queried against a non-Anthropic backend, preventing Claude Code from discovering the available models. The shim intercepts that specific request and returns a locally defined model list containing deepseek-v4-pro and deepseek-flash. All other requests are forwarded to api.deepseek.com/anthropic.

A second proxy, xcai-effort-shim.py, provides further insight into the setup. Its docstring describes the request-routing chain in the operator's own words, translated from Chinese: "The Gemini user path is Claude Code to CCR on port 3456, then to xcai at direct[.]xcai[.]pro, and finally to DeepSeek."

CCR, or Claude Code Router, is an open-source project that enables Claude Code to communicate with alternative model backends. The xcai[.]pro domain is also significant: CrowdStrike has reportedly identified it as an indicator associated with this campaign. The shim's specific function is to inject a reasoning_effort field into every outgoing request. According to the operator's documentation, this parameter is necessary because the DeepSeek backend accessed through xcai otherwise skips its reasoning stage.

Custom Agent Skills and Operational Workflows

The same .claude.json file records usage counts for 19 custom Claude Code skills, which are reusable instruction sets written by the operator for the agent. These skills provide a clear picture of the operation and the tasks the agent was designed to carry out.

They provide an overview of the operation's main activities, from reconnaissance and application analysis to mobile device automation and payment testing.

The payment-logic skill is particularly notable because a file named .secrets-cashin-test-accounts was found alongside it. The file contains three self-registered accounts with JWTs for a cash-in deposit API. A source comment describes the accounts as part of an authorized, self-built test dated September 12, 2026. Each account has its own user ID and bank account ID.

This setup is consistent with an approach to testing for insecure direct object reference (IDOR) vulnerabilities.

Genians and CrowdStrike have described similar techniques in connection with attacks against Korean loan and inquiry services.

Reconnaissance Tooling and Staged RCE Exploitation

The same directory contains the tools used to support reconnaissance, manage proxy infrastructure, and stage a remote code execution (RCE) chain.

FOFA Access Through a Third-Party API

fofa2.py is a Python client for FOFA, a Chinese cyberspace asset search engine commonly compared with Shodan and Censys. The script sends requests to the third-party service fofoapi.com. It constructs an HMAC-SHA256 signature, generates a timestamp and nonce, and submits search parameters through the service's /api/v1/search/all endpoint.

A comment in the source code states that the primary membership had expired and that a backup key was being used. This suggests that the operator had previously relied on a paid FOFA membership and had switched to an alternative access method.

def nonce():
    return hashlib.sha256(
        (UA + "1920x1080x24" + "zh-CN" + SALT).encode()
    ).hexdigest()[:32]
url = "https://fofoapi.com/api/v1/search/all?" +
      urllib.parse.urlencode(params)
### Tracking Proxy Enumeration and Exit-IP Tracking

                
Copy

The scripts proxypool.py and proxypool_enum.py manage and enumerate a rotating proxy service exposed at 154.201.79[.]246:443. The service accepts credentials following the Default.customerNNN naming pattern, allowing the operator to test multiple customer identities against the same endpoint.

It uses concurrent requests to identify exit IP addresses, retries failed probes, and maintains a persistent ledger linking identities to observed IP addresses and project assignments. The scripts also identify shared exit IPs and compare results across sampling rounds.

The initial sample reportedly contained 79 unique exit IP addresses among the first 100 identities tested. This demonstrates that the service can expose multiple exit IPs through a single proxy endpoint.

The address 154.201.79[.]246 is also identified as a proxy-related indicator in reporting by CrowdStrike, ThreatBook, and Cybersecurity News.

JNDI/LDAP Exploitation Infrastructure

Another open directory at 23.248.226[.]250:8001 holds a small, self-contained JNDI and LDAP exploitation rig built on the UnboundID LDAP SDK. According to the associated logs, the chain was staged and retrieved on October 5, 2026, at 03:42 UTC.

The LDAPRefServer.java and LDAP2.java create an in-memory LDAP directory server that returns specially crafted Java naming references in response to search requests. The server modifies search results to include a javaNamingReference object with attributes specifying a Java class name, a codebase URL, and a factory class. In LDAP2.java, these attributes point to the Exploit class hosted at the same external address.

The supplied Exploit.class provides further evidence of the intended execution chain. Its static initializer invokes system commands, including id, hostname, and uname -a, and also attempts to read /etc/hostname. The resulting output is sanitized before being incorporated into a DNSLog callback hostname under u6ud2s.dnslog.cn.

This mechanism is designed to confirm command execution through an out-of-band DNS interaction. The compiled class also contains references to HTTP-based retrieval commands, indicating an alternative mechanism for transmitting data.

The accompanying mux.py script provides a single entry point for HTTP and LDAP traffic. It inspects the first bytes of each incoming connection and forwards HTTP-like requests to a local service on port 8000, while routing other connections to the LDAP service on port 1389. This arrangement allows the two services to share one listening port, provided the traffic can be classified by its initial bytes.

Recovered Tooling and Payloads: Exchange Access and Mobile Device Operations

The files recovered from 38.244.50[.]120:8000 and from 23.248.226[.]250:8907 contained a diverse collection of scripts, binaries, source files, and configuration artifacts associated with cryptocurrency-exchange access, Linux exploitation, and mobile-device operations.

The following table summarizes the recovered artifacts and their observed or apparent functions.

The recovered artifacts fall into two broad operational areas. The first concerns cryptocurrency-exchange access and web application workflows, including administrator-session checks, withdrawal functionality, shell access, and collection of configuration files. The second concerns Linux exploitation and mobile-device research, including kernel exploit builds, iOS proof-of-concept source files, Android firmware utilities, and cloud-phone tooling.

Hunting ARTEX Infrastructure with Hunt.io

Four open directories provided two initial indicators: the ARTEX console host and its Hong Kong jump host. Using these indicators, Hunt.io SQL enables three primary hunting approaches based on certificate metadata, malware classification, and HTTP page titles.

The queries below were executed against Hunt.io during this analysis. Each query is reproduced as written, alongside its reported results and the evidence it provides.

Hunt.io supports three complementary approaches to hunting ARTEX infrastructure:

1. Certificate pivot: Search for the ARTEX issuer organization to identify hosts exposing the matching TLS certificate.

2. Malware classification: Query malware.name for ARTEX to obtain a broader set of candidate IP addresses.

3. HTTP title matching: Search for the exact console title, then expand the search to identify translated and modified title variants.

Certificate-Based Infrastructure Hunting

The ARTEX console at 38.244.50[.]120 presented a TLS certificate with ARTEX as its issuer organization. Hunt.io's SSL history records the certificate with the following SHA-256 fingerprint:

C7A884AFCD7F91408921890D9617BEF6BFAC3DAE992BC25BB9C48C0395A60842

The certificate's subject common name is 38.244.50.120. Its recorded validity period runs from September 25, 2026, to September 22, 2036.

The issuer organization provides a useful search pivot because it is a specific, distinctive string. Searching for this value can identify hosts that retain the same certificate configuration.

SQL query:

SELECT
  ip
FROM
  certificates
WHERE
  issuer.organization = 'ARTEX'
  AND timestamp gt '2026-01-01'
GROUP BY
  ip

                
Run in HuntSQL
Copy

The result returned 19 distinct IP addresses, including 38.244.50[.]120. This method is precise but limited to hosts that expose a matching certificate. Systems using a different certificate will not appear in these results.

Hunting ARTEX Through Malware Classification

ARTEX infrastructure through the malware.name field. Searching this classification provides broader coverage than the certificate pivot because it does not require the host to retain the same certificate.

SQL query:

SELECT
  ip
FROM
  malware
WHERE
  malware.name == 'ARTEX'
  AND timestamp gt '2026-01-01'
GROUP BY
  ip

                
Run in HuntSQL
Copy

The result returned 1,303 distinct IP addresses. The difference demonstrates the broader coverage of Hunt.io's ARTEX classification compared with a single certificate attribute.

Geographic Distribution of ARTEX-Tagged IP Addresses

We have performed an aggregation to find a view of the geographic distribution of ARTEX-tagged IP addresses.

SQL query:

SELECT
  asn.country_code, uniq(ip) as hits
FROM
  malware
WHERE
  malware.name == 'ARTEX'
  AND timestamp gt '2026-01-01'
GROUP BY
  asn.country_code
ORDER BY
  hits DESC

                
Run in HuntSQL
Copy

The result shows 30 different countries having ARTEX infrastructure. The United States accounts for the largest number of IP addresses, followed by China and Hong Kong. These figures describe the country attribution of the observed IP addresses, not necessarily the physical location of the operator.

HTTP Title-Based Infrastructure Hunting

The ARTEX login page provides another fingerprint through its HTML document title.

The console observed at 38.244.50[.]120 uses the following title:

ARTEX - 自主渗透测试控制台

This title matches the banner reported by Genians and provides a direct string for searching HTTP observations in Hunt.io.

SQL query:

SELECT
  ip
FROM
  http
WHERE
  html.head.title == 'ARTEX --- 自主渗透测试控制台'
  AND timestamp gt '2026-01-01'
GROUP BY
  ip

                
Run in HuntSQL
Copy

The result returned approximately 1,300 unique IP addresses. It suggests that the title-based search has broad coverage in the observed dataset.

Expanding the Search to Localized Title Variants

A further search can identify additional console instances that use translated or slightly modified titles.

SQL query:

SELECT
  html.head.title
FROM
  http
WHERE
  html.head.title LIKE '%ARTEX%'
  AND (
    html.head.title LIKE '%--- %'
    OR html.head.title LIKE '%: %'
  )
  AND timestamp gt '2026-01-01'
GROUP BY
  html.head.title

                
Run in HuntSQL
Copy

The result returned 21 distinct title strings, of which 19 were identified as potentially relevant ARTEX console variants during the analysis.

The returned titles include English, Chinese, Korean, Japanese, Russian, Portuguese, and Vietnamese variants.

Hunting ARTEX Open Directories via AttackCapture

The certificate, malware classification, and HTTP title pivots discussed above help identify ARTEX infrastructure at a broad level. An additional pivot through AttackCapture's malware name search helps narrow the results to systems where ARTEX operators may have exposed working files and supporting tools.

The search returns 280 results covering the ARTEX panel itself, other exposed services hosted on the same systems, and open directories that AttackCapture has independently flagged as malicious.

Consider the following example to illustrate how AttackCapture can be used to identify and investigate ARTEX-associated infrastructure.

Validating an Individual Result

One of the results, http://130.94.31[.]86:18888, reveals a small open directory containing two files, agt.py and agt4.py, with a combined size of 4.05 KB. AttackCapture's File Manager classifies both files as malicious.

The host profile strengthens this correlation by identifying ARTEX as the active malware and displaying a standing warning for a Potential Malicious Open Directory. The system is associated with LIGHT NODE LIMITED (AS154177), located in Seoul, South Korea.

A port scan of the same IP address provides additional context. The ARTEX panel operates on port 8787, with the HTML title ARTEX - 自主渗透测试控制台, while the open directory is accessible through the separate port 18888.

The second example reveals an SMB reconnaissance and lateral movement toolkit whose own filenames contain an explicit reference to ARTEX.

The IP address 156.251.11[.]39 belongs to the network associated with Tcloudnet (AS399077), within the IP range 156.251.11.0/24, and is geolocated to Hong Kong. Our platform flags the host as high risk, identifying ARTEX as active malware and recording three warnings for potentially malicious open directories on ports 18080, 18084, and 18443. Port 8787 serves the ARTEX panel, identified by the HTML title ARTEX - 自主渗透测试控制台.

The open directory contains an Impacket-based toolkit focused on SMB and printer RPC reconnaissance, credential-based authentication, and potential lateral movement. The exposed scripts include smbls.py, splenum.py, winregread.py, and winrm_ntlm.py. The scripts use hardcoded NTLM hashes and a machine account named ITS-RENDER-01$ to authenticate to internal hosts and enumerate network shares, printers, and registry keys.

The strongest link between the exposed toolkit and the ARTEX name appears in wtest.py. It uses impacket to connect to SMB on hardcoded IPs/ports. Uses machine account ITS-RENDER-01$ with provided LM/NTHash to connect, write 'artex_probe_11876.txt' to the print$ share, then attempts deletion.

This example extends the investigation beyond a correlation based on malware classification and service fingerprints. The host exposes an ARTEX-identified panel and a separate directory containing SMB reconnaissance tooling. The artex_probe_11876.txt filename provides an additional, direct textual association with ARTEX.

Other notable examples where Artex is found are below:

In this way, an AttackCapture's malware name search provides a useful pivot from identifying ARTEX infrastructure to examining potentially exposed operational artifacts.

Mitigation and Defensive Recommendations

The findings highlight risks associated with exposed administrative services, reusable credentials, remote access tunnels, proxy infrastructure, and exploitation tooling.

1. Remove unnecessary public access and restrict required administrative access through approved VPNs, allowlists, or dedicated management networks.

2. Reset SSH passwords and rotate API keys, proxy credentials, service tokens, and other secrets that may have been accessible through exposed files.

3. Patch internet-facing services, validate authentication and authorization controls, and restrict sensitive administrative functions.

4. Monitor for unexpected LDAP and JNDI activity, anomalous DNS callbacks, remote script downloads, unusual process execution, and unexplained outbound connections.

5. Enforce least-privilege file permissions and use a managed secrets store for credentials required by applications.

6. Restrict access to model gateways, protect their credentials, and monitor requests for unexpected destinations, unauthorized model endpoints, and suspicious automation.

7. For managed Android and iOS environments, enforce device compliance policies, trusted firmware requirements, application controls, and monitoring for unauthorized rooting, bootloader modification, or jailbreak activity.

MITRE ATT&CK Matrix

Indicator of Compromise (IOC) table

Conclusion

The investigation expands the ARTEX campaign view beyond its publicly reported infrastructure. Analysis of exposed directories associated with 38.244.50[.]120 and 23.248.226[.]250 uncovered AI model-routing components, remote access scripts, proxy management utilities, exploitation tooling, and mobile-device utilities. These artifacts indicate a broader operational environment supporting reconnaissance, exploitation, and infrastructure management.

Hunt.io queries provided additional leads through certificate metadata, malware classification, and HTTP title matching. The malware classification query returned 1,303 distinct IP addresses, while certificate and title searches offered complementary methods for identifying potentially related hosts.

These findings show the value of combining infrastructure intelligence with exposed-file analysis and source-code inspection. This approach helps investigators move beyond isolated indicators, identify relationships between operational components, and develop more targeted detection and response measures. Further validation against independent telemetry and threat intelligence will be necessary to establish the full scope of the infrastructure and its relationship to the reported activity.