One Attacker, Multiple Banks, 25,000 Records, Open-Source AI

By Lazar Milicevic · Published October 9, 2026 · 9 min read

Attackers pick targets by cost and yield, not prestige, and the tooling behind the recent South Korean bank breaches just made that math cheaper. If you run a small business with a shared inbox, a billing system, and a handful of automations, you probably have more unlocked doors than you can name. This post covers what CrowdStrike actually reported, what it does and doesn't prove, and a one-hour audit you can run on your own stack today.

What CrowdStrike actually reported (and what it didn't)

CrowdStrike's report describes a campaign against South Korean financial organizations that ran from late September to early October 2026 and resulted in exfiltrated data. The actor used ARTEX, which CrowdStrike calls a recently released, open-source, agentic penetration-testing tool developed in China, alongside large language models.

The details that matter for the rest of this post:

• ARTEX is not an AI model. It's a framework that connects to external LLMs. Its GitHub page says it shouldn't be used for real-world testing against online systems. The model reasons; the framework executes.
• The models were mixed. ARTEX ran mainly on DeepSeek v4.1-flash. The actor added GLM-5.3 (Zhipu AI) and Grok 4.6 for additional Claude Code sessions.
• The attacker's own tradecraft was exposed. CrowdStrike found open directories on attacker-controlled infrastructure holding Claude Code session histories, ARTEX configuration files, and Claude memory files. Even attackers forget to lock their own doors.
• Attribution is soft. CrowdStrike has not tied this to a named adversary. It assesses with moderate confidence that the actor is a Chinese speaker and financially motivated, based on the Chinese-developed tool and Chinese-language prompts.

Now the part most headlines blur. CrowdStrike says the total number of affected organizations has not been confirmed. The Shinhan figure comes from the bank itself: according to The Korea Herald, Shinhan said about 25,000 customers' data was leaked, including names, phone numbers, annual income, and loan borrowing figures. The bank blocked external IP access and suspended affected services.

Other caveats worth keeping straight:

• "One person" is an inference. CrowdStrike says "a threat actor." A résumé-style prompt contains personal details that CrowdStrike says likely belong to the attacker but can't be definitively tied to anyone.
• Not every bank hit is confirmed as the same actor. The Korea Herald reports the same attacker IP address appeared across seven financial firms, but public reporting hasn't cleanly separated which incidents trace back to CrowdStrike's actor.
• "AI hacked the banks autonomously" isn't supported. The evidence shows AI-assisted tooling, with a human directing it.

I'm not going to quote a total record count across all banks. If you need current numbers, check the original reporting and the regulators' statements.

The shift is automation of boring work, not new exploits

The core finding is that AI tooling can let a financially motivated actor run multiple intrusions in a short time, and CrowdStrike expects adversaries to keep experimenting to raise their tempo. Per Reuters, CrowdStrike's Adam Meyers framed it as a human adversary using AI agents for widespread attacks, letting one human target many customers in a very short time.

Nothing here suggests the models invented new vulnerabilities. What got automated is the repetitive grind: probing, testing, chaining weaknesses, reading the output, deciding the next step. A human used to type each of those commands. Now a loop does.

The attacker also used the models for the business side. CrowdStrike says the actor asked Claude where threat actors typically sell Korean data breach information and for help finding Korean Telegram data-sales groups. That's not hacking. That's the same "ask the assistant" workflow you use to draft an email, applied to monetizing stolen data.

Here's the mental model I use with clients. A scanner-plus-LLM loop looks roughly like this:

while target_surface_not_exhausted:
    observations = run_tool(next_probe)      # framework executes
    plan = llm.reason(observations, goal)    # model reasons
    next_probe = plan.next_action            # no human in the loop per step

That's a deliberate simplification, not ARTEX's code. The point: the cost per probe drops toward the price of an API call, and the loop doesn't get tired. Whether the attacker's spend was low isn't something CrowdStrike reported, so I won't put a number on it. The direction is clear enough without one.

The doors that got opened were side doors

This is the detail I'd tell every small-business owner to sit with. According to reporting summarized by Martin Cid, the intrusions reportedly hit side-door portals (for employees, outsourced developers, and loan agents), not the mobile apps or internet banking that customers use. At Shinhan, the attacker got past identity checks on a loan-broker service. Startup Fortune describes the exposed data as coming from a platform for loan agents. South Korea's Financial Services Commission then ordered every financial firm to shut off non-essential outside access.

Translate that to a ten-person company:

Automated attackers go after the cheapest door, which is almost never a clever zero-day. It's the forgotten API key, the admin account without two-factor, the old integration nobody remembers wiring up, the exported spreadsheet sitting in a shared folder.

Third parties are a measurable part of this. Verizon's 2026 Data Breach Investigations Report executive summary says breaches with third-party involvement rose 60% from the prior dataset, reaching 48% of total breaches. The same summary lists 7,256 incidents (7,152 with confirmed data disclosure) for small and medium-sized businesses, and says small organizations are disproportionately hit by ransomware and often have fewer resources. You're not a bystander in this data set.

Detection speed is the other lesson. Reported times to detect the breach were 15 hours 26 minutes at Shinhan, 41 hours 44 minutes at Hana, and 67 hours 41 minutes at KB Kookmin, per Startup Fortune. Those are banks with security teams. A small business with no log review might measure detection in weeks.

Every automation you build is a door

Here's the second-order problem I see with clients, and I include myself. I build automations that touch client data every day: invoicing, inbox triage, Telegram bots on top of Gmail. Every one of them creates a connection: a token, a webhook, a service account. Automation is how you reclaim twenty hours a week, and I'm not telling you to stop. But each connection is a door, and most small teams have no inventory of their doors.

Here's a quick way to build that inventory. If you run any scripts or self-hosted tools, start by finding secrets that ended up where they shouldn't be:

# Find likely secrets sitting in plaintext files in a project directory
grep -rIn --exclude-dir=.git --exclude-dir=node_modules \
  -E "(api[_-]?key|secret|token|password)\s*[:=]\s*['\"]?[A-Za-z0-9_\-]{16,}" .

# Find .env files that may be committed or world-readable
find . -name ".env*" -not -path "./node_modules/*" -exec ls -l {} \;

# Check whether git history ever contained a .env
git log --all --oneline -- .env .env.local

That catches the obvious cases. It won't find a key pasted into a chat message or a spreadsheet, which is exactly where small teams actually keep them. For those, you have to look manually.

The one-hour audit

Here's the concrete thing, in under an hour. Make a list of every system your automations touch: email, CRM, accounting, chat, storage. For each one, write down three things:

1. What credential does the automation use?
2. What can that credential access?
3. Could it be limited to less?

A simple table is enough. Mine looks like this:

- system: accounting
  credential: api_key (created 2025-03, owner: shared admin)
  access: read/write everything
  target: dedicated key, invoices read-only
- system: gmail
  credential: oauth token for ops bot
  access: full mailbox
  target: restrict to specific labels/scopes
- system: cloud_drive
  credential: service account
  access: all folders
  target: one folder, view-only

Then fix the worst offenders:

• Replace any shared admin login with a dedicated service account per automation.
• Turn on two-factor everywhere that supports it.
• Scope API keys to the minimum permissions, so the invoicing automation can read invoices and nothing else.
• Rotate any key older than a year.
• Store secrets in a password manager or environment variables, never in a spreadsheet or a chat message.
• Revoke stale third-party access: freelancers, old vendors, integrations you no longer use. This is your version of the Korean regulator's order to shut off non-essential outside access.

Last step: check your logs. Most platforms can show you recent logins and API activity. If you see a login from a country you've never worked in, or a token being used at 3 a.m., you've found a problem before it found you.

That hour won't make you bulletproof. It moves you out of the cheapest-target pool, and against automated attackers, that's most of the game.

Why bizflowai.io helps with this

I build AI automations for solopreneurs and small teams at bizflowai.io. If you want a second opinion on how your automations handle credentials and permissions, or help working through the audit above, get in touch. I can't promise you immunity, and nobody honest can.

The defender's side of the same story

The headline everyone will run is "AI makes hackers scary." I think that's the wrong lesson. ARTEX is an open-source agentic penetration-testing tool, and tools of that kind can by nature also be used to test your own systems. The gap isn't capability, it's attention. Attackers use these tools every day, and most small businesses have never run a single security test on their own setup.

Caveat on that point: ARTEX's own page warns against using it on real online systems, so don't point an agentic pentest framework at production infrastructure you don't fully control. Start with the free, boring checks: review your accounts, your permissions, and your logs. If you later want automated testing, do it against a staging copy or hire someone who does this professionally.

One more honest limitation: this is a story still being investigated. Attribution is moderate-confidence, the full scope across banks isn't confirmed, and details may change as regulators and CrowdStrike publish more. What won't change is the economics. If one actor with a free framework and commodity models can credibly go after financial institutions, assume someone can point the same tooling at you. The fix is boring, cheap, and available right now: shrink your permissions, lock your doors, and know what you've connected.

Sources used: CrowdStrike's report, The Korea Herald on Shinhan, The Korea Herald on the wider wave, Reuters via Claims Journal, and Verizon's 2026 DBIR executive summary.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.