cyberbezpieczeństwo
cybersecurity
ransomware
21 maja 2026
Time 12 minut czytania

24 godziny do paraliżu firmy – lekcja z ataku ransomware, którego można było uniknąć [case study]


Większość firm żyje w przekonaniu, że cyberatak to scenariusz rodem z filmu sensacyjnego – coś, co przytrafia się wyłącznie globalnym korporacjom lub instytucjom finansowym. Rzeczywistość brutalnie weryfikuje jednak takie podejście. W opisywanym przypadku atak nastąpił w weekend, w środku nocy.

W poniedziałek, zamiast porannej kawy i standardowego logowania do systemów, pracownicy zastali niedziałające środowisko. Administratorzy, po zalogowaniu się na serwery, zobaczyli natomiast krótki komunikat od grupy DragonForce: „Twoje pliki zostały wykradzione i zaszyfrowane. Chcesz je odzyskać? Zapłać.”

Czym właściwie jest ransomware?   

To nie jest zwykły wirus komputerowy. To cyfrowy porywacz, który włamuje się do systemu i bierze najcenniejsze informacje jako zakładników. Gdy tylko niepostrzeżenie przeniknie do komputera lub firmowej sieci, bezlitośnie zatrzaskuje drzwi do wszystkiego: prywatnych zdjęć, kluczowych dokumentów i gigantycznych baz danych. Warunek uwolnienia jest jeden – haracz wpłacony w anonimowej, niemożliwej do wyśledzenia kryptowalucie.

Konsekwencje takiego uderzenia są paraliżujące i wykraczają daleko poza ekrany monitorów. Szpitale odwołują ratujące życie operacje, a korporacje z dnia na dzień tracą dostęp do danych milionów klientów. Co gorsza, zasady tej gry stają się coraz bardziej brutalne. Dziś to nierzadko podwójny szantaż – hakerzy najpierw kradną wrażliwe dane, a następnie grożą ich upublicznieniem, jeśli ofiara nie ugnie się przed ich żądaniami.

Co napędza ten cyfrowy terror? Przede wszystkim astronomiczne zyski – pojedyncze okupy potrafią sięgać milionów dolarów. Ale to nie wszystko. W grę wchodzą również geopolityka oraz żądza sławy w społeczności cyberprzestępców.

case_study_ransomware_ITPunkt
Profil ofiary: 200 pracowników, zagraniczny kapitał i luka, która zatrzymała biznes

Ofiarą ataku padła firma z branży usługowej. Przy około 200 pracownikach i zagranicznym kapitale wydawała się solidnym graczem na rynku. Jednak pod fasadą nowoczesnego biura i korporacyjnych procedur krył się potężny dług technologiczny, który stał się fundamentem nadchodzącej katastrofy.

Krajobraz przed bitwą

Początkowy audyt po incydencie wykazał, że infrastruktura IT nie nadążała za dynamicznym wzrostem biznesu. Choć firma generowała wysokie obroty, jej cyfrowe serce biło w rytmie technologii sprzed dekady.

  • Kluczowe procesy biznesowe opierały się na przestarzałych systemach, głównie Windows Server 2012. W świecie cyberbezpieczeństwa to wieczność – systemy te od lat nie otrzymywały wsparcia, co czyniło je podatnymi na exploity, na które współczesne antywirusy są ślepe.

  • Brak segmentacji sieci sprawił, że infrastruktura przypominała otwarty plan biurowego open space’u. Gdy ransomware zainfekował jedną stację roboczą, rozprzestrzenił się na całą firmę w kilka minut – jak plotki z rozmowy telefonicznej prowadzonej przy jednym z biurek.

  • Kopie zapasowe istniały, ale zarządzanie nimi przeczyło wszelkim dobrym praktykom. Były łatwo dostępne z poziomu środowiska, które zostało przejęte i zaszyfrowane. W efekcie DragonForce najpierw bez problemu wykradł dane, a następnie zaszyfrował całe środowisko.

  • Brak aktywnego powiadamiania z systemu monitoringu oznaczał, że firma była głucha i ślepa na to, co działo się w jej własnym środowisku. Hakerzy przebywali w systemach przez pewien czas, rozpoznając teren i eskalując uprawnienia, podczas gdy administratorzy żyli w błogiej nieświadomości.

  • Domena Active Directory była z innej epoki – nie modernizowano jej od 2012 roku. Nieaktualny poziom funkcjonalności domeny oraz brak nowoczesnych polityk bezpieczeństwa sprawiły, że mechanizmy obronne AD były praktycznie nieobecne. Dla nowoczesnych grup ransomware takie środowisko to plac zabaw.
Przeciwnik: Kim jest grupa DragonForce? 

Historia DragonForce nie jest typowa. Grupa wypłynęła na szerokie wody pod koniec 2023 roku. Jej korzenie sięgają Malezji, a początkowe operacje przypominały raczej klasyczny haktywizm. Grupa dała się poznać jako kolektyw napędzany propalestyńskimi sympatiami, biorący na celownik instytucje rządowe, firmy i infrastrukturę Izraela oraz Indii. Włamywali się, wykradali dane, przeprowadzali ataki DDoS i podmieniali strony internetowe. Byli głośnym, agresywnym wyrazem cyfrowego buntu.

Jednak szybko zrozumieli, że sama ideologia nie opłaci rachunków za serwery i nie kupi luksusowych aut. Grupa DragonForce ewoluowała. Choć nadal nie stroni od politycznych manifestów, dziś uderza niezwykle szeroko: od brytyjskich gigantów handlu detalicznego, przez systemy transportu publicznego, aż po potężne zakłady produkcyjne rozsiane po całym świecie.

Franczyza na szantaż, czyli biznes musi się kręcić 

To, co najbardziej fascynujące w działalności „Smoków”, to ich model „biznesowy”. Grupa DragonForce przeistoczyła się z grupki aktywistów w potężną grupę, która świadczy usługi ransomware. Działa jak korporacja oferująca licencje na szantaż. Dostarcza złośliwe oprogramowanie i gotową infrastrukturę niezależnym hakerom, tzw. afiliantom.

W oczy rzuca się cennik „Smoków”. Grupa pobiera „tylko” ok. 20% prowizji z wymuszonego okupu. W przestępczym półświatku to stawka wręcz dumpingowa.

Jak w praktyce wygląda atak DragonForce? Specjaliści z zakresu cyberbezpieczeństwa, analizując incydenty związane z grupą, rozłożyli jej sposób działania, czyli TTPs – Tactics, Techniques, and Procedures – na czynniki pierwsze. To nie jest filmowe wyłamanie drzwi. To cicha, drobiazgowa robota:

  • Uchylone okno
    Wszystko zaczyna się zazwyczaj od banału – e-maila phishingowego ze złośliwym załącznikiem. Wystarczy, że jeden nieuważny pracownik kliknie to, czego klikać nie powinien.
  • Rozpoznanie bojem
    Gdy napastnicy są już w środku, rozpoczynają ciche badanie terenu. Wykorzystują do tego często narzędzia systemowe, skrupulatnie po sobie sprzątając i kasując ślady. W tym samym czasie siłowo uderzają w panele logowania, szukając Świętego Graala: kont z uprawnieniami „Administratora Domeny”.
  • Zachowanie obecności
    Kiedy zdobywają poświadczenia najwyższego szczebla, okopują się w systemie. Zmieniają klucze w rejestrze Windowsa, manipulują uprawnieniami z wykorzystaniem np. WMI, dodają ukryte harmonogramy zadań. Wyłączają również oprogramowanie antywirusowe. Zapewniają sobie tym samym „nieśmiertelność” w systemie ofiary – przetrwają nawet restarty serwerów.
  • Wielka kradzież
    Zanim ofiara zorientuje się, że wpuściła lisa do kurnika, zaczyna się drenaż. Ogromne ilości wrażliwych danych wysyłane są połączeniami na zewnętrzne serwery, często ulokowane w Rosji, jak te na niesławnym hostingu Proton66.
  • Szyfrowanie i list od porywacza
    Gdy złodzieje mają już kopię wszystkiego, co cenne, następuje uderzenie. Specjalny skrypt błyskawicznie szyfruje pliki na komputerach ofiary. Ich rozszerzenia zamieniają się na takie z prefiksem .df, a w folderach ląduje plik readme.txt. Komunikat w środku jest prosty: mamy wasze dane. Jeśli nie zapłacicie, sprzedamy je w darknecie. To klasyczny, podwójny szantaż – double extortion.
Anatomia ataku: 24 godziny, które zatrzymały firmę

Atak grupy DragonForce nie był frontalnym uderzeniem, lecz precyzyjną operacją, która wykorzystała każdy błąd w konfiguracji środowiska ofiary. Dzięki przejętym poświadczeniom hakerzy poruszali się po nim jak po mapie, którą firma sama im narysowała.

Krok 1: Wyważenie drzwi

Wszystko zaczęło się od przejęcia kont VPN za pomocą ataków phishingowych. Hakerzy, dysponując skradzionymi loginami oraz hasłami, zalogowali się do sieci firmowej, pozostając całkowicie niewidoczni. Weszli nie jako intruzi, ale jako uprawnieni użytkownicy.

Krok 2: Uderzenie w głowę

Pierwszym celem nie były serwery, lecz stacje robocze – akurat pod ręką były stacje robocze kadry zarządzającej. Znajdowały się tam najbardziej wrażliwe informacje, klucze dostępu oraz poświadczenia o najwyższych uprawnieniach. Zainfekowanie tych maszyn pozwoliło na przeprowadzenie rekonesansu i znalezienie najsłabszego ogniwa.

Krok 3: Baza operacyjna

Z zainfekowanych stacji roboczych hakerzy wykonali tak zwany ruch boczny na jeden z podatnych serwerów opartych na Windows Server 2012. Wybór nie był przypadkowy – system ten, pełen niezałatanych podatności, stał się idealnym przyczółkiem.

To tutaj doszło do największej tragedii: serwer ten służył jednocześnie jako archiwum backupów. Przejmując nad nim kontrolę, „Grupa Smoków” otrzymała w prezencie dostęp do danych, które zostały wykradzione przed rozpoczęciem dalszych działań.

Krok 4: Szach-mat

Posiadając pełną kontrolę nad podatnym serwerem i wykorzystując brak segmentacji sieci, hakerzy zaatakowali serce wirtualizacji – środowisko VMware.

Poprzez wykorzystanie luki w oprogramowaniu, „Grupa Smoków” uzyskała dostęp do konta „root”. W tym momencie hakerzy nie musieli już szyfrować pojedynczych plików na każdym serwerze z osobna.

Mając dostęp do hostów ESXi, zaszyfrowali całe dyski wirtualne wszystkich maszyn jednocześnie.

Wynik: Całkowity paraliż

  • Systemy ERP: zablokowane
  • Bazy danych: zaszyfrowane
  • Backupy: niedostępne

Firma, która jeszcze dzień wcześniej działała bez zakłóceń, po weekendzie została operacyjnie sparaliżowana. Pracownikom pozostało jedynie patrzeć w puste ekrany monitorów.

Reakcja ITPunkt: Ratunek w trybie awaryjnym 

Kiedy zespół ITPunkt wszedł do akcji, zegar tykał na korzyść „Grupy Smoków”. Każda minuta zwłoki oznaczała ryzyko nieodwracalnej utraty danych lub ich dalszego wycieku do sieci darknet. Odpowiedź na incydent została podzielona na precyzyjne fazy, mające na celu nie tylko przywrócenie systemów, ale przede wszystkim ich pełne oczyszczenie i zabezpieczenie na przyszłość.

Faza I: Powstrzymanie i zabezpieczenie

Pierwszym krokiem była całkowita izolacja sieciowa. Środowisko zostało odcięte od sieci WAN oraz wewnętrznych segmentów, co natychmiast przerwało komunikację z serwerami sterującymi (C&C) hakerów. To kluczowy moment, uniemożliwiający im dalsze operacje w środowisku.

Równolegle zespół przystąpił do zabezpieczenia materiału dowodowego. Zabezpieczono logi z urządzeń sieciowych, warstwy wirtualizacji oraz pozostałych elementów środowiska. Analiza tych cyfrowych śladów pozwoliła nam zrozumieć techniki „Smoków” i zidentyfikować próbki złośliwego oprogramowania, które zainfekowało firmę.

Faza II: Rekonstrukcja fundamentów

Zamiast natychmiastowego przywracania całości środowiska, zespół ITPunkt postawił na odbudowę całej warstwy wirtualizacji, ponowną konfigurację wszystkich warstw oraz już na tym etapie wzmocnienie bezpieczeństwa. Dopiero na tak przygotowanym gruncie rozpoczęto odzyskiwanie danych z kopii migawkowych (snapshotów) zabezpieczonych na macierzy dyskowej.

Faza III: Weryfikacja i audyt

Kluczowym elementem była analiza odzyskanych maszyn pod kątem jakichkolwiek śladów grupy atakującej. Przeprowadziliśmy ją w całkowicie odizolowanym środowisku, sprawdzając mechanizmy podtrzymania dostępu przez atakujących.

Potwierdziliśmy brak aktywnych mechanizmów adwersarzy, co dało zielone światło do rozpoczęcia przywracania ciągłości operacyjnej.

Faza IV: Nowy standard bezpieczeństwa

Powrót do pełnej sprawności nie oznaczał powrotu do starego modelu pracy. Zrekonstruowane środowisko zostało od razu włączone pod całodobowy nadzór Centrum Operacji Bezpieczeństwa (Aurora SOC). Od teraz każdy nietypowy ruch w sieci jest natychmiast wykrywany, analizowany oraz izolowany.

Dodatkowo wdrożyliśmy zaawansowany monitoring sieci darknet – Aurora DarkWatch. System ten w trybie ciągłym przeszukuje przestrzeń darknetu w poszukiwaniu wzmianek o firmie, skradzionych poświadczeniach pracowników czy próbach handlu danymi.

Gorzka lekcja: Tej sytuacji można było uniknąć 

Analiza powłamaniowa przeprowadzona przez ITPunkt nie pozostawia złudzeń: „Grupa Smoków” nie miała trudnego zadania. Wykorzystali „uchylone drzwi”, które nie były „pilnowane”. Gdyby wdrożono standardy nowoczesnego IT, ten atak zakończyłby się jeszcze na nieudanej próbie logowania, wczesnym etapie rekonesansu bądź pojedynczej stacji roboczej, która bardzo szybko zostałaby wyizolowana.

  • Gdyby wdrożono dostęp warunkowy

Firma posiadała MFA, ale było ono skonfigurowane statycznie. Hakerzy, przejmując konta VPN, ominęli zabezpieczenia, ponieważ system nie potrafił ocenić ryzyka logowania. Gdyby wdrożono dostęp warunkowy, system automatycznie zablokowałby próbę połączenia, widząc logowanie z nietypowej lokalizacji, z nieznanego urządzenia czy w nietypowych godzinach – nawet przy podaniu poprawnego kodu MFA.

  • Gdyby przeprowadzono modernizację Active Directory i serwerów

Atakujący najpewniej odbiliby się od ściany, ale w tym przypadku trafili na infrastrukturę, która technologicznie zatrzymała się w czasie. Wyobraźmy sobie poziom funkcjonalności domeny sprzed ponad dekady, której sercem zabezpieczeń był całkowicie przestarzały Windows Server 2012, a o izolację krytycznych zasobów za pomocą modelu warstwowego (tieringu) nikt nie zadbał. To podręcznikowy przykład braku cyfrowej higieny.

  • Gdyby zastosowano segmentację sieci

W przykładowej firmie sieć była płaska – pozwalała przeskoczyć z dowolnej końcówki na dowolny serwer oraz do środowiska wirtualizacji. Prawidłowo zaprojektowana sieć zatrzymałaby intruza w martwym punkcie. Haker mógłby przejąć laptop, ale nie uzyskałby dostępu do np. warstwy wirtualizacji.

  • Gdyby backup był odizolowany

Przechowywanie backupu na serwerze z autoryzacją domenową to błąd krytyczny. Nowoczesne podejście zakłada posiadanie kopii typu immutable lub całkowicie odseparowanej (Air-Gap) od sieci. Gdyby firma posiadała bezpieczny backup, szantaż „Smoków” miałby mniejszą siłę rażenia.

  • Gdyby działał aktywny monitoring

Hakerzy nie szyfrują danych w sekundę po wejściu. Najpierw badają teren i szukają luk. Aktywny system monitoringu, np. SIEM, powiadomiłby o nietypowym ruchu w środowisku, pozwalając na szybką reakcję jeszcze na etapie rekonesansu.

Rachunek zysków i strat

Inwestycja w powyższe punkty to koszt ułamka strat, jakie generuje całkowity przestój firmy zatrudniającej ok. 200 osób. W przypadku opisywanego podmiotu cena świętego spokoju była wielokrotnie niższa niż koszty akcji ratunkowej oraz strat związanych z utratą wizerunku i wyciekiem danych.

Lekcja do odrobienia dla wszystkich

Historia ataku DragonForce na opisywane przedsiębiorstwo to klasyczny przykład tego, jak dług technologiczny zamienia się w dług finansowy. Dla zarządu i zespołu IT ta sytuacja była brutalnym przebudzeniem. Dziś firma ta operuje w zupełnie innym standardzie, ale cena, jaką zapłaciła za tę naukę, była nieproporcjonalnie wysoka.

Najważniejszym wnioskiem z tego incydentu jest zrozumienie, że bezpieczeństwo systemów nie jest dane raz na zawsze. Infrastruktura, która była wystarczająca w 2012 roku, w 2026 roku staje się zaproszeniem do ataku.

Chcesz porozmawiać z naszymi ekspertami?

Napisz na eksperci@itpunkt.pl lub wypełnij poniższy formularz

Newsletter:


* Pola wymagane