SearchSubscribe

P.K. SHARMA

Cyber security intelligence, AI governance, practitioner analysis

Threat Intel

CrowdStrike's ARTEX report: AI use rests on the actor's own files, the bank breaches on one press footnote

CrowdStrike says an actor's own files show ARTEX, an open-source agentic pentesting tool, running on three model backends against South Korean finance. Its post names no bank and counts no victim, and the claim that AI made the intrusions work is not tested.

By Parminder Kumar Sharma · · 26 min read

A dark room with a graphite laptop on a walnut desk at the right. Its screen shows a map of connected empty circles, three filled cyan and one amber, with a column of empty pills at the left and three empty cards at the right. A tablet on a stand beside it shows a pale card with one empty field and a cyan button, and a phone in front shows three empty rows. The left of the picture is empty dark, with the headline and a stat drawn over it: 1 footnote.

CrowdStrike's evidence for the AI is the actor's own files; its evidence for the banks is one footnote

CrowdStrike Intelligence published its report on an unknown actor, the open-source agentic tool ARTEX and South Korean finance on 7 October 2026. The post is about 830 words (our count, tables included). It has one footnote, to the English edition of a Korean newspaper's article of 4 October. Its Details section, the only place it describes the victims, has six sentences. Five rest on "industry reports" or reporting, and four of those carry a hedge word ("according to industry reports", "reportedly", "purportedly", "reporting also suggested"); the fifth, on an employee mobile work-support system, has no hedge of its own. The sixth is CrowdStrike's caveat that the number of organisations affected "remains unconfirmed". The post names no bank, counts no people, and dates the campaign only as "late September to early October 2026". Its first sentence says the campaign "resulted in exfiltrated data", and the only basis it states for that is the industry reports.

What CrowdStrike says it saw for itself is a different kind of evidence. Open directories on servers it says the actor controlled held Claude Code session histories, ARTEX configuration files and Claude memory files, and the files show an ARTEX instance using three model backends. That half is first-hand, and only CrowdStrike can check it: the post reproduces no session text apart from one block of personal details, which this briefing does not repeat. The two halves have very different standing, and press coverage ran them together.

Our earlier briefing on the Korean breaches found AI use unconfirmed on the record. CrowdStrike moves the tool question from a page title to the actor's own files, if its description is right. It leaves the questions that matter to a defender where they were. Here is what the post does not establish:

  • That AI made the intrusions succeed. The post says the activity "demonstrates how AI tooling can enable" multiple intrusions in a short time span. It gives no count, timeline, comparison with human methods or root cause.
  • That an Anthropic model was used, or that any safeguard was bypassed or worked. The post says Claude Code sessions, and that the actor "asked Claude" two things about selling Korean breach data. It names no Anthropic model and does not say what any model answered or refused.
  • That ARTEX was the way in. The ARTEX instance is "likely responsible for the described Korean attacks". The link to any bank rests on addresses and a page string that the press reported.
  • A state, a country or a named group. The actor is "not attributed to a named adversary", and "likely a Chinese speaker", with moderate confidence.
  • A victim count. The number of organisations affected "remains unconfirmed".

What the post states, and what it does not

Table 1 sets each claim in the post against what its text supports. The reading is ours, and counts marked derived are ours.

Table 1. Claims in the CrowdStrike post of 7 October 2026, against what its text states. Quotes are from the post.

  1. Claim
    AI tooling was used
    Stated in the post
    Open directories on actor-controlled servers held Claude Code session histories, ARTEX configuration files and Claude memory files. The ARTEX instance used DeepSeek v4.1-flash as primary backend, with GLM-5.3 and Grok 4.6 for additional Claude Code sessions
    Not stated
    How many sessions or files. Their dates. What any session produced. Any excerpt. Whether these are all of the actor's files
  2. Claim
    AI made the intrusions succeed
    Stated in the post
    The activity "demonstrates how AI tooling can enable" multiple intrusions in a short time span
    Not stated
    A count of intrusions. Which step AI performed. A comparison with non-AI methods. A root cause for any breach
  3. Claim
    Claude and vendor safeguards
    Stated in the post
    Sessions called Claude Code. The actor "asked Claude" where Korean breach data is sold and for help finding sales groups
    Not stated
    Which model answered. Whether any request was refused. Any statement from Anthropic or the other vendors. Any safeguard bypassed
  4. Claim
    ARTEX
    Stated in the post
    A "recently released open-source agentic penetration testing tool developed in China". An instance "likely responsible for the described Korean attacks"
    Not stated
    Its version. What it did at any bank. Which services it touched
  5. Claim
    Who
    Stated in the post
    Not attributed to a named adversary. Likely a Chinese speaker, financially motivated, moderate confidence, from the tool and Chinese-language prompts. Details in one prompt "likely belong" to the actor
    Not stated
    A country, state or group. The post itself says available information "cannot definitively associate" the details with the actor
  6. Claim
    Victims
    Stated in the post
    Per industry reports: several South Korean financial organisations breached from late September; a broker-facing loan progress inquiry service at one bank; an employee mobile work-support system at another; the number unconfirmed
    Not stated
    Any bank's name. Any count of people. Which data. The date of any intrusion. How entry was gained. Whether data is seen leaving in the actor's files
  7. Claim
    Indicators
    Stated in the post
    Ten IP addresses, nine described as proxies and one as actor-controlled (derived count). Three ATT&CK techniques
    Not stated
    File hashes. Any domain in the table: the text names a likely model reseller that the table omits. A second actor server: the text describes two, the table lists one

Where the chain from the actor's files to the banks is CrowdStrike's own, and where it is the press

The post's logic runs in four steps. The first three are CrowdStrike's own statements. The join to the banks rests on two things the press reported, overlapping addresses and a page string, and the post names no bank at the join.

A tall single-column diagram in five cards. Cards 1 to 3, drawn solid, are CrowdStrike's own statements: open directories with Claude Code session histories, ARTEX configuration files and memory files; an ARTEX instance with three model backends; and an assessment that the instance is likely responsible for the Korean attacks. Card 4, dashed, is the press-reported join: overlapping addresses, a page string, two named services. Card 5 lists what is not stated.
Drawn by us from the CrowdStrike post of 7 October 2026 and its one footnote, the Kyunghyang Shinmun English edition of 4 October 2026.

The join is the weak point, and the post is open about its basis. CrowdStrike says activity at multiple organisations "purportedly" involved overlapping IP addresses, and that reporting "suggested" the attacker used ARTEX from a string in a page on a server. Those are the two press-reported links. CrowdStrike's own addition is one sentence: the targeted organisations in the actor's files "overlap with those identified in industry reporting". If that is right, it is the strongest sentence in the post, because it ties the actor's records to the victims by something other than addresses (our reading). It is also the sentence a reader can least check. It names no organisation, count or date.

The press half: seven or nine firms, 67,599 in mixed units, and counts that moved

The numbers in circulation come from Korean reporting, not from CrowdStrike. The post's footnote is the English edition of the Kyunghyang Shinmun, published at 23:20 Korean time on 4 October and updated on 6 October. That page says an AI tool translated it. We read the English, not the Korean original. The Straits Times of 5 October, which carries a Korea Herald report, adds per-firm counts. Table 2 sets them against the post.

Table 2. What Korean reporting says, against what CrowdStrike says. Sources: Kyunghyang Shinmun English edition (4 October, updated 6 October); Straits Times (5 October, with the Korea Herald); the CrowdStrike post.

  1. Point
    Window
    Press reports
    Kyunghyang Shinmun: information leaked between 27 and 30 September, four days counting both ends (derived). Straits Times: the breaches first came to light on 30 September
    CrowdStrike
    "Late September to early October 2026". No day counts
  2. Point
    Firms
    Press reports
    Straits Times: seven firms with exposed data and two more that detected and blocked attempts, so nine touched (derived). Kyunghyang Shinmun: nine firms with leaks, counting two online lenders
    CrowdStrike
    "Several" organisations. The number "remains unconfirmed"
  3. Point
    People
    Press reports
    Straits Times: about 25,000 at Shinhan Bank and about 40,000 at Yegaram Savings Bank, the two largest, and five other firms from 11 to 2,200. The figures add to 67,599 in mixed units (derived)
    CrowdStrike
    No count
  4. Point
    Counts that moved
    Press reports
    One large bank is 119 in the Kyunghyang Shinmun and 153 individuals in the Straits Times. The largest bank is 25,727 "items of personal information" in one and "about 25,000 people" in the other
    CrowdStrike
    None
  5. Point
    Entry
    Press reports
    Kyunghyang Shinmun: a loan-progress inquiry service used by loan brokers at one bank and an internal mobile work-support system at another, "relatively less secure internal systems". The method is "presumed": automated guessing against the broker service
    CrowdStrike
    The same two services, "reportedly". No method
  6. Point
    Addresses
    Press reports
    Straits Times: one attacker address across all seven firms. Kyunghyang Shinmun, quoting the head of the Financial Security Institute: almost the same for the banks and a bit different for the savings banks. It adds that addresses from eight countries were reportedly used
    CrowdStrike
    "Overlapping IP addresses", "purportedly". Nine proxy addresses in its table
  7. Point
    AI
    Press reports
    Chair of the Financial Services Commission, via the Straits Times: "We cannot rule out the possibility of attacks using AI"
    CrowdStrike
    The actor's own files show AI tooling

Two firms hold 65,000 of the 67,599, or 96.2 per cent (derived). The other five hold 2,599 between them, or 3.8 per cent. The units differ by firm (people, individuals, cases, outsourced workers), several figures are "about", and nothing de-duplicates anyone who is a customer of two firms, so the total is neither a count of people nor a count of records. Our earlier briefing, which read the banks' own notices in Korean, got 66,094 from slightly different figures with one firm's 2,200 left out. Treat any total as a rough size, not a count.

A spread from 11 to about 40,000 across firms hit within four days says something about the systems that answered, not about the attacker (our inference, as in our earlier briefing). CrowdStrike's phrase "multiple intrusions within a short time span" is the only link in the post from that spread to AI, and it offers no test. The Korean regulator's own English release of 6 October names no bank, gives no count and does not mention AI. It issues a consumer alert at its first level, "Caution", opens a one-month special response period, and says no phishing loss from the leaked data had been confirmed.

The backends: three models from three vendors, none of them Anthropic's

The post names three model backends and a coding harness. Table 3 sets what CrowdStrike says beside what each vendor's own page says, and how new each part was on 27 September, the day the Kyunghyang Shinmun says the attack on one bank began. The ages are derived from release dates on the vendors' pages and the newspaper's account of ARTEX's GitHub history. None of them is in the CrowdStrike post.

Table 3. The stack CrowdStrike names, against vendor and project pages read on 8 October 2026. Ages are days before 27 September 2026 (derived).

  1. Part
    ARTEX
    What CrowdStrike says
    An open-source agentic pentesting tool developed in China. An instance "likely responsible" for the Korean attacks
    Vendor or project page, and age
    First release 26 July, latest version 24 September, per the Kyunghyang Shinmun from GitHub records: 63 days and 3 days
  2. Part
    DeepSeek v4.1-flash
    What CrowdStrike says
    Primary backend of the ARTEX instance, likely reached through a reseller
    Vendor or project page, and age
    DeepSeek's release note, dated 10 September 2026: 17 days
  3. Part
    GLM-5.3
    What CrowdStrike says
    A supplement "for additional Claude Code sessions"
    Vendor or project page, and age
    Z.ai developer release notes, 18 August 2026: 40 days. The note advertises "emergent cybersecurity capabilities", a vendor claim we have not tested
  4. Part
    Grok 4.6
    What CrowdStrike says
    The same
    Vendor or project page, and age
    xAI newsroom, 14 August 2026: 44 days. Grok 4.7 followed on 21 September
  5. Part
    Claude Code
    What CrowdStrike says
    Session histories and memory files. The actor "asked Claude"
    Vendor or project page, and age
    Anthropic documentation: it "doesn't support routing Claude Code to non-Claude models through any gateway"

Every part of the stack was between 3 and 63 days old on 27 September (derived). A defence that depends on knowing the attacker's tool is stale within weeks. What stays put is the behaviour at your front door.

What "Claude" means here is the open question. CrowdStrike writes that the ARTEX instance used DeepSeek as primary backend "and the threat actor supplemented this LLM with GLM-5.3 (Zhipu AI) and Grok 4.6 for additional Claude Code sessions". Read plainly, the extra sessions ran in Claude Code with GLM and Grok behind them. Anthropic's documentation says it does not support that arrangement. That is a statement about support, not a claim that it cannot be done. Our reading is that where a session used one of those backends, no Anthropic model-side safeguard was in the path. For the sessions where the actor "asked Claude" questions, the post does not say which model answered, so those sessions show neither a safeguard bypassed nor a safeguard working. Infosecurity Magazine wrote that the attacker used ARTEX "alongside Anthropic's Claude AI model". The post does not say that.

Anthropic's own account of its safeguards is a separate claim on a separate page. On 6 October Anthropic wrote that its generally available models "have conservative cyber safeguards that block most cyber work", and reported that in its test of Claude Opus 5.5 without Cyber Verification Program access every task was blocked on the first prompt. We covered that test. It is a vendor's own result on a benchmark, and it says nothing about what happened in these sessions.

CrowdStrike's 6 October lab post is a different piece of work. The day before, CrowdStrike's Cyber Superintelligence Lab published "Request, Aggregate, Bypass: How Attackers Can Evade LLM Safety Classifiers". It tests a classifier that it says guards models such as Claude Opus 5.5 and Fable 5, and reports a 0 per cent direct bypass rate across about 515 techniques but a route round it, by splitting a task into harmless-looking pieces, in 9 of 10 categories. The ARTEX post does not cite it and does not say the actor split any task, and the lab post does not mention ARTEX or Korea (we searched its text). Two CrowdStrike teams published a day apart, and these are not one finding.

What the vendors said. Between about 14:20 and 14:30 BST we read the newsrooms of Anthropic, DeepSeek and xAI (its page is branded SpaceXAI), and the developer release notes of Z.ai, whose blog address returned not found. None had an item on ARTEX, South Korea or this report. DeepSeek's latest note is dated 10 September. A web search for a statement tying any of them to ARTEX found none. An absence on a page is not a statement, and we do not know whether any vendor has been asked.

ARTEX's own page forbids what was done, and the tool is already copied

ARTEX is open source, and its project page says what it is for. We read an Internet Archive capture of that page taken at 14:25 UTC on 7 October, because the live page is no longer reachable (below). Its description, in Chinese, calls it an "AI autonomous penetration-testing system" and the champion project of a Baidu "agent+" attack-and-defence challenge, a claim we have not checked. The capture shows about 1.9 thousand stars and 466 forks under the AGPL-3.0 licence. Our earlier briefing recorded about 1,500 stars and 320 forks on 5 October, so forks grew by 146, or 46 per cent, in about two days (derived). The README describes a planner and several parallel worker agents on a Go back end, with a human-in-the-loop chat and an approval gate for tools, and it lets the user choose the model provider. That last point is how backends from three vendors can sit behind one tool (our reading). We read the Chinese text ourselves, and the translations here are ours. Nothing was downloaded or run, no repository is linked here, and nothing about operating it is repeated.

The README's licence-and-disclaimer section is the part to read. It says the tool is only for personal study, code research and local technical verification, and must not be used to run real tests against any online system or website. It forbids scanning, probing, exploiting or attacking any website, online service or networked system, whether or not authorised (our translation), any real penetration test and any production use, and illegal intrusion or data theft. It adds that the open-source licence does not itself restrict use. So the "pentesting" label is the author's description and the disclaimer is the author's request. Neither is a control on the user. If an ARTEX instance was run against a bank, as CrowdStrike says one likely was, that use was against the README's own terms, and the terms could not have stopped it. The post's headline calls ARTEX "AI-driven", which describes the tool, not any intrusion.

Where the tool is now. At about 14:30 BST on 8 October the project's address returned "not found" on GitHub's site and its API, and the owner's public repository list in a browser showed no ARTEX repository. We cannot say who removed it or why. One public copy's description says the upstream was deleted; we did not verify that. At about 14:40 BST a GitHub search found 23 public repositories, created between 2 and 8 October, whose descriptions identify them as copies, mirrors or Korean or English builds of ARTEX. Fifteen of them were created on 8 October (our count from the search). Removing a repository does not recall an open-source tool, and those copies will change by the hour.

Wording that moved between the post and the coverage, and a language call that is not attribution

Table 4. Coverage wording against the CrowdStrike post. Infosecurity Magazine published on 8 October 2026.

  1. In the coverage
    Headline: "Chinese Hacker Deployed AI in Campaign Against South Korean Banks"
    In the CrowdStrike post
    "Likely a Chinese speaker and financially motivated", moderate confidence. "Not attributed to a named adversary"
    Our reading
    A language call became a nationality. The article text says "suspected China-based", which the post does not say either
  2. In the coverage
    "alongside Anthropic's Claude AI model"
    In the CrowdStrike post
    Claude Code sessions. No model named. Two other vendors' models paired with the Claude Code sessions
    Our reading
    Over-reads the post
  3. In the coverage
    "primarily used ARTEX to discover vulnerabilities and compromise specific services"
    In the CrowdStrike post
    No sentence says this about the banks. The post gives no method for any intrusion. Its one mention of vulnerability research concerns a different, non-bank target
    Our reading
    Not in the primary source
  4. In the coverage
    "link all the attacks to the same IP address"
    In the CrowdStrike post
    Activity at multiple organisations "purportedly involved overlapping IP addresses"
    Our reading
    Weaker in the post. The institute head said addresses differed at the savings banks
  5. In the coverage
    Breaches "affecting 25,000 and 40,000 people", citing the Straits Times
    In the CrowdStrike post
    No count
    Our reading
    Correctly credited to the Straits Times. The post does not support it

CrowdStrike's language call is a moderate-confidence judgement from two things: a tool developed in China and Chinese-language prompts. Both describe what the actor used, not who or where the actor is. The Kyunghyang Shinmun writes that use of a China-developed tool does not by itself determine the attacker's nationality. It quotes the institute head saying ARTEX is open source and available worldwide, and that addresses alone cannot identify an attacker. The tool-choice leg also weakens by the week: the first public English or Korean build of ARTEX that we found was created on 2 October, and more followed (our inference). The prompt leg stands as CrowdStrike states it.

The post also prints personal details taken from one prompt. It says they "likely belong" to the actor, and that currently available information "cannot definitively associate these details with the threat actor". Infosecurity Magazine repeats some of them. This briefing prints none. A single prompt typed by someone is not an attribution, the post says as much, and a name is not ours to print.

We have tested vendor AI claims twice already today. Talos's "AI-assisted" lures rest on three emails and a hedge. Talos's malware that talks to AI triage steered models by Talos's own bar in one of four tricks. Here the AI claim is better supported than either, by the actor's own files if CrowdStrike describes them correctly. It is the effect claim, that AI made the intrusions succeed, that has no evidence in the post. CrowdStrike sells security products, and publishing a threat report is normal vendor work. That is no reason to doubt what it says it saw. It is a reason to want to see the files.

The entry points were ordinary, and the AI label does not change the fix

Both services the press names are the kind a defender can list: a broker-facing loan progress inquiry service and an employee mobile work-support system. The Kyunghyang Shinmun reports that the attackers targeted "relatively less secure internal systems rather than customer internet and mobile banking". It quotes a security company's chief executive saying the main systems held because they have authentication beyond IDs and passwords, and the peripheral ones did not. Its account of the method is a presumption: automated guessing of values in the broker service to find valid customer numbers, then collection of the other data. The Straits Times says the attacker went round tightly secured core systems to non-core ones such as sales-support platforms, and that two other firms detected attempts and blocked them. CrowdStrike says none of this. It relays the two services and says nothing about method.

Our earlier briefing read the banks' own notices in Korean and the regulators' releases. The faults the authorities described were missing identity checks on lookups, neglected staff apps and unpatched website flaws, and press accounts say multi-factor sign-in separated the banks that were hit from those that were not. Nothing in the CrowdStrike post contradicts that. What AI tooling changes, if the post is right, is the cost of trying every neglected corner, not what is in the corners (our inference; the post offers no evidence on cost).

The downstream risk is the data. The Straits Times says the exposed data at one bank included names, phone numbers, annual income and calculated borrowing limits. The Kyunghyang Shinmun says the authorities fear it will feed loan scams that look like a real loan consultation. The Korean regulator's English release of 6 October tells firms to run help desks, tighten fraud monitoring on loan applications, new accounts and large transfers that use leaked data, and share scam information quickly.

UK reading: broker portals and staff apps are the front doors, and Cyber Essentials leaves bespoke ones out of scope

No UK organisation is named in the post or in the coverage we read. What follows is how a UK financial-services organisation, or a supplier to one, can read it. Every UK page below was read on 8 October. Broker and intermediary portals, staff mobile and work-support apps, and sales-support views are the UK equivalents of the two systems named. The Korean regulator told firms to block external access to systems unless essential (Straits Times). Table 5 sets the UK texts against this story.

Table 5. UK texts read on 8 October 2026, against this story.

  1. Source and date
    Five Eyes statement on the NCSC site, 22 June 2026
    What it says
    First practical action: reduce attack surface. "Challenge whether systems need to be exposed at all and isolate those that do not"
    What it leaves open here
    Names no system type. Nothing on broker or staff apps
  2. Source and date
    FCA, Bank of England and HM Treasury statement, 15 May 2026
    What it says
    Use access management, network security and data protection to shrink the attack surface a frontier model might reach. Not new expectations
    What it leaves open here
    It concerns frontier models. Whether the three backends here are frontier is not stated
  3. Source and date
    NCSC post on frontier AI, 30 March 2026
    What it says
    Activity from models released before March 2026 "tends to generate noticeable security alerts" where monitoring exists. AI favours "soft" targets. Basics: asset inventory, access control, configuration, logging
    What it leaves open here
    A test of frontier models, not of ARTEX. No data on how noisy the Korean activity was
  4. Source and date
    Cyber Essentials v3.3, April 2026
    What it says
    Firewall aim: "only secure and necessary network services can be accessed from the internet". Unauthenticated inbound connections blocked by default
    What it leaves open here
    Bespoke and custom web application components are out of scope, so an in-house broker portal is not tested
  5. Source and date
    NCSC assessment of AI and cyber threat to 2027, 7 May 2025
    What it says
    Most groups will repurpose commercial and open-source AI models. Fully automated end-to-end advanced attacks unlikely to 2027; skilled actors stay in the loop
    What it leaves open here
    17 months old and about advanced attacks. One case here does not confirm the trend
  6. Source and date
    FCA PS26/2 and PRA PS7/26, 18 March 2026; in force 18 March 2027
    What it says
    One incident definition, covering the confidentiality of end-user data. Initial report as soon as practicable and at the very most within 24 hours of meeting a threshold
    What it leaves open here
    We did not assess the thresholds. Not in force until 2027

The certificate gap. Cyber Essentials v3.3 says publicly available commercial web applications are in scope by default, and bespoke and custom components of web applications are out of scope. A broker portal built in-house is bespoke. On our reading of that clause, a firm can hold the certificate and have a broker portal nobody has tested. The scheme's own advice for applications is robust development and testing, with a pointer to the Software Security Code of Practice. The certificate is a baseline, not a test of this door.

What the NCSC's agentic and prompt-injection posts do and do not cover. The NCSC's 20 August 2026 post on managing the cyber risk of agentic AI and its 8 December 2025 post on prompt injection are written for people who deploy agents and LLM applications. Neither covers an adversary running its own agent against your services, and the CrowdStrike post describes no prompt injection. Two ideas from the August post still apply: safeguards built into models "should not be treated as holistic", and agent activity should be logged and monitored as user activity. Its advice to make your own agent traffic easy to attribute suggests a reverse: ask brokers and suppliers to label the automation they run against your services, so that unlabelled machine traffic stands out (our inference, not NCSC advice). The 21 September 2026 post adds the organisational point: attackers are limited by technical hurdles and defenders by policy, and organisations "also need to be focussing on improving their security the traditional way".

Reporting and resilience. Both new regimes define an operational incident as a single event, or linked events, that disrupts service to an end user outside the firm or affects the availability, authenticity, integrity or confidentiality of that user's information or data. Near misses need not be reported, and payment service providers keep a 4-hour rule. The operational resilience rules in force since 31 March 2022 required in-scope firms to operate their important business services within impact tolerances by 31 March 2025 (FCA page). Whether a broker portal is an important business service is the firm's decision to document. Data protection duties are outside this briefing: we did not read the ICO's pages, and we make no claim about them.

What to do, in the order worth doing

Our earlier briefing has a longer exposure checklist, and it still applies. This list adds what the CrowdStrike post changes. The order is our judgement. No UK regulator has issued it, and none of it describes how to attack anything.

Take this with you

In the order worth doing

  • List the front doors outside your core platform: broker and intermediary portals, staff mobile and work-support apps, sales-support and reporting views, and anything a supplier hosts for you. For each, write down who needs it from outside, and whether a caller who supplies only an identifier gets anything back.
  • Put per-record authentication on every lookup, and sign-in beyond a password on every staff and broker path. The press reports that the firms that held had authentication beyond IDs and passwords or blocked repeated attempts. Do not treat a customer number or a loan reference as a secret.
  • Load the ten addresses in the CrowdStrike post into blocklists and search your logs back to late September, but expect them to be stale: nine are described as proxies. Take them from CrowdStrike, not from this briefing, which prints none.
  • Detect behaviour, not addresses. The post lists nine proxy addresses and the Kyunghyang Shinmun reports addresses from eight countries, so address blocks will lag. Alert on many similar requests to one service from many sources, on per-identifier and per-account volume, on the same pattern hitting several of your services in the same hours, and on sessions that adapt after failures.
  • Log reads of sensitive datastores at field level: contact details, income and borrowing-limit data. Alert on bulk reads by one session or one broker account, and measure the time from the first anomalous request to a human decision. Our earlier briefing recorded reported gaps of about 15, 42 and 68 hours between first contact and the bank knowing, from press accounts of bank reports.
  • Ask brokers, introducers and suppliers to label any automation they run against your services, and to tell you who holds access. Unlabelled machine traffic at volume is then easier to separate.
  • Treat the model vendor as outside your control. The post names three vendors and the NCSC says safeguards built into models should not be treated as holistic. Your control point is your own service, not any vendor refusal.
  • Rehearse the reporting clock before 18 March 2027. Run one exercise in which a broker portal leaks applicant data: who decides it is an operational incident, who files, and whether the first report can go within 24 hours of that decision.
  • Prepare the follow-on. Ask your fraud team what a lender's applicant data would be worth to a scammer, what loan-consultation fraud would look like to them, and what warning you would send customers. The Korean regulator moved to this in its first week.

What could not be verified

The question that exposes the gap

CrowdStrike can show, if its description is right, which tool and which models an actor used. It cannot show, and does not claim to show, that any bank fell because of them. So set the AI aside and ask what the Korean regulators asked: which of your services outside the core platform will still answer a caller who offers nothing more than an identifier, and what would tell you within a day that a machine had been asking it all night?

Key facts

Sources

  1. PrimaryThe primary post, "Unknown Threat Actor Uses AI-Driven ARTEX to Target South Korean Finance", 7 October 2026 (page metadata last modified 16:11 UTC). Read in full from about 14:15 BST on 8 October, first with a browser User-Agent and then in a browser tab with matching text. It has no figures and no inline links. No address, domain, username, prompt content or personal detail is reproduced in the articleCrowdStrikeaccessed 2026-10-08
  2. Primary"Request, Aggregate, Bypass: How Attackers Can Evade LLM Safety Classifiers", 6 October 2026, from CrowdStrike's Cyber Superintelligence Lab. Read in full to establish what it tests (a content-safety classifier said to guard models such as Claude Opus 5.5 and Fable 5), its headline figures (about 515 techniques, 0 per cent direct bypass, 9 of 10 categories) and that it does not mention ARTEX or KoreaCrowdStrikeaccessed 2026-10-08
  3. PrimaryEnglish press release of 6 October 2026, "FSC-FSS Issue Consumer Alert over Potential Phishing Scams Following Data Breaches in Financial Sector": Level I (Caution) alert, one-month special response period, help desks, fraud monitoring, information sharing, and the statement that no phishing loss from the leaked data had been confirmed. It names no bank, gives no count and does not mention AIFinancial Services Commission (Korea)accessed 2026-10-08
  4. PrimaryDeepSeek-V4.1-Flash release note (listed as 2026/09/10 on DeepSeek's news index, read on 8 October). Used for the release date of the primary backend CrowdStrike names. DeepSeek's news index has no later item and no statement on ARTEX or South KoreaDeepSeekaccessed 2026-10-08
  5. PrimaryRelease notes: GLM-5.3 entry dated 2026-08-18, including its "Emergent Cybersecurity Capabilities" line (a vendor claim, not tested here). The blog address z.ai/blog returned not found. No statement on ARTEX or South KoreaZ.ai developer documentationaccessed 2026-10-08
  6. PrimaryNewsroom read on 8 October 2026: "Introducing Grok 4.6" dated 14 August 2026 and "Introducing Grok 4.7" dated 21 September 2026. No item on ARTEX or South KoreaxAI (page branded SpaceXAI)accessed 2026-10-08
  7. PrimaryNewsroom read on 8 October 2026 for any statement on ARTEX, South Korea or the CrowdStrike post: items from 27 August to 7 October were listed and none concerned themAnthropicaccessed 2026-10-08
  8. Primary"Expanding the Cyber Verification Program", 6 October 2026: generally available models "have conservative cyber safeguards that block most cyber work", and the CyScenarioBench result that without CVP access every task was blocked on the first prompt. A vendor's own accountAnthropicaccessed 2026-10-08
  9. Primary"Other LLM gateways": Anthropic does not endorse or audit third-party gateways and "doesn't support routing Claude Code to non-Claude models through any gateway". Read on 8 October 2026Anthropic (Claude Code documentation)accessed 2026-10-08
  10. PrimaryNCSC assessment, "Impact of AI on cyber threat from now to 2027", published 7 May 2025: repurposing of commercial and open-source AI models, skilled actors staying in the loop, proliferation of AI-enabled toolsNCSCaccessed 2026-10-08
  11. PrimaryBlog post, 30 March 2026: model safeguards can often be bypassed; activity from frontier models released before March 2026 tends to generate noticeable alerts where monitoring exists; AI favours soft targets; the basics (asset inventory, access control, configuration, logging)NCSC and AI Security Instituteaccessed 2026-10-08
  12. PrimaryStatement of 22 June 2026: reduce your attack surface first, "challenge whether systems need to be exposed at all", then patching, legacy, identity and incident preparationNCSC (Five Eyes statement)accessed 2026-10-08
  13. PrimaryBlog post, 20 August 2026, written for people who deploy agentic AI: built-in safeguards "should not be treated as holistic", agent activity as user activity in monitoring, making agent traffic attributable. Read in full; it does not cover an adversary running its own agentNCSCaccessed 2026-10-08
  14. PrimaryBlog post, 8 December 2025, on prompt injection in LLM applications. Read in full and not relied on here: the CrowdStrike post describes no prompt injectionNCSCaccessed 2026-10-08
  15. PrimaryBlog post, 21 September 2026: attackers are limited by technical hurdles and defenders by organisational policy; the line that organisations also need to improve their security "the traditional way"NCSCaccessed 2026-10-08
  16. PrimaryCyber Essentials: Requirements for IT Infrastructure v3.3, April 2026, 26 pages, read as text with pypdf: the firewall theme aim and requirements, and the scope clause that bespoke and custom components of web applications are out of scopeNCSCaccessed 2026-10-08
  17. PrimaryJoint statement on frontier AI models and cyber resilience, 15 May 2026: protection through access management, network security and data protection; stated not to introduce new expectationsFCA, Bank of England and HM Treasuryaccessed 2026-10-08
  18. PrimaryPS26/2, Operational incident and third party reporting, 18 March 2026: the regime applies from 18 March 2027. The PDF (fca.org.uk/publication/policy/ps26-2.pdf) was also read for the shared incident definition, the exclusion of near misses and the 24-hour and 4-hour timingsFCAaccessed 2026-10-08
  19. PrimaryPS7/26, Operational resilience: Operational incident and third-party reporting, 18 March 2026: implementation date 18 March 2027 and the same operational incident definitionPrudential Regulation Authority (Bank of England)accessed 2026-10-08
  20. PrimaryOperational resilience page, last updated 15 September 2026: rules in force 31 March 2022, firms had until 31 March 2025 to operate within impact tolerances, and the new reporting requirements from 18 March 2027FCAaccessed 2026-10-08
  21. Reported byThe article the CrowdStrike post cites as its only footnote, published 4 October 2026 at 23:20 KST and updated 6 October. Read in English; the page says it was translated by an AI tool and the Korean original was not read. Used for the 27 to 30 September window, firm lists, the two named services, the presumed method, the regulators' and institute head's remarks and ARTEX's GitHub dates as the newspaper reports themKyunghyang Shinmun (English edition)accessed 2026-10-08
  22. Reported byReport of 5 October 2026 carrying a Korea Herald piece: seven affected firms, per-firm counts (about 25,000 and 40,000 at the two largest), two firms that blocked attempts, the single attacker address, the financial regulator chair's remark on AI and the order to block external access unless essentialThe Straits Times (Korea Herald / Asia News Network)accessed 2026-10-08
  23. Reported byReport of 8 October 2026 on the CrowdStrike post. Read to compare its headline and sentences with the post (nationality, "alongside Anthropic's Claude AI model", method, a single address)Infosecurity Magazineaccessed 2026-10-08
  24. Reported byGitHub's repository search API, several queries run on 8 October 2026 at about 14:40 BST: 23 public repositories created between 2 and 8 October whose descriptions identify them as copies, mirrors or Korean or English builds of ARTEX (our count, 15 created on 8 October). The project's own page was read as an Internet Archive capture of 7 October 14:25 UTC and is deliberately not linked hereGitHubaccessed 2026-10-08

Share this briefing

Know someone who owns this problem? Send it to them.

LinkedInXWhatsAppEmail

Related briefings

The briefing, in your inbox

Practitioner analysis of cyber and AI security news. No vendor noise.

How often

Every new briefing in one email, at 7am, or at 7am, 12:30pm and 6pm. Nothing is sent when nothing is new. Unsubscribe any time.