V prosinci 2019 se staly terčem kybernetického útoku dvě organizace. Nemocnice Rudolfa a Stefanie Benešov a těžební společnost OKD. Obě organizace byly úspěšně napadeny trojicí malwarů1 Emotet – Trickbot – Ryuk. Obě organizace byly v důsledku útoku nuceny zastavit provoz a poskytování svých služeb. Nemocnice v Benešově nefungovala téměř tři týdny a škody incidentu předběžně vyčíslila na cca 30 mil. Kč. Společnost OKD pozastavila těžbu na čtyři dny a výši škod zatím nesdělila. Lze však očekávat, že i v případě OKD půjdou škody do miliónů a ani částka sdělená nemocnicí není konečná.
nemocnice malware Emotet – Trickbot – Ryuk prevence zdravotnictví
V průběhu prosince 2019 byly ransomwarem zasaženy a paralyzovány dvě organizace. Nemocnice v Benešově s 411 lůžky a cca 760 zaměstnanci, která je spádová až pro 400 000 lidí2, a těžební společnost OKD, jediný producent uhlí v České republice se ziskem téměř 1,3 mld., vlastněný skrze společnost Prisko státem.3
Obě společnosti byly v důsledku incidentu nuceny přerušit provoz. V ČR i ve světě se s ransomwarovými útoky každodenně potýká množství organizací, nicméně tyto konkrétní incidenty neunikly pozornosti veřejnosti a médií a otevřela se otázka kybernetické bezpečnosti podobných organizací. Média věnovala hodně pozornosti zejména benešovské nemocnici, protože se útok dotkl množství občanů a ukázal reálné dopady narušení kybernetické bezpečnosti na život společnosti. Nešlo tedy o abstraktní kybernetický útok, ale o skutečné zastavení chodu organizace, což řada pacientů reálně pocítila. Incidenty se podařilo zvládnout a skutečně vážné dopady (kromě finančních) se nerealizovaly, hlavně díky tomu, že za napadenou nemocnici zastoupily jiné nemocnice a uhlí je na trhu dost, takže těžba byla před Vánoci omezena. Incidenty se podařilo zvládnout a skutečně vážné dopady (kromě finančních) se nerealizovaly, hlavně díky tomu, že za napadenou nemocnici zastoupily jiné nemocnice a uhlí je na trhu dostatek, a navíc byla těžba před Vánoci omezena. Obě organizace byly zasaženy ransomwarem Ryuk, pro který se stal vstupní branou botnet Emotet a trojský kůň Trickbot. Data podle všeho odcizena nebyla, ale jak již bylo řečeno, obě organizace to na několik dní či týdnů odstavilo z provozu.
Popis Emotet – Trickbot – Ryuk
Zvýšenou aktivitu botnetu Emotet jsme evidovali na konci října 2019 na základě vyhodnocování logů z honeypotů a sinkhole serverů našich zahraničních partnerů. Docházelo k mnohonásobně vyššímu počtu záchytů, než je obvyklé. Zároveň se objevovaly první zprávy o obnovení aktivit dříve dopadených a vypnutých C&C serverů. Výkyv v aktivitě je u botnetů běžným jevem a často je provázen paralelními událostmi, jako je např. masivní phishingová kampaň. Právě Emotet takové kampaně využívá ke svému dalšímu šíření. Zatímco dříve se phishing vyznačoval špatnou češtinou, nyní to již neplatí. Čeština se časem v těchto kampaních zlepšovala až na dnešní úroveň, kdy narážíme na e-maily psané velmi dobrou obecnou nebo spisovnou češtinou. Novým trendem, který sofistikovanost phishingových e-mailů dále zvyšuje, je využívání kompromitovaných schránek k odesílání nakažené přílohy v odpovědi na dřívější legitimní komunikaci oběti.
Phishing je jako vektor útoku dlouhodobě nejvyužívanější, v závěsu lze jmenovat ukradená či slabá hesla, zranitelné a neaktualizované služby dostupné z internetu apod. Oblíbenost phishingu má bohužel základ v neznalosti a nepozornosti uživatelů, čehož útočníci úspěšně a vytrvale využívají.
Ostatním vektorům útoku lze technicky předcházet, což markantně snižuje počet kompromitovatelných strojů. To samozřejmě neplatí pro zranitelnosti typu 0-day. Ohledně způsobu průniku Emotetu do nemocnice v Benešově nelze být v tuto chvíli konkrétnější, neboť do uzávěrky tohoto článku nebyl mechanismus průniku spolehlivě prokázán.
Emotet byl původně vytvořen jako bankovní trojan ke krádeži citlivých údajů, čísel karet nebo hesel.4 Dnes slouží primárně jako vstupní malware, který útočníkovi zajistí přístup do napadené sítě. Až ve druhé fázi dochází ke stažení trojanu Trickbot, který se postará o sběr citlivých údajů. V této druhé fázi útoku rozšiřuje Trickbot portfolio dat k exfiltraci o položky typu peněženek kryptoměn, což také koresponduje s trendy v době jeho vzniku v roce 2016.5 Jeho zdrojový kód je neustále zdokonalován, např. po zveřejnění zranitelnosti EternalBlue byl schopen vlastního laterálního pohybu, a i nadále mu přibývají nové funkce. Útočník s takto širokou paletou dat může jednoduše zničit reputaci instituce nebo jí způsobit vážné finanční potíže.
Pro běžného uživatele je v případě nákazy Trickbotem obtížné vypozorovat nezvyklé chování počítače. Je pravděpodobnější, že nákazu zaznamená síťový administrátor v momentě, kdy počítač kontaktuje podezřelou adresu C&C serveru při exfiltraci dat či při dotazu na další instrukce. Jen málokterý uživatel je schopen škodlivou aktivitu detekovat přímo na nakaženém stroji. V tento moment už ale často dochází k velmi rozšířené a v některých případech úplné kompromitaci sítě. Malware totiž dokáže v produkční síti strávit bez detekce až několik měsíců a při tom kontinuálně sbírat informace. Po exfiltraci dat a kompromitaci důležitého prvku sítě útočníci přistoupí k poslednímu a z jejich pohledu i logickému kroku, kterým je spuštění ransomwaru.
V Benešovské nemocnici došlo ke stažení ransomwaru Ryuk6, který postupně mapuje všechna možná síťová úložiště na privátních adresách a šifruje na nich silnými klíči RSA-4096 a AES-256. Šifrují se buď všechna data, nebo pouze výběr souborů s předem definovanými příponami. Takto zašifrované soubory není v dnešní době možné v reálném čase bez znalosti klíčů dešifrovat. Ryuk je poměrně mladý malware, který byl poprvé zaznamenán přibližně v polovině roku 2018. Antivirové společnosti ale zjistily, že jeho zdrojový kód vychází z dřívějšího ransomwaru Hermes a považují jej za další iteraci kódu. V raných verzích Ryuk zanechal – nejčastěji na ploše – soubor s kontaktem, instrukcemi k platbě, bitcoin peněženkou a dalším textem. Tím bylo možné vysledovat, že ransomware Ryuk díky své činnosti vydělal útočníkům až 4 mil. $. V reakci začali útočníci na zašifrovaných strojích zanechávat pouze kontaktní e-mailovou adresu, kam se má vydíraný ozvat. V rámci konverzace byly oběti zaslány ukázky dešifrovaných souborů a po platbě i dešifrovací nástroj. S nástrojem pro dešifrování však často nastával problém a soubory zůstaly oběti nečitelné. Zde se již můžeme jen domnívat, zda byla v dešifrovacím programu pouze obyčejná chyba nebo zda útočníci zaslali pouze ukázku exfiltrovaných dat a záměrně po platbě předali nefunkční nástroj. I z tohoto důvodu se nedoporučuje útočníkům jakékoli výkupné platit. Dalším důvodem je nepřímá podpora útočníka a jeho finančních možností při rozšiřování infrastruktury.
Na základě rychlé komunikace zejména ze strany DPO (data protection officer) benešovské nemocnice se podařilo poměrně rychle získat základní informace o incidentu a situaci na místě. Díky tomuto podnětu Národní úřad pro kybernetickou a informační bezpečnost do řešení incidentu v benešovské nemocnici zapojil analytiky, kteří svými schopnostmi pokrývali oblasti Windows domény, Windows stanic, forenzní analýzy Windows a Linux, síťového provozu a monitoringu a virtualizace infrastruktury. V rámci incident response týmů, které jsou vysílány na místo útoku, je standardně zastoupen vedle jiných analytiků také forenzní specialista, neboť většinou na počátku řešení incidentu není dostatek informací o situaci, typu útoku či rozsahu zasažení.
Forenzní specialista se zaměřuje na zajištění důkazů, zejména aby byly použitelné v dalším vyšetřování, případně v trestním řízení. Při zajišťování je potřeba dodržet postupy, které zajistí důvěryhodnost a integritu dat. Forenzní speci alista má mimo jiné za úkol pomoci s čištěním infikovaných strojů, hledáním persistencí malwaru a analýzou prostředí. Svůj tým malware analytiků vyslal i dodavatel antivirového řešení a jeho členové na místě analyzovali infrastrukturu a vzorky malwaru. Po počáteční analýze situace, prostředí a rozsahu škod byl společně s dodavateli infrastruktury a zaměstnanci nemocnice vytvořen plán na postupnou obnovu infrastruktury. Paralelně s tím na pracovišti NÚKIB probíhala síťová a forenzní analýza, díky které se dokázala určit šíře nákazy, persistence malwaru a indikátory kompromitace. Zejména díky indikátorům kompromitace, které se v co nejkratší době distribuovaly organizacím v kompetenci NÚKIB, se zamezilo podobné nákaze u jiné organizace. Mezi indikátory kompromitace patří nejčastěji IP adresy, domény a hashe nástrojů malwaru.
Kromě indikátorů kompromitace se zjišťovala zejména doba, po jakou byly systémy infikovány. Obvyklou chybou bývá, že správci obnoví infikované zálohy, a pokud nedojde k úpravám sítě, tak se po připojení infrastruktury k internetu nákaza opět stává aktivní a může znovu vyeskalovat v šifrování dat. Demotivační účinek takové události bývá drastický, pokud vezmeme v potaz, že obnova infrastruktury může zabrat měsíce. To se v případě benešovské nemocnice naštěstí nestalo.
Incident response tým opustil nemocnici až poté, když si byl jist, že jsou nastaveny bezpečné procesy na obnovu stanic, serverů a dat. Po celou dobu konzultoval s administrátory budoucí bezpečnostní politiky, segmentaci, problémy systémů, které nelze aktualizovat, a mnoho dalších témat bezpečnosti a IT obecně. Analýzou dostupných a zajištěných dat nebylo prokázáno narušení důvěrnosti či integrity informací zpracovávaných v zasažených systémech nemocnice.
Doporučení k prevenci a řešení těchto typů incidentů
Vzhledem k výše popsané jednoduchosti šíření těchto typů incidentu a jejich dopadům je velmi důležitá prevence a ochrana. U toho je třeba myslet na dvě základní oblasti. První z nich cílí na to, aby se incident vůbec nestal. Druhá oblast řeší otázku co dělat, až se to stane. Tato oblast by měla být pojata komplexně a neměla by se omezovat pouze na IT procesy.
Preventivní opatření
Základním opatřením při zavádění bezpečnosti je zejména vůle vedení. Pokud taková podpora chybí, je zavádění bezpečnostních opatření velmi složité.
- Zálohování
Je třeba vytvářet pravidelné zálohy, které budou odděleny od provozních systémů a nebudou připojeny do sítě (offline zálohy). Tyto zálohy by měly být ukládány na geograficky oddělených lokalitách. Samotné zálohování však nestačí, zálohy musí být pravidelně testovány. Situaci, kdy při incidentu zálohy nejdou obnovit, nechce zažít asi nikdo. - Monitoring
Napadení systému nemusí být hned zřejmé, protože útočníci často v síti nějakou dobu vyčkávají. Proto je třeba detekovat a vyhodnocovat činnosti uživatelů a provoz v síti. Vzhledem k tomu, že útočníci jsou schopni nepozorovaně v systému vyčkávat, může dojít i ke kompromitaci záloh. Pokud se organizace o svém napadení nedozví včas, nemusí zálohy vždy pomoci. - Segmentace sítě
Síť by měla být segmentovaná a kancelářská (internetová) síť by měla být oddělena od ostatních (produkčních) sítí. Měly by být vytvořeny různé segmenty sítě s různými bezpečnostními pravidly a omezeními. - Aktualizace softwaru
Používání neaktuálního či nelegálního softwaru je poměrně rozšířené a velmi nebezpečné. Bezpečnostní aktualizace je třeba instalovat co nejdříve po jejich vydání. V určitých specifických systémech může být aktualizace složitá či nemožná (technická zdravotnická zařízení jsou často v provozu mnohem déle, než je životní cyklus běžného IT). V takovém případě je třeba mít tato zařízení v separátní síti bez vnějšího připojení a věnovat těmto zařízením zvýšenou pozornost. - Odstranění nezabezpečených přístupů
Nepotřebné nebo nezabezpečené přístupy by měly být odstraněny a zakázány. Pro vzdálený přístup do systému by měla být používána VPN přiřazená konkrétnímu uživateli. To platí zejména pro dodavatele. - Školení uživatelů
Obecná pravda, že největší hrozbou jsou uživatelé, stále platí. I nejlepší technické opatření tak může být neúčinné, pokud se střetne s uživateli. Jsou často první, kdo se s útokem setká, a je třeba, aby v takovém případě věděli, jak útok poznat a jak se v takovém případě správně zachovat. Proto je třeba uživatele proškolit alespoň tak, aby si byli vědomi základních rizik v kyberprostoru, základních bezpečnostních zásad, jak vypadá nestandardní chování systému a kam se mají obracet v případě takové situace. - Makra v MS Office
Makra v MS Office jsou velmi často vektorem útoku. Pokud s nimi uživatelé nemusí pracovat, je vhodné makra úplně zakázat.
Reakce
V případě přípravy reakce na incident je třeba myslet na celou řadu oblastí a každá organizace by primárně měla mít zavedeny plány a opatření pro zajištění kontinuity činností. Vedle plánů a postupů obnovy služeb je třeba mít stanovené správné postupy také v oblasti komunikace. V případě realizace incidentu je třeba komunikovat se zákazníky, dodavateli, médii a v některých případech také policií a regulátory.
- Kontinuita činností
V rámci přípravy na incidenty je nezbytné mít zpracovaný plán kontinuity činností, který poskytne odpověď na otázky týkající se obnovy systému a fungování organizace. Minimální požadavky na řízení kontinuity činností poskytuje např. §15 vyhlášky č. 82/2018 Sb., o kybernetické bezpečnosti. Organizace musí stanovit práva a povinnosti jednotlivých rolí (administrátoři, bezpečnostní role, management), vyhodnotit dopady incidentů v systémech a tyto systémy prioritizovat. Dále je třeba určit minimální úrovně poskytovaných služeb, které jsou přijatelné pro užívání, provoz a správu informačního a komunikačního systému, dobu obnovení chodu, během níž bude po kybernetickém bezpečnostním incidentu obnovena minimální úroveň poskytovaných služeb informačního a komunikačního systému, a bodu obnovení dat jako časového období, za které musí být zpětně obnovena data po kybernetickém bezpečnostním incidentu nebo po selhání. Tato oblast je velmi důležitá. Mnohé organizace se nikdy nezabývaly důležitostí informačních systémů pro jejich činnost, a tak někdy ani neví, jak jsou pro ně důležité. - Komunikační strategie
Pokud nastane incident, je třeba jej vhodně komunikovat, a to nejen vně, ale také uvnitř organizace. V rámci komunikační strategie je třeba stanovit zejména kdo, o čem, kdy a s kým bude komunikovat.- Kdo – Je třeba stanovit, kdo bude za organizaci komunikovat. Pokud půjde o více osob, je třeba zajistit jejich koordinaci a sjednotit informace. Zaměstnanci by měli vědět, kdo za organizaci komunikuje s jednotlivými zainteresovanými stranami. Informace, které jednotliví aktéři dostávají, nesmějí být v rozporu. Jediný rozdíl by měl být v úrovni detailu. Pokud lze předpokládat, že o incidentu bude komunikovat také osoba mimo organizaci (např. zástupce zřizovatele), je nezbytné zajistit jejich koordinaci.
- O čem – Každý, kdo má pravomoc za organizaci komunikovat, by měl vědět, o jakých oblastech může hovořit a do jakých detailů. Mělo by být zajištěné pravidelné reportování, které bude dodáno všem ve stejný čas. Ideálním řešením je jednotný kontaktní bod, u kterého se budou informace scházet a který je bude dále předávat např. tiskovému oddělení, vedení společnosti, zaměstnancům a dalším zainteresovaným stranám.
- Kdy – Kritická část celé komunikace tkví zejména v jejím spuštění. Dojde-li k podobnému incidentu s viditelným dopadem (tady zastavení služeb), je více než vhodné o tom ze strany organizace informovat co nejdříve. Pokud organizace promešká možnost o incidentu informovat jako první, dostává se do nevýhodné pozice, kdy na ni začínají dopadat dotazy médií, veřejnosti a dalších subjektů a ona přestane řídit situaci. Pokud o incidentu bude informovat dostatečně, bude demonstrovat, že o incidentu ví a že jej dokáže vyřešit.
- S kým – Každý zaměstnanec by měl vědět, zda a s kým může o incidentu komunikovat a do jakého detailu. Komunikace s úřady Specifickou oblastí je komunikace s úřady. Určité kybernetické incidenty je totiž třeba hlásit relevantním úřadům. Téměř jistá je v případě tohoto typu kybernetického incidentu v nemocnici komunikace s Úřadem pro ochranu osobních údajů. Další organizací, kterou je v takovém případě vhodné oslovit, je Policie ČR. Pravděpodobně se totiž bude jednat o trestný čin neoprávněného přístupu k počítačovému systému a nosiči informací podle § 230 trestního zákoníku.
Pokud je incidentem zasažena organizace, která je zařazena do kritické informační infrastruktury, správce významného informačního systému nebo mezi provozovatele základních služeb podle zákona č. 181/2014 Sb., o kybernetické bezpečnosti (dále jen zákon), musí být incident oznámen Národnímu úřadu pro kybernetickou a informační bezpečnost. Pokud organizace pod zákon nespadá, povinnost hlásit incident nemá, ale ohlásit jej může. Vládní CERT, specializované pracoviště NÚKIB s technickými kapacitami k řešení incidentů v souladu s písm. l) § 20 b) zákona, přijímá hlášení o kybernetickém bezpečnostním incidentu od orgánů a osob, které pod zákon nespadají, a tato hlášení zpracovává, pokud to jeho kapacity umožňují. Jedná-li se o kybernetický bezpečnostní incident s významným dopadem, poskytuje organizacím dotčeným kybernetickým bezpečnostním incidentem metodickou podporu, pomoc a součinnost. Pokud to tedy kapacity Vládního CERT dovolí, bude se incidentem zabývat a může jej pomoci vyřešit, jako se tomu stalo v případě incidentů v benešovské nemocnici a OKD. Je však třeba dodat, že Vládní CERT není dodavatelem IT systémů, a tedy nenahradí samotné techniky dotčené organizace nebo její dodavatele.
Incidenty lze také hlásit Národnímu CERTu, který provozuje sdružení CZ.NIC a který má možnost přijímat hlášení kybernetických bezpečnostních incidentů upravenou obdobně jako Vládní CERT (§ 17 písm. l zákona).7
Závěr
Podobný incident může zasáhnout prakticky každou organizaci. Ten prosincový v benešovské nemocnici ukázal, že kyberprostor, resp. jeho narušení, může mít vážné dopady na reálný svět, a to i v odvětví, kde je vysoký podíl lidské práce a poměrně nízká automatizace, jako např. zdravotnictví. Význam kyberprostoru a dopady jeho narušení se i díky otevřenému přístupu nemocnice a medializaci dostaly do širšího povědomí veřejnosti. Uvidíme, zda se z incidentu ostatní organizace poučí a zda nakonec dojde ke zvýšení kybernetické bezpečnosti zdravotnických i jiných zařízení.
Poznámky pod čarou:
- Pro účely tohoto článku bereme pojem malware jako široký zastřešující termín pro všechny možné typy škodlivých kódů (např. trojan, worn, dialer, spyware, ransomware atd.)
- Výroční zpráva Nemocnice Rudolfa a Stefanie Benešov, a.s. https://www.hospital-bn.cz/o-nas/vyrocni-zpravy/
- Výroční zpráva OKD, a.s. za rok 2018 https://www.okd.cz/cs/o-nas/vyrocni-zpravy
- The Evolution of Emotet: From Banking Trojan to Threat Distributor https://www.symantec.com/blogs/threat-intelligence/evolution-emotet-trojan-distributor
- Trickbot, Technical Analysis of a Banking Trojan Malware https://www.sentinelone.com/blog/trickbot-technical-analysis-banking-trojan-malware/
- Threat spotlight: the curious case of Ryuk ransomware https://blog.malwarebytes.com/threat-spotlight/2019/12/threat-spotlight-the-curious-case-of- -ryuk-ransomware/
- https://csirt.cz/cs/
Použité zdroje:
[ 1 ] The Evolution of Emotet: From Banking Trojan to Threat Distributor https://www.symantec.com/blogs/threat-intelligence/evolution-emotet-trojan-distributor
[ 2 ] Trickbot | Technical Analysis of a Banking Trojan Malware https://www.sentinelone.com/blog/trickbot-technical-analysis-banking-trojan-malware/
[ 3 ] Threat spotlight: the curious case of Ryuk ransomware https://blog.malwarebytes.com/threat-spotlight/2019/12/threat-spotlight-the-curious-case-of-ryuk-ransomware/
[ 4 ] Zákon č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů (zákon o kybernetické bezpečnosti)
[ 5 ] Vyhláška č. 82/2018 Sb., vyhláška o bezpečnostních opatřeních, kybernetických bezpečnostních incidentech, reaktivních opatřeních, náležitostech podání v oblasti kybernetické bezpečnosti a likvidaci dat (vyhláška o kybernetické bezpečnosti)
[ 6 ] ISO 22301 – Systém managementu kontinuity podnikání (BCM)
[ 7 ] Bezpečnostní doporučení NÚKIB pro administrátory 3.0, https://www.govcert.cz/download/doporuceni/NUKIB_doporuceni_admin_3.0_CB.pdf
[ 8 ] Doporučení pro mediální komunikaci, verze 2.0 https://www.govcert.cz/cs/informacni-servis/doporuceni/2699-doporuceni-pro-medialni-komunikaci-verze-2-0/
[ 9 ] Contingency Planning Guide for Federal Information Systems https://csrc.nist.gov/publications/detail/sp/800-34/rev-1/final
[ 10 ] Výroční zpráva OKD, a.s. za rok 2018 https://www.okd.cz/cs/o-nas/vyrocni-zpravy
[ 11 ] Výroční zpráva Nemocnice Rudolfa a Stefanie Benešov, a.s. https://www.hospital-bn.cz/o-nas/vyrocni-zpravy/