Autor: Wojciech Ciemski

Wprowadzenie do problemu / definicja luki

29 grudnia 2025 r. w Polsce odnotowano skoordynowaną serię ataków o czysto destrukcyjnym celu (w raporcie porównywaną do „cyfrowego podpalenia”). Kampania objęła ponad 30 farm wiatrowych i fotowoltaicznych, firmę z sektora produkcyjnego oraz dużą elektrociepłownię (CHP) dostarczającą ciepło dla ok. pół miliona odbiorców. Kluczowe jest to, że incydent dotknął jednocześnie środowisk IT i OT, co nadal jest rzadkością w publicznie opisywanych zdarzeniach.

Wąskim gardłem nie była „jedna magiczna luka CVE”, tylko kombinacja: ekspozycja zdalnego dostępu, słabe uwierzytelnianie (w tym brak MFA), odziedziczone konfiguracje i praktyki (np. powtarzanie kont/ haseł między lokalizacjami), a następnie konsekwentna automatyzacja działań destrukcyjnych w sieciach stacyjnych/zakładowych.

W skrócie

• Ataki z 29.12.2025 były skoordynowane i nastawione na sabotaż (niszczenie danych/urządzeń), a nie ransomware.
• Wektor na obiektach OZE: urządzenia FortiGate jako VPN/firewall z wystawionym interfejsem VPN do Internetu, bez MFA; dodatkowo pojawia się wątek reuse’owania poświadczeń między obiektami.
• W OT obserwowano m.in. działania na RTU/HMI: użycie domyślnych danych logowania (np. na kontrolerach) i próby uszkadzania/wymazywania systemów oraz elementów sterowania.
• CERT Polska przypisał aktywność klastrowi Static Tundra (powiązywanemu z FSB / Center 16), podczas gdy część analiz zewnętrznych (m.in. ESET) wskazuje na możliwe związki z Sandworm.
• Rząd podkreśla, że Polska obroniła się przed skutkami typu blackout, ale incydent potraktowano jako sygnał do dalszego wzmacniania systemu.

Kontekst / historia / powiązania

W ostatnich latach granica między „APT do szpiegostwa” a „APT do sabotażu” coraz częściej się zaciera. W tym incydencie istotne są dwa równoległe wątki:

1. Atrybucja państwowa: według informacji opisywanych publicznie, strona polska wskazuje na rosyjską służbę (FSB) jako prawdopodobnego sprawcę, a sam incydent miał miejsce w okresie niskich temperatur i śnieżyc, co zwiększało potencjalną presję operacyjną na energetykę i ciepłownictwo.
2. Spór o „kto dokładnie”: CERT przypisuje kampanię klastrowi Static Tundra, natomiast część badaczy zwraca uwagę na podobieństwa wipera DynoWiper do wcześniejszych narzędzi kojarzonych z Sandworm (w tym do wipera nazwanego przez ESET „ZOV”). To klasyczny przypadek, gdzie malware similarity ≠ jednoznaczna atrybucja, bo narzędzia i techniki mogą być współdzielone, odsprzedawane lub kopiowane.

Analiza techniczna / szczegóły luki

1) OZE i punkt przyłączenia (GCP): FortiGate jako brama wejścia

Raport wskazuje, że w badanych obiektach OZE urządzenia typu FortiGate pełniły rolę koncentratora VPN i firewalla. W każdym przypadku interfejs VPN był wystawiony do Internetu i dopuszczał uwierzytelnianie kontami z konfiguracji bez MFA. Ze względu na destrukcję, nie zawsze udało się odzyskać komplet logów, ale z analizy wynika, że część urządzeń bywała w przeszłości podatna (w tym na klasy błędów umożliwiających RCE) przez dłuższe okresy.

Dodatkowo pojawia się ważna obserwacja operacyjna: w branży ma być powszechne powtarzanie kont i haseł między wieloma lokalizacjami. To oznacza, że kompromitacja jednego obiektu może stać się „kluczem głównym” do kolejnych.

2) OT: RTU, przekaźniki zabezpieczeniowe, HMI – sabotaż zamiast tylko IT

W części środowisk sterowania obserwowano działania, które nie polegały wyłącznie na niszczeniu plików na stacjach roboczych, ale również na destabilizacji komponentów OT (np. poprzez logowanie z domyślnymi poświadczeniami i wykonywanie komend destrukcyjnych na kontrolerach). To szczególnie niebezpieczne, bo „wymazanie” lub uszkodzenie urządzeń OT może wymagać interwencji terenowej i wydłużać czas odtworzenia usług.

3) Wipery i dystrybucja: DynoWiper i LazyWiper oraz GPO/PowerShell

CERT opisuje użycie wcześniej niekojarzonych rodzin wiperów, których celem było nieodwracalne niszczenie danych, bez elementu wymuszenia okupu. W raporcie rozróżniono scenariusze uruchomienia: w środowiskach OZE malware miał być odpalany bezpośrednio na maszynie HMI, a w elektrociepłowni i firmie produkcyjnej dystrybucja odbywała się w domenie Active Directory przez skrypt PowerShell uruchomiony na kontrolerze domeny (model „szybkiego rażenia” wielu hostów).

4) Firma produkcyjna: kompromitacja urządzenia brzegowego i persistence

W przypadku firmy produkcyjnej opisano dostęp przez urządzenie brzegowe Fortinet, a także modyfikacje konfiguracji, które miały zapewnić trwałość dostępu nawet po zmianach haseł (m.in. poprzez mechanizmy skryptowe na urządzeniu).

5) Atrybucja techniczna: „Static Tundra” i zastrzeżenia dot. podobieństw do Sandworm

CERT wskazuje, że infrastruktura i charakterystyki komunikacji pokrywają się z tym, co publicznie opisywano dla klastra „Static Tundra”, a jednocześnie zaznacza, że podobieństwa DynoWiper do wiperów wiązanych z Sandworm są zbyt ogólne, by same w sobie przesądzały o sprawstwie.
Z kolei ESET opisuje podobieństwa DynoWiper do ich wcześniejszych obserwacji destrukcyjnego malware przypisywanego Sandworm (ZOV), przy jednoczesnym zastrzeżeniu, że nie wszystkie elementy operacji muszą pochodzić od jednej grupy.

Praktyczne konsekwencje / ryzyko

1. Ryzyko kaskadowe w OZE: nawet jeśli pojedyncza farma nie destabilizuje systemu, równoległe uderzenie w dziesiątki obiektów zwiększa obciążenie operatorów, czas reakcji i ryzyko błędów proceduralnych.
2. Czas odtworzenia w OT: urządzenia sterujące, RTU czy elementy telemechaniki mogą wymagać fizycznej wymiany/ponownego wgrania firmware’u i walidacji – a to oznacza realny koszt i przestoje.
3. Eskalacja intencji: publicznie podkreślano, że to incydent „sabotażowy” i jeden z poważniejszych tego typu w ostatnich latach. Taki sygnał zmienia model zagrożeń dla firm, które dotychczas projektowały ochronę głównie pod wyciek danych lub phishing.

Rekomendacje operacyjne / co zrobić teraz

Poniżej „checklista” w kolejności od działań o najwyższym ROI do bardziej złożonych:

1) Zdalny dostęp (VPN/edge) – natychmiastowe „higieniczne minimum”

• Włącz MFA wszędzie, gdzie jest zdalny dostęp administracyjny lub operatorski (VPN, portale, jump-hosty). Brak MFA pojawia się wprost jako element ryzyka.
• Wymuś unikalne konta i hasła per obiekt (koniec z re-use między farmami/lokalizacjami).
• Audyt urządzeń brzegowych: aktualizacje, przegląd ekspozycji usług, usunięcie „starych” reguł i kont technicznych.

2) Segmentacja IT/OT i kontrola ścieżek lateral movement

• Odseparuj domenę/AD od stref OT (lub przynajmniej twardo kontroluj relacje zaufania, konta serwisowe i ścieżki RDP/SMB).
• W OT: dopuszczaj tylko niezbędne protokoły i kierunki komunikacji; rozważ jump-serwery z silnym uwierzytelnianiem i pełnym logowaniem.

3) Eliminacja domyślnych poświadczeń i twardnienie urządzeń OT

• Usuń domyślne hasła/konta na RTU/HMI i urządzeniach pośredniczących (to w raporcie pojawia się jako realny wektor destrukcji).
• Włącz i egzekwuj mechanizmy weryfikacji firmware (tam, gdzie dostępne) oraz kontroluj proces aktualizacji i źródła obrazów.

4) Odporność na wipery

• Kopie zapasowe offline/immutable + testy odtworzenia (nie „mamy backup”, tylko RTO/RPO na stole).
• EDR/monitoring na kontrolerach domeny i serwerach zarządzających: wykrywanie nietypowych działań PowerShell/GPO, masowych modyfikacji polityk, nietypowych zadań harmonogramu itp. (w raporcie opisano dystrybucję przez skrypt i domenę).

5) Przygotowanie organizacyjne

• Scenariusze IR dla sabotażu (wiper/OT): procedury izolacji, odcięcia zdalnego dostępu, przełączeń ręcznych, kontaktów vendor/PSIRT.
• W sektorze energii: ćwiczenia „table-top” łączące zespoły SOC + automatycy + utrzymanie ruchu.

Różnice / porównania z innymi przypadkami

Static Tundra (FSB) vs Sandworm (GRU) w tym incydencie sprowadza się do pytania: czy obserwujemy „nową fazę” tej samej grupy, współdzielenie narzędzi, czy operację mieszaną?

• CERT argumentuje atrybucję do klastra Static Tundra m.in. na podstawie infrastruktury i jej charakterystyk, jednocześnie traktując podobieństwa DynoWiper do narzędzi sandwormowych jako niewystarczające do twardej identyfikacji.
• ESET widzi techniczne podobieństwa DynoWiper do ZOV i łączy je z Sandworm, ale też dopuszcza, że elementy operacji mogły być rozdzielone między różne podmioty.
• Publiczne doniesienia podkreślają, że polskie władze wskazały na FSB jako prawdopodobnego sprawcę, a sama operacja była postrzegana jako eskalacja w stronę działań destrukcyjnych.

W praktyce dla obrońców wniosek jest prosty: modeluj zagrożenie po TTP, nie po etykiecie grupy. Jeśli masz ekspozycję VPN bez MFA, re-use poświadczeń i słabą separację IT/OT – „kto” jest drugorzędne wobec „jak szybko może to powtórzyć ktoś inny”.

Podsumowanie / kluczowe wnioski

• To był incydent, w którym sabotaż cyfrowy dotknął jednocześnie IT i OT, a celem było niszczenie, nie zysk.
• Najbardziej „przyziemne” problemy (MFA, unikalne hasła, ekspozycja VPN, domyślne konta) okazały się krytyczne w skali krajowej.
• Atrybucja (Static Tundra vs Sandworm) jest ważna politycznie, ale operacyjnie kluczowe są powtarzalne techniki: kompromitacja edge, ruch boczny, a potem szybka destrukcja (w tym przez mechanizmy domenowe).
• Nawet gdy nie doszło do blackoutu, incydent pokazuje, że odporność musi obejmować wipery + OT recovery, a nie tylko ochronę przed wyciekiem danych.

Źródła / bibliografia

1. Raport techniczny CERT: „Energy Sector Incident Report – 29 December 2025”. (cert.pl)
2. Artykuł: The Hacker News – podsumowanie i kontekst (DynoWiper/LazyWiper, wątki FortiGate, przypisanie do Static Tundra). (The Hacker News)
3. Analiza: ESET – „DynoWiper update: Technical analysis and attribution”. (welivesecurity.com)
4. Komunikat rządowy: Gov.pl – o odparciu ataku i działaniach wzmacniających. (Gov.pl)
5. Depesza: Reuters – wątek przypisania i komentarze ekspertów. (Reuters)