A cybersecurity investigation has linked an open-source AI agent designed to help organisations test their own security to an attack campaign targeting financial institutions in South Korea. Shortly after, the agent’s developer announced that ARTEX would no longer be updated or publicly available and would therefore become closed source.
This case serves as a warning regarding the evolving character of cyber risk. AI did not on its own “hack” the banks: rather, a human operator used an agentic penetration-testing tool in combination with large language models. The incident demonstrates how AI tools can assist an attacker in progressing more quickly through various stages of an intrusion and how hard it is to contain software once it has been made publicly available.
It also poses a more difficult question: if a legitimate security tool is used in an improper way, does closing its source make anyone safer?
The ARTEX Cyberattack Case
ARTEX is an open-source agent designed for automating penetration testing. Unlike a standalone AI model, it links to external large language models and makes use of them to help with security-testing tasks. The person who developed it stated that the aim of the project was to assist organisations in assessing their risks and in improving their defences.
CrowdStrike has stated that a threat actor employed ARTEX in conjunction with large language models as part of an operation aimed at South Korean financial organisations. The company noted that this activity took place from late September through to early October 2026 and led to data being obtained by the affected organisations. While it has a moderate level of confidence that the actor was probably Chinese-speaking and motivated by financial gain, it did not assign the campaign to any specific group.
Reuters has stated that nine or more South Korean banks have either made disclosures or have been reported as having been the target of cyberattacks since late September, after which the South Korean authorities initiated an investigation and President Lee Jae Myung called for a strong response.
The figure given in the public reports for the number of affected customers was about 68,000, although the full extent and details of the incidents are still under investigation. The reports stated that the information that had been exposed included names, phone numbers, income figures, loan limits, and details regarding the loans.
Even when passwords or account balances are not at issue, such details can be dangerous. If a fraudster knows a person’s name, their contact information, income, and recent loan activity, then he or she will be able to make a fake bank call or message appear much more believable. Furthermore, data that has been stolen can be combined with information obtained from other data breaches in order to carry out identity theft and targeted phishing.
What ARTEX did—and what remains unclear
According to CrowdStrike, ARTEX is one of the tools the attacker used. It was used in conjunction with various large language models, such as Anthropic’s Claude Code, when carrying out attacks on financial organisations. Investigators found ARTEX configuration files and records of AI sessions in infrastructure linked to the campaign.
The difference is important since the evidence available does not indicate that ARTEX made the decision on its own to attack banks or that it operated without any human instruction; on the contrary, it shows that a person used a toolset enabled by artificial intelligence to help carry out offensive security operations. Moreover, the fact that a Chinese-developed tool was used does not prove that the attacker was acting on behalf of the Chinese government. CrowdStrike has not assigned the activity to a specific adversary, and officials from South Korea have warned that the origin of a tool does not determine the identity or nationality of its user.
The targets also extended to systems beyond the main online banking services. The accounts pointed out vulnerabilities in auxiliary services, for example, in the portals used by external loan agents and the mobile tools used by employees. This is a well-known but important security lesson: instead of trying to break directly into a system’s most visible front door, attackers usually look for the less securely protected connections around it.
The fact that has come out in the public report is that AI did not discover all the vulnerabilities, carry out all the intrusion steps, or directly cause the data breach. It does indicate that agentic tools and language models were used as part of the attacker’s workflow. This is sufficient to give the incident importance—yet it does not provide a basis for overstating what the evidence shows.
Why an AI agent changes the risk
Penetration-testing tools are created with the aim of detecting vulnerabilities. When in the hands of authorised people, they enable security teams to identify systems that are exposed, check the effectiveness of controls, and correct any problems before criminals are able to take advantage of them. However, the same capabilities can be misused if the tools are used against systems that one does not own or for which one does not have permission to carry out testing.
An AI agent could increase the speed and degree of coordination of the process. According to its design and the permissions it has, it might be used to organise information, interpret the results of the tools, suggest the following steps, or carry out repetitive tasks. Although a human operator still has to make the decisions, the amount of manual work needed for certain activities could decrease.
That creates several practical risks:
- With more activity taking place in a shorter amount of time, an attacker can use automation to look at a number of targets or systems at the same time.
- Because the barriers to entry are lower: AI support can help less experienced operators to understand technical outputs or put together workflows.
- An operator is able to get the model to explain its mistakes, modify the plan, or produce different versions.
- There is greater operational scale since a small team or even one person could carry out more activities than previously.
- It is more difficult to assign responsibility because the attackers can pass the activity through infrastructure in a number of countries and make use of tools that are easily available, which makes it hard to determine who is to blame.
This does not mean that every AI tool will succeed in carrying out an attack. Rather, it indicates that defenders should anticipate familiar threats such as reconnaissance, vulnerability exploitation, credential abuse, and data theft being carried out in a more automated manner and at a faster pace.
South Korean authorities have cautions that the use of AI could spill over from the banking sector to other industries and to public-sector organisations. This concern does not merely relate to the field of finance; any organisation which has exposed services, sensitive information, or supplier links that are only weakly protected might come under similar pressure.
Why the developer closed ARTEX
On Thursday the developer who had the GitHub handle ‘Autumn-27’ stated that ARTEX would no longer be updated and would be made into closed source software. He also declared that no further versions would be released to the public and that maintenance support would cease. The GitHub page was subsequently removed, as Reuters reported.
The developer called the decision a reaction to misuse, at the same time stressing that ARTEX had originally been meant for legitimate security testing.
It’s reasonable to expect that. A developer might feel a sense of responsibility if the tool they have developed is linked to harm. However, shutting down the source code brings with it questions regarding what it can and cannot achieve.
The project might become less convenient to get or alter from its official source and could also delay access to future releases. However, it does not necessarily mean that existing copies are removed, that users are prevented from modifying earlier versions, or that other developers are stopped from creating similar tools. After software has been made publicly available, it is not possible to reliably erase it by withdrawing the original repository.
There is also a defensive compromise. Since open-source tools can be examined, tested and improved by security researchers, removing public access might reduce certain kinds of misusage but could at the same time hinder legitimate researchers from auditing the tool and understanding how it works. Neither the publication of a security tool as open-source nor its publication as closed-source ensures that it is safe. The result will depend on the tool’s capabilities, the safeguards it has, the way it is distributed and the manner in which users deploy it.
The security lesson for banks
What financial institutions should do first is not to discuss the ARTEX developer’s choice, but to find out how the attacks got into the vulnerable systems and to determine if similar routes exist in their own environments.
Treat peripheral systems as part of the bank
Portals for loan agents, mobile applications for employees, interfaces for brokers, customer support systems, and links with vendors should be given security consideration no less than that given to core banking services. A system can be referred to as ‘auxiliary’ even if it contains sensitive data or provides access to more important assets.
Review internet-facing applications
Portals for loan agents, mobile applications for employees, interfaces for brokers, customer support systems, and links with vendors should be given security consideration no less than that given to core banking services. A system can be referred to as ‘auxiliary’ even if it contains sensitive data or provides access to more important assets.
Tighten identity controls
External partners and employees should be given only the access that corresponds to the requirements of their roles. The damage caused by compromised credentials or by accounts with too much access can be reduced through the use of multifactor authentication, strong session management, careful controls over service accounts, and regular reviews of access.
Watch for unusual behavior
Monitoring should include more than just a check for login failures; security teams ought to watch out for unusual access patterns, unexpected data downloads, abnormal use of administrative functions, activity originating from unfamiliar locations, and traffic that departs from the normal behavior of the application.
Prepare for personal-data exposure
The response doesn’t finish once the affected service has been secured if customer data has been stolen. Banks have to determine what information was exposed, notify the relevant people, provide support for fraud monitoring, and be ready for subsequent scams based on the stolen details.
What organisations should do about AI-enabled tools
It would be a mistake for security teams to think that blocking a specific tool will deal with the overall risk; ARTEX is just one instance of a wider category of AI-assisted tools that combine models with scripts, security utilities, and external services.
A more durable response includes:
- When putting together threat models, include AI tools and think about the ways in which attackers might use them for reconnaissance, vulnerability analysis, social engineering, and data processing.
- Improve how you manage exposure by knowing which services can be accessed from the internet and which systems rely on third-party portals or applications.
- Establish rules concerning authorised testing. Specify which people may use the automated testing agents, which environments they are allowed to test, and what precautions are necessary.
- Keep an eye on the movement of data and put in place controls to pick up any unusual data exports and access of sensitive records.
- Practice dealing with a data breach. Check how well the security, fraud, legal, privacy, communications, and business teams work together after a customer data breach has occurred.
- Indicators should be shared responsibly. Financial institutions must work with regulators, sector information-sharing groups, and reliable security partners.
What we want is not to ban all forms of security automation since organisations need it if they are to test and protect their systems, which are becoming more and more complex. All automated testing should be authorised, kept under control, properly logged, and kept separate from the production environments unless there is a clear and approved reason for not doing so.
What is the dilemma in this case? Should we control the tool or should we reduce the vulnerabilities?
The ARTEX episode might lead governments and technology companies to concentrate on controlling offensive AI tools; that could be one aspect of the response, particularly since such tools can be used to automate high-risk actions. However, limitations on the tools themselves are unlikely to deal with the problem.
Attackers have the ability to change the tools they use. A closed project can be copied over. Other models and scripts can carry out similar tasks. Yet the vulnerabilities which allowed the intrusion to take place may still exist.
A balanced approach needs to address both sides:
- Enhance the security of systems that are exposed.
- Make it easier for legitimate defenders to carry out responsible testing.
- Establish clear boundaries regarding actions that are carried out autonomously.
- It is necessary to have strong controls in place for AI agents that have access to sensitive systems.
- Look into any misuse and take legal action against criminal activities.
- Do not consider a tool’s country of origin as evidence of the attacker’s identity or affiliation.
The situation also shows the importance of careful communication to the public. While early reports can pick up useful warning signs, any statements regarding attribution, the scale of the issue, and the exact role of AI should continue to be qualified until the investigations have provided stronger evidence.
A turning point, not an AI apocalypse
The ARTEX case does not demonstrate that AI has achieved fully autonomous cyberattacks or that banks are no longer able to defend themselves; it does show that AI-enabled tools have become involved in actual offensive operations and that the distinction between legitimate security testing and malicious use largely depends on authorisation, intent, and control.
The point for organisations is practical in that they should secure the systems that have been overlooked, restrict access, keep an eye on data flows, and make preparations for attacks which may now be faster and more automated than they used to be.
For developers the situation is more complicated; although withdrawing a tool after it has been misused may be an responsible action, it alone is not sufficient to get the fundamental capability out of circulation. The broader security community have to think about how to make powerful tools safer when they are being developed, distributed and used without taking away from the defenders the tools that they need.
The most important question is not whether ARTEX is open or closed source. It is whether financial institutions and other organisations can find and fix the weaknesses that let an attacker turn any tool into an entry point.
About the Author
