Obnova po ransomware útoku: ako zistiť, ktorej zálohe možno dôverovať

Zálohovanie patrí k základom kybernetickej bezpečnosti. Keď však príde skutočný incident, existencia zálohy ešte neznamená, že sa firma môže bezpečne vrátiť do prevádzky. Rozhodujúce je vedieť, kedy sa kompromitácia začala, čo všetko útočník ovplyvnil a ktorému bodu obnovy možno dôverovať.

V nedeľu 24. augusta 2025 začali v americkom štáte Nevada vypadávať informačné systémy. Virtuálne servery prestali fungovať, niektoré služby boli nedostupné a vyšetrovatelia objavili zašifrované súbory aj správu s požiadavkou na výkupné.

Na prvý pohľad išlo o typický ransomvérový incident. Útok sa prejavil, systémy boli zasiahnuté a nastal čas obnovovať prevádzku.

Lenže vyšetrovanie odhalilo zásadnú skutočnosť: útočník sa do prostredia dostal už 14. mája 2025, teda viac než tri mesiace pred viditeľným útokom.

Počas nasledujúcich týždňov si udržiaval prístup, získaval prihlasovacie údaje, zvyšoval oprávnenia a presúval sa medzi systémami. Bezpečnostný nástroj síce v júni zachytil pôvodný škodlivý program, skrytý prístup však pretrval. V auguste útočník prenikol aj k citlivým systémom a pred spustením ransomvéru odstránil zálohovacie zväzky.

Podľa oficiálnej správy trvala obnova zasiahnutých služieb 28 dní. Nevada nevyplatila výkupné, no na riešenie incidentu musela vynaložiť značné personálne aj externé kapacity.

Tento prípad otvára otázku, ktorá je pre bezpečnostné tímy často náročnejšia než samotné obnovenie dát: Ak sa útok prejavil v auguste, ale kompromitácia sa začala v máji, do ktorého momentu je ešte bezpečné vrátiť systémy?

Najnovšia záloha nemusí byť najdôveryhodnejšia

Pri bežnom technickom výpadku býva rozhodovanie pomerne priamočiare. Ak zlyhá server alebo dôjde k poškodeniu dát, IT tím spravidla hľadá poslednú funkčnú zálohu a snaží sa minimalizovať stratu dát aj čas nedostupnosti.

Pri kybernetickom incidente však platia iné pravidlá.

Predstavme si, že firma v piatok ráno zistí zašifrované produkčné systémy. K dispozícii má zálohy zo štvrtka, stredy, pondelka a predchádzajúceho piatka.

Ktorú by ste obnovili?

Prvá odpoveď bude pravdepodobne štvrtkovú. Je najaktuálnejšia a jej použitím by firma prišla o najmenej dát.

Potom však príde nová informácia: prvý kompromitovaný používateľský účet sa objavil už pred dvanástimi dňami. Vybrali by ste si stále tú istú zálohu?

Nie je to otázka s jedinou univerzálnou odpoveďou. Záloha vytvorená po prvotnom prieniku nemusí byť automaticky nepoužiteľná. Rovnako však nemožno predpokladať, že je bezpečná len preto, že sa dá technicky obnoviť.

Útočník mohol medzičasom vytvoriť nové účty, zmeniť oprávnenia, upraviť konfiguráciu služieb alebo umiestniť do prostredia mechanizmus, ktorý mu umožní opätovný prístup.

Technicky úspešná obnova tak ešte nemusí znamenať odstránenie kompromitácie.

Dátum odhalenia nie je dátum začiatku útoku

Ransomvér je často až poslednou, najviditeľnejšou fázou incidentu. Predchádzať mu môže obdobie, počas ktorého útočník nenápadne zisťuje, ako prostredie funguje, kde sa nachádzajú citlivé dáta a aké má možnosti pohybu.

Preto je pri obnove dôležité spätne rekonštruovať časovú os.

Bezpečnostný tím sa musí pýtať nielen na to, kedy boli systémy zašifrované, ale aj na to, kedy sa objavili prvé neobvyklé prihlásenia, zmeny oprávnení, nové vzdialené prístupy či podozrivé zásahy do konfigurácie.

Práve tu získavajú zásadný význam bezpečnostné logy.

Záznamy o prihláseniach, činnosti privilegovaných účtov, systémových zmenách a bezpečnostných udalostiach môžu pomôcť poskladať udalosti do súvislostí. Jednotlivý záznam nemusí byť sám osebe podozrivý. Až jeho spojenie s ďalšími udalosťami môže ukázať, že nejde o bežnú administrátorskú aktivitu.

Napríklad prihlásenie správcu mimo pracovného času nemusí automaticky znamenať incident. Ak však po ňom nasleduje zmena oprávnení, vytvorenie novej služby a prístup k zálohovaciemu serveru, bezpečnostný význam celej sekvencie sa mení.

Problém nastáva, keď tieto informácie nie sú dostupné.

Útočníci sa totiž môžu pokúsiť odstrániť stopy svojej činnosti. Aj v prípade Nevady vyšetrovanie zaznamenalo mazanie udalostných logov. Ak organizácia uchováva záznamy iba na systémoch, ktoré útočník ovládol, môže o dôležitú časť dôkazov prísť práve vo chvíli, keď ich najviac potrebuje.

Zber logov preto nestačí. Dôležitá je aj ich ochrana, dostupnosť a schopnosť vyhodnotiť ich v kontexte ďalších informácií.

Ako určiť bod obnovy, ktorému možno dôverovať

Rozhodovanie o obnove je v praxi kombináciou technickej analýzy a riadenia rizika.

Bezpečnostný tím potrebuje najskôr pochopiť rozsah incidentu. Nestačí identifikovať zašifrované servery. Treba preveriť, ktoré účty boli kompromitované, aké oprávnenia útočník získal a či mohol zasiahnuť aj systémy používané na zálohovanie alebo správu infraštruktúry.

Následne prichádza otázka integrity dostupných záloh.

Bezpečnostné skenovanie môže pomôcť identifikovať podozrivé alebo škodlivé súbory v zálohovaných dátach. Samotný výsledok skenovania však nemusí zachytiť všetky formy kompromitácie.

Záloha totiž môže obsahovať dáta bez zisteného škodlivého kódu, ale súčasne aj neželané zmeny konfigurácie, upravené oprávnenia alebo účty vytvorené útočníkom. Tie nemusia byť pri bežnej kontrole súborov rozpoznané ako malvér.

Preto je potrebné vyhodnocovať viacero typov informácií spoločne.

Ak bezpečnostné logy naznačujú, že k zmene privilegovaných účtov došlo v utorok, a zálohovací systém uchováva body obnovy z pondelka a stredy, tieto informácie môžu významne ovplyvniť ďalší postup.

Stredajšia záloha môže obsahovať zmeny vykonané útočníkom. Pondelková môže predstavovať vhodnejší východiskový bod, no aj ten musí prejsť ďalším overením.

Nie vždy je cieľom nájsť jeden absolútne „čistý“ dátum. Často ide o postupné znižovanie neistoty a výber takého stavu, pri ktorom má organizácia dostatočné dôkazy na prijatie rizika obnovy.

Dôležité je tiež rozlišovať medzi obnovou dát a obnovou dôveryhodnosti celého systému. Tieto dve úlohy spolu súvisia, ale nie sú totožné.

Kedy obnovovať a kedy radšej vybudovať systém nanovo?

Pri incidente môže byť najrýchlejšou cestou obnovenie celého virtuálneho servera zo zálohy. Nemusí to však byť vždy najbezpečnejší postup.

Ak má tím dôvodné podozrenie, že útočník získal administrátorské oprávnenia, upravil systémové komponenty alebo vytvoril mechanizmy trvalého prístupu, obnova pôvodného systémového obrazu môže preniesť problém späť do produkcie.

V takom prípade môže byť vhodnejšie vybudovať systém nanovo z dôveryhodných inštalačných zdrojov, bezpečne nastaviť konfiguráciu a obnoviť iba potrebné, overené dáta.

Rozhodnutie medzi obnovou a novým vybudovaním systému závisí od viacerých faktorov: typu kompromitácie, kvality dostupných dôkazov, dôveryhodnosti systémového obrazu, kritickosti služby aj času potrebného na jednotlivé varianty.

Inak sa bude postupovať pri bežnom súborovom serveri, inak pri doménovom radiči, databázovom systéme alebo serveri, na ktorom útočník získal najvyššie oprávnenia.

Zásadná otázka znie: Dokážeme primerane overiť integritu systému, ktorý sa chystáme vrátiť do prevádzky?

Ak odpoveď nie je dostatočne podložená, rýchla obnova môže vytvoriť iba dočasný pocit vyriešeného problému.

Pred návratom do produkcie nestačí overiť, že systém funguje

Úspešné spustenie aplikácie alebo databázy je dôležitý krok. Nie je to však koniec bezpečnostnej obnovy.

Pred návratom do bežnej prevádzky potrebuje tím primerane overiť, že boli odstránené identifikované prístupy útočníka, preverili sa kompromitované účty a prihlasovacie údaje a že obnovené prostredie neobsahuje známe mechanizmy opätovnej kompromitácie.

Rovnako dôležité je skontrolovať relevantné konfigurácie, sieťové prístupy a bezpečnostné opatrenia. Obnovené systémy by mali byť monitorované tak, aby bolo možné zachytiť prípadnú pokračujúcu podozrivú aktivitu.

Súčasťou rozhodovania je aj biznisový kontext.

Nie všetky systémy musia byť obnovené naraz. Organizácia potrebuje určiť priority podľa toho, ktoré služby sú nevyhnutné na zachovanie prevádzky a ktoré možno bezpečne spúšťať postupne.

Pri výrobnom podniku môže ísť o systémy riadiace výrobu a logistiku. V nemocnici o dostupnosť kľúčových zdravotníckych aplikácií. V poskytovateľskej firme o systémy potrebné na obsluhu zákazníkov.

Bezpečnosť a rýchlosť obnovy preto nemožno posudzovať oddelene. Cieľom je dostať kritické služby späť do prevádzky čo najskôr, ale bez zbytočného rizika, že sa incident zopakuje.

Problémom bývajú informácie rozdelené medzi rôzne systémy

V mnohých organizáciách existujú potrebné informácie, no sú roztrúsené medzi viacerými nástrojmi.

Zálohovací systém ukazuje dostupné body obnovy. Bezpečnostné nástroje upozorňujú na podozrivé udalosti. Logy obsahujú záznamy o prihláseniach a systémových zmenách. IT administrátori majú ďalšie informácie o konfiguráciách a prevádzke.

Počas incidentu je však potrebné tieto informácie rýchlo spojiť.

Práve vtedy sa ukazuje, aké dôležité je pripravovať sa na obnovu ešte pred útokom. Ak sa tím začne až počas krízovej situácie rozhodovať, kde nájde potrebné logy, kto má prístup k zálohám a ako bude overovať ich použiteľnosť, stráca čas.

Hodnota preto nespočíva iba v samotnom zálohovaní alebo samostatnej detekcii hrozieb, ale aj v schopnosti vytvoriť z dostupných údajov použiteľný obraz incidentu.

Prečo IXPERTA prepája zálohy, bezpečnostnú analýzu a logy

Na túto potrebu reaguje aj riešenie IXTRUST spoločnosti IXPERTA.

Jeho východiskom je, že bezpečná obnova po kybernetickom incidente si vyžaduje viac než samotnú dostupnosť záloh. Organizácia potrebuje lepšie rozumieť ich bezpečnostnému stavu a zároveň mať k dispozícii relevantné informácie o udalostiach, ktoré incidentu predchádzali.

IXTRUST preto prepája bezpečné zálohovanie, bezpečnostné skenovanie záloh a prácu s bezpečnostnými logmi.

Rozšírené možnosti služby zahŕňajú zber a chránené uchovávanie logov, analýzu bezpečnostných udalostí a ich vyhodnocovanie v súvislosti so zálohovanými dátami. Tieto informácie môžu pomôcť pri rekonštrukcii incidentu, identifikácii potenciálnych hrozieb a výbere vhodného bodu obnovy.

Nejde o automatickú záruku, že každá obnovená záloha bude bezpečná. Ide o poskytovanie kvalitnejších podkladov pre odborné rozhodovanie v situácii, keď na správnom postupe závisí dostupnosť celej organizácie.

Takýto prístup je relevantný najmä tam, kde je výpadok IT priamo spojený s prerušením výroby, poskytovania služieb alebo iných kritických procesov.

Otázka, ktorú by si mal položiť každý CISO

Prípad Nevady ukazuje, že viditeľný kybernetický útok môže byť vyvrcholením udalostí, ktoré sa začali dávno predtým. Ukazuje tiež, že útočník sa nemusí zamerať iba na produkčné dáta, ale aj na samotné možnosti obnovy.

Pre bezpečnostné tímy z toho vyplýva dôležitá zmena uvažovania.

Nestačí vedieť, ako často sa zálohuje a či posledný test obnovy prebehol úspešne. Potrebné je rozumieť aj tomu, ako organizácia pri incidente určí rozsah kompromitácie, ako získa dôveryhodné informácie o minulých udalostiach a podľa čoho rozhodne o návrate systémov do prevádzky.

Najnovšia záloha nemusí byť najbezpečnejšia. A technicky úspešná obnova nemusí automaticky znamenať bezpečný návrat.

Preto by si každý CISO mal položiť jednu praktickú otázku:

Dokážeme v prípade skutočného incidentu obhájiť, prečo dôverujeme práve tomu bodu obnovy, ktorý sme si vybrali?

Ak odpoveď stojí iba na tom, že ide o poslednú dostupnú zálohu, možno je čas prehodnotiť, ako firma prepája zálohovanie, bezpečnostné logy a pripravenosť na obnovu.

IXPERTA sa venuje kybernetickej bezpečnosti, ochrane dát a prevádzkovej odolnosti IT prostredí. Jej riešenie IXTRUST prepája zálohovanie, bezpečnostné skenovanie záloh a analýzu logov s cieľom poskytnúť organizáciám lepšie podklady na bezpečnú obnovu po incidente.