Ransomware ve výrobní firmě: jak prevence omezila škody
Akira ransomware zasáhl výrobní firmu s 250 zaměstnanci. Díky předchozí gap analýze, governance a nacvičené reakci byla firma zpět v plném provozu za 72 hodin bez výkupného. Rozbor vektoru útoku, co se vyplatilo mít připravené a co je z toho přenosné na vaši firmu.
Na konci března 2026 zasáhl ransomware Akira středně velkou českou výrobní firmu (250 zaměstnanců, dva závody, ERP s denním objemem desítek milionů Kč), pro kterou jsme předtím zpracovali gap analýzu a navázali na ni průběžnou bezpečnostní governance. Útočníci zašifrovali 21 z 28 produkčních Windows serverů a požadovali výkupné 14 mil. Kč v Bitcoinu. Díky obraně postavené během předchozí spolupráce (immutable backup, segmentace IT a OT zóny, nacvičená rozhodovací matice) byla firma zpět v plném provozu za 72 hodin bez zaplacení výkupného a se ztrátou dat v jednotkách hodin. Tady je rozbor, jak útok proběhl, co se vyplatilo mít připravené a co je z toho přenosné na jinou firmu.
Klient v této studii je anonymizován z důvodů NDA. Všechna technická fakta (TTP řetězec, časové milníky, použitá obranná opatření, metriky obnovy) odpovídají reálnému incidentu, u kterého jsme klienta podporovali v rámci průběžné governance v březnu 2026.
Jak útok začal?
Forenzní analýza ukázala řetězec s TTP konzistentními s rodinou Akira ransomware (přesná atribuce na konkrétního afilianta není v rámci rychlé IR akce možná). Útok probíhal ve třech fázích a každá z nich měla zranitelnost, kterou útočníci využili.
Vstup: kompromitovaný RDP přístup kontraktora
Vstupním bodem byl RDP účet externího implementačního partnera, který firmě pomáhal s ERP customizacemi. Účet měl trvale aktivní přístup do produkční domény bez MFA, bez Conditional Access pravidel a bez time-bound aktivace. Útočníci získali platné přihlašovací údaje přes infostealer malware na partnerově osobním notebooku, který používal pro firmu i pro soukromé účely. S funkčním heslem se pak prostě přihlásili do RDP brány zákazníka, kde nebyla nasazená MFA ani geofencing. V provozních logách to vypadalo jako běžné přihlášení kontraktora a nevzbudilo žádný alert.
MFA a Conditional Access pro kontraktorské RDP přístupy byly v naší gap analýze flagované jako prioritní nález s plánovaným rolloutem v následujícím kvartálu — klient čekal na dokončení překlápění dodavatelských účtů pod centrální IAM. Útok přišel dřív, než se rollout stihl spustit.
Eskalace: Mimikatz a DCSync
Po vstupu útočníci spustili Mimikatz (open-source nástroj pro extrakci hesel a tiketů z paměti Windows) na kompromitovaném serveru a vydolovali z LSASS přihlašovací údaje dalších uživatelů včetně účtu s delegovanými právy. Tento účet pak použili pro DCSync útok (technika replikace doménových hashů přímo z DC bez nutnosti přístupu k disku), kterým získali NTLM hashy všech doménových účtů včetně KRBTGT (master účet, jehož kompromitace umožňuje útočníkovi forge libovolných Kerberos tiketů a tedy plnou impersonaci všech uživatelů). Od tohoto okamžiku měli prakticky neomezený přístup do celé domény bez nutnosti znovu prolomit jediné heslo.
Distribuce: PsExec a Group Policy
Ransomware payload se na cílové stroje rozkopíroval kombinací PsExec (manuální push) a modifikované Group Policy s logon scriptem (automatický push). Šifrování se spustilo synchronizovaně v noci na sobotu, kdy je IT helpdesk minimálně obsazený a první zaměstnanci přijdou až v pondělí ráno. V tu chvíli již byly post-exploitation aktivity v doméně téměř 11 dnů, během kterých si útočníci interní prostředí prohlédli, identifikovali zálohovací infrastrukturu a pokusili se ji vyřadit, neúspěšně.
Reakce a obnova v 72 hodinách
Reakce klienta vycházela z IR runbooku, který jsme spolu sestavili v rámci governance, a z metodiky NIST SP 800-61r2 (Computer Security Incident Handling Guide) ↗ a CISA #StopRansomware Guide ↗. Hlavní rozdíl mezi obnovou v 72 hodinách a v 14 dnech je v prvních 8 hodinách: jak rychle se zóna útoku ohraničí a začne forenzní stopa.
T+0 až T+8 h: ohraničení a triáž
Klient měl díky průběžné governance jasný IR runbook s telefonním stromem, escalation maticí a přiřazenými rolemi. IT lead zahájil ohraničení během 90 minut od detekce: síťově izoloval napadenou IT zónu od OT segmentu (výrobní linky), což zabránilo škodě v provozní vrstvě, kterou ransomware dosud nezasáhl. Současně odpojil připojení k externím partnerům a zablokoval odchozí komunikaci ze serverů do internetu, aby přerušil případnou data exfiltraci. Náš tým poskytoval po telefonu konzultace v rámci aktivní governance smlouvy; technickou exekuci a forenziku zajistil interní IT klienta s podporou externího forenzního partnera.
T+8 až T+24 h: forenzní analýza
Externí forenzní partner provedl analýzu vybraných kompromitovaných hostů (RAM dump, registry, event logy, Volume Shadow Copies). Identifikoval initial access vektor, patient zero, časový průběh post-exploitation a nasazení payload. Bez této analýzy by obnova ze záloh znamenala riziko, že se obnoví prostředí, kde útočníci stále mají persistenci a po pár dnech celý cyklus zopakují.
T+24 až T+72 h: obnova z immutable backupu
Firma měla nasazený Veeam Hardened Repository v geograficky odděleném datacentru s immutable lockem na 14 dnů, architekturu navrženou v rámci našeho předchozího governance auditu. Útočníci se k němu pokusili dostat přes kompromitovaný admin účet, ale immutable flag jim zabránil zápis nebo smazání. Interní IT obnovilo všech 21 zasažených serverů z poslední čisté zálohy (zhruba 4 hodiny před šifrováním), s tím že kritické VM šly first-priority a méně důležité postupně. Souběžně klient rotoval všechna doménová hesla včetně KRBTGT (dvakrát, podle Microsoft best practice) a zrušil všechny existující Kerberos tickety.
Co fungovalo a co selhalo
| Oblast | Co fungovalo | Co selhalo |
|---|---|---|
| Zálohy | Veeam Hardened Repository, immutable 14 dnů, geograficky oddělené DC | Bez selhání v této oblasti |
| Síťová segmentace | Firewall mezi IT a OT zónou (výroba zůstala pojízdná) | Plochá Active Directory bez tieringu (Tier 0/1/2 model neexistoval) |
| Identita | Kerberos lifecycle byl funkční, šly rychle rotovat hesla i KRBTGT | Žádné MFA na RDP, žádné Conditional Access, kontraktor s trvalým přístupem |
| Detekce | Antivirový alert na Mimikatz aktivitu na DC v T-11 dnů | EDR/XDR neexistoval, antivirový alert spadl do nezpracované fronty |
| IR proces | IR runbook připravený v rámci governance, escalation matice, telefonní strom | Tabletop cvičení 0× za poslední 3 roky, vedení nevědělo, kdo komu kdy oznamuje |
| Dodavatelé | Smluvní vztah s kontraktorem umožňoval pozastavení přístupu okamžitě | Nadměrná oprávnění bez least-privilege auditu, BYOD bez kontroly |
Co si z toho odnést?
Šest poučení, která z incidentu přenášíme klientům jako součást gap analýzy a preventivní governance:
- Striktní dodavatelská governance: least privilege přístupy, pravidelný audit, BYOD restrikce
- Active Directory tiering (Tier 0/1/2 model): admin účty oddělené od denních uživatelských
- MFA a Conditional Access na všechny vzdálené přístupy včetně partnerských RDP
- EDR/XDR s aktivním monitoringem a SOC, který alerty zpracovává v reálném čase
- Immutable backup mimo doménu zasaženou útokem, pravidelně testovaný restore (ne jen že běží)
- Tabletop cvičení s vedením firmy 2× ročně: odzkoušená rozhodovací matice v krizi
Útočníkům stačí 24 hodin. Týmu bez nacvičené obnovy klidně 14 dnů. S nacvičenou 72.
Pokud potřebujete podobnou připravenost, začněte u gap analýzy, která pokryje organizační i technickou vrstvu. Pokračujte skenováním zranitelností a penetračními testy na klíčové aplikace a perimetr. Pro řízení celé bezpečnostní agendy včetně BCP/DRP a komunikace s NÚKIBem doporučujeme cyber security governance jako trvalé operativní zázemí. Pokud nemáte interní CISO ani manažera KB, pronájem bezpečnostních rolí pokrývá obě role v dohodnutém rozsahu hodin. Pro pomoc s konkrétními bezpečnostními platformami (Veeam, Fortinet, Bitdefender a další) slouží bezpečnostní poradenství. Vstupní vektor v této studii byl přesně ten typ rizika, který detailněji rozebíráme v článku o dodavatelském řetězci a NIS2.
