Ransomware w organizacji – jak przebiega cyberatak i co zrobić w pierwszych godzinach po wykryciu incydentu?

Jak rozwija się atak ransomware i co zrobić po jego wykryciu? Poznaj plan działań na pierwsze 24 godziny: od izolacji systemów i zabezpieczenia dowodów po ocenę naruszenia danych, obowiązki RODO i bezpieczne odtwarzanie środowiska.
17 października 2026
blog

Typowy przebieg ataku ransomware: wektor wejścia i rozpoznanie

Moment, w którym organizacja zauważa zaszyfrowane pliki, zwykle nie jest początkiem ataku. W incydentach prowadzonych przez operatorów ransomware wcześniej dochodzi do uzyskania dostępu i rozpoznania środowiska. Ten etap może trwać od godzin do tygodni, choć nie każdy atak przebiega według takiego scenariusza — część kampanii automatyzuje działania i szybko przechodzi do wyrządzania szkód.

Na początku warto rozróżnić dwa pojęcia. Wektor wejścia to sposób, w jaki napastnik dostaje się do organizacji, na przykład przez przejęte konto lub podatną usługę. Rozpoznanie wewnętrzne polega natomiast na ustaleniu, do jakiego środowiska trafił, co jest w nim dostępne i które zasoby mogą mieć znaczenie dla dalszego ataku.

Jak napastnicy uzyskują pierwszy dostęp?

Ransomware nie musi zaczynać się od otwarcia podejrzanego załącznika. Pierwszym krokiem może być również logowanie poprawnymi danymi użytkownika albo wykorzystanie luki w urządzeniu dostępnym z internetu. Do typowych dróg wejścia należą:

  • Phishing i socjotechnika. Wiadomość, fałszywa strona logowania lub kontakt podszywający się pod pomoc techniczną służą nakłonieniu użytkownika do ujawnienia danych, zatwierdzenia dostępu albo uruchomienia złośliwego pliku. Nie każda taka próba od razu instaluje ransomware — często jej celem jest dopiero stworzenie punktu zaczepienia.
  • Przejęte konta i usługi zdalnego dostępu. Napastnicy korzystają ze skradzionych haseł, danych pozyskanych przez złośliwe oprogramowanie lub niewystarczająco zabezpieczonych usług, takich jak VPN czy RDP. Brak uwierzytelniania wieloskładnikowego ułatwia nadużycie hasła, ale samo wdrożenie MFA nie wyklucza wszystkich sposobów przejęcia dostępu.
  • Podatności w systemach wystawionych do internetu. Luki w bramach VPN, urządzeniach brzegowych i aplikacjach publicznych mogą pozwolić na wejście bez udziału pracownika. Ten scenariusz różni się od phishingu tym, że wykorzystuje słabość techniczną, a nie decyzję użytkownika.
  • Dostęp przez dostawcę lub narzędzie administracyjne. Przejęcie konta partnera, zaufanego połączenia albo systemu zdalnego zarządzania może otworzyć drogę do infrastruktury klienta. Legalne narzędzie staje się wówczas kanałem nieautoryzowanych działań.

Osoba uzyskująca pierwszy dostęp nie zawsze jest późniejszym operatorem ransomware. Dostęp do środowiska bywa sprzedawany przez pośredników określanych jako initial access brokers. Dlatego początkowe włamanie i dalsza aktywność mogą być rozdzielone w czasie oraz prowadzone przez różne podmioty.

Co obejmuje rozpoznanie wewnątrz organizacji?

Po wejściu napastnik próbuje ustalić, jakie możliwości daje przejęte konto lub urządzenie. Sprawdza dostępne informacje o użytkownikach, strukturze sieci, usługach katalogowych, serwerach i udziałach plikowych. Szuka też wskazówek dotyczących systemów biznesowych, kopii zapasowych oraz stosowanych zabezpieczeń. Na tym etapie chodzi przede wszystkim o zbudowanie obrazu środowiska, a nie jeszcze o przejmowanie kolejnych systemów.

Rozpoznanie nie musi opierać się na specjalistycznym złośliwym oprogramowaniu. Napastnicy mogą wykorzystywać wbudowane funkcje systemu i legalne narzędzia administracyjne, przez co pojedyncze zdarzenia przypominają zwykłą pracę działu IT. Znaczenie ma kontekst: kto wykonuje daną czynność, z jakiego urządzenia, o jakiej porze i czy odpowiada to jego obowiązkom.

Jakie sygnały mogą ujawnić ten etap ataku?

Podejrzenia mogą wzbudzić nietypowe logowania zdalne, aktywność konta poza jego dotychczasowym profilem, odpytywanie wielu zasobów w krótkim czasie czy użycie narzędzi administracyjnych na stacji, na której wcześniej nie występowały. Żaden z tych sygnałów samodzielnie nie dowodzi ataku ransomware. Dopiero powiązanie zdarzeń z logów uwierzytelniania, usług zdalnego dostępu, urządzeń sieciowych i systemów ochrony stacji roboczych pozwala ocenić, czy tworzą spójny obraz włamania. Brak zaszyfrowanych plików nie oznacza więc, że środowisko pozostaje bezpieczne — może oznaczać, że atak znajduje się jeszcze na etapie przygotowania.

Eskalacja uprawnień i ruch boczny: przejęcie domeny i rozszerzanie dostępu

Dostęp do jednego komputera nie oznacza jeszcze kontroli nad organizacją. Aby ją uzyskać, napastnik zwykle rozwija atak w dwóch kierunkach: zdobywa większe uprawnienia i dociera do kolejnych zasobów. Eskalacja uprawnień zwiększa zakres dozwolonych działań, a ruch boczny rozszerza zasięg dostępu w środowisku. Te procesy często się przeplatają — przejęcie kolejnego serwera może ujawnić poświadczenia, które otworzą drogę do systemów o większym znaczeniu.

Eskalacja uprawnień: od konta użytkownika do dostępu administracyjnego

Napastnik działający z uprawnieniami zwykłego użytkownika ma ograniczone możliwości. Dlatego próbuje uzyskać kontrolę nad kontem uprzywilejowanym albo wykorzystać podatność lub błędną konfigurację, która pozwoli mu wykonywać działania administracyjne. Znaczenie mają m.in. nadmierne uprawnienia kont usługowych, niewłaściwie chronione poświadczenia oraz używanie kont administracyjnych do codziennej pracy.

Administrator lokalny i administrator domeny to nie ten sam poziom kontroli. Pierwszy zarządza określonym urządzeniem; drugi ma szerokie uprawnienia w domenie Active Directory. Samo przejęcie lokalnego administratora nie daje automatycznie dostępu do całej organizacji. Może jednak ułatwić dalszy atak, zwłaszcza gdy na urządzeniu są dostępne poświadczenia uprzywilejowanych kont lub to samo hasło administratora lokalnego jest używane na wielu komputerach.

Ruch boczny: wykorzystanie dostępu do kolejnych systemów

Ruch boczny polega na przechodzeniu między urządzeniami, serwerami i usługami z wykorzystaniem uzyskanego dostępu. Nie zawsze wymaga zwiększenia uprawnień: przejęte konto użytkownika może już pozwalać na dostęp do kilku aplikacji lub zasobów sieciowych. W kampaniach ransomware szczególnie istotne są jednak połączenia umożliwiające zdalne zarządzanie kolejnymi systemami.

Atakujący mogą korzystać z legalnych mechanizmów administracyjnych, takich jak zdalny pulpit, PowerShell Remoting czy narzędzia do centralnego zarządzania urządzeniami. Ich obecność sama w sobie nie dowodzi ataku. Znaczenie ma kontekst użycia: kto nawiązuje połączenie, z jakiego urządzenia, do jakiego systemu i czy odpowiada to normalnym obowiązkom danego konta. Z tego powodu nieautoryzowane działania mogą początkowo przypominać rutynową pracę administratorów.

W Cognity często słyszymy pytania, jak w praktyce odróżnić legalną administrację od działań napastnika — odpowiadamy na nie także na blogu. Podczas analizy warto zwrócić uwagę na nietypowe źródła logowania, połączenia z systemami, którymi dane konto zwykle nie zarządza, oraz nagły wzrost liczby urządzeń, do których uzyskuje dostęp. Żaden z tych sygnałów nie przesądza samodzielnie o ataku, ale ich zestawienie z historią aktywności konta pomaga wskazać zdarzenia wymagające pilnej weryfikacji.

Przejęcie domeny: kontrola nad mechanizmami zaufania

W środowisku Active Directory szczególnie groźne jest uzyskanie możliwości zarządzania kontami, grupami uprzywilejowanymi lub zasadami grupy (GPO). Kontrola nad tymi elementami może pozwolić napastnikowi zmieniać konfigurację wielu urządzeń i wykorzystywać centralne mechanizmy administracyjne do rozszerzania dostępu. Zasięg takiego przejęcia zależy jednak od architektury środowiska, delegacji uprawnień i relacji zaufania — nie musi obejmować wszystkich systemów organizacji.

Nie każdy atak ransomware wymaga przejęcia domeny. Niekiedy wystarcza dostęp do platformy zarządzania stacjami roboczymi, środowiska wirtualizacji lub wybranych serwerów. O potencjalnej skali incydentu decyduje więc nie tylko liczba przejętych kont, lecz przede wszystkim to, jakie działania te konta umożliwiają i do jakich zasobów prowadzą.

Eksfiltracja danych, szyfrowanie i mechanizmy wymuszenia (double/triple extortion)

Szyfrowanie plików nie musi być pierwszym ani jedynym celem ataku ransomware. Zanim organizacja zobaczy żądanie okupu, napastnicy mogą już dysponować kopią jej dokumentów. Kradzież danych i blokada dostępu do systemów tworzą dwa niezależne źródła nacisku: groźbę ujawnienia poufnych informacji oraz koszt przestoju. Dlatego możliwość odtworzenia środowiska z kopii zapasowych nie oznacza jeszcze, że organizacja uwolniła się od skutków ataku.

Eksfiltracja: dane opuszczają organizację

Eksfiltracja polega na nieuprawnionym przesłaniu danych poza kontrolowane środowisko. Napastnicy mogą wybierać informacje o największej wartości szantażowej: dokumentację finansową, umowy, dane pracowników i klientów, korespondencję zarządu czy tajemnice przedsiębiorstwa. Nie zawsze kopiują wszystkie dostępne zasoby — mniejszy, starannie dobrany zbiór również może stać się podstawą wymuszenia.

Przed wysłaniem pliki bywają gromadzone w jednym miejscu, kompresowane i dzielone na części. Transfer może odbywać się przez legalne usługi przechowywania plików lub narzędzia używane także przez administratorów, co utrudnia odróżnienie go od zwykłej aktywności. Duży ruch wychodzący jest jednym z możliwych sygnałów, ale jego brak nie wyklucza kradzieży: dane mogą opuszczać sieć stopniowo.

Deklaracja przestępców o wykradzeniu danych nie jest równoznaczna z potwierdzoną eksfiltracją. Udostępniona próbka może potwierdzać posiadanie określonych dokumentów, lecz sama nie przesądza o skali kradzieży ani o aktualności całego zbioru.

Szyfrowanie: uderzenie w dostępność usług

Szyfrowanie ma odebrać organizacji dostęp do zasobów potrzebnych do pracy. Może objąć pliki na stacjach roboczych, udziały sieciowe, serwery i środowiska wirtualne. Zakłócenie działania jednego krytycznego systemu bywa dotkliwsze niż zaszyfrowanie tysięcy mniej istotnych dokumentów. Napastnicy mogą również próbować usunąć lub uszkodzić dostępne kopie zapasowe, aby ograniczyć możliwość samodzielnego przywrócenia działalności.

Nie każdy wariant ransomware szyfruje całą zawartość plików. Częściowe szyfrowanie może przyspieszyć atak, a jednocześnie wystarczyć do uniemożliwienia korzystania z danych. Zakończenie tego etapu często ujawnia incydent użytkownikom: aplikacje przestają działać, pliki stają się nieczytelne, a w katalogach pojawiają się notatki z żądaniem okupu.

Double i triple extortion: jak napastnicy zwiększają presję

Mechanizmy wymuszenia różnią się przede wszystkim tym, jakie konsekwencje napastnicy wykorzystują jako argument za zapłatą:

  • Wymuszenie oparte na szyfrowaniu — żądanie zapłaty za narzędzie lub klucz umożliwiający odszyfrowanie danych. Głównym źródłem presji jest niedostępność systemów i koszt przestoju.
  • Double extortion, czyli podwójne wymuszenie — połączenie szyfrowania z kradzieżą danych i groźbą ich publikacji lub sprzedaży. Szantaż pozostaje skuteczny także wtedy, gdy ofiara może odtworzyć systemy z backupu.
  • Triple extortion, czyli potrójne wymuszenie — dołożenie kolejnego rodzaju nacisku, np. ataku DDoS albo bezpośredniego kontaktowania się z klientami i partnerami ofiary. Termin nie ma jednej powszechnie przyjętej definicji; opisuje rozszerzenie presji poza szyfrowanie i groźbę ujawnienia danych.

Występują również ataki polegające wyłącznie na kradzieży danych i szantażu, bez ich szyfrowania. Odzyskanie dostępności i odzyskanie kontroli nad poufnością to dwa odrębne problemy. Odszyfrowanie plików nie usuwa kopii pozostających u napastników, a obietnica ich skasowania po zapłacie nie daje wiarygodnej gwarancji, że dane nie zostaną ponownie wykorzystane.

Plan działań po wykryciu incydentu: pierwsze 1–2–4–24 godziny

Po wykryciu ransomware trzeba równolegle ograniczać zasięg ataku, ustalać skalę incydentu i utrzymywać procesy niezbędne do działania organizacji. Priorytetem nie jest natychmiastowe uruchomienie wszystkich usług, lecz odzyskanie kontroli nad środowiskiem. Zbyt szybkie przywrócenie systemów może zakończyć się kolejnym szyfrowaniem, jeśli napastnik nadal ma dostęp.

W Cognity omawiamy reagowanie na takie incydenty zarówno od strony technicznej, jak i praktycznej – z uwzględnieniem realiów pracy uczestników szkoleń. Poniższe przedziały liczy się od wykrycia incydentu, a nie od początku ataku. To punkty kontrolne, nie sztywna kolejność: przy aktywnym szyfrowaniu izolację i decyzje o ograniczeniu działania usług podejmuje się od razu.

Pierwsza godzina: ograniczenie szkód i uruchomienie zespołu

Wyznacz osobę kierującą reakcją na incydent oraz właściciela decyzji biznesowych. Zespół techniczny powinien wiedzieć, kto może zatwierdzić odłączenie segmentu sieci, zatrzymanie usługi lub przejście na pracę awaryjną. Ustal kanał koordynacji niezależny od środowiska, którego bezpieczeństwo jest niepewne, i rozpocznij dziennik działań z godziną, wykonawcą oraz uzasadnieniem każdej istotnej decyzji.

Izolacja ma odciąć napastnikowi możliwość dalszego działania. Obejmuje przede wszystkim urządzenia z potwierdzonymi oznakami ataku, ale jej zakres zależy od sytuacji:

  • Pojedynczy host: zastosuj izolację sieciową przez EDR lub odłączenie interfejsów sieciowych. Jeśli to możliwe, zachowaj kontrolowany dostęp narzędzi reagowania.
  • Wiele systemów lub aktywne rozprzestrzenianie: rozważ odcięcie segmentu, ograniczenie komunikacji między strefami albo czasowe zatrzymanie zagrożonej usługi.
  • Podejrzenie nadużycia konta lub dostępu zdalnego: zablokuj wskazane konto, unieważnij aktywne sesje i ogranicz zagrożony kanał dostępu. Działania dotyczące kont usługowych wymagają oceny wpływu na zależne systemy.

Równolegle sprawdź, czy infrastruktura kopii zapasowych jest odseparowana od zagrożonego środowiska i czy przejęte konta mogą usuwać lub modyfikować kopie. W środowiskach przemysłowych i systemach istotnych dla bezpieczeństwa ludzi sposób izolacji uzgodnij z osobami odpowiedzialnymi za ich eksploatację.

Do 2 godzin: triage, czyli szybka ocena skali i priorytetów

Triage nie jest pełnym dochodzeniem. Ma dostarczyć informacji potrzebnych do decyzji: co jest dotknięte atakiem, co pozostaje zagrożone i gdzie interwencja przyniesie największy efekt. Alerty EDR, dostępne logi uwierzytelniania, informacje z sieci oraz zgłoszenia użytkowników pozwalają zbudować pierwszą mapę incydentu.

Ustal przede wszystkim:

  • które urządzenia, konta i usługi wykazują oznaki naruszenia, a których status pozostaje nieznany;
  • czy szyfrowanie lub inna nieautoryzowana aktywność nadal trwa;
  • czy zagrożone są systemy tożsamości, zarządzania środowiskiem i kopii zapasowych;
  • które procesy biznesowe już nie działają i jakie są skutki ich dalszej niedostępności.

Oddzielaj ustalenia potwierdzone od hipotez. Brak alertu nie dowodzi, że system jest bezpieczny, zwłaszcza gdy monitoring obejmuje tylko część infrastruktury. Wynikiem tego etapu powinna być robocza lista systemów dotkniętych incydentem, zagrożonych oraz wymagających weryfikacji, wraz z priorytetem dalszych działań.

Do 4 godzin: decyzje kryzysowe i tryb działania organizacji

Na podstawie wstępnej oceny osoba kierująca incydentem przedstawia decydentom konkretne warianty: utrzymanie ograniczonej działalności, wyłączenie wybranych usług lub szersze odseparowanie środowiska. Każdy wariant powinien uwzględniać ryzyko dalszych szkód, wpływ na kluczowe procesy i warunki bezpiecznego wznowienia pracy.

W tym czasie należy zatwierdzić zakres izolacji, uruchomić dostępne procedury ciągłości działania i wskazać usługi niezbędne do minimalnego funkcjonowania organizacji. Potrzebne są też decyzje o zasobach: obsadzie kolejnych zmian, budżecie awaryjnym i ewentualnym wsparciu specjalistycznym. Właściciele procesów biznesowych określają skutki przestoju; zespół techniczny ocenia, czy proponowany sposób pracy nie zwiększy zasięgu incydentu.

Ustal rytm odpraw oraz odpowiedzialność za zadania. Każda odprawa powinna kończyć się krótkim zestawieniem: co wiadomo, co się zmieniło, jakie decyzje zapadły i kiedy nastąpi kolejna ocena.

Do 24 godzin: stabilizacja i przygotowanie kontrolowanego odtwarzania

Celem pierwszej doby jest ustabilizowanie sytuacji i przygotowanie planu przywracania usług — niekoniecznie zakończenie napraw. Zweryfikuj skuteczność izolacji, poszukaj oznak aktywności poza rozpoznanym obszarem i zaktualizuj zakres incydentu. Samo ustanie szyfrowania nie oznacza usunięcia zagrożenia.

Odtwarzanie powinno mieć określone warunki rozpoczęcia. Należą do nich ograniczenie rozpoznanych dróg dostępu napastnika, przygotowanie odseparowanego środowiska, zabezpieczenie kont używanych do odbudowy oraz sprawdzenie dostępności i przydatności kopii zapasowych. Kolejność przywracania musi uwzględniać zarówno znaczenie usług, jak i ich zależności techniczne.

Przed upływem doby organizacja powinna mieć aktualny obraz sytuacji, wskazanych właścicieli zadań i zatwierdzony plan na kolejną zmianę. Dla każdej odtwarzanej usługi warto z góry określić kryteria odbioru, sposób monitorowania po uruchomieniu oraz warunki ponownej izolacji, jeśli pojawią się oznaki naruszenia.

💡 Pro tip: Przy przekazywaniu incydentu kolejnej zmianie zapisz nie tylko wykonane zadania, lecz także działania wstrzymane, powody ich wstrzymania i warunki wznowienia. Dzięki temu kolejny administrator nie uruchomi odizolowanej usługi tylko dlatego, że wygląda na sprawną.

Zabezpieczenie dowodów i współpraca zewnętrzna: CSIRT, ubezpieczyciel, prawnicy, dostawcy

Po ataku ransomware organizacja potrzebuje nie tylko sprawnych systemów, lecz także wiarygodnego zapisu tego, co się wydarzyło. Materiał dowodowy pomaga ustalić zakres naruszenia, zweryfikować sposób uzyskania dostępu i ocenić, czy napastnik nadal ma możliwość działania. Może być również istotny dla postępowania karnego, rozliczenia szkody z ubezpieczycielem oraz oceny odpowiedzialności kontraktowej. Zabezpieczanie śladów powinno towarzyszyć ograniczaniu skutków incydentu, ale nie może opóźniać działań niezbędnych do zatrzymania aktywnego ataku.

Co zabezpieczyć i jak zachować wiarygodność materiału

Priorytet mają informacje, które mogą szybko zniknąć: zawartość pamięci operacyjnej, dane o aktywnych procesach i połączeniach oraz logi podlegające rotacji. Ich pozyskanie warto powierzyć specjalistom informatyki śledczej i reagowania na incydenty, czyli DFIR. Kolejność zbierania materiału zależy od stanu środowiska i ryzyka dalszych szkód — nie ma potrzeby wykonywania pełnego obrazu każdego urządzenia bez wcześniejszego określenia celu analizy.

Podstawowy zakres zabezpieczenia obejmuje:

  • Logi i telemetrię: zdarzenia z systemów tożsamości, VPN, poczty, EDR, zapór sieciowych, usług chmurowych i systemów kopii zapasowych.
  • Materiał z wybranych urządzeń: obrazy nośników, zrzuty pamięci oraz istotne pliki i konfiguracje, pozyskane metodami ograniczającymi zmiany w badanym środowisku.
  • Ślady wymuszenia i kontaktu: notatki z żądaniem okupu, wskazane adresy i identyfikatory, oryginalne wiadomości wraz z nagłówkami oraz korespondencję z napastnikiem, jeśli do niej doszło.
  • Dokumentację działań zespołu: chronologię obserwacji, decyzji i zmian w systemach, z podaniem czasu, osoby wykonującej czynność oraz jej uzasadnienia.

Każdy materiał powinien mieć udokumentowane pochodzenie i historię przekazania — tzw. łańcuch dowodowy. Należy zapisać źródło, datę i sposób pozyskania, użyte narzędzie oraz osoby uzyskujące dostęp. Dla plików i obrazów warto obliczyć sumy kontrolne, np. SHA-256, pozwalające wykryć późniejsze zmiany. Analizę prowadzi się na kopiach roboczych, a egzemplarze źródłowe przechowuje z ograniczonym dostępem i ochroną przed modyfikacją. Przy zestawianiu zdarzeń trzeba uwzględnić strefy czasowe i ewentualne rozbieżności zegarów.

CSIRT, ubezpieczyciel, prawnicy i dostawcy — różne role

Zewnętrzni partnerzy nie zastępują siebie nawzajem. Warto wyznaczyć jedną osobę koordynującą kontakty, aby ustalenia techniczne, wymagania polisy i decyzje prawne nie trafiały do oddzielnych, niespójnych obiegów.

PartnerZakres współpracyCo uzgodnić na początku
Właściwy CSIRTPrzyjęcie zgłoszenia, wymiana informacji o zagrożeniu i wsparcie w zakresie właściwości danego zespołu.Właściwość zespołu, bezpieczny kanał kontaktu oraz zakres potrzebnych danych. W Polsce należy ustalić właściwy CSIRT, np. CSIRT NASK, CSIRT GOV lub CSIRT MON; samo zgłoszenie nie oznacza przejęcia obsługi incydentu.
Ubezpieczyciel cyberObsługa szkody i organizacja świadczeń przewidzianych polisą, niekiedy z udziałem wskazanych ekspertów.Termin i sposób zawiadomienia, wymogi dokumentacyjne oraz zasady zatwierdzania usług i kosztów. Warunki różnią się między polisami.
PrawnicyOcena zobowiązań umownych, wsparcie przy zabezpieczeniu materiału i zawiadomieniu organów ścigania oraz ocena ryzyk prawnych decyzji.Zasady dokumentowania ustaleń i udostępniania analiz. Sam udział prawnika nie nadaje automatycznie wszystkim materiałom ochrony przed ujawnieniem.
Dostawcy IT, chmury i usług bezpieczeństwaZabezpieczenie danych znajdujących się poza bezpośrednią kontrolą organizacji oraz wsparcie analizy ich usług.Retencję logów, możliwość wstrzymania ich usuwania, zakres eksportu danych, uprawnienia do działań i dostępność zespołu reagowania.

Udostępnianie informacji pod kontrolą

Do pierwszego kontaktu przygotuj zwięzły pakiet: czas wykrycia ze strefą czasową, opis objawów, znany zakres dotkniętych usług, wykonane czynności i dane osoby koordynującej. Oddziel potwierdzone ustalenia od hipotez. Pełne obrazy systemów lub obszerne zbiory logów przekazuj dopiero po uzgodnieniu celu, zakresu, sposobu ochrony i okresu przechowywania danych. Mogą zawierać dane osobowe, tajemnice przedsiębiorstwa i aktywne poświadczenia.

Jeśli firmowa poczta lub konta administratorów mogły zostać przejęte, kontakty z partnerami prowadź przez niezależny, zweryfikowany kanał. Rejestruj, komu i kiedy udostępniono materiał, a prośby o zabezpieczenie logów oraz uzgodnienia dotyczące kosztów potwierdzaj pisemnie. Ułatwia to zarówno analizę techniczną, jak i późniejsze wykazanie, jakie działania rzeczywiście podjęto.

💡 Pro tip: W prośbie do dostawcy o zabezpieczenie logów wskaż konkretne usługi, konta i przedział czasu wraz ze strefą czasową, a następnie poproś o potwierdzenie zakresu zabezpieczonych danych oraz terminu ich przechowywania. Samo przyjęcie zgłoszenia nie oznacza, że automatyczne usuwanie logów zostało wstrzymane.

Ocena wpływu na dane osobowe i obowiązki zgłoszeniowe (RODO) oraz komunikacja wewnętrzna i zewnętrzna

Przy ataku ransomware ocena naruszenia ochrony danych osobowych nie może sprowadzać się do pytania, czy napastnik wykradł pliki. Naruszenie może dotyczyć także dostępności lub integralności danych — na przykład wtedy, gdy zaszyfrowanie dokumentacji uniemożliwia jej wykorzystanie albo dochodzi do nieuprawnionej zmiany zapisów. Sam incydent cyberbezpieczeństwa nie oznacza jednak automatycznie obowiązku zgłoszenia do organu nadzorczego. Trzeba ustalić, czy doszło do naruszenia ochrony danych osobowych i jakie ryzyko powoduje ono dla osób, których dane dotyczą.

Jak ocenić wpływ incydentu na osoby, których dane dotyczą?

Ocena powinna obejmować kategorie danych, zakres naruszenia, przybliżoną liczbę osób i rekordów oraz możliwe konsekwencje. Znaczenie ma nie tylko ujawnienie numerów PESEL, danych finansowych czy informacji o zdrowiu, lecz także kontekst ich przetwarzania. Niedostępność dokumentacji medycznej może zagrażać ciągłości leczenia, a ujawnienie danych pracowników — ułatwiać oszustwa lub prowadzić do naruszenia ich prywatności.

Należy uwzględnić czas niedostępności danych, możliwość ich odtworzenia, skuteczność wcześniejszych zabezpieczeń oraz podatność poszkodowanych osób na negatywne skutki zdarzenia. Posiadanie kopii zapasowej nie wyklucza naruszenia, a brak dowodów eksfiltracji nie jest równoznaczny z potwierdzeniem, że do niej nie doszło. W ocenie trzeba oddzielić potwierdzone fakty od przypuszczeń i wskazać, czego nadal nie ustalono. Punktem odniesienia są prawa i wolności osób fizycznych, nie wyłącznie straty finansowe czy reputacyjne organizacji.

Zgłoszenie do organu nadzorczego a zawiadomienie osób

RODO przewiduje dwa odrębne obowiązki, o różnych progach ryzyka. Zgłoszenie naruszenia organowi nadzorczemu nie zastępuje zawiadomienia osób, a publikacja komunikatu na stronie internetowej nie zastępuje automatycznie żadnego z tych działań.

ObowiązekKiedy powstaje?Termin
Zgłoszenie właściwemu organowi nadzorczemu — w Polsce co do zasady Prezesowi UODOGdy stwierdzono naruszenie ochrony danych osobowych, chyba że jest mało prawdopodobne, by skutkowało ono ryzykiem naruszenia praw lub wolności osób fizycznych.Bez zbędnej zwłoki, w miarę możliwości nie później niż 72 godziny po stwierdzeniu naruszenia.
Zawiadomienie osób, których dane dotycząGdy naruszenie może powodować wysokie ryzyko naruszenia ich praw lub wolności, z uwzględnieniem wyjątków z art. 34 ust. 3 RODO.Bez zbędnej zwłoki — nie obowiązuje tu odrębny termin 72 godzin.

Nie należy odkładać zgłoszenia do czasu zakończenia analizy technicznej. Stwierdzenie naruszenia wiąże się z uzyskaniem wystarczającej pewności, że zdarzenie doprowadziło do naruszenia ochrony danych osobowych, a nie z poznaniem wszystkich szczegółów ataku. Jeżeli informacji nie da się przekazać jednocześnie, art. 33 RODO pozwala dostarczać je sukcesywnie, bez zbędnej dalszej zwłoki. Opóźnienie zgłoszenia ponad 72 godziny wymaga uzasadnienia.

Organizacja działająca jako podmiot przetwarzający powiadamia administratora bez zbędnej zwłoki po stwierdzeniu naruszenia; nie ma własnego, ogólnego terminu 72 godzin na takie powiadomienie. Administrator dokumentuje każde naruszenie, jego skutki i podjęte działania zaradcze, również wtedy, gdy nie zgłasza go organowi. W dokumentacji warto wyraźnie uzasadnić ocenę ryzyka i wynikającą z niej decyzję.

Komunikacja: potwierdzone informacje i konkretne zalecenia

Komunikacja wewnętrzna powinna zapewnić osobom decyzyjnym, zespołowi obsługującemu incydent i inspektorowi ochrony danych — jeżeli został wyznaczony — spójny obraz sytuacji. Pracownicy potrzebują natomiast informacji adekwatnych do swojej roli: co zdarzenie oznacza dla ich danych, gdzie kierować pytania i kto odpowiada za kontakt z osobami spoza organizacji. Należy unikać rozpowszechniania danych poszkodowanych oraz niepotwierdzonych szczegółów incydentu.

Zawiadomienie osób wymagane przez art. 34 RODO musi być napisane jasnym i prostym językiem. Powinno opisywać charakter naruszenia, możliwe konsekwencje, zastosowane lub proponowane środki zaradcze oraz wskazywać kontakt do IOD lub innego punktu udzielającego informacji. Zalecenia dla odbiorców powinny odpowiadać rzeczywistemu zagrożeniu — na przykład ostrzegać przed ukierunkowanym phishingiem, jeśli ujawniony zakres danych może go ułatwiać.

Komunikaty dla klientów, partnerów i mediów powinny opierać się na tych samych potwierdzonych faktach, choć mogą różnić się zakresem. Zamiast deklarować „dane są bezpieczne”, gdy analiza jeszcze trwa, należy precyzyjnie wskazać, co ustalono, co pozostaje przedmiotem weryfikacji i gdzie będą publikowane aktualizacje. Taka komunikacja ogranicza dezinformację bez składania obietnic, których organizacja nie może jeszcze uzasadnić.

Czego nie robić podczas incydentu ransomware

Podczas incydentu ransomware szkodliwe bywają nie tylko opóźnienia, lecz także pochopne próby naprawy. Restart serwera, uruchomienie przypadkowego narzędzia czy podłączenie kopii zapasowej mogą utrudnić analizę albo narazić kolejne zasoby. Nie podejmuj działań tylko dlatego, że zwykle pomagają przy awarii IT. W tym przypadku w środowisku może nadal działać napastnik.

Nie myl odizolowania urządzenia z jego wyłączeniem

Odłączenie hosta od sieci ogranicza jego komunikację, natomiast wyłączenie zasilania powoduje również utratę danych z pamięci operacyjnej, potencjalnie ważnych dla analizy. Nie restartuj więc masowo urządzeń ani nie odłączaj ich automatycznie od prądu. Nie oznacza to jednak zakazu wyłączenia w każdej sytuacji: gdy trwa lokalne szyfrowanie, a inne sposoby jego zatrzymania są niedostępne, ograniczenie szkód może mieć pierwszeństwo. Taka decyzja powinna wynikać z oceny sytuacji, nie z rutyny.

Nie usuwaj śladów w ramach „sprzątania”

Nie kasuj notatek z żądaniem okupu, podejrzanych plików ani kont przed uzgodnieniem sposobu zabezpieczenia informacji o nich. Nie uruchamiaj też bez planu czyszczenia systemów, reinstalacji czy przywracania ustawień fabrycznych. Usunięcie widocznego objawu nie jest dowodem usunięcia napastnika. Zbyt wczesne porządki mogą utrudnić ustalenie drogi wejścia i zakresu naruszenia.

Nie przywracaj usług do niezaufanego środowiska

Presja na wznowienie pracy nie powinna prowadzić do podłączania repozytoriów kopii zapasowych do skompromitowanych systemów ani odtwarzania danych przed sprawdzeniem warunków bezpiecznego powrotu. Kopia może zawierać wcześniejsze ślady kompromitacji, a aktywny dostęp napastnika umożliwić ponowny atak. Sam komunikat o poprawnym zakończeniu odtwarzania nie potwierdza bezpieczeństwa usługi.

Nie używaj potencjalnie przejętych urządzeń do odzyskiwania kontroli

Nie loguj się z nich na konta administracyjne, do konsoli kopii zapasowych ani do systemów zarządzania bezpieczeństwem. Równie ryzykowna jest zmiana haseł na urządzeniu, które może przechwytywać nowe dane uwierzytelniające. Unikaj także przekazywania szczegółów działań obronnych kanałami komunikacji, do których atakujący mógł uzyskać dostęp.

Nie testuj przypadkowych deszyfratorów na jedynych kopiach plików

Obietnica szybkiego odzyskania danych nie potwierdza wiarygodności narzędzia. Niewłaściwy deszyfrator może uszkodzić pliki, a fałszywy program — uruchomić kolejne złośliwe oprogramowanie. Ewentualne testy powinny dotyczyć kopii i narzędzi o zweryfikowanym pochodzeniu. Nie przesyłaj też poufnych dokumentów do publicznych serwisów analitycznych bez sprawdzenia zasad ich przechowywania i udostępniania.

Nie działaj samodzielnie pod presją żądania okupu

Nie podejmuj na własną rękę kontaktu z napastnikiem, negocjacji ani decyzji o zapłacie. Zapłata nie gwarantuje odzyskania danych, ich usunięcia przez przestępców ani zakończenia wymuszenia. Nie traktuj również deklaracji atakującego jako wiarygodnego potwierdzenia zakresu incydentu. Zarówno zapewnienie, że „nic nie wyciekło”, jak i groźba publikacji wszystkich danych wymagają niezależnej weryfikacji — nie mogą zastępować ustaleń technicznych.

8. Mini-checklista dla dyżurnego IT/SOC oraz rekomendacje prewencyjne

Checklista dyżurna powinna pomagać w pracy pod presją, a nie zastępować procedurę reagowania na incydent. Jej zadaniem jest potwierdzenie, że alarm ma właściciela, najważniejsze ustalenia są zapisane, a osoby decyzyjne otrzymują spójny obraz sytuacji. Zabezpieczenia prewencyjne pełnią inną funkcję: ograniczają możliwość rozprzestrzenienia ataku i zwiększają szanse na odtworzenie usług bez płacenia okupu.

Mini-checklista do wykorzystania podczas dyżuru

  • Zarejestruj zdarzenie: zapisz czas wykrycia wraz ze strefą czasową, źródło alarmu, identyfikatory podejrzanych urządzeń i kont oraz numer sprawy. Oddziel potwierdzone fakty od hipotez.
  • Potwierdź odpowiedzialność: sprawdź, kto koordynuje incydent, kto może zatwierdzać działania wpływające na dostępność usług i czy zgłoszenie zostało odebrane przez właściwą osobę.
  • Sprawdź status działań ochronnych: odnotuj, które zasoby objęto ograniczeniami dostępu, a które nadal wymagają decyzji. Nie zakładaj, że wysłanie polecenia izolacji oznacza jego skuteczne wykonanie.
  • Zweryfikuj widoczność: ustal, czy dostępna jest telemetria z EDR, systemów tożsamości i urządzeń sieciowych. Brak nowych alertów przy niedziałającym monitoringu nie potwierdza zatrzymania ataku.
  • Przygotuj przekazanie dyżuru: zapisz aktualny zakres podejrzeń, wykonane działania, otwarte zadania, ich właścicieli oraz termin następnej aktualizacji. Korzystaj z uzgodnionego kanału komunikacji, niezależnego od środowiska podejrzewanego o przejęcie.

Kopie zapasowe: zasada 3-2-1-1-0 i sprawdzone odtwarzanie

3-2-1-1-0 oznacza trzy kopie danych łącznie z danymi produkcyjnymi, przechowywanie na dwóch różnych typach nośników, jedną kopię poza główną lokalizacją, jedną kopię offline lub niezmienialną oraz zero błędów stwierdzonych podczas weryfikacji kopii i testów odtwarzania. Kopia poza siedzibą nie jest automatycznie kopią odporną na ransomware — może pozostawać dostępna do usunięcia z przejętego konta administratora.

Dostęp administracyjny do backupu powinien być oddzielony od codziennej administracji środowiskiem. Sam komunikat o poprawnym wykonaniu backupu nie dowodzi, że usługę da się przywrócić. Testy odtwarzania muszą obejmować jej zależności, integralność danych i rzeczywisty czas przywrócenia. Wyniki należy porównywać z RTO, czyli docelowym czasem odtworzenia, oraz RPO, określającym dopuszczalny zakres utraty najnowszych danych.

Segmentacja, EDR i PAM — trzy różne role

Segmentacja sieci ogranicza komunikację między stacjami roboczymi, serwerami, systemami zarządzania i infrastrukturą kopii zapasowych do rzeczywiście potrzebnych połączeń. Sam podział na VLAN-y nie wystarczy, jeśli ruch między nimi pozostaje szeroko dozwolony.

EDR służy do wykrywania podejrzanych zachowań na urządzeniach, analizy zdarzeń i reagowania, na przykład przez izolację hosta. Jego wartość zależy od pokrycia środowiska, sprawności agentów oraz obsługi alertów. Należy regularnie sprawdzać również urządzenia, z których telemetria przestała napływać.

PAM ogranicza i kontroluje korzystanie z kont uprzywilejowanych: pomaga nadawać dostęp tylko na potrzebny czas, chronić poświadczenia i rozliczać sesje administracyjne. Uzupełniają go oddzielne konta administratorów, zasada najmniejszych uprawnień oraz MFA, szczególnie dla dostępu zdalnego i funkcji administracyjnych.

Skuteczność tych zabezpieczeń trzeba potwierdzać ćwiczeniami: czy dyżurny potrafi odizolować urządzenie, czy utrata konta domenowego nie otwiera dostępu do backupu i czy krytyczna usługa wraca w akceptowalnym czasie. Każda wykryta luka powinna otrzymać właściciela i termin usunięcia. W Cognity łączymy teorię z praktyką — dlatego zagadnienia reagowania na incydenty rozwijamy także w formie ćwiczeń na szkoleniach.

Najczęściej zadawane pytania i odpowiedzi odnośnie Ransomware w organizacji – jak przebiega cyberatak i co zrobić w pierwszych godzinach po wykryciu incydentu?

Jak rozpoznać atak ransomware, zanim pliki zostaną zaszyfrowane?

Atak ransomware można podejrzewać na podstawie powiązanych anomalii w logowaniach, aktywności kont i dostępie do zasobów. Sygnałami ostrzegawczymi są nietypowe połączenia zdalne, odpytywanie wielu systemów w krótkim czasie czy używanie narzędzi administracyjnych poza normalnym zakresem obowiązków. Pojedynczy sygnał nie potwierdza włamania. Dopiero zestawienie logów uwierzytelniania, zdarzeń sieciowych i alertów ochrony urządzeń pozwala ocenić, czy trwa przygotowanie do ataku.

Co zrobić w pierwszej godzinie po wykryciu ransomware w firmie?

W pierwszej godzinie po wykryciu ransomware trzeba ograniczyć zasięg ataku i uruchomić skoordynowaną reakcję. Najważniejsze działania to:

  • wyznaczenie osoby kierującej incydentem i osoby zatwierdzającej decyzje biznesowe;
  • izolacja zagrożonych urządzeń oraz ograniczenie przejętego dostępu;
  • sprawdzenie, czy napastnik może modyfikować lub usuwać kopie zapasowe;
  • uruchomienie niezależnego kanału komunikacji i dziennika działań.

Zakres ograniczeń powinien uwzględniać skalę incydentu oraz wpływ na procesy krytyczne i bezpieczeństwo ludzi.

Czy po wykryciu ransomware należy wyłączyć komputer?

Nie należy automatycznie wyłączać komputera — zwykle najpierw trzeba odizolować go od sieci. Wyłączenie zasilania usuwa zawartość pamięci operacyjnej, która może pomóc w analizie incydentu. Sama izolacja sieciowa nie zatrzymuje jednak szyfrowania lokalnych plików. Jeżeli szyfrowanie nadal trwa, a inne sposoby jego zatrzymania są niedostępne, wyłączenie urządzenia może być uzasadnione ograniczeniem szkód. Decyzję należy udokumentować.

Kiedy można bezpiecznie przywrócić systemy z backupu po ataku ransomware?

Odtwarzanie można rozpocząć po ograniczeniu rozpoznanych dróg dostępu napastnika i przygotowaniu odseparowanego środowiska. Trzeba również zabezpieczyć konta używane do odbudowy oraz sprawdzić przydatność kopii, w tym możliwość występowania w nich wcześniejszych śladów kompromitacji. Kolejność przywracania powinna uwzględniać znaczenie usług i ich zależności techniczne. Samo poprawne odtworzenie danych nie potwierdza bezpieczeństwa systemu, dlatego potrzebne są kryteria odbioru i monitoring po uruchomieniu.

Jakie dowody zabezpieczyć po ataku ransomware?

Po ataku ransomware trzeba zabezpieczyć ślady techniczne, materiały związane z wymuszeniem i dokumentację reakcji zespołu. Priorytet mają dane, które mogą szybko zniknąć:

  • pamięć operacyjna oraz informacje o aktywnych procesach i połączeniach;
  • logi systemów tożsamości, VPN, EDR, sieci i backupu;
  • notatki z żądaniem okupu oraz oryginalne wiadomości;
  • chronologia obserwacji, decyzji i zmian w systemach.

Należy udokumentować pochodzenie materiałów i historię ich przekazania, nie opóźniając zatrzymania aktywnego ataku.

Komu zgłosić atak ransomware w organizacji?

Atak ransomware należy skierować do właściwego CSIRT oraz uruchomić kontakty wymagane przez umowy i obowiązki organizacji. W Polsce trzeba ustalić właściwość CSIRT NASK, CSIRT GOV lub CSIRT MON. Jeżeli organizacja ma polisę cyber, powinna sprawdzić zasady zawiadomienia ubezpieczyciela i zatwierdzania kosztów. Prawnicy wspierają ocenę obowiązków i zawiadomienie organów ścigania, a dostawcy pomagają zabezpieczyć logi. Zgłoszenie do CSIRT nie oznacza przejęcia obsługi incydentu.

Czy każdy atak ransomware trzeba zgłosić do UODO w ciągu 72 godzin?

Nie każdy atak ransomware wymaga zgłoszenia do UODO — decydują naruszenie ochrony danych osobowych i ryzyko dla osób. Naruszenie może obejmować także niedostępność danych, bez potwierdzonego wycieku. Administrator zgłasza je bez zbędnej zwłoki, w miarę możliwości do 72 godzin od stwierdzenia, chyba że ryzyko naruszenia praw lub wolności jest mało prawdopodobne. Nie trzeba czekać na zakończenie analizy technicznej; brakujące informacje można uzupełniać sukcesywnie.

Czy zapłacenie okupu za ransomware gwarantuje odzyskanie danych?

Zapłacenie okupu nie gwarantuje odzyskania danych, usunięcia skradzionych kopii ani zakończenia szantażu. Odszyfrowanie plików i ochrona poufności to odrębne problemy: nawet działające narzędzie deszyfrujące nie odbiera napastnikom wykradzionych dokumentów. Ich deklaracje wymagają niezależnej weryfikacji. Kontaktu z przestępcami, negocjacji ani decyzji o zapłacie nie należy podejmować samodzielnie, poza uzgodnionym procesem zarządzania incydentem i oceną ryzyk prawnych.

icon

Formularz kontaktowyContact form

Imię *Name
NazwiskoSurname
Adres e-mail *E-mail address
Telefon *Phone number
UwagiComments