ARTEX Financial Sector Hacking: How Prepared Were We?

The Story of Polestar SIEM's Response to Shadow IT and API Security

Even with requests that appear normal, questions remain that security monitoring must verify.

With traces of ARTEX being uncovered in recent serial security breaches across the financial sector, AI-automated attacks have emerged as a challenge for security monitoring operations. However, what defenders should pay attention to is not just the name of the tool. It is the fact that services neglected in security management—such as loan solicitor inquiries and employee business support—became gateways for data access.[1][2]

The server responds normally, and the login succeeds. But did the caller actually have the authorization to view that data? The fact that a service is functioning is entirely different from the fact that access is legitimate.

To narrow this gap, we have prepared external exposure observation, web and API log analysis, evidence-based judgment, and approval-based responses. Let us connect the lessons learned from recent incidents with the development history of Polestar SIEM.[4]

Rather than chasing the names of attack tools,
we connect the vulnerabilities that those tools can exploit.

The problem ARTEX revealed lay in "forgotten business services"

In public data compiled by Genians GSC, different cases are introduced: Shinhan Bank's loan solicitor lookup service, KB Kookmin Bank's mobile business support system for employees, and Hyundai Capital's solicitor inquiry page. While the services differ, the question remains: we must re-verify external touchpoint authentication, authorization, and monitoring scope.[3]

Figure 1. Three public analysis cases and the monitoring questions derived in this article. Dates indicate media publication dates, not the dates of the attacks.[3]

What AI changed is the speed at which it leads to the next attempt

According to the guide by SK shieldus, ARTEX connects functionality that breaks down goals, a Planner that decides the next action, and multiple Workers responsible for execution. Because results are fed back into subsequent decisions, reconnaissance, verification, and repeated queries can follow in rapid succession. This is why defenders cannot stop at merely checking alerts from individual IPs.[1]

CrowdStrike announced on October 7 that it analyzed ARTEX configuration files and session records of AI tools found on attacker infrastructure linked to the campaign. However, this data alone does not confirm that incidents across all financial institutions were attacks carried out by the exact same tool or threat actor. Damages and infiltration paths must be distinguished based on each institution's investigation findings.[2]

Is the inquiry function open?
Who is repeating those inquiries, and with what authorization?

We prioritized "connection" over simple alerts

The starting point of our preparations was not individual features, but connections. Security analysts can only decide their next course of action when external-facing services are linked to the logs they generate, and when the evidence to interpret alerts is connected to response permissions.

Figure 2. Feature addition history confirmed from the source repository. This does not mean all features were completed before the incident occurred.[4]

First, inspect services visible from the outside

External domain monitoring is implemented to query public observation data for registered in-house domains and explicit subdomains, and to check services, candidate CVEs, and change histories. It uses InternetDB or configured Shodan integrations, and does not involve the SIEM directly port-scanning target servers.[4]

What matters here is the meaning of observation. If collection fails, it must not be interpreted as "0 risks found," nor should a service be considered "fully decommissioned" simply because it did not appear in a single query. The implementation explicitly differentiates between uncollected, partially collected, error states, and comparable change results.[4]

However, this feature does not represent a turnkey ASM that automatically discovers every unmanaged asset and Shadow API. Automatic collection is disabled by default, and registration scopes and integration environments must be verified. A process that pairs separate asset surveys with API catalogs and assigns owners and log collection targets is also required.[1][4]

Preventing "200 OK" from being read as "Safe"

Holding an access badge does not mean you can open every drawer. In APIs as well, a successful login only means the caller's identity has been verified; it does not guarantee authorization to query the requested data.[1]

Figure 3. Conceptual diagram of authentication and authorization assuming a service that queries only one's own data. The SIEM does not substitute for authorization checks.[1]

Standardize log names first, then compare under identical conditions

We enhanced web, API, and WAF logs so that request methods, paths, response codes, payload sizes, and session identifiers can be used in correlation analysis. For instance, response codes expressed differently are normalized within the HTTP context, and existing stored logs are also mapped to be interpreted via the same correlation fields.[4]

The proxy connection peer srcIp and the client address clientIp are also not merged into a single value. However, normalizing headers does not authenticate the validity of those values. In practical deployments, the proxy's header trust boundaries and the origins of user and session values must be audited together.[4]

On this foundation, one can investigate whether "successful responses for a specific lookup API are repeating in an unusual pattern." Actual test cases also include applying API path and response code conditions to distinguish non-matching requests and different groups. To expand this to identical user queries across multiple IPs, validated user-session mappings and legitimate batch exceptions must additionally be verified within the service scope.[4]

Object-level authorization results and actual returned data must be obtained from application audit logs. Authorization violations and the extent of data leaks cannot be determined solely by response codes or request volumes.[1]

Selene gathers evidence for judgment; it does not assume execution authority

It is difficult to prioritize investigations based on a single API alert alone. Looking at other alerts for the same user or asset, deviations from normal behavior, threat intelligence, and asset criticality together explains "why this alert must be examined right now."

Figure 4. Boundaries of judgment, explanation, and execution reconstructed based on current implementation. This is not an actual product screenshot.[4]

Starting from stored alerts, Selene constructs evidence tailored to the identified user, asset, host, IP, and time window. It organizes related alerts, UEBA, CTI, etc., and preserves the inputs read at the time of judgment. Omitted or truncated evidence is also indicated, allowing the rationale for the judgment to be reviewed later.[4]

The current default evaluator is a CPU-based heuristic. While it can be used without external AI APIs or GPUs, we do not call this an SOC model trained and validated on customer data. The displayed confidence score also does not represent real-world accuracy. The default mode is OBSERVE. Because the currently connected evaluation method has not completed confidence verification in customer SOC environments, automated blocking is not approved based solely on AI judgment.[4]

The explanatory LLM is a separate request path designed to articulate stored judgments in an easily understandable manner. Even if trained models are applied in the future, they must undergo evaluation and verification with customer data. Separating the capability to aid judgment from the authority to execute responses—this is the safety mechanism we have prepared.[4]

When the same attack signs appear, here is how we investigate and respond

Suppose repeated requests from multiple IPs are detected on an external partner lookup service. The following is an operational application scenario utilizing implemented features, and is not a reproduction or blocking record of an actual financial incident.

Figure 5. An example connecting Guided Response controls with operational procedures. External device integrations require per-environment verification.[4]

First, verify the context of the service. Cross-check external exposure observations with asset inventories. Check whether the responsible department, web logs, and authentication/lookup audit records are being collected. Any section without records is treated as a blind spot requiring verification.[1][4]

Next, examine requests as behavioral units. Investigate repeated queries and IP changes based on server-verified users and sessions within the same service. After confirming whether they stem from normal batch jobs or consultation tasks, review generated alerts alongside Selene's related evidence. Different users are not merged simply because they share the same name or similar IPs.

Actions begin with a preview. Check targets, connectors, approval conditions, and dry-run results of the associated playbook. Explicit execution requests pass through existing SOAR control paths. If targets or definitions change, re-confirmation is required, and duplicate requests return existing executions. If results are ambiguous, actions are not re-executed automatically.[4]

Root causes are remediated within the service. Independent of verified firewall and EDR integrations, API call rate limiting or session invalidation requires integration with Gateways and authentication systems. Fixing object-level authorization flaws is also the application's responsibility. SIEM links the evidence needed for that judgment with response histories.[1][4]

Even after blocking, questions must continue

Restricting a single IP does not conclude the matter. Retries via other paths and impacts on normal business operations must be assessed together, alongside suppressing repeated queries and remediating authentication/authorization flaws.[1]

Three Frequently Asked Questions

Does Polestar SIEM automatically identify ARTEX?
The features introduced here are not dedicated ARTEX identifiers. They detect anomalous behaviors through external exposure observation and web/API correlation analysis, utilizing linked evidence to inform judgments.[4]

Are repeated HTTP 200 responses blocked immediately?
No. The caller's business scope, authorization results, return records, and legitimate tasks are reviewed together. A successful request alone does not establish unauthorized access.[1]

Can AI arbitrarily suspend financial services?
Selene does not execute playbooks directly. It operates through explicit requests and existing approval and protection policies, with the scope of remediation defined by audited integrations and customer operating policies.[4]

The preparation we speak of is verifiable connection

We have prepared tests ranging from HTTP normalization to preview alterations and duplicate execution controls. Actual ARTEX attack reproduction and customer-environment detection and response performance require separate validation.[4]

Preparation that remains even if the name ARTEX changes:
Visible assets, connected evidence, and controllable responses.

Start with a single external query service. Connecting the owner, authorization checks, query logs, and response permissions—this is where Polestar SIEM's Shadow IT response begins.

References

[1] SK shieldus, "Incident Analysis and Response Guide Targeting Shadow IT in the Era of AI-Automated Attacks". As of 2026.10.6.

[2] CrowdStrike, 2026.10.7. Unknown Threat Actor Uses AI-Driven ARTEX to Target South Korean Finance

[3] Genians GSC, Published 2026.10.12 · Analysis as of 10.7. Analysis of Financial Sector Security Breach Issues

Author: YW Jung | Information Security Team