AI Agent Breach: ARTEX and Korea's Financial Firms

From late September into early October, attackers using ARTEX, an open-source Chinese penetration-testing agent, reached seven South Korean financial companies, among them major banks (Seoul Economic Daily). Data on about 68,000 customers and employees was exposed, including income and loan limits for some. CrowdStrike traced the campaign through files on the attackers’ own server, and police have not identified who was behind it (CrowdStrike).

What happened

The attacker appears to have been after personal and financial records to sell. CrowdStrike found prompts asking Claude where Korean breach data is usually sold and how to find Telegram groups that trade it. Targets included a bank’s loan progress inquiry service and a bank’s employee mobile work-support system.

ARTEX was built by Chinese engineer Li Puhua to help organizations test their own networks, and anyone can download and modify it. CrowdStrike found the attacker’s ARTEX instance on 38.244.50[.]120, port 18899, along with Claude Code session histories and a CLAUDE.md file of Chinese-language penetration-testing instructions. ARTEX called DeepSeek v4.1-flash through xcai[.]pro, likely an API reseller, with GLM-5.3 and Grok 4.6 as supplements. CrowdStrike assesses with moderate confidence that the attacker is “likely a Chinese speaker and financially motivated.”

How it could have been caught

An agent that breaks into a network still has to act inside it, and each of those actions is new to the environment. A baseline of process and network activity would have flagged the first shell started by a bank’s public web application, since that application had never started one. Detection keys on behavior inside the network, so routing traffic through nine proxy addresses adds no cover.

What this looks like in Trace

Here is one intrusion path traced end to end inside the bank that ran the breached loan inquiry service. The service, the external addresses, and the models come from CrowdStrike’s report. Workload names, process ancestry, internal hosts, which address each step reached, and timings are illustrative.

Network trace. Workload web/loan-inquiry, the internet-facing loan progress inquiry service. Each row is a tuple Trace’s sensor recorded, checked against the baseline.

Each proxy address is another first-seen destination for the same process, so the rotation lands in one case.

Inference. ARTEX did its reasoning on the attacker’s servers, so those model calls never crossed the bank’s network. An implant left on the host that needed a model would have to reach xcai[.]pro or another provider through the AI proxy, presenting a credential the bank never issued, or start a model process the host had never run.

Traceback. At T+0:12 the triage agent opens a case and follows the chain:

customer-db query → python3 → sh → java (loan-inquiry) → no deploy → no commit → no ticket → no author

The chain stops at the loan inquiry process with nothing behind it, and that dead end is the finding.

Verdict: an outside intrusion reaching customer loan records from a public web service. The case goes to the security team with the process chain, both database connections, and the attacker’s addresses attached, about 12 minutes after the first shell and before the bulk transfer at T+0:26.

This analysis reconstructs the incident from public reporting and walks through where Trace would have raised the first alert inside the cloud of one of the affected banks. Detection times are illustrative.