Cyberatak Na Polską Energetykę W Grudniu 2025 – Analiza Techniczna, Wipery I Problem Atrybucji - Security Bez Tabu

Cyberatak Na Polską Energetykę W Grudniu 2025 – Analiza Techniczna, Wipery I Problem Atrybucji

Kontekst ataku na infrastrukturę energetyczną

Grudzień 2025: Polska staje się celem skoordynowanego cyberataku wymierzonego w sektor energetyczny. Atak objął ponad 30 farm wiatrowych i fotowoltaicznych, dużą elektrociepłownię zaopatrującą ~500 tys. mieszkańców oraz firmę z sektora przemysłowego. Wszystkie działania miały charakter czysto destrukcyjny – cyberatak porównano do celowego podpalenia, zwłaszcza że nastąpił w okresie silnych mrozów i zamieci śnieżnych tuż przed Nowym Rokiem.

Mimo zakłócenia komunikacji między farmami OZE a operatorami sieci, nie doszło do przerw w dostawach prądu czy ciepła. Incydent ten uznaje się za największy atak na infrastrukturę energetyczną Polski od lat, stanowiący znaczącą eskalację w porównaniu do wcześniejszych zdarzeń.

Cele i przebieg ataku (29 grudnia 2025)

Atak na farmy wiatrowe i fotowoltaiczne (OZE)

Cyberatak skoncentrował się na stacjach przyłączeniowych farm wiatrowych i solarnych – punktach węzłowych, gdzie energia z OZE trafia do sieci dystrybucyjnej. Po uzyskaniu dostępu do wewnętrznych sieci tych stacji, agresor przeprowadził rekonesans, a następnie uruchomił zautomatyzowany plan sabotażu: uszkadzanie firmware kontrolerów, kasowanie plików systemowych oraz uruchamianie własnego malware typu wiper. Rano 29 grudnia zaplanowana sekwencja destrukcji została wyzwolona jednocześnie w wielu lokalizacjach. W efekcie zniszczono lub „uceglono” (ang. bricked) wybrane urządzenia RTU i sterowniki, przez co stacje utraciły łączność z systemem operatora i zdolność zdalnej kontroli. Produkcja energii nie została jednak przerwana, gdyż farmy wiatrowe/solarne nadal generowały prąd lokalnie pomimo utraty zdalnego nadzoru.

Atak na elektrociepłownię (CHP)

Równolegle celem stała się duża elektrociepłownia zaopatrująca blisko pół miliona odbiorców w ciepło. Atak ten poprzedzony był długotrwałą infiltracją infrastruktury IT/OT zakładu – napastnicy już od marca 2025 kradli w tle wrażliwe informacje operacyjne, m.in. dokumentację modernizacji OT i systemów SCADA. Dzięki temu zdołali zdobyć uprzywilejowane dostępy (konta administracyjne), co pozwoliło na swobodne poruszanie się po sieci zakładowej. Finałem operacji miał być sabotaż – nieodwracalne zniszczenie danych na urządzeniach w sieci elektrociepłowni za pomocą złośliwego oprogramowania typu wiper. Jednak w krytycznym momencie, gdy atakujący próbowali uruchomić destrukcyjny malware, jego działanie zostało zablokowane przez zainstalowane oprogramowanie EDR (Endpoint Detection & Response). Dzięki temu próba zakłócenia dostaw ciepła została udaremniona – planowany efekt sabotażu nie został osiągnięty.

Incydent w firmie produkcyjnej

Tego samego dnia (29 grudnia) hakerzy podjęli również próbę zdestabilizowania działalności prywatnego przedsiębiorstwa produkcyjnego. Atak na firmę był oportunistyczny i niezwiązany bezpośrednio z celami w sektorze energii, choć przeprowadzony w skoordynowaniu czasowym z tamtymi zdarzeniami. Wykorzystano ten sam destrukcyjny malware co w elektrociepłowni, dążąc do zaszyfrowania/skasowania danych w sieci IT firmy. Choć szczegóły tego incydentu są ograniczone, wiadomo, że wiper użyty u producenta wyrządził szkody w systemach IT, ale nie miał powiązania z infrastrukturą OT pozostałych celów.

(Uwaga: Powyższe trzy ataki – na OZE, na elektrociepłownię i na firmę – były elementami jednej kampanii, lecz każdy miał nieco inny przebieg i cel cząstkowy. Poniższa analiza techniczna omawia wspólne elementy technik użytych przez agresora.)

Analiza techniczna ataku – wektory, wipery i skutki w OT/IT

Wektory wejścia: FortiGate, VPN i podstawowe błędy zabezpieczeń

Pierwszym etapem ataku było przełamanie zewnętrznych zabezpieczeń sieciowych chroniących infrastrukturę krytyczną. Napastnicy wykorzystali podatne urządzenia Fortinet (np. firewalle FortiGate) – wiele z nich pracowało z domyślnymi hasłami administracyjnymi i bez włączonej uwierzytelności dwuskładnikowej (MFA). Te podstawowe zaniedbania ułatwiły zadanie: agresorzy znaleźli niezabezpieczone bramy VPN i firewalle wystawione do Internetu, po czym wykorzystali znane luki lub słabe hasła, by uzyskać dostęp do sieci wewnętrznych OT. Innymi słowy, do kluczowych segmentów infrastruktury krytycznej prowadziły drzwi zamknięte przysłowiową „kłódką na kod 1234”. Gdy tylko hakerzy przedostali się przez obwodę, rozpoczęli właściwy atak w głębi sieci.

Lateral movement i rekonesans w sieci ofiary

Po uzyskaniu przyczółków w sieciach energetycznych, atakujący przystąpili do rekonesansu i poszerzania swoich uprawnień (lateral movement). Wykorzystując wykradzione poświadczenia kont (np. hashy haseł administratorów) oraz skrypty automatyzujące (m.in. PowerShell), przemieszczali się pomiędzy serwerami i segmentami sieci. W elektrociepłowni przygotowania trwały miesiącami – już we wcześniejszych etapach intruzi zdołali wyciągnąć z serwerów katalogowych kopie baz kont (np. plik NTDS.dit) oraz zrzuty pamięci LSASS, co umożliwiło przejęcie kolejnych haseł i dostępów w domenie Windows (tzw. ataki Pass-the-Hash, Golden Ticket itp.). Jednocześnie prowadzono cichą kradzież wrażliwych danych – zwłaszcza plików dot. infrastruktury OT, planów modernizacji sieci SCADA, konfiguracji urządzeń przemysłowych itp.. W tym celu napastnicy nawet logowali się do usług chmurowych (np. Microsoft 365) ofiar, pobierając dokumenty techniczne związane z automatyką przemysłową. Z perspektywy obrońców, nic nie wskazywało jeszcze na destrukcyjne intencje – aktywność wyglądała jak typowa kampania szpiegowska, co uśpiło czujność. Do końca grudnia agresorzy zgromadzili jednak potrzebne dostępy i informacje, by przejść do fazy sabotażu.

Destrukcyjne malware w akcji: DynoWiper i LazyWiper

Kluczowym elementem ataku okazało się customowe oprogramowanie destrukcyjne typu wiper, stworzone specjalnie na potrzeby tej kampanii. ESET wykrył i przeanalizował nieznany wcześniej plik usuwający dane, nadając mu nazwę DynoWiper. Równolegle CERT Polska odnotował użycie prostego skryptu PowerShell kasującego pliki, ochrzczonego jako LazyWiper. DynoWiper był wdrożony na zaatakowanych komputerach z Windows (np. stacjach operatorskich HMI w energetyce), gdzie jego zadanie polegało na nadpisywaniu plików losowymi danymi i usuwaniu krytycznych danych systemowych – celem było unieruchomienie tych maszyn. Co istotne, malware ten nie zawierał mechanizmów trwałej persystencji ani komunikacji z infrastrukturą C2, działał więc jak jednorazowa „bomba” mająca zniszczyć lokalne zasoby. Natomiast LazyWiper to prawdopodobnie skrypt użyty w sieci IT firmy produkcyjnej – automatyzował on usuwanie danych na zainfekowanych hostach, prawdopodobnie w mniej zaawansowany sposób niż DynoWiper (np. kasując pliki przez systemowe polecenia PowerShell). Oba narzędzia zadziałały równocześnie w wielu środowiskach: DynoWiper uderzył w komputery HMI/SCADA energetyki, zaś LazyWiper skasował dane w sieci biurowej producenta. W rezultacie dziesiątki stacji roboczych i serwerów zostały trwale uszkodzone na poziomie software – nie były w stanie się uruchomić lub traciły ważne funkcje. Warto zauważyć, że DynoWiper skupiał się tylko na środowisku IT (Windows) i nie zawierał komponentów atakujących urządzenia przemysłowe OT. To sugeruje, że destrukcja infrastruktury odbywała się dwutorowo: poprzez wipery na systemach komputerowych oraz odrębne działania sabotażowe bezpośrednio na urządzeniach sterujących.

Sabotaż urządzeń OT i „brickowanie” sprzętu przemysłowego

Równolegle z atakiem malware’owym, sprawcy podjęli bezpośrednie działania wymierzone w infrastrukturę OT (Operational Technology). Mając uprzednio dostęp do paneli i interfejsów zarządzania automatyką w farmach i stacjach, manipulowali oni ustawieniami i firmware kontrolerów polowych. Z raportu wynika, że w niektórych przypadkach wgrano zmanipulowane/okrojone firmware do urządzeń RTU i sterowników bay controllers, co doprowadziło do ich awarii i zablokowania możliwości ponownego uruchomienia (tzw. firmware corruption powodujący bootloop). Resetowano konfiguracje zabezpieczeń (np. przywracając urządzenia do ustawień fabrycznych), zmieniano hasła i adresy IP na przejętych sprzętach, a nawet modyfikowano lub wyłączano reguły w zaporach sieciowych wbudowanych w urządzenia ICS. Na poziomie sieci OT odnotowano też masowe działania typu “factory reset” na niektórych modemach i konwerterach (np. urządzenia Moxa), co zdalnie rozstroiło ich konfigurację i przerwało komunikację między stacją a operatorem. Wszystkie te zabiegi miały na celu trwałe pozbawienie operatorów zdalnego wglądu i kontroli nad polową infrastrukturą – i faktycznie, w wielu zaatakowanych punktach kontrolnych odzyskanie zdalnego monitoringu wymagało fizycznej naprawy urządzeń w terenie. Krótko mówiąc, atakujący nie ograniczyli się do „zaszycia” Windowsów – uderzyli również w sprzęt przemysłowy, czyniąc go ślepym i głuchym. Takie działanie bezpośrednio na warstwie OT jest rzadko spotykane i niezwykle groźne, gdyż typowe mechanizmy ochronne IT (antywirusy, EDR) tam nie działają.

Skuteczność ataku: Mimo szeroko zakrojonej kampanii sabotażowej, ostateczny wpływ na fizyczne działanie systemu energetycznego był ograniczony. Zniszczenia dotyczyły warstwy monitoringu i IT – komunikacja i automatyka stacji została zakłócona, ale dostawy energii i ciepła nie ustały. Sieć elektroenergetyczna wykazała się odpornością (dzięki rezerwie mocy z elektrowni systemowych), a szybka reakcja obrońców – zwłaszcza zablokowanie wipera przez EDR w elektrociepłowni – zapobiegła najgorszemu scenariuszowi. Incydent ten należy więc traktować jako “bliski sukces” atakujących – byli o krok od wywołania realnej awarii, lecz ostatecznie ich operacja zakończyła się niepowodzeniem w sferze efektu końcowego. Niemniej jednak z punktu widzenia technik i skali – atak ten pokazał, że napastnicy dysponują zdolnością do poważnego zakłócenia OT i byli gotowi jej użyć.

Sandworm vs Berserk Bear – dylemat atrybucji ataku

Poszlaki wskazujące na Sandworm (GRU)

Kilka tygodni po incydencie analitycy z firmy ESET opublikowali raport, w którym powiązali atak z działalnością grupy Sandworm – rosyjskiej jednostki APT znanej z ataków na infrastrukturę krytyczną (przypisywanej wywiadowi wojskowemu GRU, jednostka 74455). Analiza próbek DynoWipera oraz taktyk, technik i procedur (TTPs) wykazała silne podobieństwo do wcześniejszych ataków Sandworm, zwłaszcza kampanii w Ukrainie. ESET podkreślił, że kod i schemat działania DynoWipera mocno pokrywa się z rodziną wiperów znanych z operacji Sandworm (np. z użytym miesiąc wcześniej w Ukrainie wiperem “ZOV”). Na tej podstawie przypisano atak Sandwormowi z umiarkowaną pewnością (medium confidence). Eksperci zwrócili też uwagę na symboliczny timing – uderzenie nastąpiło niemal dokładnie w 10. rocznicę słynnego ataku Sandworm na ukraińską sieć energetyczną z grudnia 2015, który doprowadził do pierwszej w historii przerwy w dostawie prądu spowodowanej malware. Tego typu zbieżność czasowa mogła być celowym sygnałem. Wnioski ESET potwierdziły ogólne podejrzenia – Rosja stała za atakiem, a styl wskazywał na ekipę Sandworm, znaną z agresywnych cyber-sabotaży (NotPetya 2017, Olympic Destroyer 2018, Industroyer2 2022 itp.).

Static Tundra / Berserk Bear – ustalenia CERT Polska (FSB)

Oficjalne stanowisko Polski po dochodzeniu CERT Polska okazało się jednak odmienne. Analiza infrastruktury użytej w ataku (serwerów VPS, tras ruchu, narzędzi anonimizujących) wykazała duże pokrycie z zasobami używanymi wcześniej przez grupę znaną jako Static Tundra. Według klasyfikacji różnych firm jest to ten sam aktor co Berserk Bear (CrowdStrike), Dragonfly lub Energetic Bear (Symantec), określany też jako Ghost Blizzard (Microsoft). Wspólnym mianownikiem tych nazw jest rosyjska Federalna Służba Bezpieczeństwa (FSB), a konkretnie Centrum 16 FSB, któremu przypisuje się działalność tej grupy w cyberprzestrzeni. Co istotne, Berserk Bear od lat wykazuje szczególne zainteresowanie sektorem energetycznym i znane są mu zdolności do atakowania urządzeń przemysłowych – to pasuje do profilu zaobserwowanego w Polsce ataku. Polskie władze w oficjalnych komunikatach oskarżyły więc FSB o przeprowadzenie grudniowej operacji. Podkreślono przy tym, że jest to pierwszy publicznie odnotowany przypadek działania destrukcyjnego przypisywany tej grupie – wcześniej Berserk Bear znany był głównie ze szpiegostwa i penetracji długoterminowych, nie sabotażu. Taka zmiana taktyki (jeśli potwierdzona) budzi niepokój, bo dowodzi gotowości rosyjskich służb do bezpośredniego niszczenia infrastruktury, a nie tylko kradzieży danych.

Rozbieżności i problem jednoznacznej atrybucji

Sprzeczne wnioski co do sprawców uwidoczniły klasyczny problem atrybucji w cyberbezpieczeństwie. Czy za atakiem stoi Sandworm (GRU), czy raczej Berserk Bear (FSB)? Oba zespoły mają rosyjskie afiliacje, ale zupełnie inny „modus operandi” historycznie. Pewne elementy wskazują na Sandworm – zwłaszcza podobieństwa malware do wcześniejszych wiperów GRU. Inne tropy sugerują działanie Berserk Bear – np. wykorzystanie słabych zabezpieczeń w starych urządzeniach i infrastruktura ataku powiązana z FSB. Jedną z hipotez jest możliwa współpraca lub podział ról między grupami. ESET w swoim rozszerzonym raporcie zaznaczył, że elementy tej operacji mogły być wykonane przez różne rosyjskie grupy hakerskie (np. malware dostarczony przez Sandworm, ale operacja sieciowa przez ludzi FSB). Istnieje też możliwość celowego pozostawienia mylących śladów przez atakujących, by skierować uwagę analityków na niewłaściwego trop (tzw. false flag). W efekcie atrybucja pozostaje niejednoznaczna, a dyskusje w środowisku bezpieczeństwa trwają. Niezależnie od tego, Polska jasno wskazała na Rosję jako mocodawcę ataku, co Moskwa tradycyjnie zdementowała. Dla ekspertów kluczowy wniosek jest następujący: rosyjskie grupy APT, niezależnie czy wojskowe czy cywilne, są zdolne do przeprowadzenia tak złożonych i destrukcyjnych ataków na infrastrukturę krytyczną – a więc zagrożenie jest realne, a podziały między grupami mogą się zacierać.

Wnioski – co oznacza ten atak dla bezpieczeństwa OT?

Grudzień 2025 stał się zimnym prysznicem dla polskiej (i europejskiej) branży energetycznej. Choć tym razem atak nie wywołał blackoutu ani zatrzymania sieci ciepłowniczej, incydent obnażył poważne słabości zabezpieczeń OT i pokazał, że przeciwnik jest gotów użyć destrukcji na niespotykaną dotąd skalę. Po raz pierwszy celem cyberataku stały się rozproszone źródła energii odnawialnej (farmy wiatrowe/PV) – to nowy rozdział, bo dotąd większość głośnych ataków na energetykę dotyczyła wielkich elektrowni lub sieci przesyłowych. Atak pokazał też, że klasyczne zaniedbania (np. domyślne hasła, brak aktualizacji) w systemach OT mogą zostać bezlitośnie wykorzystane przez państwowych aktorów. Niestety, większość organizacji w sektorze nadal nie traktuje cyberbezpieczeństwa przemysłowego priorytetowo – co ten incydent dobitnie wypunktował. Polska odpowiedziała zapowiedzią wzmocnienia regulacji i wymagań ochrony dla operatorów infrastruktury krytycznej (m.in. nowych ustaw dot. bezpieczeństwa IT/OT i reagowania na incydenty). Jednak prawo to nie wszystko – potrzebna jest realna zmiana podejścia na poziomie technicznym. Poniżej przedstawiamy checklistę kluczowych działań, które każdy operator systemów OT/ICS w energetyce (i nie tylko) powinien wdrożyć, by zminimalizować ryzyko powtórki scenariusza DynoWipera.

Checklist: zabezpieczenie infrastruktury OT przed atakami typu DynoWiper

  • Utwardź dostęp zdalny i urządzenia perymetryczne: zabezpiecz firewalle/VPN (np. FortiGate) – usuń domyślne konta admina i hasła, włącz uwierzytelnianie 2FA dla dostępu zdalnego, na bieżąco instaluj łatki bezpieczeństwa i aktualizacje firmware. Podstawowe konfiguracje “out of the box” muszą zostać zastąpione przez bezpieczne ustawienia przed podłączeniem urządzeń do Internetu.
  • Eliminuj słabe konfiguracje w sieci OT: zinwentaryzuj wszystkie urządzenia przemysłowe (RTU, sterowniki, IED, konwertery) pod kątem domyślnych poświadczeń i niepotrzebnych usług. Natychmiast zmień domyślne loginy/hasła na unikalne silne hasła, wyłącz nieużywane usługi (telnet, FTP, niezaszyfrowane protokoły) i ogranicz dostęp do interfejsów zarządzających tylko do zaufanych sieci. Każde pozostawione standardowe hasło to zaproszenie dla atakującego.
  • Segmentuj sieć IT/OT: wprowadź wyraźny podział sieci (strefy zdemilitaryzowane, firewalle między OT a IT) – tak, aby kompromitacja części biurowej nie umożliwiała od razu dotarcia do sieci sterowania. Ogranicz ruch pomiędzy segmentami do minimum niezbędnego dla działania biznesu. Segmentacja utrudni agresorom poruszanie się lateralne i powstrzyma rozprzestrzenianie malware w całej infrastrukturze.
  • Monitoruj infrastrukturę OT pod kątem anomalii: wdroż rozwiązania typu IDS/IPS i SIEM przystosowane do protokołów przemysłowych (IEC-104, DNP3, Modbus itp.). Loguj zdarzenia z urządzeń OT (sterowników, stacji HMI, inżynierskich) i integruj je z monitoringiem SOC. Ustaw alerty na nietypowe zachowania – np. uruchomienie nieznanych poleceń PowerShell, zmiany konfiguracji PLC poza oknem serwisowym czy komunikację urządzeń przez sieć Tor/VPN. Wczesne wykrycie próby sabotażu daje szansę na reakcję zanim dojdzie do destrukcji.
  • Wzmocnij higienę haseł i dostępów uprzywilejowanych: przeprowadź przegląd kont uprzywilejowanych w systemach OT. Usuń zbędne konta administracyjne, wprowadź regularną zmianę haseł i unikalne hasła dla każdego systemu. Rozważ wdrożenie hasłowych skarbców (vault) i ograniczenie dostępu administratorów tylko do adresów zarządzających. Atakujący w analizowanym incydencie wykorzystali słabe hasła i brak rotacji – nie dopuść do tego we własnej sieci.
  • Stosuj zabezpieczenia endpointów również w OT: zapewnij ochronę antywirusową/EDR na krytycznych stacjach roboczych w środowisku przemysłowym (np. serwerach SCADA, HMI). Odpowiednio skonfigurowane EDR potrafi zablokować nieznane wipery, co pokazał przykład elektrociepłowni (system EDR zatrzymał DynoWipera, zanim ten zdołał wyczyścić dane). Choć w OT zwykle ostrożnie podchodzi się do oprogramowania zabezpieczającego, wybrane kluczowe węzły (stacje inżynierskie, serwery historii) powinny mieć zapewnioną taką ochronę i aktualizacje baz zagrożeń w trybie offline.
  • Przygotuj plan reagowania na incydenty w OT: opracuj i przećwicz procedury awaryjne na wypadek ataku destrukcyjnego. Obejmij planem scenariusze wiperów – czy posiadamy kopie zapasowe krytycznych systemów sterowania? Czy wiemy, jak ręcznie poprowadzić ruch w sieci energetycznej w razie utraty telemetrii? Regularnie organizuj ćwiczenia typu red team/blue team symulujące atak na OT, aby sprawdzić skuteczność procedur i czas reakcji. Włącz się też w wymianę informacji o zagrożeniach – np. z CERT Polska i sektorowymi zespołami CSIRT – by otrzymywać na bieżąco indikatory ataku (IoC) i ostrzeżenia o nowych taktykach przeciwnika. Im lepiej przygotowany zespół i infrastruktura, tym większa szansa na zneutralizowanie ataku zanim wyrządzi on fizyczne szkody.

Podsumowanie

Atak z grudnia 2025 był groźnym precedensem, ale również cenną lekcją dla branży. Cyberbezpieczeństwo systemów OT nie jest już teoretycznym zaleceniem – to konieczność, jeśli chcemy zapobiec scenariuszom w stylu DynoWiper. W świecie rosnącej konwergencji IT/OT i narastającego zagrożenia ze strony zaawansowanych grup APT, energia bez odpowiedniego zabezpieczenia może łatwo paść ofiarą cyfrowego sabotażu. Polska miała szczęście w nieszczęściu – tym razem się udało obronić. Następnym razem stawką mogą być realne przerwy w dostawach prądu czy ciepła. Warto działać zawczasu, bez paniki, ale z pełną determinacją, aby bezpieczeństwo energetyki nie było już tabu.

Oczywiście serdecznie polecam przeczytać raporty CERT, Dragos i Esset oraz słowa komentarza badacza bezpieczeństwa Joe Slowika. to będą pierwsze 4 linki bibliografii.

Bibliografia