Sign in Subscribe

What four Korean bank breaches teach anyone who self-hosts

What four Korean bank breaches teach anyone who self-hosts

This week OpenAI held a "Cyber CXO Roundtable" in Seoul and invited about 60 executives, including chief information security officers from South Korean companies, according to DigitalToday and Aju Press (both 16 October 2026). Kim Kyung-hoon, head of OpenAI Korea, Dominic Grillo, head of technical success, and Wana Tun, a security engineer, set out AI-based strategies for responding to cyber threats.

Aju Press reports that Grillo and Tun told the room defenders should give AI the code and operating context of their systems, so they can plug holes before attackers strike. The room had a fresh example to think about. In late September, hackers breached internet-facing support systems at four Korean lenders, which Aju Press names as Shinhan Bank, KB Kookmin Bank, Hana Bank and BNK Busan Bank.

Aju Press adds that the Financial Security Institute found traces of ARTEX, an open-source AI penetration-testing platform, on suspected attack servers, though how much AI was involved has not been confirmed. If you run your own servers, the useful part of this story is not the sales pitch. It is which systems actually fell.

What fell, and why the first job is to reduce your attack surface

The Korea Herald reported on 5 October, in coverage also carried by TechTimes, that the campaign ran for about a week starting 28 September. The systems reached were peripheral business-support tools: a mobile portal used by loan solicitors at Shinhan, an employee mobile support system at KB Kookmin, and a sales support system at Hana. They were not the consumer banking apps.

The method was not clever. According to the same reporting, every confirmed breach used credential stuffing: username and password pairs from earlier breaches, fed at speed into login portals that anyone on the internet could reach. Where figures had been made public by 5 October, the confirmed count of affected individuals exceeded 65,000, though no direct financial losses had been confirmed at that point.

The Korea Herald also reported that at Shinhan the anomaly was not detected until the following morning, more than 15 hours after first access, with a total dwell time of roughly 30 hours. At KB Kookmin, detection took roughly 43 hours.

This is the shape of most self-hosted risk. It lives in the NAS web UI, the monitoring dashboard, the old wiki you stopped updating and the admin port you opened for one afternoon. Each is a login page on the open internet, and most of us would not know if someone started knocking.

What the AI part does and does not mean

"AI penetration-testing tool" invites a picture of a machine breaking into banks on its own. Investigators did not say that. A Korea Financial Security Institute official told the Herald Business: "A hacker used the AI as a tool."

The tool is not secret, either. Per the Korea Herald and TechTimes, ARTEX began as a winning entry in a challenge run by Baidu's Security Response Center and is distributed openly through GitHub. Its use does not tell you who was behind the attack. Investigators say attribution remains unresolved, and the same reporting notes that Oasis Security tracked 359 IPs tied to ARTEX activity, 65.7 percent of them in the United States.

What changes when tools like this are free is the skill floor. Working through a long list of login pages with leaked passwords takes less expertise than it used to. The target list did not get smarter. It got cheaper to work through, and your exposed login page is on it.

Take inventory: what of yours is actually reachable?

You cannot shrink a list you have never written down. Start on the box itself and ask what is listening:

sudo ss -tulpn
docker ps --format '{{.Names}}  {{.Ports}}'

Anything bound to 0.0.0.0 or [::] listens on every interface. A Docker mapping like 8080:80 does the same, and Docker writes its own firewall rules, so ufw may not block it. If only your reverse proxy needs the service, use 127.0.0.1:8080:80.

Then check the edge of your network:

  • Your router's port forwards and your VPS provider's firewall. Look for rules you forgot, and turn off UPnP if nothing needs it.
  • Every hostname on your reverse proxy. Each proxied login page is exposed, even on a subdomain you never shared, because public certificates land in certificate transparency logs.
  • A test from outside. From a separate server, run nmap -Pn against your own public IP and compare the result with what you believe is closed.

For each item on the list, make one of three decisions:

  1. Take it off the internet. If nobody outside your home or team needs it, close the forward and bind it to localhost or your LAN.
  2. Put it behind a VPN. If only you and a few people need it, use WireGuard or Tailscale and close the public port.
  3. Put real authentication in front of it. If it must be public, add a login layer at the reverse proxy, before the app's own login page. Our guide to setting up an nginx reverse proxy covers the base setup.

Authentication, reuse and your old forum password

Credential stuffing works because people reuse passwords. If your old forum password is also your Nextcloud or Portainer password, the forum's leak is the key to your dashboard. The attacker does not break anything. They just try the pair.

What to do instead:

  • Unique passwords for every service, generated by a password manager, including the "temporary" ones.
  • MFA wherever the app supports it. For apps that do not, put an identity layer such as Authelia or Authentik in front at the proxy, so a stranger never sees the app's own login form.
  • SSH keys only. Set PasswordAuthentication no and remove old or default accounts.
  • Throttle repeated failures rather than hoping. fail2ban or CrowdSec can ban an address after a few bad logins, and nginx can slow down a login endpoint.
# in the http block
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

# in the server block
location /login {
    limit_req zone=login burst=5;
    proxy_pass http://127.0.0.1:8080;
}

Stuffing runs can rotate through many addresses, so throttling slows an attacker down but does not stop one. Unique passwords and MFA are what make a leaked pair worthless.

Detection: how long would it take you to notice?

By the Korea Herald's account, Shinhan's intruder was inside for roughly 30 hours and KB Kookmin took roughly 43 hours to notice. Those are banks with security teams. If someone logged into your dashboard tonight with a valid password, when would you find out? For many homelabs, the honest answer is never. Aim to know within the hour.

Start with the logs you already have:

journalctl -u ssh --since today | grep -i 'failed password'
journalctl -u ssh --since today | grep 'Accepted'
awk '$9 == 401 || $9 == 403' /var/log/nginx/access.log | tail -n 50

On some distributions the unit is sshd. Check each app's own log too, because many apps answer a failed login with a normal page that the proxy log will not flag.

Then alert on two things: a spike in failed logins, and a successful login from a place or device you do not recognize. fail2ban, CrowdSec or a small cron script can push those to ntfy or email. Stuffing traffic often looks like ordinary logins from ordinary addresses, which is why our earlier post on blocking bot traffic by behavior focuses on patterns rather than single IPs.

What OpenAI is selling, and what you already control

Aju Press and DigitalToday describe Daybreak as OpenAI's AI-based integrated cyber defence package. It links OpenAI's models with Codex and Codex Security to support vulnerability detection, verify in a controlled setting whether a flaw is exploitable, prepare fixes and confirm the fixes work. DigitalToday adds that OpenAI described "Defense Factory", its internal model for connecting AI agents with existing security and development tools to keep checking for vulnerabilities.

Access is gated to what OpenAI calls verified defenders. OpenAI said many major Korean companies have adopted Daybreak or are considering it, according to Aju Press. That is OpenAI's own claim, and pricing was not disclosed.

OpenAI's own advice in the room was measured. DigitalToday reports that OpenAI stressed companies should clearly define the data, systems and task scope AI can access, and that people must review and approve key security measures.

For a self-hoster, the contrast is simple. One option is a gated service whose pitch asks you to hand over your code and operating context. The other needs nobody's approval: closing a port forward, binding a container to localhost, turning on MFA and reading your auth log. As reported, the confirmed breaches started with a reachable login page and a password that had leaked before. You can fix both on your own box this week.

If you want a second pair of eyes

If you would rather have someone audit what is reachable in your stack, put authentication in front of it and hand you the list, have a look at my services page.

Fiverr: hiteshsaini459 · Upwork: hiteshsaini25