[Contributed Article] Rethinking the Side Door to Financial Security

이용 위드네트웍스 프로덕트 총괄 상무 이사

In the era of AI-driven attacks, financial security starts with knowing which assets are exposed and which risks remain unresolved.

A data breach at a credit card company revealed that a vulnerability had gone unpatched even though a security patch had been available since 2017, alongside gaps in multiple security controls. In a series of attacks targeting the financial sector in 2026, external business access points used by loan agents and employees were again identified as attack paths.

Investigations are still underway to determine how extensively artificial intelligence (AI) was used in these attacks. But the questions financial security teams must answer are clear: Have all externally exposed assets been identified? Do they know which unresolved risks remain on those assets, and are they taking action to address them?

In October 2025, the government announced comprehensive information security measures covering more than 1,600 IT systems across the public, financial, and telecommunications sectors, including 261 in the financial sector. It also pledged to establish a continuous vulnerability assessment framework using penetration testing and ethical hackers. These measures followed a series of major hacking incidents involving telecommunications companies and credit card issuers.

Approximately one year later, in late September 2026, another wave of breaches struck the financial sector. Data leaks were confirmed at nine financial companies, including banks, savings banks, capital finance companies, and online investment-linked finance providers, according to reports published as of October 7.

The Financial Supervisory Service identified 28 IP addresses associated with hacking attempts, excluding duplicates. Financial regulators sent an urgent inspection checklist to approximately 500 financial companies, while the Ministry of Science and ICT recommended security inspections for approximately 28,000 organizations registered as having a chief information security officer (CISO).

Although another round of extensive inspections has begun, a fundamental question remains: Why do breaches through external business access points continue to occur in a financial sector that has undergone inspections, certification, and regulatory oversight?

Part of the answer lies in access points that were either invisible or visible but left unaddressed. Attackers focus first on where they can gain entry, rather than on how important a system is to the business. AI is reducing the time and cost required to identify and repeatedly test such opportunities.

Attacks Began at the Side Door, Not the Core Network

The attack paths identified in the recent wave of financial-sector breaches did not involve core customer transaction networks such as internet or mobile banking.

Instead, the identified entry points included services that allow loan agents to check customers’ loan application status, mobile business-support systems for employees, sales-support systems, and web pages with inadequate session validation. Systems that permitted external access for operational convenience became major targets.

The following are five cases involving external business access points identified in incidents disclosed or reported by October 7, 2026.

According to media reports citing an incident report submitted to the National Assembly, an attacker targeting Bank A attempted to bypass mobile-phone authentication by repeatedly entering random values, such as customer numbers. The attacker then focused on six lookup functions, including those used to retrieve loan application results.

If an attacker can access other customers’ information after passing or bypassing the initial authentication step, the issue is not simply whether authentication exists. The critical question is whether authorization to access the requested information is verified for every individual lookup request.

At an emergency inspection meeting on October 4, Financial Services Commission Chairman Lee Eog-won also pointed out that relatively poorly managed areas—such as external web pages and servers used by loan agents and employees for operational convenience—had been exploited. He called for comprehensive checks of externally exposed IT assets, authentication and access controls, and intrusion detection systems.

Application programming interfaces (APIs) were behind many of these external business access points. One analysis suggests that some business systems originally intended for internal networks exposed selected functions externally through APIs without sufficiently strengthening authentication and access controls, allowing attackers to discover and exploit those interfaces.

Security teams may also be unaware of every system and its configuration when business units add external access points to meet operational needs. One domestic security services company described the targets in the recent attacks as “shadow IT”—systems, services, and APIs missing from official asset inventories or inadequately managed because they had been assigned a low inspection priority. At a September seminar, the Financial Security Institute also warned that APIs were emerging as major targets for AI-agent attacks and called for stronger API security management, including checks for exposed security keys.

APIs absent from an inventory are easily excluded from inspections. Even when listed, they remain an unresolved risk if access permissions are not verified with every call. A system does not become unimportant simply because it is not part of the core transaction network. The data leaked in the recent incidents included not only names and contact details but also annual income, loan limits, and, in some cases, portions of resident registration numbers. This was one reason financial regulators strengthened monitoring through the Financial Fraud Detection System (FDS) during a month-long special response period for secondary harm from personal data leaks, beginning October 6.

A system’s business importance and the sensitivity of its data are two different measures. If sensitive information can be retrieved through an external business interface, authentication, access permissions, and intrusion detection must be assessed just as rigorously as they are for customer-facing channels. A security company experienced in financial-sector penetration testing also recommended in a white paper analyzing the incidents that inspection scope should be based on the systems and paths an attacker could actually reach.

The time required to detect attacks and share information also deserves attention. Reports citing an incident report submitted to the National Assembly stated that Bank A took approximately 15 hours to detect activity after the first abnormal access and around 30 hours to block the final attacking IP address. According to reports citing an incident report obtained by Representative Park Min-gyu’s office, Bank B did not identify an incident until approximately 68 hours after the initial attack—about 25 hours after the attack had stopped. A report citing a Financial Security Institute official said that after attack IP addresses identified during the first reporting institution’s investigation were shared with the financial sector, other companies examined their access logs and discovered additional compromises.

There had also been prior warnings. According to reports citing National Assembly submissions and Financial Supervisory Service advisories, on September 4 the regulator warned of an increase in attacks targeting externally exposed systems and called for checks on devices missing security updates and the removal of unnecessary services, ports, and APIs. On September 30, it circulated attacker IP addresses and described the suspected attack method as “automated attacks believed to involve AI agents.”

From late August through September 30, the Financial Security Institute shared indicators of compromise with the financial sector on six occasions. Some financial companies successfully blocked attacks quickly during the same period, so the existence of warnings alone cannot establish the cause of each incident. Nevertheless, every financial company should be able to explain how shared threat intelligence led to inspections, remediation, and revalidation of its assets.

Questions Raised by the 2025 Credit Card Company Breach

A data breach at a credit card company in 2025 illustrates these structural problems even more clearly. According to enforcement documents from the Financial Supervisory Service, the company failed to apply a critical Oracle WebLogic security patch, CVE-2017-10271, released in October 2017 for its online payment server. The Financial Security Institute had recommended that all financial companies apply the patch on three occasions between 2018 and 2024.

However, the company’s overseas payment web service had not been registered with its web application firewall and was therefore excluded from intrusion detection and prevention. Antivirus software was also absent from the server. Approximately 2.97 million people’s credit information was exposed in the incident.

The inspection and reporting process is also significant. The enforcement documents identified problems including a self-assessment score of 100 despite the fact that the online payment system’s security measures had not actually been inspected, as well as security deficiencies reported to management that remained unresolved. During the 2025 parliamentary audit, Representative Kim Nam-geun’s office also pointed out that the WebLogic asset had been omitted from the asset inventory and was therefore never included in the inspection scope.

On July 31, 2026, the Financial Services Commission imposed a 1.5-month partial business suspension and a fine of KRW 5 billion on the company. It was the first such action in a case involving data leakage caused by hacking.

The lesson is clear: assets missing from an inventory can escape inspection. Even assets that are listed can become attack paths if the necessary security measures are not implemented.

What Inspections of Listed Assets Miss

Vulnerability assessments, certification audits, and internal self-assessments are generally conducted on assets that an organization has identified and submitted for review.

This approach has two limitations. First, systems missing from the asset inventory may also be excluded from inspection. Second, even listed assets can create a gap between assessment results and reality if the actual operation of security controls and the status of vulnerability remediation are not verified.

The credit card company’s self-assessment score of 100 despite the absence of an actual inspection illustrates the second problem. Kim Seung-joo, a professor at Korea University’s Graduate School of Information Security, commented on the incidents: “If you don’t know what you have, you can’t inspect it properly.”

When inspection scope is based solely on an organization’s submitted asset inventory, servers and external business access points omitted from that list can be overlooked. An independent discovery process is therefore needed to verify that the inventory is complete.

Financial companies must distinguish between two questions. The first is: “Do the assets we inspected contain known vulnerabilities?” The second is: “Which assets have not been inspected, and are the security controls on inspected assets actually working?”

The first question concerns vulnerability management; the second concerns asset identification and external exposure management. If the second question cannot be answered, the results of the first are difficult to trust. Both questions must ultimately lead to concrete remediation.

A discovered vulnerability left unresolved without an assigned owner or remediation deadline is itself an unaddressed risk. Meanwhile, IT environments are constantly changing. New web services and APIs are created, and the access points, accounts, and permissions used by loan agents and outsourced personnel change. The adoption of AI and software-as-a-service (SaaS) is also increasing as network-segmentation regulations are relaxed. If these changes are not identified in time, new security gaps can emerge between periodic inspections.

According to the white paper mentioned earlier, more than 30 financial-sector penetration tests conducted over the past three years repeatedly uncovered flaws in identity and authorization verification. Such flaws were more often caused by missed validation during operational changes or maintenance than during initial development.

Periodic inspections and certification remain necessary. However, they cannot, by themselves, keep pace with all the changes that accumulate between inspections.

AI Is Accelerating Attack Discovery and Repeated Testing

AI has attracted considerable attention in the recent series of financial-sector breaches. Strings associated with ARTEX, an open-source autonomous penetration-testing tool developed in the Chinese-speaking community and publicly available at the time, were found on a server believed to have been used in the attacks. A Financial Security Institute official said that tracing attack logs and IP addresses revealed signs that the hackers had used the AI tool. On October 4, Financial Services Commission Chairman Lee Eog-won also said that the possibility of hacking attacks using AI could not be ruled out.

Subsequent threat intelligence analyses provided more detail. In a report published on October 7, CrowdStrike said that an analysis of exposed AI task records and configuration files on an attacker’s server indicated that the attacker had used ARTEX alongside a separate AI coding session. DeepSeek was identified as the main language model used by ARTEX.

The attacker separated the primary attack server from the server running ARTEX and routed activity through nine proxy IP addresses. CrowdStrike assessed, with moderate confidence, that financial gain was the likely motive. It also described the incident as an example of how AI tools can enable attacks against multiple organizations within a short period.

A domestic threat intelligence company also found evidence that an ARTEX management interface and an AI model relay program had been running together on one of the attack IP addresses shared by financial regulators. However, the company noted that further investigation was needed to determine whether AI had actually been used in the data-exfiltration stage.

The distinction between what is technically possible and what has been confirmed in an actual incident is important. Evidence that AI tools assisted attackers in reconnaissance and vulnerability testing does not prove that AI autonomously carried out every stage of the personal data theft. Separately from this series of breaches, the head of the Financial Security Institute’s Financial AI Security Research Center presented a case involving AI-agent attacks targeting domestic financial companies at an event in September.

In that case, an attacker used a DeepSeek-based agent to scan for WebLogic assets and targeted approximately 300 financial companies in Korea and overseas. Web shells were installed on some systems to explore internal assets. The attack involved human instructions at each stage and was detected and blocked when the attacker attempted to download additional malware.

This demonstrates that older middleware assets, such as the WebLogic software implicated in the 2025 credit card company breach, remain targets for large-scale automated scanning. In a reproduction experiment conducted by Soongsil University’s AI Safety Research Center, publicly available language models and ARTEX identified missing authentication and object-level authorization flaws in an intentionally vulnerable simulated banking service in approximately six minutes without human intervention.

However, this result came from a controlled experimental environment and does not measure the defensive capabilities of actual financial companies. Blocking a single attack tool would not solve the underlying problem either. On October 8, ARTEX’s developer announced that public distribution and updates would be discontinued and the project moved to private status due to the risk of misuse.

That decision cannot remove copies that have already been distributed. There are also reasons to be cautious about attributing attacks to AI. The recent attacks could have been carried out with conventional automation tools, and some argue that poor vulnerability management in financial companies’ auxiliary systems—not the use of AI itself—is the fundamental issue.

Kim Seung-joo of Korea University also emphasized that some of the financial-sector incidents discussed alongside these attacks were unrelated to ARTEX or AI, and that each incident should be evaluated separately.

These observations make the core challenge for financial security even clearer.

The key change in attacks against external business access points is the speed at which attackers can discover vulnerable systems and repeatedly test them. Attackers exploit gaps in validation between scheduled inspections through automated, repeated attempts.

Managing the risks of AI agents deployed internally by organizations and the systems connected to them is a separate challenge. This article focuses on what financial companies should identify and manage first when external attackers use AI.

Financial Regulators’ Security Management Standards Are Changing

Financial regulators have already outlined a response to these changes. In July 2026, the Financial Services Commission distributed its *Guidelines for Responding to Frontier AI Security Threats in the Financial Sector*. It emphasized that because AI can rapidly explore a financial company’s attack surface, accurately identifying and managing IT resources and supply chains is essential.

The guidelines recommend identifying all assets—including systems, applications, APIs, cloud resources, open-source software, and outsourced service providers—and classifying them according to internet exposure, business criticality, data sensitivity, and patch status.

The approach to patch management is also changing. Rather than focusing solely on “eliminating vulnerabilities,” the guidelines propose shifting the emphasis to “reducing the likelihood of a successful attack.” High-risk vulnerabilities should be managed on a daily basis, while systems awaiting patches should receive compensating controls, such as temporary network isolation or service restrictions.

The authorities have also introduced exemptions for minor disruptions that occur when applying patches addressing vulnerabilities they have formally communicated. This is intended to ease concerns in the field about who bears responsibility if a patch causes an operational disruption. However, the guidelines themselves are recommendations, and legal liability and penalties for leaking personal credit information remain separate matters.

The broader policy direction is one of “autonomous security and accountability for outcomes.” The Financial Services Commission introduced this principle in its August 2024 roadmap for improving network-segmentation rules. In February 2025, it revised the Electronic Financial Supervision Regulations, reducing the number of detailed conduct rules from 293 to 166. The goal is to let financial companies assess their own risks and select appropriate security measures while remaining accountable for the results.

Autonomous security, however, requires objective evidence. It is difficult to make self-directed security work in practice if an organization cannot even explain what assets it owns or which of them are exposed externally.

Following the recent incidents, regulators have also begun to clarify their inspection plans. The Financial Services Commission said it would promptly announce measures to shorten vulnerability assessment cycles, expand inspection scope, and strengthen the implementation of remediation. These plans reflect concerns that financial companies have had too much discretion in deciding which assets to include in assessments.

During a parliamentary audit on October 8, Financial Services Commission Chairman Lee Eog-won said, “Our response has been extremely inadequate, even in very basic areas.” He also remarked, “To stop AI, we ultimately have to use AI.”

Although the additional measures have yet to be announced, the direction suggests that regulators intend to verify both the scope of assets being inspected and whether vulnerability remediation is actually completed.

Financial regulations overseas are moving in a similar direction. Article 8 of the European Union’s Digital Operational Resilience Act (DORA) requires financial entities to identify, classify, and document their information and communication technology (ICT) assets and update their inventories whenever significant changes occur. Article 10 of Delegated Regulation (EU) 2024/1774 requires automated vulnerability scans at least weekly for ICT assets supporting critical or important functions.

These requirements do not directly apply to Korean financial companies. Nevertheless, they show that regulatory attention is expanding beyond whether inspections have been conducted to how accurately organizations identify and explain their assets and risks.

Continuous Exposure Management Must Complement Periodic Inspections

The answer for financial security is not to eliminate periodic inspections. It is to continuously track changes that occur between inspections and ensure that externally exposed assets and unresolved risks lead to actual remediation. This requires a repeatable management process spanning discovery, validation, remediation, and proof of completion.

The key question is not “How many systems have been inspected?” but “How quickly can risks be discovered and verified, and remediation be demonstrated?”

1. Continuously Discover Every Externally Accessible Entry Point

Inspections must cover not only customer-facing channels but also access points used by employees, loan agents, outsourced personnel, and business partners. These include discontinued or neglected web services, development and test servers, APIs, virtual private networks (VPNs), management interfaces, and legacy middleware.

Organizations should not rely on a single asset register. They need to cross-check domain name system (DNS) records, digital certificates, cloud accounts, deployment records, web application firewalls, API gateways, account-management records, and outsourcing contracts to identify missing assets.

APIs should also be maintained in an inventory linked to existing asset information. Records should specify which internal systems and data each externally callable API connects to, who is responsible for it, and when it should be retired.

The Open Worldwide Application Security Project (OWASP) lists improper inventory management among the top 10 API security risks. In practice, API inventory creation and retirement planning can be postponed because of separate budget requirements, and individual APIs may lack designated owners after operational handover.

Decommissioning a system must involve more than shutting down its server. Related domains, accounts, authentication tokens, API keys, and business-partner access permissions must also be removed. Organizations should verify which internal assets can be reached from outside and whether access policies grant more permissions than necessary.

Financial regulators’ emergency inspection checklist likewise called for disabling unnecessary services and ports on externally exposed systems and strengthening access controls.

2. Link Security Control Status to Discovered Assets and Prioritize Risk

Software and version information for identified assets should be checked against Common Vulnerabilities and Exposures (CVE) identifiers and evidence of actual exploitation. Indicators of compromise shared by financial regulators and the Financial Security Institute should also be linked to the relevant assets so they lead to inspections and remediation.

Not every vulnerability can be identified by comparing software versions alone. Authentication bypasses and flaws in object-level authorization require separate authorization testing.

Risk prioritization must not rely on a single score. It should consider actual exploitation likelihood, external exposure, data sensitivity, and business impact together.

3. Verify Authentication and Authorization for Every Data Request

A user’s successful login does not mean they should have access to all information. Every API call should trigger a server-side check to confirm that the requester is authorized to access the specific customer’s information or data. Controls are also needed to detect and limit continuous or high-volume lookup requests.

External collaboration accounts should receive only the minimum permissions required for their tasks, and those permissions should be revoked as soon as the work is complete.

It is also important to reduce the potential impact of an intrusion by applying measures such as multifactor authentication, least-privilege access, and network segmentation, based on the assumption that an intrusion may occur.

The information made available through external interfaces should itself be minimized. At an emergency response meeting on October 2, the Financial Services Commission called for checks to identify internal information lookup paths with missing or inadequate authentication and to reduce unnecessary external exposure of information.

Designing systems to provide only the minimum information needed for a task can limit the scope of a data leak even if a breach occurs.

4. Validate Systems from the Attacker’s Perspective According to Risk

Continuous asset discovery, automated scanning, and periodic in-depth security validation should be operated as distinct but complementary activities. In-depth validation may include blind penetration testing and AI-based automated assessments conducted within a preapproved scope. Checking individual vulnerabilities alone can miss actual attack paths.

For example, an attacker might obtain a customer number from one lookup service and enter it into another function to retrieve additional information. Such a chained attack may be difficult to uncover by inspecting each system independently. Connections between functions and systems therefore need to be tested through attack scenarios.

Experts who understand financial operations and system architecture must also assess the actual risk indicated by AI-based testing results. For production systems, testing should include non-destructive validation, request-rate limits, clear stop conditions, and rollback procedures.

Blocking an attacker’s IP address is an emergency response, not a final solution. After blocking it, organizations must investigate historical access logs, abnormal processes, file modifications, and external communications to determine whether an intrusion has already occurred.

5. Prove Remediation Through Results, Not Recommendations

Each asset should have a designated business owner and technical contact, a remediation deadline, an exception approver, and an expiration date for any approved exception. Unresolved high-risk vulnerabilities and long-standing exceptions should be tracked so that executives and boards can review them. Patching should include predeployment testing, change approval, rollback plans, and compensating controls.

Management can use the following metrics to determine whether the security framework is working in practice:

• The proportion of externally observed entry points, including APIs, that are linked to the official asset inventory and have designated owners.

• The time from discovering a new entry point to registering it, applying security controls, and completing revalidation.

• Remediation times and overdue cases for externally exposed high-risk vulnerabilities and vulnerabilities known to be exploited.

• The proportion of shared indicators of compromise that lead to asset inspection, remediation, and revalidation, along with the time required.

• The scope and results of authorization checks for externally exposed systems that process personal credit information.

• The time from the first abnormal access to detection and blocking.

When a management framework is first introduced, the number of unidentified assets discovered may rise as systems that were previously unknown are brought to light.

This does not necessarily mean security management has deteriorated. It may instead indicate that risks that were previously invisible are finally being brought under management.

Trust in Financial Services Depends on Explaining Risks and Proving Remediation

In the 2026 wave of financial-sector breaches, external business access points and the APIs connected behind them were identified as attack paths. Enforcement documents related to the 2025 credit card company data breach also revealed an unapplied security patch and a self-assessment score reported without an actual inspection.

Further investigations are needed to establish the precise causes of the recent incidents and the extent to which AI was used. Nevertheless, both incidents raise the same questions.

Do financial companies know exactly which of their assets are exposed externally? Do they understand the unresolved risks affecting those assets? And are they turning the risks they discover into actual improvements? Answering these questions requires relevant information to be connected.

If externally exposed asset inventories, results from different assessment tools, shared threat intelligence, responsible personnel, remediation deadlines, approved exceptions, and revalidation results are scattered across separate registers and reports, it becomes difficult to quickly determine what is exposed and what remains unresolved.

That is why an integrated management framework is needed to connect asset and vulnerability information within a single operational workflow.

The key is not simply adopting a particular security tool. What matters is an operational structure that uses consistent asset information to prioritize risks, clearly assign remediation responsibilities and deadlines, and verify whether improvements have actually been made.

Trust in financial services cannot be maintained solely by a record showing that no incident occurred. It depends on the ability to continuously discover external business access points and explain their authentication controls, vulnerabilities, access permissions, and remediation status.

The criteria for security investment must also change—from “How many systems have been inspected?” to “How quickly can we discover externally exposed assets, reduce unresolved risks, and clearly demonstrate the results of remediation?”

When a new vulnerability is disclosed, financial companies should be able to answer one immediate question: “Which operational assets in our organization contain the affected component?”

In actual security operations, the discovery of externally exposed assets, identification of affected components, and management of systems connected to AI must all be integrated into a unified risk and remediation framework.

The core of financial security in the AI era is not simply passing inspections.

It is continuously discovering externally exposed assets and unresolved risks, ensuring they lead to actual remediation, and objectively demonstrating the results.

---

원문 보기

전자신문