How financial business interfaces create choices for attackers—and how ARTEX could change the cost of investigating them.
Incident Analysis · South Korean Banks · Attack Strategy · ARTEX · Financial Systems
Analysis based on publicly available information as of October 12, 2026.
Abstract
Between September 27 and 30, 2026, several major South Korean banks experienced overlapping cyberattacks. Shinhan Bank disclosed a breach affecting approximately 25,700 customers. [6] KB Kookmin Bank reported the exposure of information concerning 119 customers and employees, while Hana Bank confirmed the exposure of 89 customers’ personal information. The attacks concentrated on loan-inquiry services, employee mobile applications, and outside-sales systems rather than the banks’ core transaction-processing infrastructure.
On October 7, CrowdStrike reported that it had identified attacker-controlled infrastructure containing configuration files for ARTEX, a Chinese-developed AI penetration-testing system, together with Claude Code session histories and memory files. Its investigation linked the infrastructure to activities targeting South Korean financial organizations, although the complete scope of the campaign and the role of AI in individual intrusions remained uncertain. [1]
The attacks raise a question that is more important than whether an AI system discovered a novel vulnerability: why was attacking the business interfaces of several banks a viable strategy in the first place?
Modern financial institutions are not single, uniformly protected systems. They are collections of services built for different business purposes, under different contractual relationships, and often maintained by different organizational units. Loan brokers need to check applications, employees need access to customer information outside branches, and customers need to verify the identities of financial intermediaries. Each requirement creates a legitimate route through which information becomes accessible.
Defenders must preserve these business functions while enforcing their intended access restrictions. The complexity inside each institution makes those restrictions difficult to keep consistent. The variety of interfaces across institutions gives attackers a separate advantage: they can compare candidates and pursue a different service when one proves unpromising. They need not compromise an entire bank if one legitimate information service exposes data beyond its intended authorization boundary.
This difference between how complex systems are organized and how attackers can explore them is the central subject of this article.
The publicly documented activity does not establish that ARTEX autonomously selected the banks, discovered every weakness, or executed every intrusion. But its architecture provides a concrete way to examine how persistent, multi-target exploration could change the economics of an attack strategy that was already viable without AI.
1. Incident Overview
The breaches disclosed in early October 2026 had a distinctive feature: the affected systems were important to financial operations without being the principal infrastructure through which customers transferred money or maintained their accounts.
Shinhan Bank reported the exposure of personal information belonging to approximately 25,700 customers through services associated with loan applications and broker inquiries. The compromised information reportedly included names, telephone numbers, annual income, and loan limits, with resident registration numbers and connected identity information involved in a smaller number of records. [2, 6]
KB Kookmin Bank reported a breach involving its employee-facing RM Agent and PB Agent systems. Subsequent reporting based on material submitted to the National Assembly identified 99 affected customers and 20 employees, a total of 119 people, with 153 individual information items exposed. These applications supported employees’ business activities rather than ordinary consumer banking transactions. [3]
Hana Bank disclosed that 89 customers’ personal information had been exposed following abnormal access to its outside-sales support system, known as ODS. The bank stated that the affected system was separate from its internet and mobile banking transaction channels. [4]
Other financial companies reported incidents during the same period, including BNK Busan Bank and Hyundai Capital. At Hyundai Capital, an externally accessible mortgage-broker verification page was attacked, exposing information concerning 146 loan brokers. The company stated that it had not identified an intrusion into its internal systems or a breach of ordinary customer information. [5]
These incidents should not automatically be counted as successful operations by one attacker. CrowdStrike identified relevant infrastructure and overlapping targets, but did not establish a complete attribution chain for every publicly reported breach.
The distinction matters because the different cases demonstrate different technical problems.
Shinhan’s incident involved a loan-related information service and reports of repeated attempts to access customer information. KB and Hana involved employee or sales-support systems whose exact exploitation paths have not been publicly reconstructed. Hyundai Capital involved an explicitly public verification service that returned information beyond its intended public scope.
What connects these cases is not a confirmed common software vulnerability. It is the presence of business interfaces capable of exposing valuable information without requiring control over the institutions’ central financial transaction systems.
That is a much broader attack surface than the familiar image of breaking into a bank’s core network.
2. Attack Timeline
The reported timeline shows overlapping activity across institutions. By itself, that overlap does not establish a common operator.
On October 6, News1 published a reconstruction based on incident reports obtained by a National Assembly member. MBC also reported specific Shinhan timestamps from a bank report obtained through a lawmaker. The reported activity overlapped across several major banks, while the institutions recognized and contained the incidents at different times. [6, 17]
| Date and time (KST) | Reported activity |
|---|---|
| September 27, 23:19 | Suspicious access begins against KB Kookmin Bank’s employee support systems |
| September 28, 18:04 | Suspicious access begins against Shinhan Bank’s M-Shinhan service |
| September 28, 19:11 | Concentrated requests begin against six Shinhan inquiry services |
| September 29, 09:30 | Shinhan identifies suspicious activity and begins blocking source IPs |
| September 29, 13:43 | Shinhan suspends the targeted M-Shinhan service |
| September 29, approximately 18:00 | The reported attack period against KB ends |
| September 29, 19:03 | Shinhan recognizes that customer information has been exposed |
| September 30, 00:15 | Shinhan completes additional IP blocking |
| September 30, 12:16 | Suspicious activity begins against Hana’s ODS |
| September 30, 19:00 | KB recognizes its incident |
| September 30, 22:52 | The reported attack period against Hana ends |
| October 2 | Hana publicly confirms the information breach |
Sources: News1’s reconstruction of bank incident reports [6] and MBC’s reporting on Shinhan’s incident report [17]. These timestamps come from reporting about nonpublic institutional records, not independently obtained network logs.
The reported attack periods against KB and Shinhan overlapped. Hana became another target while the earlier incidents were still being investigated.
This does not prove that a single operator was simultaneously directing every attack. The extent of common control and the division of labor between people and software remain unresolved. Nevertheless, the temporal distribution is consistent with activity directed at multiple organizations rather than an operation wholly concentrated on establishing deep control inside one institution.
2.1 What happened at Shinhan
Shinhan provides the clearest publicly reported sequence of actions.
MBC’s account of Shinhan’s incident report says access began against M-Shinhan on September 28. The attackers tried random customer numbers and then concentrated requests on six services, including loan-application results. That account does not establish which authentication or authorization check was defeated. [17]
An earlier Yonhap report supplied important context about the business system itself. M-Shinhan allowed loan brokers to check the processing status of applications they handled. The report described a website-based environment accessible through broker credentials, and identified loan consultation information entered by brokers as the exposed data. Credential stuffing was discussed as a suspected access method, not an established final forensic conclusion. [2]
These accounts describe different parts of the activity: a broker-facing service and repeated inquiries that reached customer information. Neither report is sufficient to reconstruct the initial access or the complete authentication and authorization logic.
The distinction is important. Compromising a broker account would explain how an external actor might obtain an authenticated session. It would not, by itself, establish whether the attacker could retrieve only that broker’s assigned applications, whether object-level authorization failed, or whether some other vulnerability permitted access beyond the intended scope.
Shinhan recognized the suspicious activity approximately fifteen hours after the first reported access. It began blocking source IP addresses, but MBC reports that the attacks continued. The bank suspended M-Shinhan at 13:43 on September 29, recognized the information exposure at 19:03, and completed its final IP block at 00:15 on September 30. [17]
The result illustrates a limitation of treating the visible source address as the whole attack. IP blocking can interrupt a particular communication path, but it does not necessarily remove the weakness in the exposed business function or prevent an operator from attempting the same objective through another route.
2.2 What the other banks add to the timeline
KB’s reported attack period lasted approximately 42 hours and 41 minutes. Its recognition of the incident came after the reported activity had ended. Hana’s ODS was attacked for approximately ten and a half hours, while the disclosure and investigation continued afterward.
These figures should not be interpreted as a comparable ranking of detection capabilities, since the banks’ definitions of incident recognition and their available evidence differ.
They do, however, reveal an operational problem. Multiple institutions were investigating incidents within their own systems while suspicious activity appeared across the financial sector.
By October 6, Yonhap reported that South Korea’s Financial Supervisory Service had identified 28 IP addresses associated with the broader attacks, distributed across twelve countries, and that threat information was being shared with financial institutions. [7]
This produced two different scopes of activity. Each bank had to determine what happened in its own environment, which accounts or services were involved, and which data had been exposed. Financial authorities had to reconstruct patterns across institutions and distribute indicators rapidly enough to prevent further compromises.
The attackers, meanwhile, could move between visible interfaces without respecting the organizational boundaries that governed those investigations.
That asymmetry is the starting point for understanding the strategy.
3. How Financial IT Created the Opportunity
The interfaces attacked in September were not simply abandoned components that banks could remove without consequence. Many existed because financial institutions had deliberately extended their operations beyond conventional branches and internal networks.
Understanding that history is essential. An attack surface is not merely the collection of exposed servers. It is the technical expression of the business relationships an institution has chosen, or has been required, to support.
3.1 Loan brokerage became a major distribution system
South Korean banks use loan brokers to support mortgage distribution and other lending activities. Brokers may receive applications, explain products, collect documents, and communicate with customers while banks retain responsibility for underwriting and other regulated functions.
The arrangement has an established institutional history. Regulatory guidance for loan brokers was introduced in 2010, and oversight moved to a statutory framework under the Financial Consumer Protection Act in 2021.
By the end of that year, 10,143 loan brokers were registered, according to the Financial Services Commission. The same announcement identified more than 31,000 registered leasing and installment-finance intermediaries. The Commission emphasized that financial companies had to maintain internal controls covering delegated duties, broker conduct, and the protection of consumer information. [8]
This created a fundamental operational requirement: people outside the bank needed information about work being performed inside it.
A broker handling a mortgage application may need to know whether documents have been received, whether an application is under review, and whether a decision has been reached. A lender that relies heavily on brokers cannot treat these requests as exceptional administrative events.
At Shinhan, the channel was commercially significant. A July 2026 report described broker-mediated applications as accounting for approximately half of the bank’s household loan applications, and reported that Shinhan was managing the volume through monthly application limits. On September 17, the bank allocated an additional KRW 500 billion in mortgage application capacity to its broker channel. [9]
There is no public evidence that this particular allocation caused the subsequent breach, or that the affected service was specifically modified to support it. The significance of the material is different: broker access was part of a substantial and actively managed business operation, not merely a neglected auxiliary feature.
The bank had a legitimate reason to provide brokers with information. It also had to ensure that the information accessible through this channel was limited to what each broker was entitled to receive.
Those requirements are not equivalent.
3.2 Reconstructing the exposed business interfaces
The reports identify four different interfaces, their intended users, and the information exposed. They do not publish the banks’ application diagrams or request logs. Figure 1 therefore maps documented business functions and reported exposure, while leaving the incident-time route to the underlying records unresolved. The four rows are separate systems, not one shared network or a proven sequence chosen by one attacker. [2][3][4][5][15]
At Shinhan, brokers used credentials for the M-Shinhan mobile service to check the progress of their own loan applications. Reporting also identifies six broker-facing inquiry pages affected in the incident. It does not establish whether M-Shinhan and all six pages shared a session, backend, or record store. The bank described credential compromise and suspected credential stuffing; the exact initial-access method and the route from an authenticated inquiry to another customer’s record remain unconfirmed. [2][15]
At KB, RM Agent supported employees serving corporate customers and PB Agent supported those serving individual customers. Both were mobile employee support systems, and the reported attack exposed information about customers and employees. The public reports do not show how the external actor entered either system, what service identity it acquired, or whether the returned records came from a local store or a separate internal service. [3][15]
At Hana, the affected ODS supported staff working outside branches, with field devices connected to a business-support system. The bank reported exposure of 89 customers’ personal information and said its consumer internet and mobile banking systems were separate. The available reports do not show where the affected records were stored, which service fetched them, or where access was checked. [4][15]
Hyundai Capital presents a different boundary: a publicly reachable mortgage-broker verification page was intended to return public broker details, but also exposed internal identifiers and resident registration numbers. The company said its internal systems and customer records were not breached. The evidence establishes an excessive response from a public interface; it does not identify the page’s underlying database or projection code. [5]
These are the limits of reconstruction from public reporting. Request traces, service-to-service identities, endpoint code, record-source mappings, and broker-to-application assignment tables would distinguish a missing object-level check from an overbroad backend credential, a cached copy, or an overly broad response field selection. The reported outcomes establish the information boundary reached, not which of those internal mechanisms failed.
3.3 Delegating work does not automatically define data access
A financial institution can establish a contractual relationship with a broker without thereby defining every technical permission that the broker should receive.
A contract may authorize a broker to handle certain products, customers, or applications. The IT system must turn those business relationships into decisions about individual requests.
Consider the architecture implied by a loan-status inquiry.
The system receives an authenticated identity representing a broker or other authorized user. It also receives an identifier for the application whose status is requested. The backend must then determine whether the authenticated identity is entitled to access that particular application, and which fields may be returned.
Successful authentication identifies who is making the request.
It does not answer whether the requester is authorized to see the particular customer’s information.
A correct inquiry service therefore needs a relationship between the requesting identity, the broker’s current contractual or organizational status, the assigned application, and the information being returned. That relationship may also change over time as assignments move, contracts expire, or applications close.
In a large financial institution, the underlying information may be held across several systems. Broker registration, customer identity, application processing, and inquiry presentation may each have different owners or implementation histories.
The resulting challenge is not simply securing an HTTP endpoint. It is preserving the meaning of the business authorization across these systems.
Shinhan’s reported incident demonstrates why this matters. If an attacker can authenticate to an inquiry service and subsequently change the identifier of the requested application, the outcome depends on whether the system enforces the relationship between the user and that application.
The publicly available reporting does not show the exact failed check, if any, or establish that an object-level authorization flaw alone caused the breach. It does, however, identify the precise relationship that a technical reconstruction would need to examine.
The relevant question is not whether the user could log in. It is which records that login was supposed to authorize.
3.4 Outside sales and employee mobility created different routes to information
Loan brokerage was only one source of externally accessible business systems.
Hana’s ODS had a different operational purpose. Outside-sales systems allow employees to conduct work away from branches, including preparing electronic documents and connecting field activities to the bank’s internal processing environment.
South Korean financial institutions had been expanding electronic documentation and outside-sales capabilities for years before the incident. The broader industry history reflects pressure to reduce paper-based workflows and allow employees to complete customer-facing tasks beyond the branch. [10]
Contemporaneous reporting on Hana’s incident report classified the affected ODS as a demilitarized-zone, or DMZ, system. That describes the exposed network segment, not how the ODS obtained the customer records later disclosed. The bank described the affected channel as separate from ordinary internet and mobile banking. [4][16]
The public record does not identify the precise authorization defect or backend path exploited at Hana. Nonetheless, the reason such a path existed is clear: employees needed a way to perform banking work outside the traditional internal environment.
KB’s RM Agent and PB Agent presented a related but distinct case. These systems supported employee activities associated with customer and relationship management. They were not the main consumer transaction applications, but they handled information relevant to financial services.
The three banks therefore exposed different forms of legitimate business work: intermediary loan inquiries, employee relationship-management support, and outside-sales processing.
These systems did not have to share code, vendors, or vulnerabilities to offer attackers potentially valuable targets.
Their common property was that each provided a route through which a legitimate business role could request information associated with the financial institution.
3.5 The same business requirement did not produce the same architecture everywhere
The contrasting experiences of Woori Bank and NH NongHyup Bank are particularly useful because they demonstrate that financial institutions did not all implement external business access in the same way.
According to October 6 reporting, Woori allowed brokers to view relevant applications through designated tablet devices and required certificates and biometric authentication for access. The reported arrangement did not rely solely on an ordinary username and password.
NH NongHyup used a different operating model. Brokers did not receive equivalent access routes into the bank’s internal environment; applications were passed to branches, where employees continued the processing. The bank also maintained controls against repeated access attempts. [11]
Both institutions were reportedly targeted during the same period, but no comparable information disclosure had been confirmed as of October 6.
This does not prove that their particular architectural decisions caused the different outcomes. Attack intensity, targeted functions, and unobserved weaknesses were not held constant, and some investigations were still underway.
It does establish something narrower but important: similar financial business activities can be implemented through substantially different access arrangements.
One model exposes a broker-facing inquiry function. Another restricts its use to controlled devices with additional authentication. Another assigns more of the work to employees inside the institution.
Each arrangement imposes different operational costs and offers different external access opportunities.
The relevant difference is not simply whether an organization invested more in security. It is how the business process was translated into technical access.
ChosunBiz, citing 2025 information-protection disclosures, reported annual spending of KRW 36.9 billion and 97.8 dedicated security staff at Shinhan, compared with KRW 36.4 billion and 101 at Woori. It reported KRW 43.3 billion and 96.7 staff at KB, and KRW 37.2 billion and 71.9 at Hana. These reported totals measure institution-wide resources, not the quality of a particular inquiry service or access rule. The different incident outcomes cannot be attributed to spending or staffing from this comparison alone. [11]
The existence and reach of an externally accessible interface are architectural choices, even when the underlying business activity is unavoidable.
4. Why the Strategy Was Viable
The cases above reveal two distinct effects. Within each institution, more systems and owners make it harder to keep business permissions consistent. Across the sector, different institutions expose a wider variety of interfaces from which an attacker can choose.
Financial institutions develop and manage systems according to business purpose. An attacker seeking information can compare interfaces by reachability, the identity or authentication needed to use them, the information they might return, and the time and effort needed to investigate them.
The public record does not reveal the attacker’s actual comparison or the cost of testing each candidate. These are analytical criteria for explaining the opportunity, not a recovered target-selection plan.
4.1 Business boundaries are not the attacker’s boundaries
Within a bank, loan brokerage, relationship management, outside sales, and customer verification are separate activities. Their systems may be budgeted, designed, and operated by different teams, with different contractors and control procedures.
From the perspective of an attacker seeking information, all four can be candidates for the same investigation: can an externally reachable function return data that the requester should not receive?
This does not require the functions to contain the same vulnerability. It requires only that they offer information-bearing operations worth evaluating.
A broker inquiry might depend on authenticated access to assigned applications. An employee support application might rely on device identity and organizational role. A public verification page might deliberately accept unauthenticated requests but need strict limits on the fields returned.
The mechanisms differ, yet all three expose a relationship between a requesting party and information held by the institution.
An attacker can examine those relationships across organizations, whereas the defender must ensure that each one accurately reflects its own business obligations.
This is a more specific asymmetry than the familiar claim that defenders must protect everything while attackers need to find one weakness.
The defender’s responsibility is distributed across different business functions and ownership structures. The attacker’s selection process can unify those functions into a single set of potential information-access opportunities.
4.2 The cases illustrate different forms of exposure
The contrast between Shinhan and Hyundai Capital makes the distinction especially clear.
At Shinhan, the broker-facing environment was intended for a restricted class of users. Public reporting raised questions about compromised credentials, abnormal repeated inquiries, and attempts to expand access to customer information. The critical security issue lies in how an authenticated or otherwise accepted request was constrained to information legitimately available to that requester.
At Hyundai Capital, the initial access condition was different. The broker-verification page was deliberately public.
The exposed records reportedly contained both information meant for public verification—such as broker names, contact details, and registration numbers—and internal identifiers and resident registration numbers that were not meant to be public. Hyundai Capital stated that no access to its internal systems had been identified. [5]
The latter case shows that even a correctly public service can produce a security failure if the information returned exceeds its intended disclosure scope. It is a comparison case, not a proven additional operation by the ARTEX-associated actor.
These are not necessarily instances of the same code-level bug. One concerns a restricted business workflow and the relationship between an identity and customer records. The other concerns the fields an unrestricted verification function should disclose.
For an attacker, both can serve the same objective: obtain valuable information without first establishing control over the institution’s core systems.
This is why a cross-institutional strategy need not depend on finding a universal exploit. The attacker can choose among different weaknesses arising from different legitimate functions.
4.3 Selection changes the importance of any single defense
Selection starts with a question about access, not a presumption that every candidate is vulnerable. A public verification page is reachable without a broker or employee identity, but its intended output may be narrow. A broker portal may hold richer customer information, but require credentials and limit each user to assigned applications. An employee application may expose another useful dataset while imposing device or role restrictions. Woori’s reported device and authentication controls and NH NongHyup’s broker workflow further change what an external actor would have to obtain or overcome. [5, 11]
The attacker can then compare the potential value of the information with the work required to reach and examine it. A response that returns only intended public fields lowers the value of continuing on that path; a controlled device or unavailable identity raises its cost. An information-bearing function whose effective permissions appear broader than its business purpose would warrant closer examination. These are conditional choices, not findings about what the September operator actually saw or decided.
This process can repeat across services and institutions. A failed or costly investigation of one candidate does not require defeating that bank’s strongest controls before considering another. The attacker can stop, preserve what was learned, and spend effort where the combination of access, possible data value, and remaining work looks more favorable.
This does not guarantee success. Attempts may be detected, apparently promising services may enforce their permissions correctly, and the cost of examining candidates may exceed the value of any result. Nor does the overlapping attack timeline prove that one operator optimized a common queue of targets. It shows why a sector containing diverse information interfaces could support that strategy, while leaving the actual selection process unknown.
4.4 Organizational complexity can conceal technical responsibility
The creation of an interface is usually justified by the business function it supports. Its secure operation, however, may depend on several independent responsibilities.
A business department determines who needs the service. A contractor may implement the application. An identity-management system authenticates users. Another system holds customer records. A security team reviews the environment and monitors access.
The intended authorization boundary must survive all of these divisions.
An error does not necessarily require any party to have made an obviously irrational decision. A broker may legitimately need access, a service may legitimately need customer information, and an external application may legitimately be deployed to support the workflow.
The failure can emerge in how those legitimate requirements are connected.
For example, a backend service might correctly identify a broker without correctly checking that the requested application belongs to that broker. A public-facing service might correctly identify a registered intermediary while returning fields intended only for internal administration.
These are illustrative failure modes, not confirmed diagnoses of the affected banks.
They explain why the relevant unit of analysis is the complete relationship between an external principal, the business operation, the protected data, and the authority permitting access.
The institution-wide spending and staffing figures in section 3.5 likewise cannot establish whether any one of these relationships was implemented correctly.
The October 2026 response from South Korea’s Financial Services Commission makes this point unusually explicit.
At an October 4 meeting, described in an October 6 release, the Commission instructed financial institutions to identify externally exposed assets and services, including systems accessed by employees and other personnel for business purposes. It required that external access be restricted unless essential, and that both permissions and accessible information be limited to what was necessary. It specifically identified systems used by loan brokers, contractors, and employees as requiring scrutiny of personal credit information and authentication routes. [12]
This was not merely a request to block a list of hostile IP addresses. It was a demand to reconsider the relationships between business access and information access across the financial sector.
The defensive unit identified by the regulator was no longer just the server or network segment. It was the complete set of externally accessible business functions and the information each could expose.
That is also the level at which the attack strategy becomes intelligible.
5. What ARTEX Changes
The strategy described above does not depend on artificial intelligence.
Attackers have long used automation to enumerate services, test credentials, submit repetitive requests, and extract information from poorly controlled interfaces. None of those operations requires a language model merely to execute.
The more consequential question is what happens before and between those operations: how an attacker discovers a relevant service, interprets its business purpose, identifies promising directions, preserves observations, and decides what to investigate next.
This is where ARTEX becomes relevant.
5.1 The attacker infrastructure found by CrowdStrike
CrowdStrike’s October 7 report described an attacker-controlled environment containing ARTEX configuration files, Claude Code session histories, and Claude memory files.
Its analysis identified two principal servers: a Hong Kong-based host associated with the operator’s primary environment and another host running ARTEX. DeepSeek v4.1-flash served as the main ARTEX language-model backend, while other Claude Code sessions used GLM-5.3 and Grok 4.6. The operator also used multiple proxy addresses. [1]
The recovered material established more than the presence of an AI product on a server. CrowdStrike found evidence of actual operational use in activities targeting South Korean financial organizations. The sessions also included queries about where Korean breach data might be sold, supporting an assessment of financial motivation without proving that any transaction occurred.
The report did not publish a complete mapping from individual bank requests to specific ARTEX planning decisions, model outputs, or worker executions.
Consequently, the presence of ARTEX cannot by itself answer whether the model discovered a vulnerability, chose a target, generated a particular request, or merely supported operations directed by a human.
That limitation is fundamental to evaluating the role of AI in the incident.
5.2 ARTEX separates assets from the history of exploration
A pinned ARTEX source tree whose changelog dates version 0.3.15 to October 7 provides a useful view of the system’s design. It implements a Go backend, agent orchestration, a PostgreSQL-backed state model, and a distinction between an Asset Graph and an Exploration Graph. [13]
The Asset Graph represents domains, IP addresses, applications, services, and endpoints and assigns those assets to companies.
The Exploration Graph represents the progression of an investigation. Its nodes include goals, intents, facts, findings, and hints, connected through relationships that record how an investigation developed.
The distinction matters because discovering an endpoint is not the same as deciding what to investigate about it.
An asset record can establish that a service exists. An exploration record can indicate that a particular question about the service has been examined, that a result was observed, and that the result supports or motivates another direction.
ARTEX uses a Planner to examine exploration state and issue new intents. Workers claim those intents, execute tools, and write observations back into the persistent state. Changes to that state can trigger further planning.
The archived implementation also includes mechanisms for workers to inspect other workers’ execution histories, including observations that were not formally promoted into facts.
This design reduces the dependence of an investigation on the context of a single LLM call. Information can persist after a worker finishes, and future work can be informed by what has already been attempted.
But there are important limits.
The changelog dates version 0.3.15 after the principal September attacks. Its complete feature set cannot automatically be projected backward onto the version used by the attacker. In addition, the asset data and exploration histories have different sharing scopes, so the existence of a global asset store does not demonstrate that attack knowledge was automatically transferred between all targets.
The source proves an architectural capability, not the exact sequence of decisions made during the breaches.
5.3 The economic importance is in choosing the next investigation
For a cross-institutional attacker, the difficult part is not necessarily sending a large number of requests.
It is deciding which services are worth examining, interpreting their responses, determining whether an observation justifies another test, and preserving that knowledge while moving among targets.
Conventional scanners, asset inventories, and case-management tools can already retain targets, observations, and work queues. Persistence alone does not explain an AI-specific reduction in effort. The unmeasured proposition here is whether ARTEX’s Planner could interpret saved observations and select a useful next investigation with less human triage.
ARTEX attempts to join those processes. Its Asset Graph can hold the candidate services and their relationships; its Exploration Graph can preserve what an investigation tried, observed, and still needs to establish. The Planner can propose another intent from that state, and Workers can execute it and return observations. The archived code demonstrates these components, not a numerical ranking of banks by expected payoff. [13]
Applied to the selection criteria in section 4, a planner could revisit recorded reachability, authentication conditions, and response behavior and propose another test without an operator manually comparing every candidate. That would require accurate interpretation: the system would have to distinguish a legitimate broker’s view of an assigned application from access to another customer’s record, or public verification fields from internal identifiers.
If those functions reduce the human work of documenting and revisiting heterogeneous services, more candidates could be examined for a given effort. That is the specific economic change at issue; ARTEX’s architecture does not show how much work it saved in this campaign.
CrowdStrike did not provide the number of candidates ARTEX evaluated, the cost of the model calls, the duration of human involvement, or a comparison against equivalent non-AI operations. There is insufficient evidence to quantify a reduction in attack costs or to conclude that autonomous planning caused the observed compromises.
The more defensible finding is that the operator used a system expressly designed to manage persistent exploration, during a period in which attacks were reported against multiple financial institutions.
That combination makes the potential economic effect concrete enough to investigate, without establishing its magnitude.
5.4 The two sides of complexity
Internal complexity creates authorization relationships that must stay consistent within each institution; sector-wide diversity presents an attacker with different interfaces to compare. The reported cases show that variety, but do not establish that organizational complexity caused a specific failure or that ARTEX reduced the search cost.
6. Conclusion
The reported incidents involved interfaces built for loan brokerage, employee support, outside sales, and intermediary verification. Their different access conditions are central to explaining the reported information exposure, while compromise of core transaction systems has not been demonstrated.
Shinhan’s inquiry functions and Hyundai Capital’s public verification page illustrate distinct information-access boundaries; Woori and NH NongHyup show that comparable business needs can be implemented with different external access conditions. The available evidence does not prove a common vulnerability or a single operator’s target-ranking process.
ARTEX connects asset records, investigation history, planning, and tool execution. It could reduce the work of comparing and revisiting heterogeneous interfaces, but the recovered material does not quantify that effect or establish autonomous selection in the September incidents.
For a defender, the complexity of a large IT system is a set of obligations that must remain consistent. For an attacker, the same complexity is a set of alternatives from which to choose. Here, the first arises within each institution’s business and authorization architecture; the second arises from the variety of interfaces across the sector. The attacks show why both matter even while the operator’s actual decisions remain unknown.
References
Incident reporting and attacker infrastructure
[1] CrowdStrike Intelligence. Unknown Threat Actor Uses AI-Driven ARTEX to Target South Korean Finance. October 7, 2026. Attacker infrastructure, recovered Claude Code sessions, ARTEX configuration, LLM backends, and attribution limits.
[2] Yonhap News Agency. Shinhan Bank’s Loan Customer Information Exposed Through Website-Based Inquiry Service. October 1, 2026. Broker-facing M-Shinhan service, loan consultation records, reported authentication conditions, and suspected credential abuse.
[3] MBC News. KB Kookmin Bank Incident and the Exposure of Customer and Employee Information. October 2026. Reported information exposure and employee support systems.
[4] Yonhap News Agency. Hana Bank Reports Personal Information Breach Affecting 89 Customers. October 2, 2026. ODS intrusion, exposed information categories, and separation from the bank’s consumer transaction systems.
[5] MoneyToday. Hyundai Capital Reports Exposure of Information on 146 Mortgage Brokers. October 3, 2026. Public broker-verification page and exposure of internal identifiers.
[6] News1. Eight Countries’ IP Addresses Used in Attacks on South Korean Banks. October 6, 2026. Reconstruction of attack and response timelines based on bank reports provided to a National Assembly member.
[7] Yonhap News Agency. 28 IP Addresses Behind Recent Attacks on Korean Financial Institutions. October 6, 2026. Financial Supervisory Service threat indicators and cross-sector coordination.
[17] MBC News. Shinhan Bank Attack Began on September 28 and Continued Overnight. October 2, 2026. Shinhan incident-report chronology, randomized customer-number attempts, concentrated inquiries, response times, and recognition of information exposure.
Business history and financial IT architecture
[8] Financial Services Commission. Registration and Supervision of Loan Brokers Under the Financial Consumer Protection Act. January 3, 2022. Broker registrations, delegated duties, contractual controls, and consumer information protection obligations.
[9] Seoul Economic Daily. Shinhan Bank Halts July Broker-Channel Loans Early. July 7, 2026. Reported share of household-loan applications and monthly broker-channel limits. Yonhap News Agency. Shinhan Bank Allocates KRW 500 Billion in Additional Mortgage Capacity to Broker Channel. September 17, 2026. Additional mortgage capacity for the broker channel.
[10] Electronic Times. Digitization of Outside-Sales Workflows in South Korean Financial Institutions. June 8, 2020. Historical context for electronic documentation and outside-sales systems.
[11] ChosunBiz. Basic Controls Stop Korea Bank Hacks as AI Attacks Expose Gaps at Others. October 6, 2026. Reported access arrangements at Woori and NH NongHyup and contrasts with affected institutions.
[15] NewsPim. Employee and Broker Systems Targeted as Banks Expand Field Operations. October 8, 2026. RM Agent and PB Agent roles, Hana field-device connection, and six Shinhan broker inquiry pages.
[16] NoCutNews. AI-Driven Indiscriminate Hacking Attempts Put Financial Sector on Alert. October 6, 2026. Reporting on Hana’s incident report classifying the affected ODS as a DMZ-zone system.
Regulatory response
[12] Financial Services Commission. Emergency Financial-Sector Security Inspection Meeting. October 6, 2026. External IT assets, authentication routes, access restrictions, broker and contractor systems, and limits on accessible personal credit information.
[14] Financial Services Commission. Emergency Response Meeting on Financial-Sector Cyber Incidents. October 2, 2026. Identification of externally exposed services and sector-wide security reviews.
ARTEX implementation
[13] Hinln. ARTEX Source Archive, pinned revision f3e3f54. The changelog dates ARTEX v0.3.15 to October 7, 2026.
Relevant implementation files:
- README.md — System Architecture, raw text
- agent/planner.go — Planning and Exploration State
- agent/tools.go — Exploration Graph Operations
- agent/tools_insert.go — Asset Registration and Management
- server/engine.go — Planner and Worker Execution Lifecycle
- CHANGELOG.md — Version History, raw text
Evidentiary scope
This analysis uses public disclosures, regulatory statements, reporting based on nonpublic bank incident reports, CrowdStrike’s infrastructure investigation, and an archived ARTEX source tree available as of October 12, 2026.
The underlying bank network logs, complete internal incident reports, affected application source code, and the full attacker session histories were not available for independent examination.
Reported technical behavior is therefore distinguished from architectural reconstruction. The proposed cross-institutional strategy explains why the observed targeting pattern could have been effective; it does not establish the attacker’s actual internal optimization process. The archived ARTEX implementation demonstrates capabilities for persistent exploration but does not prove that each capability was used in September or that ARTEX autonomously conducted every intrusion.