The side door is the front line

*A Chinese-speaking operator used an open-source AI attack framework against at least nine South Korean financial institutions. Lower priority, non-core systems were the ones compromised.

What happened

Beginning in late September 2026, a series of data breaches hit South Korean financial institutions. Shinhan Bank, KB Kookmin Bank and Hana Bank were named publicly; by early October, at least nine institutions had disclosed an incident or been named in local reporting, and the government convened an emergency meeting.¹

CrowdStrike attributed the campaign’s tooling with moderate confidence to a single financially motivated, Chinese-speaking operator — not to a named group. The operator used ARTEX, an open-source agentic penetration-testing framework developed in China, alongside frontier and Chinese-hosted language models, and orchestrated it with Claude Code.²³ Measured across the campaign, the exposure reaches roughly 67,000 individuals — names, phone numbers, annual income figures and loan limits.¹ Shinhan Bank alone reported about 25,000 affected records.⁴

Two details from the reporting deserve more attention than the headline number.

The first is what got breached. At one bank it was a loan-progress inquiry service used by financial brokers. At another it was an employee mobile work-support backend. Neither is the core banking platform. The vulnerabilities were mundane — SQL injection and authentication bypass in internet-facing web applications.¹ The vault lock was never picked. Somebody worked the side doors.

The second is how cheap the campaign was to run. ARTEX is a multi-agent harness, not a model: a planner breaks the objective into tasks, worker agents execute real tooling against live targets, findings accumulate, and the loop continues until the goal is met. The operator pointed it at targets and supplied a hosted model. One person, multiple institutions, a few weeks.

Why the side doors are now the front line

Side doors have always existed. What changed is the cost of finding them.

A peripheral service — a broker portal, a partner lookup, an internal tool with an internet-facing front — used to be worth attacking only if you already knew it was there, or got lucky. Enumerating an organisation’s whole external surface, testing each endpoint for the boring, reliable classes of bug, and keeping the results organised across many targets was slow, skilled work. It scaled with headcount, and headcount is what a single actor does not have.

An agentic harness removes both constraints at once. It is patient in a way people are not, it retries, and it does not get bored at endpoint four hundred. The framework the operator used here was built for authorised testing and shipped with a default blocklist — of government and university domains. Financial institutions were not on it, so a default install pointed at a bank had nothing in its way.¹ Guardrails implemented as a domain list are a filter, not a control.

The consequence is not that every organization will be breached by an AI agent this quarter. It is that the peripheral tier of your estate has been repriced. The services you treat as low-stakes — the internal tool with a vendor front end, the partner API, the reporting portal some business unit stood up — are now the most attractive targets you have, because they are the ones with the least review and the most access to real records.

The part you can actually use

Agentic attacks are template-driven, which makes them legible if you are looking. The indicators below are drawn from the two vendor analyses of this campaign, and none of them require new tooling.¹²

• Sequential and high-volume lookups against your own endpoints. An agent enumerating records produces a pattern: requests in sequence, unusually high record counts per session, endpoints hit far more often than human behaviour would explain. If your broker portal will return client 10001, 10002, 10003 to anyone who asks, you do not have a detection problem — you have an authorisation problem. Fix that first; it is the actual vulnerability in most of these incidents.

• Your servers making calls to model providers. Outbound requests from an application server to api.anthropic.com, api.deepseek.com, open.bigmodel.cn or api.x.ai are worth investigating when no deployment explains them. The same signal applies in your own environment for a different reason: an unexpected LLM endpoint from an internal host is a reasonable proxy for “something is running that nobody told you about.”

• Structured data leaving over HTTPS to somewhere it should not. The exfiltrated fields here were names, phone numbers and financial attributes. Bulk egress of that shape is detectable even without knowing the attack that produced it.

• Web shells in unexpected places. *.aspx and *.jsp files appearing in application paths that never contained them.

• Agent session artefacts. The most instructive detail in the whole campaign is how it was unravelled. Investigators found attacker-controlled servers with open directories exposing Claude Code session histories, memory files and the framework’s configuration — including a directly readable prompt file at /.claude/CLAUDE.md.² The operation was legible because the operator’s tooling kept records and nobody closed the door on them. Two consequences worth holding at once: agentic tooling is a forensic channel that works in your favour during an investigation, and any agentic tooling running in your own environment is producing files about your environment that you should know the location of.

What to do this quarter

1. Test authorization, not just authentication. The breached services let users reach records outside their remit. Repeat that test as applications change, and verify that a broker can only see a broker’s clients. This single control addresses the majority of what happened here.

2. Add rate limits and enumeration alerts to record-returning endpoints on partner, broker and employee portals. Sequential-lookup patterns and high records-per-session counts are cheap rules that catch an automated reconnaissance pass early.

3. Inventory the peripheral tier deliberately. You know your core systems. The question is whether you have a current list of every internet-facing service in the organisation, who owns it, and what data it can reach — including the ones built by a business unit and never reviewed. Most first inventories of this tier turn up more than expected, and the useful output is not the count but the ownership: a service with no named owner is a service with no one watching it.

4. Treat open-source agentic security tooling as hostile code. If anyone in your organisation runs one of these frameworks — for testing or otherwise — isolate it from production, keep production credentials out of it, and enforce scope in configuration and code rather than in prompts. The prompt is the least reliable place to put a boundary. Review forks before execution, because after a tool like this becomes news the upstream project often closes while the copies keep circulating.

If you only do one thing

Ask your team, this week, to list every internet-facing service in the organisation and name its owner. Not the core platforms — those are covered. The ones somebody stood up for a specific process and then forgot.

Then pick the three that can return records about customers and confirm, by testing rather than by asking, that they cannot return someone else’s.

The lesson of this campaign is not that AI is coming for your perimeter. It is that AI has made your side doors cheap to test, and the side doors were never the part anyone was watching.

Illuminate Risk LLC helps mid-market organisations map what their AI agents can reach, govern what they can do, and see the activity their existing detection was never written for. If you want a second opinion on where your exposure actually sits — including the peripheral services nobody has inventoried — a 25-minute discovery call is the place to start. No proposal until we both know it is a fit.

Footnotes

1. Zscaler ThreatLabz, Threat Actor Abuses Agentic AI Pentesting Framework to Target South Korean Financial Institutions (14 October 2026) — campaign assessment, ~67,000 individuals’ PII, SQL injection and authentication bypass in peripheral web applications, and the default blocklist covering government and university domains but not financial institutions. https://www.zscaler.com/blogs/security-research/threat-actor-abuses-agentic-ai-pentesting-framework-target-south-korean ↩ ↩² ↩³ ↩⁴ ↩⁵

2. CrowdStrike Intelligence, Unknown Threat Actor Uses AI-Driven ARTEX to Target South Korean Finance (7 October 2026) — attribution assessment (moderate confidence, Chinese-speaking, financially motivated), the two-server architecture, the exposed /.claude/CLAUDE.md, and the LLM backends used. https://www.crowdstrike.com/en-us/blog/unknown-threat-actor-uses-artex-to-target-south-korean-finance/ ↩ ↩² ↩³

3. BleepingComputer, ARTEX AI, Claude agents used in cyberattacks on South Korean banks (10 October 2026) — ARTEX going closed-source, and the English- and Korean-language derivatives still in circulation. https://www.bleepingcomputer.com/news/security/hacker-used-artex-ai-and-claude-agents-to-target-south-korean-banks/ ↩

4. Reported by The Straits Times and relayed by Infosecurity Magazine — Shinhan Bank approximately 25,000 affected records; Yegaram Savings Bank approximately 40,000. News-media figures, not vendor-confirmed: https://www.infosecurity-magazine.com/news/chinese-hacker-ai-korean-banks/ ↩