Quick Read Summary
- The developer of ARTEX says the software will no longer receive public releases or maintenance after security firms linked it to attacks on South Korean banks.
- CrowdStrike said a suspected attacker used ARTEX and Anthropic’s Claude Code in a campaign aimed at stealing customer data.
- At least nine South Korean banks have been reported as targets since late September; investigators have not publicly established every detail of the attacks.
The developer of ARTEX, who uses the GitHub handle Autumn-27, said the project would become closed-source and receive no further public versions or maintenance. Reuters reported on 9 October that the project’s GitHub page had been taken down.
ARTEX was presented as an open-source agent for automated penetration testing. It was designed to connect to external language models, including ChatGPT, Claude and DeepSeek, and help organisations test their networks for vulnerabilities. It was not itself a standalone language model.
The developer said the original aim was to help businesses assess risk and improve security. the company said on GitHub, the developer opposed illegal use of the software and said the project would no longer be updated following reports of misuse.
US cybersecurity firm CrowdStrike said the suspected attacker behind recent South Korean bank incidents was likely a 26-year-old based in China who used ARTEX alongside Claude Code. CrowdStrike said the campaign sought to steal customers’ personal information. Those are the firm’s attribution and assessment, not a court finding.
At least nine South Korean banks have disclosed or been reported by local media as targets of cyberattacks since late September. The incidents prompted South Korean police to open an investigation and President Lee Jae Myung to call for a strong response.
China’s foreign ministry said it was not familiar with the case and reiterated that China opposes hacking. The public information available in the Reuters report does not establish the full number of affected customers, the exact data accessed or whether all incidents were conducted by the same actor.
How ARTEX was used
Penetration-testing tools are built to find weaknesses before criminals do. The same capabilities can be used by attackers to scan networks, identify exposed services and automate parts of an intrusion. Open-source distribution makes tools easier for legitimate security teams to inspect and adapt, but it also allows others to obtain and modify them.
Adding a language model can make a tool easier to operate by allowing users to describe a task in ordinary language and chain together multiple steps. That convenience does not itself make a tool malicious. The risk depends on the permissions it has, the systems it targets and the safeguards around its use.
Closing the public repository may reduce easy access to the project’s maintained version, but it cannot remove copies already downloaded or guarantee that modified versions will disappear. Organisations that used ARTEX will need to review where it was deployed, what credentials it could access and whether its logs show unexpected activity.
Financial institutions should treat the reported campaign as a reason to review external exposure, access logs and unusual authentication events, while following instructions from their national cyber authorities. A tool name alone is not enough to determine whether a network has been compromised; defenders need evidence from their own systems.
Security teams should also check whether testing tools are restricted to authorised environments and whether their use is logged. Agent-based tools can execute multiple actions in sequence, so controls should cover the full workflow rather than only the initial command.
The episode shows a recurring challenge for software developers: a tool intended for defensive work can be repurposed quickly, and the public release decision may change after it becomes associated with a real attack. The investigation in South Korea will need to establish what happened at each bank and what evidence links the incidents.
What investigators have said
The public account needs to be separated into three questions: what happened at the banks, what role the tool played, and who was responsible. A security company's technical assessment can help investigators connect activity across systems, but attribution usually depends on several kinds of evidence, including infrastructure records, malware behaviour, access logs and links between accounts. The information described in the current reporting does not resolve every part of that chain.
That distinction matters because a tool can appear in an attack without being the sole cause of it. An attacker may combine legitimate utilities, custom code, stolen credentials and cloud services. Removing one public project can change the attacker's options, but it does not by itself establish the full method used against each institution.
Banks hold identity, account and transaction information that can be used for fraud, extortion or further intrusions. Their networks also connect to payment systems and third-party service providers, so a breach can create risks beyond the first compromised account. Institutions typically need to investigate whether attackers reached customer records, internal systems or only exposed services, because each outcome has different implications for customers and regulators.
Customers should be cautious about messages that claim to come from a bank and refer to a recent incident. They should use the phone number or app already known to them, not contact details supplied in an unexpected message. Banks should provide specific guidance if customers need to change credentials or take other action.
The investigation will need to establish the scope of access, identify affected systems and determine whether any customer data was removed. Banks may also review vendor access, remote administration tools and security alerts around the reported period. Public updates may be limited while investigators and institutions preserve evidence, so the absence of a detailed public account should not be interpreted as proof that no further damage occurred.
For developers of defensive tools, the episode is a reminder that publishing software also creates responsibilities around documentation, default permissions and safeguards. Those measures cannot prevent every misuse, but they can make authorised use clearer and reduce the chance that a tool is deployed outside the environment for which it was intended.