ARTEX AI and Claude Agents Used in Cyberattacks Against South Korean Banks

The Story Begins: When AI Becomes an Attacker's Assistant

Imagine investigating a cyberattack against a major bank. You expect to find familiar evidence: suspicious scripts, malware, stolen credentials, or unusual network connections.

But this time, the investigation reveals something different.

The attacker has been using AI-powered tools to support their operations. Their infrastructure contains configuration files, saved AI conversations, and records of previous sessions. Instead of discovering only conventional attack tools, investigators find evidence of how the attacker interacted with AI systems while conducting their activities.

This is the situation described in a report published by BleepingComputer on October 10, 2026.

According to the report, a Chinese-speaking threat actor targeted multiple South Korean financial institutions using ARTEX AI, an agentic penetration-testing suite, alongside Claude Code agents.

The case is significant because it illustrates two sides of AI in cybersecurity: AI can help automate complex technical tasks, but the records generated during that work can also become valuable forensic evidence.

Which Banks Were Targeted?

The reported campaign affected South Korea's financial sector, with the following institutions named in the reporting:

• Shinhan Bank

• KB Kookmin Bank

• Hana Bank

The reported consequences included exposure of customers' personal information and credit card data, with system outages occurring in some cases.

The incidents prompted a response from the South Korean government, including an emergency meeting and calls for immediate security measures to protect critical IT systems.

The full technical details of each bank incident are not established by the supplied report. Therefore, the findings should not be interpreted as proof that every institution experienced the same attack method or impact.

What Is ARTEX AI?

ARTEX AI was described as an open-source, agentic penetration-testing suite developed in China.

Traditional penetration-testing tools generally perform specific tasks based on instructions provided by an operator. An agentic AI system can go further by using a language model to help plan tasks, interpret results, and coordinate multiple steps in a workflow.

In a security-testing context, this may involve activities such as:

• Analyzing information about a target environment

• Suggesting potential weaknesses to investigate

• Helping organize technical findings

• Supporting multi-step testing workflows

• Interpreting results and recommending next actions

These capabilities can be useful for legitimate security assessments. They can also be abused when an operator directs them against systems without authorization.

The important distinction is that AI-assisted activity does not automatically mean an attack was fully autonomous. Human operators may still select targets, provide instructions, review results, and decide what happens next.

In this reported campaign, CrowdStrike confirmed the use of ARTEX AI in real-world attacks.

The AI Models Behind the Operation

One of the most revealing findings concerned the language models used by the attacker.

According to CrowdStrike, the ARTEX instance used DeepSeek v4.1-flash as its primary language-model backend. The threat actor also used GLM-5.3, associated with Zhipu AI, and Grok 4.6 for additional Claude Code sessions.

The researchers further assessed that the actor likely accessed DeepSeek through an API proxy or reseller associated with the domain xcai[.]pro.

The reported setup can be summarized as follows:

<box border radius="lg" padding={3} gap={2}> <box background="surface-secondary" radius="md" padding={3} align="center" gap={1}> **Threat Actor**

<text color="secondary" size="sm" textAlign="center">Selects targets and directs activities</text>

</box> <box align="center"> <icon name="arrow-down" size="lg" /> </box> <box border radius="md" padding={3} align="center" gap={1}> **ARTEX AI**

<text color="secondary" size="sm" textAlign="center">Agentic penetration-testing workflow</text>

</box> <box align="center"> <icon name="arrow-down" size="lg" /> </box> <box background="surface" border radius="md" padding={3} gap={2}> <text textAlign="center" weight="medium">Reported AI components</text> <grid columns={2} gap={2}> <grid-item> <box background="surface-secondary" radius="md" padding={2} align="center"> <text weight="medium">DeepSeek</text> <text size="xs" color="secondary">Primary backend</text> </box> </grid-item> <grid-item> <box background="surface-secondary" radius="md" padding={2} align="center"> <text weight="medium">GLM</text> <text size="xs" color="secondary">Additional sessions</text> </box> </grid-item> <grid-item span={2}> <box background="surface-secondary" radius="md" padding={2} align="center"> <text weight="medium">Grok and Claude Code</text> <text size="xs" color="secondary">Additional AI-assisted activity</text> </box> </grid-item> </grid> </box> </box>

This is a simplified representation of the reported tool usage, not a complete attack-chain reconstruction.

The use of multiple AI tools suggests that the actor's workflow was not limited to a single model or interface. However, the supplied report does not establish exactly which model performed each individual attack action.

The Mistake That Exposed the Attacker

One of the most interesting parts of this case was not the AI technology itself. It was the information the attacker inadvertently exposed.

CrowdStrike researchers identified infrastructure containing publicly accessible directories with:

• Claude Code session histories

• ARTEX AI configuration files

• Claude memory files

These records offered investigators a view into the attacker's working environment.

Normally, defenders reconstruct an incident by combining endpoint telemetry, network logs, authentication events, and other evidence. Here, the exposed files reportedly provided additional context about the tools being used and the activities being performed.

Session histories can be particularly valuable because they may preserve interactions with an AI assistant, including task instructions, technical context, and the progression of a workflow.

Configuration files can reveal how a tool was set up. Memory files may retain information used across sessions.

When such material is exposed, it can help researchers connect activity across different stages of an operation.

The lesson: AI session data and configuration files should be treated as potentially sensitive operational records—not harmless development artifacts.

The Attacker Also Exposed Personal Information

The researchers reportedly found that the threat actor had used the same AI tools to create a résumé.

That résumé exposed identifying and contact information, along with a Telegram account.

Based on the résumé, CrowdStrike assessed that the person might be a 26-year-old Chinese individual who studied at South China University of Technology and lived in Maoming, Guangdong, China.

However, the researchers also found an inconsistency: the individual had initially provided a date of birth in 2007.

Because of this discrepancy, the researchers did not consider the available personal details reliable enough to confirm the actor's identity.

This is an important attribution lesson for investigators.

A résumé, username, contact detail, or AI conversation may provide a useful lead, but it does not independently establish who carried out an attack. Such details can be inaccurate, fabricated, or associated with someone other than the operator.

The responsible conclusion is that the information provided potential attribution leads—not a confirmed identity.

What Did the Attacker Plan to Do With the Stolen Data?

Another unusual finding concerned the apparent lack of a clear monetization plan.

According to the report, the exposed records did not reveal a specific plan for monetizing the data stolen from the South Korean banks. The actor reportedly asked Claude to suggest Telegram groups focused on selling Korean data.

This detail offers a glimpse into the actor's apparent decision-making process, but it does not establish the ultimate purpose of every action or prove that the data was successfully sold.

For incident responders, the distinction matters. Data theft, attempted monetization, and confirmed sale of stolen information are separate claims that require different evidence.

Why Did ARTEX AI Become Closed-Source?

Following confirmation that ARTEX AI had been used in real-world attacks, its developer decided to make the project closed-source and discontinue further updates, according to the report.

This raises a broader question for the cybersecurity community: what should happen when a tool created for legitimate security work is abused?

Penetration-testing tools can help defenders identify weaknesses before criminals exploit them. But the same capabilities can be repurposed by unauthorized operators.

Changing a project's licensing or availability does not automatically remove existing copies or eliminate misuse. It does, however, demonstrate the difficult decisions developers face when their tools appear in real-world attacks.

The broader issue is not simply whether AI tools should exist. It is how their capabilities, access, deployment, and misuse are managed.

What This Means for SOC Analysts and Threat Hunters

This case provides several practical lessons for defenders. The following are recommended investigation approaches based on the reported evidence; they are not claims that every technique was observed in these bank incidents.

1. Investigate Exposed AI Development Artifacts

When investigating suspicious infrastructure, look for unintentionally exposed files and directories that could reveal operational activity.

Potentially useful artifact types include:

• AI coding-assistant session histories

• Agent configuration files

• Local memory or context files

• API configuration and environment files

• Debug logs

• Source-code repositories

If these files are discovered, preserve them using the organization's evidence-handling procedures. They may contain credentials or sensitive personal information, so access should be restricted.

2. Correlate AI Tool Usage With Target Activity

The presence of an AI coding assistant or penetration-testing framework is not, by itself, evidence of malicious behavior.

A stronger investigation correlates tool execution with activity such as:

• Unexpected scanning

• Unauthorized authentication attempts

• Exploitation indicators

• Unusual outbound connections

• Access to sensitive systems

• Unexpected data transfers

The goal is to determine whether the tools were used in an authorized assessment or as part of an attack.

3. Review API and Egress Activity

Where endpoint and network telemetry are available, investigate connections to external AI services and API providers when the surrounding behavior is suspicious.

Useful questions include:

• Which process initiated the connection?

• Which host and user were involved?

• Was the destination expected for that system?

• Did the connection coincide with suspicious scanning or exploitation?

• Were sensitive files accessed before or after the connection?

• Is there evidence of unauthorized data transfer?

An AI service connection alone should not trigger a conclusion of compromise.

4. Protect AI Session Data

Organizations adopting AI coding assistants and agentic tools should assess whether their session histories, configuration files, or memory stores contain sensitive information.

Defensive controls should include:

• Restricting access to development artifacts

• Preventing accidental publication of private repositories

• Keeping API keys and credentials out of session files

• Scanning repositories for exposed secrets

• Reviewing permissions on logs and stored sessions

• Applying appropriate retention and deletion policies

5. Keep Attribution Evidence Separate From Technical Evidence

A username, résumé, or contact detail can support an investigative lead, but should not be treated as proof of identity.

Maintain separate records for:

• Observed technical behavior

• Infrastructure relationships

• Tooling and configuration evidence

• Claimed or inferred operator identity

• Confidence and alternative explanations

This helps prevent an early assumption from becoming an unsupported conclusion in the final incident report.

IOC & Technical Indicators

Important: The supplied report does not include a complete set of conventional IOCs such as malicious IP addresses, malware hashes, or verified command-and-control domains. The items below are the technical indicators and contextual identifiers explicitly mentioned in the report. They should not all be treated as confirmed malicious IOCs.

1. Domain

<box border radius="md" padding={3} gap={1}> <row align="center" gap={2}> <icon name="globe" size="lg" /> **`xcai[.]pro`** </row> <badge color="warning">Reported likely API proxy/reseller</badge> CrowdStrike reportedly assessed that the actor likely accessed DeepSeek through this service. The report does not establish that the domain itself is malicious, so it should be treated as a contextual investigation lead rather than a confirmed block indicator. </box>

2. Tools and Frameworks

IndicatorContextARTEX AIAgentic penetration-testing suite reportedly used in the attacksClaude CodeAI coding assistant; session histories were reportedly found on exposed infrastructureDeepSeek v4.1-flashReported primary LLM backend for the ARTEX instanceGLM-5.3Additional model reportedly used in Claude Code sessionsGrok 4.6Additional model reportedly used in Claude Code sessions

These are tooling and behavioral indicators, not inherently malicious software or services.

3. Exposed Artifact Types

Researchers reportedly found:

Claude Code session histories ARTEX configuration files Claude memory files

These are artifact categories described in the report, not exact filenames or file hashes. Investigators can use them as a starting point when examining similar exposed infrastructure.

4. Target Organizations

The following institutions were named in the reporting:

Shinhan Bank KB Kookmin Bank Hana Bank

These are contextual entities associated with the reported campaign, not malicious IOCs.

IOC Handling Recommendations

Before adding an indicator to a blocklist or detection rule:

1. Verify the exact domain, IP, hash, or artifact from a reliable source.

2. Determine whether the indicator is directly associated with malicious activity.

3. Check the organization's own telemetry for relevant observations.

4. Record the source, observation time, confidence, and limitations.

5. Avoid blocking legitimate AI services solely because they appear in this report.

Defensive Recommendations

Organizations can use this case to strengthen both conventional security controls and their management of AI-assisted development.

For financial institutions:

• Review access to critical banking systems and sensitive customer data.

• Monitor suspicious authentication, exploitation, and outbound traffic.

• Correlate endpoint, network, identity, and application telemetry.

• Investigate unusual data access and potential exfiltration.

• Validate that incident-response procedures cover AI-assisted attacks.

For organizations using AI development tools:

• Protect AI session histories and local memory files.

• Restrict access to API credentials and configuration secrets.

• Audit public repositories for accidental exposure.

• Monitor agent execution and outbound network activity.

• Establish clear authorization boundaries for automated security testing.

For threat hunters:

• Search for exposed operational artifacts when investigating attacker infrastructure.

• Correlate tool usage with observed attack behavior.

• Maintain confidence levels for every investigative conclusion.

• Treat attribution claims cautiously until independently corroborated.

The Bigger Lesson: AI Changes the Workflow, Not the Need for Evidence

This incident illustrates how AI-assisted tools can become part of an attacker's operational workflow. They may help coordinate technical tasks, interpret results, and support decisions, while human operators remain involved.

It also demonstrates that investigators may find useful evidence in unexpected places. An exposed session history or configuration file can reveal information that conventional network and endpoint logs may not capture.

But the presence of AI does not remove the need for disciplined investigation. Defenders must still establish what happened, which systems were affected, what data was accessed, and which conclusions are supported by evidence.

For SOC analysts and threat hunters, the central lesson is straightforward:

Investigate the attacker's behavior, the infrastructure they used, the artifacts they left behind, and the impact on the target—not merely the AI tools named in the report.

As AI-assisted security tools become more capable, protecting operational records and correlating technical evidence will become increasingly important.