ARTEX and the Korean bank breaches: what to check first

Thank you!

You're subscribed!

Oops! Something went wrong while submitting the form.

In late September, an attacker using an open-source AI agent called ARTEX went after South Korean banks. By October 3, seven financial institutions had disclosed breaches covering at least 68,000 people, among them Shinhan, KB Kookmin and Hana. CrowdStrike tied ARTEX to the campaign, though not every breach has been publicly attributed to it.

The agent didn't use a zero-day. It went after a broker loan-status API, employee mobile apps and a recruiter search page, and asked them for records they should never have returned.

The framework has since spread. In October, Microsoft and CrowdStrike tied it to two China-linked state groups, Storm-0940 and VAPOR PANDA. On November 6, Microsoft reported a Cambodia-based crime group using ARTEX against financial organizations, mostly in Southeast Asia, plus a smaller number of large financial organizations globally. We went through the public reporting from CrowdStrike, ThreatBook, Microsoft and Korean regulators.

What happened

Between September 27 and 30, internet-facing business systems at five Korean lenders were attacked in succession. Shinhan reported to regulators on September 30, and the Financial Supervisory Service and Financial Security Institute opened on-site investigations the same day. By October 3, four commercial banks, two savings banks and a consumer-finance company had disclosed data loss (ThreatBook).

The stolen fields included names, resident registration numbers, income, loan limits and employers. That's enough for a scammer to pose convincingly as a loan officer, and the Financial Services Commission held an emergency meeting on October 2 and sent every institution a checklist for its customer-facing systems.

On October 7, CrowdStrike tied the campaign to ARTEX. The operator had left an open directory on a server holding the tool's configuration and their own AI session histories, including requests for help finding Telegram groups to sell Korean data (BleepingComputer). The developer took ARTEX closed-source the next day, but forks and translated versions are still circulating (Digital Watch).

How the agent got in

Most confirmed entry points were business apps built for brokers, field staff or partners, sitting outside core banking. Pieced together from the CrowdStrike and ThreatBook analyses, the chain looks like this:

Recon. ARTEX's recon modules crawl sites and parse their HTML and JavaScript to find the APIs behind them. The operator ran it against several banks at once.
Target selection. It settled on systems wired to customer and staff data: a broker loan-status API, employee mobile backends for relationship managers, a recruiter search page.
Access-control gap. On these systems, the server didn't properly check who was calling or whether they were allowed to see the record they asked for. A request carrying someone else's ID got that person's data back.
Enumeration. The agent cycled through business IDs, kept the ones that returned data, and used each hit to query related services for income and loan details.
IP rotation. Traffic came from 28 IPs across 12 countries. When Shinhan blocked sources, the agent moved to new ones and continued.

System	What was exposed	Scale
Broker loan-status API	Names, phone numbers, income, estimated loan limits	~25,700 customers
Server storing customer information	Names, dates of birth, contact details	~40,000 customers (preliminary)
Corporate-customer services	Online-banking IDs, company and contact details	2,370 records
Employee mobile apps for relationship and private bankers	Customer and staff contact details, some encrypted ID numbers	119 people
Field sales-support system	Resident registration numbers, contact details, employers	89 customers
Public loan-recruiter query page	Recruiter IDs and resident registration numbers	146 recruiters
Customer-facing web page	Outsourced developers' names, phone numbers, dates of birth	11 people

System:
Broker loan-status API

What was exposed:
Names, phone numbers, income, estimated loan limits

Scale:
~25,700 customers

System:
Server storing customer information

What was exposed:
Names, dates of birth, contact details

Scale:
~40,000 customers (preliminary)

System:
Corporate-customer services

What was exposed:
Online-banking IDs, company and contact details

Scale:
2,370 records

System:
Employee mobile apps for relationship and private bankers

What was exposed:
Customer and staff contact details, some encrypted ID numbers

Scale:
119 people

System:
Field sales-support system

What was exposed:
Resident registration numbers, contact details, employers

Scale:
89 customers

System:
Public loan-recruiter query page

What was exposed:
Recruiter IDs and resident registration numbers

Scale:
146 recruiters

System:
Customer-facing web page

What was exposed:
Outsourced developers' names, phone numbers, dates of birth

Scale:
11 people

None of the requests in step 4 carried anything malicious. Each one was a well-formed call to a real endpoint with a plausible ID.

Why the usual controls didn't stop it

The controls in place assumed an attacker who works at human pace and sends something a signature can catch. ARTEX, however, broke both these assumptions.

When Shinhan blocked the offending sources, the agent rotated to fresh exit nodes and kept querying. A control keyed on where traffic comes from struggles against an attacker that can rent new addresses on demand.

Generic WAF rules had nothing to match. As step 4 shows, the traffic was valid API calls, and a WAF looking for injection strings or known exploit payloads sees a normal request every time.

Broker portals, field-staff apps and recruiter lookups tend to be owned by a business unit and built for convenience. If the security team doesn't know an endpoint returns resident registration numbers, nobody tests whether it checks who's asking. An annual pentest scoped to the main banking apps rarely reaches them. ARTEX, itself a pentest tool, reached them in days.

The last gap is human speed response. An agent like ARTEX works around the clock and adapts as it goes, while most response processes still need a person to triage the alert, write a blocking rule and get approval before anything changes on a customer-facing service. By the time a fix is signed off, the agent has usually moved on with the data.

Where Miggo fits

The detail that stayed with us was the broker loan-status API. It was a small, convenient service that someone built to answer status questions, and it had a direct line to the customer database. ARTEX had to find it by probing. The bank's security team likely didn't know it existed either, so it came down to who found it first. Miggo makes sure that's the defender: it maps an endpoint like this from the first day it sees the service's traffic.

At the edge, the attack looked like valid calls from rotating IPs. Miggo's runtime map shows where each call lands: the entry point it hit and the customer data behind it.

The ARTEX campaigns so far have come in two ways: logic flaws, like the authorization gaps in Korea, and exploitable flaws in internet-facing systems. Miggo answers each one differently.

Find the side doors first. Miggo uses DeepTracing technology on live traffic to build a running map of every API endpoint, which ones are reachable from the internet, and which databases and services each one reads. A broker loan-status API that queries customer records shows up on that map whether or not anyone added it to the inventory. This answers the questions many security teams are now asking: where are our 'hidden' APIs, and what do they return?

Test them the way an agent would. A2S2, our agentic attack simulation system, works from the same runtime map. It starts with the endpoints that touch sensitive data and checks what an attacker could actually do with them in your environment, to prove actual exploitability.

Close exploitable flaws in minutes. The second crew to pick up ARTEX went after exploitable flaws. Microsoft reports Storm-3358 used it to exploit anonymous file upload and server-side request forgery (SSRF) on internet-facing systems, then installed remote access trojans (Microsoft). Flaws like these stay open from discovery until a patch ships, and that's the window autonomous mitigation closes. Miggo narrows the backlog to the vulnerabilities that are reachable and exploitable at runtime. Then, Miggo's mitigation loop generates a customized mitigation for each exploitable vulnerability and deploys it in log mode, to confirm it holds in your environment against potential bypasses and without blocking legitimate traffic. A protection that fails in log mode goes back to be rebuilt. Only a mitigation that is tested and holds is switched to blocking.

For logic flaws like the authorization gaps exploited by ARTEX, the permanent fix still belongs in the application code. Miggo shortens the path to it, from "we might have an exposed broker API somewhere" to the specific endpoint, the code path behind it and the data it hands out.

What to check this week

These are the five actions we recommend security teams take to protect against ARTEX:

List the side doors. Every internet-reachable app built for brokers, partners, field staff or recruiters, with an owner and the fields each endpoint returns.
Test object-level authorization with two accounts you control. Create two test users, A and B, on each of those apps. Sign in as A and capture the request that fetches A's own record. Resend it with B's customer, case or application ID while keeping A's session. If B's record comes back, the endpoint trusts the ID in the request instead of checking who is asking, which is the gap ARTEX used.
- Swap every identifier the endpoint accepts: path segments, query strings, JSON body fields and headers, including IDs that look opaque or encoded.
- Repeat with no session, an expired session, and a session from a different role, such as a broker requesting a staff-only record.
- Try neighboring IDs. If the next number up returns a real record, an agent can walk the whole table.
- Read the failures too. An error that confirms a record exists, or returns some of its fields, is enough to enumerate.
- Run this in staging, or in production only with your own test accounts and change approval. Never use real customer IDs.
Search the logs from September 27 onward. Check WAF, gateway and application logs for the indicators CrowdStrike, Microsoft and Korean regulators published, and for ARTEX recon user agents such as artex-enrich/1.0 and spa-api-recon. Treat these as hunting leads, not blocking rules: Microsoft notes that agents change them quickly.
Alert on records per session. Flag any session, token or endpoint that touches an unusual number of distinct customers, even when the requests are slow and spread across many IPs.
Time your response. Measure how long it takes today to go from "this endpoint is exposed" to a verified protection in production. The Korean attacker worked through five institutions in four days.

To learn more on how Miggo can help protect against autonomous attackers, contact here.

<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/gsap.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/Flip.min.js"></script>

<script>
  document.addEventListener("DOMContentLoaded", (event) => {
    gsap.registerPlugin(Flip);
    const state = Flip.getState("");
    const element = document.querySelector("");
    element.classList.toggle("");
    Flip.from(state, {
      duration: 0,
      ease: "none",
      absolute: true,
    });
  });
</script>

<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/gsap.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/Flip.min.js"></script>

<script>
  document.addEventListener("DOMContentLoaded", (event) => {
    gsap.registerPlugin(Flip);
    const state = Flip.getState("");
    const element = document.querySelector("");
    element.classList.toggle("");
    Flip.from(state, {
      duration: 0,
      ease: "none",
      absolute: true,
    });
  });
</script>