Deep Dive: How a Solo Hacker Weaponized Agentic AI and ‘ARTEX’ to Breach South Korea’s Financial Sector

In early October 2026, a suspected lone threat actor used an autonomous, AI-driven penetration testing framework to breach several tier-one South Korean financial institutions. No nation-state syndicate or multi-year advanced persistent threat (APT) campaign was behind it. One financially motivated operator ran open-source agentic AI tools through the whole attack lifecycle. The campaign ran from late September to early October 2026 and compromised peripheral systems at major banks, exposing the personal and financial data of more than 144,000 customers.

Threat intelligence from CrowdStrike’s Counter Adversary Operations team shows that large language models acting as autonomous agents have lowered the barrier to wide-scale, coordinated intrusions against hardened financial targets. The main weapon was ARTEX, a recently released, China-developed agentic penetration testing system that turns raw AI reasoning into executable offensive tradecraft. The actor paired it with a multi-model LLM stack and routed traffic through obscure API relays. Strong core banking defenses count for little when the shadow APIs connecting a bank to third-party brokers go unmonitored.

This analysis covers the ARTEX framework, the peripheral API breaches, the multi-model AI infrastructure behind them, and the OpSec failures that exposed the actor. For CISOs, SOC analysts, and threat hunters, it is a case study in how agentic AI gets weaponized and why non-core financial attack surfaces need attention now.

How ARTEX works: anatomy of an agentic pentest framework

The speed of the bank breaches makes more sense once you see the tool’s architecture. ARTEX is not a traditional vulnerability scanner like Nessus, and it is not a static web application testing proxy like Burp Suite. It is an autonomous, multi-agent penetration testing system driven by LLM orchestration. A developer using the alias “Autumn-27” released it on GitHub in late July 2026. It gained traction in offensive security circles until the developer abruptly pulled it from public update cycles after its misuse in the Korean banking hacks.

Under the hood, ARTEX is a high-performance Go monolith backend with a Next.js frontend and a PostgreSQL database for state management. Its offensive capability comes from the norma SDK, a framework for managing AI agent behavior in complex environments. The SDK supplies the agents’ primitives: agentcore for lifecycle management, tool definitions for executing shell commands and network requests, permission boundaries that stop the AI from destroying its own host environment, and harness modules for interacting with target infrastructure. A memory module lets the agents keep context across multi-turn interactions, including discovered subdomains and valid credentials, throughout a prolonged intrusion.

The dual-graph architecture and goal decomposition

Simple script-generating AI wrappers lack what ARTEX has: a “Dual-Graph” architecture that changes how the tool approaches a target network. A traditional scanner runs a linear list of checks against an IP address. ARTEX uses two graphs. One maps the target’s technical topology (servers, ports, services, APIs), and the other maps the business objectives the penetration test has to complete.

When the threat actor enters a high-level objective such as “Extract customer PII from the loan broker portal”, the ARTEX Planner module starts goal decomposition. The Planner splits the objective into a shared Todo list of micro-tasks and hands them to specialized sub-agents. One agent might scrape JavaScript files for hidden API endpoints while another fuzzes the discovered endpoints for Insecure Direct Object References (IDOR) and a third writes Python scripts on the fly to parse and exfiltrate the JSON responses. That lets a solo operator run reconnaissance, exploitation, and data staging concurrently, with the output of an entire red team.

Why the peripheral systems fell

Many people in financial cybersecurity assume that protecting the core banking ledger and the main consumer mobile app is enough. The ARTEX campaign exploited exactly that perimeter-based thinking. The actor did not try to breach the core banking platforms, which are typically protected by Hardware Security Modules (HSMs), mutual TLS authentication, and strict air-gapped network segmentation. The AI agents went after shadow APIs and peripheral services that connect banks to external financial brokers and to internal employee support systems.

At Shinhan Bank, the entry point was a loan-progress inquiry service used by third-party financial brokers. External contractors often build these broker portals and integrate them through RESTful APIs. To maximize conversion rates and user experience, they tend to favor accessibility over strict security controls, which leaves weak rate limiting and inadequate object-level authorization checks.

Exploiting IDOR through agentic fuzzing

The main vulnerability across the affected institutions, including KB Kookmin Bank and Hana Bank, was IDOR in API endpoints. In a typical loan-broker API, a request to check a loan application status might look like this: GET /api/v1/loan/status?application_id=987654321. If the API never verifies that the authenticated user owns application_id=987654321, an attacker can iterate through sequential or predictable application IDs and scrape the database.

A human penetration tester might test a few dozen IDs by hand before writing a script. The ARTEX agents automated the process at scale. They generated fuzzing scripts dynamically, analyzed HTTP responses to identify valid application IDs, and moved straight to extracting the payloads. At Shinhan Bank alone, the enumeration exposed about 25,000 customer records, including names, phone numbers, annual income, and approved loan limits.

At KB Kookmin Bank, the agents compromised an internal mobile work-support system built for employees. Internal tools like this often assume that anyone connecting from an authorized IP range or holding a valid corporate token is legitimate. The agents, working through compromised proxy infrastructure, got past those implicit trust boundaries and harvested internal communications and employee directories. The campaign also hit Hana Bank, BNK Busan Bank, Yegaram Savings Bank, Hyundai Capital, Welcome Savings Bank, and several online lending firms, which shows how much risk sits in interconnected financial supply chains.

The multi-model AI stack and API relays

The actor’s LLM infrastructure was tiered. Instead of sending every task to one expensive frontier model, the operator balanced cost, latency, and reasoning ability across several. The primary backend for the ARTEX instance was DeepSeek v4.1-flash, a model tuned for fast code generation and quick logical deduction.

The role of xcai[.]pro and API relays

CrowdStrike’s analysis indicates that the actor did not reach the DeepSeek API directly. All LLM requests went through xcai[.]pro, which is assessed to be an LLM API proxy or relay service. In the underground AI development community, these relays (often called “中转站”, or transit stations) offer three advantages. They mask the developer’s true origin IP, so the upstream AI provider never logs the attacker’s residential or commercial address. They aggregate billing, which lets an attacker buy API credits with stolen credit cards or cryptocurrency without tying the payments to personal accounts. And they bypass geographic restrictions, giving actors in regions with strict AI export controls or localized internet firewalls access to global or competing regional models.

DeepSeek v4.1-flash handled the high-volume API fuzzing and script generation. The exposed ARTEX server directories showed that the operator added GLM-5.3 (from Zhipu AI) and Grok 4.6 for harder reasoning tasks during specific Claude Code sessions. The split makes sense: cheaper, faster models for brute-force reconnaissance, and heavier, costlier ones for analyzing business logic flaws or writing custom exfiltration malware.

The exposed CLAUDE.md file

The most damaging OpSec failure was leaving the ARTEX configuration directories open to the public internet. The main infrastructure node, on a Hong Kong-based IP address, exposed an open directory containing the /.claude/CLAUDE.md file. In AI-assisted development environments, a CLAUDE.md file works as a system-level prompt, giving the agent persistent context, operating rules, and instructions for how to behave inside the repository.

The exposed file held a comprehensive Chinese-language prompt telling the LLM how to conduct autonomous penetration testing, in effect the operational doctrine for the agents. The directory also held extensive Claude Code session histories and memory files, which gave threat hunters an unfiltered view of the attacker’s workflow, command history, and decision-making.

Threat actor profile: the hubris of “YY”

The session histories and memory files let analysts build a detailed profile of the actor, and the actor’s own hubris cost them their anonymity. In the Claude Code logs, the user asked the AI to write a professional cybersecurity researcher résumé. The prompt told the AI to list the successful South Korean bank breaches as verified bullet points of professional experience.

That résumé request also carried specific personal identifiers: the name “YY”, a Chinese mobile phone number (17820191556), and the Telegram handle @YY520CN. The profile put the actor at 26 years old, though they first gave a date of birth of September 22, 2007 before correcting the age, and it listed their education as the South China University of Technology in Maoming, Guangdong, China.

Other Claude Code sessions used the @YY520CN username for vulnerability research on a Telegram-based NFT gift marketplace and for targeting a Chinese payment platform. The financial motive shows in the actor’s queries to the AI. They asked where stolen South Korean breach data is usually sold on the dark web and requested help finding specific Korean data-sale groups on Telegram.

CrowdStrike assesses with moderate confidence that the actor is a Chinese-speaking, financially motivated individual. The personal details in the prompt could be spoofed or could belong to an identity the operator stole to mislead investigators. Even so, the volume of consistent telemetry tied to the @YY520CN handle gives international law enforcement and threat intelligence teams a solid starting point.

Regulatory response and political fallout

The finding that a publicly available open-source tool could strip PII from the country’s largest banks drew a strong reaction from financial regulators in Seoul. South Korean President Lee Jae Myung publicly addressed the breaches. He confirmed that authorities had found definitive indications that AI agents played a central role in the attacks and directed a multi-agency investigation.

After CrowdStrike published its report and media coverage linked ARTEX to the bank breaches, “Autumn-27” announced that ARTEX would stop receiving public updates and move to a closed-source model. The developer said the tool was meant for legitimate security testing and defensive research, and acknowledged that malicious actors had badly misused it. Open-source security projects often go closed-source when a dual-use tool moves from theoretical risk to active abuse. That does little about copies already forked and deployed by underground groups.

MITRE ATT&CK mapping and infrastructure analysis

To hunt for remnants of this campaign and prepare for future agentic AI attacks, SOC teams should map the observed behavior to the MITRE ATT&CK framework. The ARTEX campaign leans on techniques from Resource Development, Command and Control, and Collection.

Infrastructure topology and proxy chains

The intrusion used a two-server design that separated the AI reasoning engine from the active exploitation payloads. A Hong Kong-based IP address served as the primary command-and-control (C2) node and hosted the exposed open directories with the AI memory files. The IP address 38.244.50[.]120 hosted the ARTEX instance that ran the network scans and API fuzzing against the South Korean targets.

To hide the origin of the exploitation traffic and dodge IP reputation blocklists, the actor routed all outbound attack traffic through a chain of proxy servers. The ARTEX configuration files contained a hardcoded list of proxy IP addresses used during the campaign. This matches MITRE ATT&CK technique T1090 (Proxy). It let the actor mask their infrastructure and spread the malicious traffic across many networks, which makes automated blocking by bank WAFs much harder.

AI capability acquisition

The most novel mapping in this campaign is T1588.007 (Obtain Capabilities: Artificial Intelligence). Historically, the technique referred to actors buying stolen credentials or visiting dark web forums for exploit kits. In the 2026 threat landscape it also covers provisioning LLM API keys, deploying agentic frameworks like ARTEX, and using API relays like xcai[.]pro to sustain autonomous offensive operations. The actor effectively hired an AI red team, using the models to write exploitation scripts on the fly that got past static signature detection.

Strategic defense: securing the shadow API

The main lesson of the ARTEX campaign is that financial institutions cannot rely on the perceived security of their core banking environments. The attack surface now includes third-party broker portals, internal employee support applications, and partner APIs. In my view, defending against agentic AI means moving from signature-based detection to behavioral and zero-trust architectural models.

1. Eliminate IDOR with strict object-level authorization

The most serious technical failure ARTEX exploited was missing object-level authorization in peripheral APIs. Every API endpoint that touches PII needs strict Broken Object Level Authorization (BOLA) checks. A valid session token is not enough. The API gateway must cryptographically verify that the token has explicit ownership rights over the specific application_id or account_number in the request. SAST and DAST pipelines should also add AI-driven BOLA testing agents to catch these flaws before code reaches production.

2. Add AI-aware rate limiting and behavioral analytics

Traditional rate limiting, such as blocking an IP after 100 requests per minute, does not stop an agent that spreads requests across hundreds of proxy IPs while simulating human-like delays and randomized request headers. Defenses should track session behavior instead of IP velocity. If a single authenticated session starts sequentially querying thousands of distinct loan application IDs, the API gateway should trigger a step-up authentication challenge or terminate the session, whatever the source IP.

3. Egress filtering and LLM API monitoring

Security teams should monitor outbound network traffic for connections to known LLM API relays and unauthorized AI endpoints. Blocking all AI traffic is not realistic in a modern enterprise, but unauthorized egress to domains like xcai[.]pro, or to unknown IP ranges hosting open-source agentic frameworks, can give early warning of an internal compromise or a rogue shadow-IT deployment. Threat intelligence feeds should also carry the infrastructure signatures of known agentic pentest frameworks, so SIEM platforms can alert on the HTTP headers and user-agent strings that tools like ARTEX generate.

4. Secure the third-party supply chain

Banks should enforce strict security SLAs on every third-party broker portal and contractor-developed application. These peripheral systems deserve the same continuous agentic penetration testing as the core banking platforms. Requiring mutual TLS (mTLS) for all API communication between the bank and external brokers means that even if an AI agent finds a vulnerable endpoint, it cannot interact with it without the tightly controlled cryptographic client certificates.

Indicators of Compromise (IoCs)

The following Indicators of Compromise are associated with the ARTEX campaign against South Korean financial institutions. Security administrators should ingest these defanged indicators into their SIEM, MISP, or threat intelligence platforms to hunt historical telemetry and block future activity. IP addresses and domains are intentionally defanged (for example, [.]) to prevent accidental resolution.

Indicator	Type	Reported Role in Campaign
38.244.50[.]120	IP Address	Threat actor-controlled server hosting the active ARTEX exploitation instance.
101.53.80[.]20	IP Address	Proxy node used to obfuscate ARTEX-related attack traffic.
205.214.59[.]31	IP Address	Proxy node used to obfuscate ARTEX-related attack traffic.
124.155.252[.]63	IP Address	Proxy node used to obfuscate ARTEX-related attack traffic.
154.201.79[.]246	IP Address	Proxy node used to obfuscate ARTEX-related attack traffic.
23.248.249[.]90	IP Address	Proxy node used to obfuscate ARTEX-related attack traffic.
23.158.220[.]98	IP Address	Proxy node used to obfuscate ARTEX-related attack traffic.
103.248.148[.]84	IP Address	Proxy node used to obfuscate ARTEX-related attack traffic.
203.160.133[.]172	IP Address	Proxy node used to obfuscate ARTEX-related attack traffic.
209.209.85[.]38	IP Address	Proxy node used to obfuscate ARTEX-related attack traffic.
xcai[.]pro	Domain	LLM API proxy/relay utilized to access DeepSeek v4.1-flash anonymously.
http[:]//38.244.50[.]120:18899/.claude/CLAUDE.md	URL Path	Exposed configuration file containing AI pentesting prompts and target context.

Conclusion

The October 2026 breaches of the South Korean financial sector show agentic AI working as a real offensive tool. ARTEX was publicly available, and one financially motivated actor used it with multi-model reasoning, automated goal decomposition, and API relays to run a campaign that would once have needed a coordinated group. The targets were the forgotten corners of the financial API ecosystem, not the core banking systems.

As open-source AI frameworks improve, the line between automated vulnerability scanning and autonomous, reasoning-based intrusion will keep blurring. My advice to banks is to assume an agent like this can reach every connected endpoint, and to lock down peripheral APIs with zero-trust architecture on that basis.