Case study po ataku ransomware w firmie MŚP

W poniedziałek o 7:40 pracownicy nie mogli otworzyć folderów z zamówieniami, a system księgowy wyświetlał komunikat o błędzie. Kilka minut później na ekranach serwerów pojawiła się informacja o zaszyfrowanych danych i żądaniu okupu. Ten case study po ataku ransomware opisuje modelowy, ale oparty na typowym przebiegu incydentu scenariusz w firmie MŚP. Nie chodzi w nim o spektakularny atak, lecz o decyzje, które w pierwszych godzinach przesądzają o skali przestoju i kosztach powrotu do działania.

Firma zatrudniała około 70 osób, korzystała z serwera plików, kilku aplikacji biznesowych, Microsoft 365 oraz zdalnego dostępu dla części zespołu. Miała kopie zapasowe, ale nie sprawdzała regularnie, czy można z nich odtworzyć wszystkie krytyczne systemy. To częsta sytuacja: backup istnieje, lecz jego użyteczność podczas realnego incydentu pozostaje niepotwierdzona.

Case study po ataku ransomware: pierwsze 24 godziny

Atak nie zaczął się od szyfrowania plików. Wcześniej napastnik uzyskał dostęp do konta użytkownika – prawdopodobnie przez wiadomość phishingową lub przejęte hasło użyte poza firmą. Następnie poruszał się po środowisku, wyszukiwał serwery, udziały sieciowe i konta z podwyższonymi uprawnieniami. Dopiero gdy miał odpowiedni dostęp, uruchomił szyfrowanie.

To rozróżnienie ma znaczenie. Komunikat z żądaniem okupu jest widocznym skutkiem ataku, a nie jego początkiem. Jeśli firma skupi się wyłącznie na przywróceniu plików, może pominąć aktywne konto napastnika, złośliwe mechanizmy uruchamiania lub wykradzione dane. W efekcie problem może wrócić po kilku dniach albo podczas odtwarzania środowiska.

Pierwsza właściwa decyzja polegała na odłączeniu podejrzanych komputerów i serwerów od sieci, bez ich pochopnego wyłączania. Izolacja zatrzymuje możliwość dalszego rozprzestrzeniania się ataku, a pozostawienie systemu w stanie działania może ułatwić zebranie śladów potrzebnych do analizy. Zakres działań zależy jednak od sytuacji: czasem należy odciąć pojedyncze urządzenie, a czasem segment sieci lub zdalny dostęp.

Równolegle zespół ustalił prosty, biznesowy priorytet: które usługi muszą wrócić jako pierwsze, aby firma mogła realizować zamówienia, wystawiać dokumenty i komunikować się z klientami. Nie wszystkie systemy mają tę samą wartość w pierwszej dobie incydentu. Odtworzenie środowiska powinno wynikać z potrzeb operacyjnych, a nie z kolejności alfabetycznej serwerów na liście administratora.

Co należało zabezpieczyć przed odbudową

Przed uruchomieniem odtwarzania należało zachować logi z serwerów, zapór sieciowych, Microsoft 365 i urządzeń końcowych. Logi są zapisem zdarzeń: pokazują między innymi nietypowe logowania, uruchomione procesy, zmiany uprawnień czy komunikację z podejrzanymi adresami.

W praktyce szczególnie istotne były odpowiedzi na kilka pytań. Kiedy pojawiło się pierwsze nietypowe logowanie? Które konta administracyjne zostały użyte? Czy napastnik uzyskał dostęp do poczty lub danych w chmurze? Czy prócz szyfrowania doszło do kopiowania danych na zewnątrz?

Ostatnie pytanie jest często pomijane. Współczesne grupy ransomware mogą najpierw kraść dane, a dopiero później szyfrować zasoby. Z tego powodu przywrócenie pracy systemów nie zamyka incydentu. Firma powinna nadal oceniać potencjalny wpływ na informacje, klientów i obowiązki formalne, najlepiej z udziałem właściwych osób technicznych, zarządczych oraz – gdy sytuacja tego wymaga – prawnych.

Dlaczego sam backup nie rozwiązał problemu

Firma miała kopie zapasowe, ale część z nich była dostępna z poziomu infrastruktury objętej atakiem. To zwiększa ryzyko, że napastnik mógł je usunąć, zaszyfrować albo pozostawić w nich złośliwy kod. W tym przypadku dostępna była też oddzielona kopia starsza o kilka dni. Pozwoliła rozpocząć odtwarzanie, ale oznaczała konieczność ręcznego uzupełnienia części danych operacyjnych.

To pokazuje podstawowy kompromis. Kopia offline lub logicznie odseparowana lepiej chroni przed ransomware, ale może wymagać bardziej przemyślanego procesu obsługi. Sama liczba backupów nie jest najważniejsza. Liczy się to, czy firma zna ich zakres, czas potrzebny na odtworzenie i potrafi odtworzyć system w praktyce.

Przed przywróceniem danych zespół przygotował czyste środowisko dla najważniejszych usług. Zresetowano hasła uprzywilejowane, przejrzano konta administracyjne, ograniczono zdalny dostęp i sprawdzono konfigurację mechanizmów wieloskładnikowego uwierzytelniania. Nie warto odtwarzać systemu do takiego samego stanu, który umożliwił atak.

Odbudowa w kolejności biznesowej

Najpierw przywrócono podstawowe usługi tożsamości i bezpieczny dostęp administratorów. Następnie uruchomiono system obsługi zamówień, serwer plików z dokumentacją bieżących zleceń oraz pocztę dla zespołów mających kontakt z klientami. Dopiero potem wracały systemy pomocnicze i archiwalne zasoby.

Przy każdym etapie weryfikowano, czy system działa poprawnie i czy nie pojawiają się oznaki ponownej aktywności napastnika. To spowalnia proces w porównaniu z mechanicznym odtworzeniem wszystkiego naraz, ale ogranicza ryzyko odtworzenia infekcji lub przeoczenia nieuprawnionego dostępu.

Co monitoring 24/7 mógł wykryć wcześniej

W analizowanym scenariuszu sygnały ostrzegawcze prawdopodobnie pojawiły się przed szyfrowaniem. Mogły to być logowanie do poczty z nietypowej lokalizacji, użycie konta poza normalnymi godzinami pracy, próby dostępu do wielu serwerów, zmiany w uprawnieniach lub masowe operacje na plikach.

Pojedynczy alert nie musi oznaczać ataku. Administratorzy MŚP często spotykają fałszywe alarmy, błędy konfiguracji i zwykłe zdarzenia operacyjne. Wartość daje dopiero analiza alertów w kontekście całego środowiska. MDR łączy wykrywanie zagrożeń z oceną ich znaczenia i reagowaniem na incydenty, aby podejrzane zdarzenie nie czekało do rana lub do czasu, gdy ktoś znajdzie wolną chwilę.

W modelu SOC as a Service firma nie musi budować własnego zespołu analityków pracującego przez całą dobę. Monitoring bezpieczeństwa IT 24/7 może obejmować komputery, serwery, pocztę w chmurze, zapory sieciowe i kluczowe źródła logów. Tam, gdzie jest to uzasadnione, SIEM pomaga centralnie zbierać oraz korelować zdarzenia z wielu systemów. EDR z kolei dostarcza widoczności na urządzeniach końcowych i może ułatwić izolację komputera, zanim zagrożenie dotrze do kolejnych zasobów.

Technologia nie zastępuje procesu ani odpowiedzialności po stronie firmy. Daje jednak dane i czas, których zwykle brakuje w pierwszych minutach incydentu. Dla przedsiębiorstwa bez własnego SOC szczególnie ważne jest, aby było jasne, kto odbiera alarm, kto podejmuje decyzję o izolacji oraz jak przebiega komunikacja z zarządem i pracownikami.

Wnioski dla firmy, która chce przygotować się rozsądnie

Największą zmianą po takim incydencie nie powinien być zakup przypadkowego narzędzia, lecz uporządkowanie podstaw. Firma powinna wiedzieć, gdzie znajdują się jej krytyczne dane, kto ma do nich dostęp, które usługi są niezbędne do działania i jaki czas przestoju jest akceptowalny. Bez tych odpowiedzi nawet dobre narzędzia będą generować chaos zamiast bezpieczeństwa.

Potrzebne są również regularne testy odtwarzania backupów oraz wieloskładnikowe uwierzytelnianie, zwłaszcza dla poczty, dostępu zdalnego i kont administracyjnych. Równie istotne jest szkolenie pracowników z rozpoznawania phishingu. Człowiek nie jest najsłabszym ogniwem z definicji – potrzebuje jasnych zasad i bezpiecznego sposobu zgłaszania podejrzanych wiadomości.

Warto przygotować krótki plan reagowania na incydent: listę osób decyzyjnych, kontaktów technicznych, krytycznych systemów oraz zasad izolowania urządzeń. Taki dokument nie zatrzyma ataku, ale pozwala uniknąć dyskusji o podstawach w chwili, gdy każda godzina przestoju wpływa na klientów i pracę zespołu.

Dojrzałość cyberbezpieczeństwa nie polega na przekonaniu, że incydent nigdy się nie wydarzy. Polega na zdolności do szybkiego rozpoznania problemu, ograniczenia jego skutków i bezpiecznego powrotu do pracy. Dla MŚP stały monitoring oraz wsparcie w analizie i reagowaniu są często bardziej praktyczne niż próba samodzielnego utrzymywania pełnego zespołu bezpieczeństwa.

Dyrektor ds. Technologii (CTO). Ze względów bezpieczeństwa nie publikujemy imion i nazwisk autorów — artykuły podpisywane są wyłącznie stanowiskiem, bez danych identyfikujących konkretną osobę.