Za tři dny uniklo z jihokorejských bank Shinhan, KB Kookmin, Hana a BNK přes 25 000 klientských záznamů. Žádná z bank nepřišla o data přes jádro bankovnictví — vnikly jim systémy, které se skoro nikdy nedostanou do bezpečnostního auditu: portál pro externí úvěrové makléře a interní podpora pro prodejce. Na pozadí se našly stopy nástroje, který automatizuje penetrační testování pomocí AI, ale ani banka, ani regulátor to oficiálně nepotvrdili. I bez potvrzení platí jedno: útočníci napadli přesně ten typ systému, který firmy při hodnocení rizika AI agentů obvykle vynechávají.
Co se stalo
- Shinhan Bank, ~25 000 klientů. Podle deníku Korea Herald probíhal neoprávněný přístup v noci z 29. na 30. září 2026, banka podezřelou aktivitu zaznamenala kolem 9:30 ráno 29. září. Unikla jména, telefonní čísla, roční příjem, vypočtené úvěrové limity, 66 rodných čísel a 97 identifikátorů CI (korejský ekvivalent ověření totožnosti). Vstupní branou byla „jednoduchá ověřovací služba“ pro externí úvěrové makléře — systém, kterým makléři zadávají žádosti klientů a kontrolují schválení, ne hlavní bankovní aplikace.
- Hana Bank, 89 klientů — a vlastní obhajoba banky. Podle navazujícího článku Korea Herald šlo o systém ODS (podpora pro prodejce), unikla rodná čísla, jména, adresy, kontakty a jména zaměstnavatelů. Hana Bank k tomu řekla: „Systém je oddělený od systémů internetového a mobilního bankovnictví, které zpracovávají finanční transakce“ — tedy že platby klientů zůstaly mimo dosah útoku.
- KB Kookmin (119 klientů) a BNK Financial Group (11 záznamů). Stejný vzorec: menší, okrajové systémy, ne core banking. U KB Kookmin unikla jména, telefonní čísla, adresy a rodná čísla; u BNK šlo o údaje externě zaměstnaných pracovníků.
- Nástroj ARTEX AI — nalezený, ne potvrzený. Bezpečnostní analytici našli na serveru, který mohl souviset s útokem na Shinhan, stopy nástroje ARTEX AI — veřejně dostupného open-source nástroje na bázi LLM, který automatizuje průzkum sítě, hledání zranitelností a jejich zneužití. Korea Herald i korejská ekonomická média (např. SBS Biz) ale výslovně píšou, že ani Shinhan, ani finanční dohled zapojení tohoto nástroje oficiálně nepotvrdily. Co je potvrzené: šlo o „credential stuffing“ — útočníci zkoušeli ve velkém kombinace jmen a hesel uniklých z jiných, dřívějších úniků.
- Reakce regulátora. Korejská Komise pro finanční služby (FSC) a Úřad finančního dohledu (FSS) svolaly mimořádná jednání, nařídily bankám bezpečnostní audity a posílení ověřování přístupu. FSS zahájil místní šetření u Shinhan a podle Korea Herald přes integrovaný dohledový systém rozeslal varování více než 500 finančním institucím a poskytovatelům elektronických platebních služeb.
Proč se to týká i vás
Česká firma nemá korejské klienty ani makléřský portál, ale má svůj ekvivalent: systém, který není „ten hlavní“, proto na něj nikdo neposílá penetrační test ani ho nezahrnul do přehledu kritických aktiv. Partnerský portál pro obchodní zástupce, interní nástroj pro podporu prodeje, API pro externí makléře nebo franšízanty — přesně tahle kategorie systémů ve všech čtyřech korejských bankách propustila útočníka dovnitř, zatímco klasické internetové a mobilní bankovnictví zůstalo bez incidentu.
Druhá věc, kterou si z toho má smysl odnést, je opatrnost s atribucí. Zpráva „AI nástroj hackl banku“ se šíří rychleji a líp prodává titulky než „útočníci zkoušeli uniklá hesla ve velkém a trefili se do špatně chráněného vedlejšího systému“. Obojí může být pravda zároveň — credential stuffing je potvrzený, nástroj ARTEX AI je jen stopa na jednom serveru. Než si firma vezme konkrétní incident jako argument pro nebo proti nasazení AI nástrojů do bezpečnosti, má smysl počkat na to, co nakonec potvrdí vyšetřování, ne první titulek.
Co s tím
- 1. Sepište si systémy, které obsluhují externí partnery (makléře, franšízanty, dodavatele), a zkontrolujte, kdy byly poprvé v bezpečnostním auditu. Pokud odpověď je „nikdy“ nebo „nevíme“, máte svůj ekvivalent makléřského portálu Shinhan.
- 2. Zkontrolujte, jestli tyto vedlejší systémy mají stejnou ochranu proti opakovaným přihlašovacím pokusům (rate limiting, MFA) jako hlavní aplikace. Credential stuffing funguje tam, kde chybí omezení počtu pokusů za minutu nebo kde druhý faktor přihlášení chybí „jen u téhle jedné interní appky“.
- 3. Ověřte, že hesla a přístupy z vedlejších systémů nejdou dohledat ke stejným účtům jako v hlavní aplikaci. Právě propojení „okrajový systém → citlivá data o klientovi“ změnilo menší díru v méně hlídaném systému na únik desítek tisíc záznamů.
- 4. Než o incidentu mluvíte dovnitř firmy jako o „AI hacku“, ověřte si, co je v daném případě skutečně potvrzené. Rozhodnutí o bezpečnostním rozpočtu založené na nepotvrzené atribuci je rozhodnutí založené na titulku, ne na faktu.
A teď proti vlastnímu byznysu: pokud vaše firma nemá partnerský portál, API pro externí subjekty ani jiný „vedlejší“ systém s přístupem k osobním údajům klientů, tenhle incident se vás věcně netýká — nejde o obecné varování před AI, ale o konkrétní slabinu v konkrétní architektuře. Nemusíte kvůli tomu objednávat audit jen proto, že se o tom psalo v novinách.
Kde to řeším s klienty
Mapování toho, které systémy ve firmě obsluhují externí partnery a jestli mají stejnou úroveň ochrany jako hlavní aplikace, řešíme v rámci AI Agent Governance Checkupu. Pokud si nejste jistí, jestli se vás tohle téma týká vůbec, začněte AI Risk Scanem zdarma.