Incident overview: the periphery was breached, not the core
From late September to early October 2026, a series of leaks of customer and employee data was confirmed in Korea’s financial sector. According to a media tally on October 4, data on about 66,000 individuals and up to about 2,200 corporate records leaked from seven financial companies: four banks, two savings banks and one capital company (a specialized credit finance company).
The attackers did not go after core banking systems. The attacks concentrated on auxiliary systems for employees and loan brokers: internet-facing peripheral systems set up for convenience at work, such as lookup services for loan brokers, work support systems for employees and sales support systems. The Financial Services Commission (FSC) also identified systems used by employees and by external personnel such as loan brokers and outsourcing vendors as the cause of these breaches.
The authorities’ demands point the same way. At an emergency response meeting on October 2, the FSC asked firms to review their internet-facing IT assets and the state of their access control, cut off paths that reach internal information without authentication, and share attacker IPs and techniques. Then, at an emergency review meeting for the entire financial sector on October 4, it required firms to block all external access as a rule, except where essential, and, where external access is unavoidable, to keep access rights and the information that can be queried to a minimum. The Korea Internet & Security Agency (KISA) also named identifying internet-facing assets, checking access rights on web and API, and protecting accounts and credentials as priorities in its October 3 security hardening advisory for companies.
Based on published reports, the attack unfolded as follows.
| Stage | Attack technique | Weakness exposed |
|---|---|---|
| Reconnaissance | Automatically scanned internet-facing web pages and servers for brokers and employees | Poor management of internet-facing peripheral systems |
| Authentication bypass | Tried to bypass authentication by entering values such as customer numbers at random | No limit on attempts and no strong authentication |
| Data collection | Repeatedly called lookup APIs while changing input values such as customer numbers | Missing server-side authorization checks (IDOR) |
| Evasion | Used IPs from multiple countries and kept querying by another route when blocked | Limits of a response centered on IP blocklists |
| Automation | Indications that ARTEX, an LLM-based open-source penetration tool, was used | Automated attacks that outpace human response |
Around the same time, cases of banks that avoided damage were also reported. One bank required a separate certificate and biometric authentication, so an ID and password alone were not enough to reach its work systems. Another did not give loan brokers an access path to its internal network in the first place. What they had in common: they required separate proof, not just an account, to decide who could connect.
The trace left by the AI penetration tool: hard-coded User-Agents
ARTEX is an open-source autonomous AI penetration testing tool published on GitHub, mainly within the Chinese-speaking community. A large language model (LLM) analyzes the target, plans an attack path and then runs security tools. According to reports, the Financial Security Institute (FSI) found signs of ARTEX use while tracing the logs and attacker IPs of the first bank to report a breach. The FSI explained that it could identify the attackers because common characteristics remained in the data the tool sent, even as the attacker IPs changed.
ARTEX’s public source code hard-codes User-Agent strings that can be sent to target web systems. PLURA’s blog analysis listed these values as candidate indicators of compromise (IOCs) to search for first in web application firewalls (WAFs).
| Hard-coded User-Agent value | Purpose in the public source |
|---|---|
artex-enrich/1.0 | Requests that check web asset information |
Mozilla/5.0 (spa-api-recon) | A script that collects HTML and JavaScript files to find API paths |
Mozilla/5.0 (spa-api-recon spider) | A script that crawls web pages and collects links and input forms |
These values need careful interpretation. The three values are candidates found in the public source code, and they have not been verified as values observed in the actual attack logs of this incident. ARTEX can also crawl by driving a real Chromium browser, which sends that browser’s own request headers unchanged. Blocking the three strings does not mean blocking the tool as a whole.
Two sides of a hard-coded value: a detection clue and a bypass
For defenders, a temporary detection clue
When an attack tool uses a hard-coded User-Agent, you can search for that string in WAF or access logs to find past access history, and block requests coming in now. As an initial response, this is useful.
But one line of code changes this value. The moment a detection rule is published, the attacker knows it too. IP blocklists fell short against IP rotation across multiple countries for the same reason. Blocking based on values the attacker chooses tends to become a catch-up response.
For attackers, a string they only need to copy once
There is a problem in the opposite direction as well. In the HTTP standard RFC 9110, User-Agent is a header in which the software sending a request identifies itself. The standard gives the server no way to check whether that claim is true. Browser developer tools, command-line tools and scripts can each send whatever value they like.
So if you decide whether to allow access based on the User-Agent, the control does not hold. If you enforce “access only from the dedicated app” or “access only from the secure browser” by looking for a fixed string in the User-Agent, an attacker passes that check simply by looking up a legitimate device’s User-Agent once and copying it as is. Automated tools keep trying these header combinations, changing them tirelessly.
| Identifier | Who sets the value | Effort to change it | In this incident | Appropriate use |
|---|---|---|---|---|
| User-Agent | Self-reported by the client | One line of code | The tool’s hard-coded values were published as candidate indicators but can be replaced | Supplementary detection indicator |
| IP address | Connection route | Switch to proxies or overseas servers | Attacked again from another country’s IP after being blocked | Detection and after-the-fact blocking |
| ID and password | User | Enter leaked or guessed values | Attempted authentication bypass by random guessing | Combine with other factors |
| Client certificate | Issued by the organization; private key kept on the device | No connection without the private key | A bank that avoided damage required a certificate in addition to the account | Basis for access decisions |
The defense you need: proof, not strings
As Kookmin Ilbo reported, it is hard to keep outsiders out without actually verifying the identity of the connecting device and the user. There are four principles.
- Decide access with an identity that cannot be forged. The basis is a client certificate issued by the organization and a non-exportable private key stored on the device. Only a device holding the private key can complete the connection, so the decision does not change however the User-Agent or IP is altered.
- Decide before the HTTP request. Mutual TLS (mTLS) uses the client authentication procedure of the TLS standard (RFC 8446) to verify the client certificate during the TLS handshake. Requests from clients that fail verification do not reach the web application. Even if the server still has authorization flaws that have not yet been found, the path by which external automated tools reach those flaws is cut off.
- Use User-Agent and IP as detection indicators. There is no need to discard them. Use shared indicators of compromise to investigate past history, and use them as supplementary signals for finding anomalies that remain even after certificate verification passes.
- Fix server-side authorization checks separately. The server must check every time whether the requesting user is authorized to view that customer number. The OWASP API Security Top 10 lists this flaw as its first risk, Broken Object Level Authorization (API1). Add rate limits on bulk and sequential queries as well.
Which parts BrowZen addresses
BrowZen is a Chromium-based secure browser installed and used on employee PCs. It is one way to put the financial authorities’ demand into practice at the entry point to work systems: block external access as a rule, and keep it to a minimum where it is unavoidable. Two of its features relate to this incident: access enforcement, which restricts the way into work systems to BrowZen, and applying policy, which controls what each user can do after they connect.
1. Client certificate-based access enforcement
BrowZen uses client certificates (mTLS) to allow access to work systems only from BrowZen running on a registered device. Certificate verification happens during the TLS handshake, so the User-Agent string plays no part in the decision. By attack stage, it looks like this.
| Attack stage | With access enforcement applied |
|---|---|
| Reconnaissance of internet-facing systems | Scanners and scripts without a certificate are cut off at the connection stage and cannot collect the page and API structure |
| User-Agent spoofing | Even an exact copy of a legitimate device’s User-Agent does not connect without the certificate and private key |
| IP rotation across countries | The decision is not based on IP, so the result is the same whichever country’s IP is used |
| Account and authentication bypass attempts | Even with a valid account, a client that is not BrowZen on a registered device does not reach the login screen |
| ID enumeration (IDOR) | External tools cannot reach the lookup API. The flaw itself, however, must be fixed on the server |
2. Applying policy after access
Users who come in from a legitimate device still need controls, for cases where an account has been taken over or an insider is gathering information.
- User and group policy: The policy that matches the signed-in person and their group is applied automatically
- Upload and download policy: Allows or blocks file uploads and downloads by site and department
- Capture and screen-sharing blocking and user watermark: Blocks capture of work screens and stamps the user ID, connecting IP and time on the screen so the leak path can be traced
Scope and limits
- In scope: Web-based work systems that employees and partner companies use on PCs. The same principle can be applied, based on registered devices, to users who need to connect from outside, such as loan brokers and outsourced staff
- Out of scope: Customer-facing public services and mobile apps. You cannot require customers to use a specific browser, and BrowZen v1.0 supports Windows, with mobile on the roadmap. Mobile work systems were also among the targets in this incident, so mobile needs separate controls
- Server flaws are fixed on the server: Access enforcement reduces the attack surface but does not fix authorization flaws. Paths by which legitimate users exploit the same flaws must be closed with server-side checks
What to check now
- Make a thorough inventory of internet-facing systems for employees, partner companies and loan brokers
- In access-decision code and WAF settings, find where a “dedicated app” or “dedicated browser” is identified by comparing User-Agent or IP strings
- Confirm that lookup APIs have object-level authorization checks and limits on bulk and sequential queries
- Investigate access logs from late September onward using the shared attacker IPs and candidate User-Agents
- Move work systems that genuinely need external access to certificate-based device and browser verification
In closing
In this incident, the attackers could change IPs, change accounts and, when needed, change the User-Agent as well. What they could not change is the private key that exists only on a registered device. Moving the basis of access control from values the attacker can change to proof the attacker cannot change is how defense keeps pace in an era when AI has accelerated attacks.
You can find BrowZen’s features and deployment environments on the BrowZen product page, and the basic concept of a secure browser and how it differs from VDI and RBI in What a Secure Enterprise Browser Is.
References
Public agency announcements and standards documents
- Financial Services Commission, We will respond closely to recent cyber threats in the financial sector (press release, 2026-10-02, in Korean)
- Financial Services Commission, The entire financial sector will respond to cyber threats with heightened vigilance (press release, meeting 2026-10-04, posted 10-06, in Korean)
- Korea Internet & Security Agency (KISA) Boho Nara, Security hardening advisory for companies against recent cyberattacks (2026-10-03, in Korean)
- IETF, RFC 9110 HTTP Semantics, 10.1.5 User-Agent
- IETF, RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3
- OWASP, API Security Top 10 2023, API1 Broken Object Level Authorization
Media reports
- The Financial News, Seven financial companies breached: data on 66,000 individuals and 2,200 corporate records leaked (2026-10-04, in Korean; English edition)
- Kookmin Ilbo, [Exclusive] Focused only on “customer-facing” security, they were breached through “employee and partner company” systems (2026-10-05, in Korean)
- Hankook Ilbo, “25,000 vs. 0”: why hacking damage differed, as attention turns to security gaps between banks (2026-10-05, in Korean)
- Herald Business, [Exclusive] The tool behind the serial bank hacks was China’s “ARTEX AI,” used by hackers (2026-10-03, in Korean; English edition)
- Korea JoongAng Daily, From banks to lenders, suspected AI hacks expose cracks in Korea’s financial defenses (2026-10-04)
- Korea JoongAng Daily, AI hackers target Korea’s banks, trigger industrywide security review (2026-10-04)
- The Korea Herald, Korean banks on high alert after wave of cyberattacks (2026-10-05)
- The Kyunghyang Shinmun, Financial sector breached via the back door by AI… debate over the current ‘network separation’ security system (2026-10-05, English edition)
Security industry analysis
- PLURA blog, [First report] Financial sector hacking IOCs: public indicators related to ARTEX AI and items to check immediately (2026-10-03, in Korean)
