The Korean Bank Hacker Left a Second Server Wide Open

The operator behind this autumn’s breaches at seven South Korean financial institutions left a second server wide open, and it shows how one person ran a whole AI attack crew. Security Affairs reports on new research from Hunt.io, which pivoted from the one console server already made public to a Hong Kong jump host holding 42 files: credentials, tunnel scripts, AI routing proxies and exploit tooling. The breaches, between late September and early October, exposed personal, job, income and loan data on roughly 66,000 to 67,000 people and about 2,200 companies.

38.244.50[.]120 (ARTEX console, ports 443/8090, tunnel destination)
23.248.226[.]250 (Hong Kong jump host, open directories on 18099 and 8001)
154.201.79[.]246 (rotating proxy service)
u6ud2s.dnslog[.]cn (DNS callback in the staged JNDI exploit)
130.94.31[.]86 · 156.251.11[.]39 (other ARTEX consoles, not tied to the bank breaches)

C7A884AFCD7F91408921890D9617BEF6BFAC3DAE992BC25BB9C48C0395A60842 (TLS certificate fingerprint, issuer organization ARTEX)

Source article: Inside ARTEX: AI Hacking Tools, Exposed Servers and South Korean Bank Breaches
Publisher: Security Affairs
Published: Nov. 7, 2026
URL: https://securityaffairs.com/202607/ai/inside-artex-ai-hacking-tools-exposed-servers-and-south-korean-bank-breaches.html

Executive Summary

Between late September and early October 2026, seven South Korean financial institutions suffered data breaches through internet-facing systems, exposing personal, employment, income and loan data on roughly 66,000 to 67,000 individuals and about 2,200 corporations. CrowdStrike and Genians attributed the intrusions to ARTEX, an open-source, AGPL-licensed autonomous penetration testing framework developed in China; CrowdStrike assessed with moderate confidence that a single financially motivated, Chinese-speaking individual operated it rather than an established group, and no vendor has assigned a group name, so this report refers to the operator only as the ARTEX operator. Hunt.io pivoted from the publicly reported console host 38.244.50[.]120 to a second exposed open directory on a Hong Kong jump server, 23.248.226[.]250, which held a credentials file, sshpass-driven reverse SSH tunnel and sync scripts pointing at the console, a Claude Code harness routed through local proxy shims and the xcai[.]pro reseller to DeepSeek models, 19 custom agent skills (code audit, reconnaissance, web injection, WAF bypass, authentication testing, payment logic testing and mobile operations), FOFA reconnaissance via a third-party API, enumeration of a rotating proxy pool at 154.201.79[.]246, and a staged JNDI/LDAP exploitation setup that confirms command execution through a DNS callback. The intrusion chain as reported runs from FOFA-driven discovery of internet-facing banking applications, through AI-agent-driven testing and exploitation of web application flaws (with tooling consistent with IDOR testing of account and loan objects), to data collection and exfiltration, with traffic relayed through rotating proxies. The framework is widely deployed beyond this campaign: Hunt.io counted 1,303 ARTEX-tagged addresses in 30 countries and several unrelated open directories. Hunt leads, false positive expectations and indicators are detailed below; neither Security Affairs nor Hunt.io published detection rules or file hashes.

ATT&CK chain: Reconnaissance → Resource Development → Initial Access → Execution → Command and Control → Collection → Exfiltration

Hunt Lead Grid

ARTEX Console, Jump Host and Proxy Infrastructure Sweep

The ARTEX console at 38.244.50[.]120 sits on Cogent in Los Angeles with 15 open ports; the login page, titled “ARTEX – 自主渗透测试控制台” (“autonomous penetration testing console”), is served on ports 443 and 8090 behind a TLS certificate whose issuer organization is ARTEX (SHA-256 fingerprint C7A884AFCD7F91408921890D9617BEF6BFAC3DAE992BC25BB9C48C0395A60842), alongside a Gemini2API admin console and a Tinyproxy service. The Hong Kong jump host 23.248.226[.]250 (AS138415) exposed directories on ports 18099 and 8001 and was flagged by Hunt.io on Sept. 5, Sept. 26 and Oct. 5, 2026. The recovered proxy scripts enumerated a rotating service at 154.201.79[.]246:443, which produced 79 unique exit IPs in the first 100 identities tested; CrowdStrike, ThreatBook and Cybersecurity News also list that address per Hunt.io. Two further ARTEX consoles Hunt.io validated, 130.94.31[.]86 (port 18888, Seoul) and 156.251.11[.]39 (port 18080, an SMB reconnaissance kit writing artex_probe_11876.txt), are not tied to the bank breaches. The detection logic is a retrospective sweep of inbound web, WAF and load-balancer logs for requests from these addresses and of outbound firewall logs for any connection to them, plus a check of TLS inspection or certificate logs for the ARTEX issuer string.

Use WAF, reverse proxy and load-balancer access logs for internet-facing applications, firewall and NetFlow records, and TLS certificate logs from inspection appliances where available. Sweep back to Aug. 1, 2026, since the harness on the jump host had been running since Aug. 4. Scope first to customer-facing web and API applications, especially those serving account, loan or payment data. The proxy address fronts a commercial rotating service, so the 79 exit IPs behind it change constantly and blocking them is the wrong control; use any hit to pull the full request history for that session instead. Do not block the xcai[.]pro reseller or the FOFA API reseller fofoapi[.]com as indicators of compromise in your own environment: they are services the operator consumed, not hosts that touch victims, and are better tracked as context. Any request from the console or jump host addresses against your applications should be escalated and the targeted application tested for IDOR and injection flaws.

Hunt Lead Level: 1 (Junior Analyst)

ATT&CK: Command and Control → T1090.002 (Proxy: External Proxy); Initial Access → T1190 (Exploit Public-Facing Application)

Sources: “Inside ARTEX: AI Hacking Tools, Exposed Servers and South Korean Bank Breaches”, Security Affairs, Nov. 7, 2026, https://securityaffairs.com/202607/ai/inside-artex-ai-hacking-tools-exposed-servers-and-south-korean-bank-breaches.html (source article); “ARTEX Exposed: Infrastructure Behind the South Korea Bank Hack”, Hunt.io, Nov. 2026, https://hunt.io/blog/artex-south-korea-bank-infrastructure (additional source, same campaign)

Servers Resolving dnslog.cn Callback Hostnames

The staged exploitation directory at 23.248.226[.]250:8001, retrieved on Oct. 5, 2026 at 03:42 UTC, contains a JNDI/LDAP chain whose hosted Java class runs a shell command that triggers a DNS lookup of u6ud2s.dnslog[.]cn, so the operator learns the target executed code without needing a return connection. The compiled class also references HTTP-based retrieval commands as an alternative way to move data. dnslog.cn is a public out-of-band testing service, and the same callback pattern is how automated exploitation frameworks confirm blind injection and deserialization bugs. The detection logic is simple: any DNS query from a server, container or application host for a name under dnslog[.]cn, and specifically for u6ud2s.dnslog[.]cn, is a sign that something on that host processed attacker-supplied input and executed it.

Use recursive resolver logs, DNS firewall or protective DNS logs, and EDR DNS telemetry. Sweep back to Aug. 1, 2026, and keep the query running, since out-of-band callbacks are a common confirmation step for many operators beyond this campaign; extend the watch list to similar services your threat intelligence tracks. Scope to servers and especially Java application hosts; workstation hits are more likely to be security staff testing. Allowlisting should be by documented penetration test windows and named tester hosts, never by domain. Blocking dnslog.cn at the resolver is a reasonable hardening step, but it hides the signal, so log the query before you sinkhole it. A server-side hit means likely code execution: capture the process that made the query, preserve the application logs for the requests just before it, and escalate to incident response.

Hunt Lead Level: 1 (Junior Analyst)

ATT&CK: Command and Control → T1071.004 (Application Layer Protocol: DNS)

Sources: source article (above); Hunt.io report (above), additional source

Outbound LDAP from Java Web Applications after JNDI Lookups

Hunt.io describes the staged chain end to end: the target application performs a JNDI lookup that reaches a rogue LDAP server run by the operator, the LDAP server returns a manipulated search result with a Java naming reference (built in LDAP2.java), the application fetches and loads the hosted exploit class, the class runs a shell command, and the DNS callback confirms it; one helper script lets web and LDAP traffic share a single port so the chain works through restrictive egress. The behavioral anchor is a Java process on an internet-facing server initiating an outbound LDAP or LDAPS session to an external address, on 389, 636 or an unusual port such as one also used for HTTP, followed within seconds by an outbound HTTP request for a .class or JAR file and, in the worst case, by the Java process spawning sh, bash or cmd. Build the rule as that sequence on one host rather than as any single event.

Use EDR process and network telemetry from application servers, egress firewall logs with application identification, and proxy logs for class and JAR downloads. Sweep back to Aug. 1, 2026. Scope to internet-facing Java workloads (application servers, API gateways, admin consoles) in banking, lending and payment environments first. Legitimate Java applications do talk LDAP, but to internal directory servers you can enumerate; allowlist by destination address and service account, not by process name. Egress filtering that blocks outbound LDAP from application tiers is the right preventive control, and patching the vulnerable library is required; a WAF rule on the “${jndi:” string alone is the wrong choice because obfuscated payloads routinely bypass it. A Java process spawning a shell after an external LDAP session is a compromise, so isolate the host and escalate. The lead generalizes to any JNDI injection campaign, not just this operator.

Hunt Lead Level: 2 (Pro)

ATT&CK: Initial Access → T1190 (Exploit Public-Facing Application); Command and Control → T1105 (Ingress Tool Transfer)

Sources: Hunt.io report (above), additional source; source article (above)

Object-ID Enumeration Across Accounts through Rotating Proxies

Next to the payment-logic agent skill, Hunt.io found a file holding three self-registered accounts with JWTs for a cash-in deposit API, each with its own user ID and bank account ID and dated Sept. 12, 2026, which it says is consistent with testing for insecure direct object reference flaws, the technique CrowdStrike and Genians described against Korean loan and inquiry services. Other skills extracted internal JavaScript API calls from target sites, searched decompiled APKs for internal endpoints and secrets, and tested authentication, while the proxy scripts rotated through dozens of exit IPs. The attack pattern to detect is a small number of authenticated sessions or tokens requesting account, loan, inquiry or transaction objects whose identifiers belong to other customers, often sequentially, spread across many source IPs so per-IP rate limits never trip. Detection logic: for each token, session or user ID, count the distinct object identifiers requested on sensitive endpoints and the share of those that don’t belong to the authenticated user, and alert when that exceeds a baseline, with extra weight when the same token appears from many IPs or ASNs in a short window.

Use application and API gateway logs that record the authenticated principal, the object identifiers in paths, query strings and bodies, the response code and size, and the client IP; WAF logs alone usually lack the principal. Baseline 30 days per endpoint and per client type, then sweep back to Aug. 1, 2026. Scope to customer-facing APIs that return personal, loan, income or payment data, including mobile APIs found in the app package. Expect false positives from internal staff tools, partner aggregators and batch integrations; allowlist those by client credential, not by IP. Rate limiting by IP is the wrong control here, because the rotating proxy defeats it, and blocking the proxy’s exit IPs is a losing game; enforce object-level authorization server-side and rate limit per principal. A confirmed cross-account read is a breach of customer data and should go straight to incident response and the privacy team. The lead generalizes to any IDOR abuse, AI-driven or not.

Hunt Lead Level: 3 (Elite)

ATT&CK: Initial Access → T1190 (Exploit Public-Facing Application); Command and Control → T1090.002 (Proxy: External Proxy)

Sources: Hunt.io report (above), additional source; source article (above)

Hash Appendix

Neither the source article nor the Hunt.io report publishes file hashes for the recovered scripts, shims or exploit binaries, and the files are not named specifically enough to pivot on in OTX or VirusTotal, so no hashes were added. The one fingerprint published is a TLS certificate fingerprint, not a file hash: C7A884AFCD7F91408921890D9617BEF6BFAC3DAE992BC25BB9C48C0395A60842 (certificate on 38.244.50[.]120, issuer organization ARTEX).

References Appendix

• “Inside ARTEX: AI Hacking Tools, Exposed Servers and South Korean Bank Breaches”, Security Affairs, Nov. 7, 2026, https://securityaffairs.com/202607/ai/inside-artex-ai-hacking-tools-exposed-servers-and-south-korean-bank-breaches.html (source article; campaign summary, recovered tooling, hunting and defensive recommendations)
• “ARTEX Exposed: Infrastructure Behind the South Korea Bank Hack”, Hunt.io, Nov. 2026, https://hunt.io/blog/artex-south-korea-bank-infrastructure (additional source; infrastructure pivots, IOC table, ATT&CK table, JNDI/LDAP and IDOR details)
• MITRE ATT&CK Enterprise technique pages linked above, MITRE, https://attack.mitre.org/