Čtyři dny, 85 účtů, žádná nová zranitelnost. Co ukázal první samostatný AI útok na stát

Ve středu 12. srpna zveřejnila izraelská firma Dream rozbor útoku, o kterém se píše jako o prvním samostatně běžícím AI útoku na stát. Za čtyři dny prolomil 85 účtů, vytáhl přes 2 500 osobních záznamů a rozšířil se na dodavatele, úřad pro jadernou bezpečnost a sedm energetických firem. Zajímavější než ta čísla je ale to, co v přejímajících zprávách chybí: ten útok nenašel jedinou novou zranitelnost. Všechno, co použil, je na seznamu, který má váš pentester dvacet let. Právě proto se to týká i firmy, která si o sebe myslí, že je pro cizí rozvědku moc malá.

Co se stalo

• Kdo a kdy: výzkumný tým DREAM Lab našel začátkem července kompletní pracovní adresář útočícího systému — archiv o velikosti 160 MB a 1 395 souborů. Rozbor vyšel 12. srpna 2026 pod názvem Inside a Multi-Agent AI Framework Used to Compromise Government Entities in Asia. Samotný útok běžel 1.–4. července 2026 ve dvanácti vlnách.
• Jak byl postavený: ne jako jeden skript. Systém stál na dvou veřejně dostupných agentních frameworcích — Hermes a OpenClaw — a v každé vlně pouštěl až osm očíslovaných podagentů souběžně, každého na jiný cíl a jinou techniku. Napříč kampaní jich Dream napočítal od A po Q.
• Čeho dosáhl: zmapoval 21 propojených státních systémů, prolomil 85 zaměstnaneckých účtů, vytáhl 2 564+ osobních záznamů (1 409 zaměstnanců, 916 uživatelů z nechráněného API a 239 právníků z nechráněného koncového bodu ministerstva spravedlnosti), sedm klientských tajemství SSO a šest přístupů do interních databází. Pak se rozšířil na dodavatele státního IT, úřad pro jadernou bezpečnost, státní e-mailový systém a sedm a víc energetických firem.
• Jak obešel pojistky modelu: žádným technickým trikem. Celou kampaň operátoři modelu popsali jako „autorizovaný penetrační test". Dream to shrnuje větou, která stojí za zapamatování: pojistky drží jen proti operátorovi, který se ptá poctivě.
• Odkud útok byl: Dream píše o „vládních subjektech v Asii" a zemi ve svém rozboru nejmenuje. Že šlo o Tchaj-wan, uvedl Financial Times s odvoláním na obeznámený zdroj. Na čínsky mluvícího operátora ukazuje jazyk dokumentace: interní hlášení ve zjednodušené čínštině, výstupy o cíli v tradiční. To je indicie, ne důkaz o zadavateli.

Čím se ten útok skutečně dostal dovnitř

Tohle je jádro věci. Seřazeno tak, jak to šlo za sebou — a u každého bodu si zkuste sami odpovědět, jestli to u vás neplatí taky:

• Přečetl si váš frontend. Prvním krokem bylo stažení a rozbalení JavaScriptových balíčků státního portálu. Z nich vypadaly URL, koncové body API, OAuth client ID a konfigurace Keycloaku. Na jednom cíli takhle našel 36+ koncových bodů API — mnohé bez jakéhokoli ověření. Jeden systém vydal celou databázi uživatelů komukoli, kdo se zeptal.
• Našel zapomenuté ladicí koncové body. Tři skryté koncové body v produkční aplikaci přijímaly libovolný požadavek a vracely platnou přihlášenou session. Bez hesla. Vývojářské zadní vrátka, která někdo nechal v ostrém provozu.
• CAPTCHA ho nezastavila. Portál byl proti hádání hesel chráněný obrázkovou CAPTCHOU. Systém na ni nasadil běžnou open-source OCR knihovnu Tesseract a podle Dreamu ji řešil se 100% úspěšností. Pak zkoušel předvídatelná hesla odvozená od zaměstnaneckých ID — velké písmeno, přidaný symbol — a prolomil 85 účtů (nejdřív 12, pak dalších 73, jak objevoval další vzorce).
• Jedno API přijímalo podepsané tokeny bez podpisu. Klasika alg: none — kdokoli si mohl vyrobit platný token totožnosti, aniž by znal podpisový klíč.
• A tohle byl skutečný zesilovač: 84 z 85 účtů (98,8 %) prošlo přes SSO do interního systému. Každý vnitřní systém měl vlastní vstupní bod, který automaticky věřil session z kancelářského portálu. Žádné druhé ověření, žádné MFA, žádné potvrzení uživatelem. Bez tohohle mostu by incident skončil u 85 účtů v jednom portálu.

Ani jedna z těch věcí není objev. Je to nechráněné API, zapomenutá zadní vrátka, slabá hesla, chybějící MFA a chyba v ověřování podpisu. AI nepřinesla novou zranitelnost — přinesla rychlost a paralelismus. Dvanáct vln za čtyři dny, čtrnáct útočných řetězců rozpracovaných najednou, průběžné přepočítávání toho, kam se vyplatí tlačit dál.

Co jsem při ověřování našel navíc

Titulky mluví o „AI, která si sama našla zranitelnosti". V původním rozboru stojí několik věcí, které to obrázek dost mění — a dvě z nich jdou proti zájmu firmy, která tu zprávu vydala.

• Statická analýza pomocí AI nepřinesla ani jeden skutečný průnik. Systém si stáhl vývojářské SDK k národnímu SSO a pustil na něj vlastní AI analýzu kódu (Dream ji označuje jako Local-LLM-SAST-0day). Něco našla — otevřené přesměrování, podezřelou výměnu autorizačního kódu. Jenže Dream to porovnal s finálním seznamem potvrzených zranitelností a výsledek je jednoznačný: nulový překryv. Všechny reálné průniky přišly ze serverových chyb, které by našel běžný černoskříňkový test bez jakékoli znalosti SDK. Nálezy „AI hledače nul-day" skončily v koši.
• Web shell neprošel. Ke spuštění kódu na serveru nedošlo. Systém sice nahrál web shell přes neomezené nahrávání souborů, ale druhá vrstva ověřování (Forms Authentication) zabránila jeho spuštění. V přejímkách jsem tuhle část nenašel nikde; v původním textu je popsaná jako částečný úspěch, který zůstal před vzdáleným spuštěním kódu stát.
• Systém dělal chyby a sám je odhaloval. V závěrečném souhrnu je vedle osmi potvrzených zranitelností i sedm falešných poplachů. Nejlepší příklad: agent hlásil SQL injection, protože odpověď serveru trvala 21 sekund — což si vyložil jako úspěšné SLEEP(5). Při metodickém přetestování se ukázalo, že server jen čekal na timeout odesílání ověřovacího e-mailu. Nález byl přeřazen mezi falešné a vyloučen. Každý potvrzený nález musel podle dokumentace přežít fyzické ověření plus dvě kola po třech nezávislých přetestech — šest opakování, než se směl počítat.
• „Stačí spustit model" neplatí. Dream sám píše, že postavit systém, který takhle funguje, dá výrazně víc práce než „jen" pustit model: vyžaduje ladění na konkrétní úkol, koordinaci agentů a doladění rozhodovací logiky. Ta pravděpodobnostní vrstva je na to nejlepší doklad — každý nález startuje na 50 % a mění se podle druhu důkazu (potvrzení ručním dotazem má desetinásobnou váhu oproti výchozímu stavu, přítomnost WAF váhu naopak snižuje). Řetězec s odhadem 99 % úspěšnosti pak realita potvrdila na 98,8 %.
• Zdroj má na poplachu zájem. Dream prodává státům obrannou AI a rozbor končí doporučením, že bezpečnostní produkty se musí posunout k „AI-native" přístupu. Ověřená nezávisle je existence a rozsah nálezu, který převzaly FT, CyberScoop, The Register i další. Vlastní archiv útočníka veřejný není — čísla stojí na Dreamu.

Proč se to týká i vás

Odpověď „my nejsme ministerstvo" tady nefunguje, a to ze dvou důvodů.

• Změnila se ekonomika, ne technika. Dream to shrnuje takto: náklady na vedení kompetentního útoku se zhroutily, náklady na obranu ne. Doteď platilo, že důkladné proklepnutí středně velké firmy stojí útočníka člověkotýden, a proto se dělalo jen tam, kde se to vyplatí. Když totéž udělá osm agentů paralelně za víkend, hranice „na nás se nikomu nevyplatí" mizí.
• Vstupní bod byl váš veřejný web. Celý útok začal tím, že si někdo stáhl a rozebral zkompilovaný JavaScript z veřejného portálu. To může udělat kdokoli právě teď u vás — a najde v něm to, co tam vaši vývojáři nechali: adresy interních API, klientská ID, testovací koncové body.
• Nejdražší chyba byla ta nejnudnější. Ne prolomení hesel, ale SSO most, kterému stačila jedna session z jednoho portálu. Tenhle vzorec má skoro každá firma, která zavedla jednotné přihlašování a už u toho neřešila, co se stane, když jeden účet padne.
• Tohle není téma AI Actu. Řeknu to natvrdo, protože se to bude plést: v tomhle případě nejste provozovatel ani poskytovatel AI systému. Jste obětí. Žádná dokumentace, žádné hodnocení rizik podle nařízení a žádný audit shody vám tenhle incident nezastaví. Zastaví ho konfigurace.

Co s tím

Čtyři kroky. Všechny zvládne váš vlastní IT tým nebo dodavatel webu, žádný z nich nepotřebuje konzultanta a všechny odpovídají přesně tomu, čím se ten útok dostal dovnitř.

• 1. Zkuste svoje API bez přihlášení. Vezměte adresy, které používá váš web nebo aplikace, a zavolejte je bez tokenu — obyčejným curl bez hlavičky Authorization. Cokoli, co vrátí data místo chyby 401, je nález. Tohle byl u tchajwanského úřadu zdroj většiny ukradených záznamů a jde to otestovat za hodinu.
• 2. Projděte, co je vidět ve vašem frontendu. Otevřete zkompilované JS balíčky svého webu a hledejte adresy, které do veřejné části nepatří: administrační rozhraní, testovací a ladicí koncové body, klientská ID. Co tam je, to má útočník taky. Ladicí vstupy patří do produkce jen tehdy, když jsou za ověřením — a nejlíp tam nepatří vůbec.
• 3. Nespoléhejte na CAPTCHU jako ochranu proti hádání hesel a zakažte hesla odvozená od jména či osobního čísla. Obrázkovou CAPTCHU vyřešila volně dostupná OCR knihovna se stoprocentní úspěšností. Ochranou je omezení počtu pokusů, uzamčení účtu a kontrola hesel proti seznamu úniků, ne obrázek s písmenky.
• 4. Zapněte druhý faktor tam, kde se přechází mezi systémy, ne jen u vstupní brány. Nejcennější zjištění z celého rozboru: 98,8 % prolomených účtů prošlo dovnitř proto, že interní systémy bez dalšího ověření věřily session z portálu. Zkontrolujte, jestli si vaše aplikace za SSO vynucují MFA i pro přihlášení odvozené z jiné aplikace. Když ne, jeden prolomený účet vám otevře všechno.

A kdyby zbyl čas na páté: ověřte, že vaše API odmítá tokeny s alg: none. Je to jeden test a chyba, kterou by v roce 2026 už neměl mít nikdo — přesto ji ten útok použil.

Kde to řeším s klienty

Budu upřímný stejně jako minule: na tenhle článek se audit AI governance nekupuje. Všech pět bodů výše je běžná bezpečnostní hygiena a patří do penetračního testu. Pokud máte pentest mladší než rok, který pokrýval veřejné API, správu session a SSO, tímhle článkem se nemusíte zabývat — jen si ověřte, že se nálezy opravdu zavřely. Pokud ho nemáte, kupte si pentest, ne audit AI.

Kde má smysl se ozvat, je jiná otázka: co všechno u vás dnes umí jednat samo. Útočníkovi stačily veřejně stažitelné agentní frameworky a model, kterému stačilo říct, že jde o autorizovaný test — a stejné nástroje má dnes ve firmě spousta lidí legálně. Soupis agentů, jejich oprávnění a semafor rizika je přesně to, co dělá AI Agent Governance Checkup. Když si nejste jistí, jestli se vás to vůbec týká, napište si o AI Risk Scan zdarma. Na tenhle vzorec z druhé strany — kdy agent uposlechne pokyn schovaný v datech, které si přečte — jsme se dívali v článku Firewall ten požadavek zablokoval, a na to, kdy hranice povolí i bez útočníka, v článku Modely utíkají ze sandboxu.