Atak na polską elektrociepłownię – jak błąd w konfiguracji FortiGate otworzył drzwi, a ESET PROTECT zatrzymał wipera
Atak na polską elektrociepłownię z końca 2025 roku to jeden z najbardziej pouczających incydentów ostatnich lat w obszarze bezpieczeństwa infrastruktury krytycznej. Celem była duża jednostka obsługująca blisko 500 tys. odbiorców. Nie chodziło o okup. Chodziło o trwałe zniszczenie systemów.
Sprawa została opisana przez CERT Polska, a techniczne szczegóły dotyczące użytego malware przedstawił ESET. To nie jest kolejna historia o ransomware. To studium błędu konfiguracyjnego na styku sieci i administracji oraz przykład tego, jak dobrze wdrożony EDR może uratować organizację w ostatnim możliwym momencie.
1. Gdy firewall przestaje być tarczą
Z perspektywy biznesu sprawa jest prosta. Elektrociepłownia to nie sklep internetowy. Przestój oznacza realne konsekwencje dla mieszkańców i instytucji publicznych. W sezonie grzewczym kilka dni niedostępności systemów sterowania i zaplecza IT może oznaczać kryzys operacyjny i reputacyjny.
Wektor wejścia był zaskakująco klasyczny. Urządzeniem brzegowym był firewall klasy NGFW – FortiGate produkcji Fortinet. Nie wykorzystano egzotycznej podatności zero-day. Kluczową rolę odegrała konfiguracja i sposób zarządzania dostępem administracyjnym.
Panel zarządzania był dostępny z internetu w zbyt szerokim zakresie. Nie ograniczono dostępu do wybranych adresów IP. Nie wymuszono MFA dla kont administracyjnych. Dodatkowo hasło było używane również w innych instytucjach.
To scenariusz, który w audytach widzimy częściej, niż klienci chcieliby przyznać. Urządzenie brzegowe traktowane jest jako bezpieczne z definicji. Tymczasem jeżeli interfejs administracyjny jest publicznie osiągalny, a dane uwierzytelniające nie są unikalne i chronione drugim składnikiem, kompromitacja jest kwestią czasu.
2. Od dostępu do FortiGate do pełnej kontroli domeny
Po uzyskaniu dostępu do FortiGate napastnicy zestawili połączenia VPN i rozpoczęli systematyczny rekonesans. Firewall przestał być barierą. Stał się punktem pivotowania.
Z raportu wynika, że infiltracja była rozłożona w czasie. To szczególnie istotne. Atakujący nie przeszli od razu do destrukcji. Najpierw zmapowali środowisko, zidentyfikowali serwery krytyczne, przejęli konta uprzywilejowane i zbudowali pełną widoczność infrastruktury.
W praktyce oznacza to ruch lateralny, eskalację uprawnień i przejęcie kontroli nad środowiskiem domenowym. W tym momencie klasyczne mechanizmy perymetryczne przestają mieć znaczenie. Atakujący działa jak administrator.
W projektach OT i energetycznych często obserwujemy brak realnej segmentacji między IT a systemami produkcyjnymi. VLAN istnieje, ale reguły ACL są zbyt szerokie. VPN zestawiany jest do sieci, w której znajdują się również serwery zarządzające. To tworzy ścieżkę do systemów krytycznych.
Jeżeli firewall jest pierwszym ogniwem, to brak segmentacji jest drugim.
3. DynoWiper – sabotaż zamiast okupu
Faza końcowa miała charakter destrukcyjny. Zastosowane malware określane jako DynoWiper należało do klasy wiperów. W przeciwieństwie do ransomware, które szyfruje dane w celu wymuszenia zapłaty, wiper nadpisuje pliki i niszczy strukturę systemu plików.
Oznacza to realne uszkodzenie danych, partycji, a nawet mechanizmów startowych systemu. Odbudowa wymaga pełnego odtworzenia z kopii zapasowych i rekonfiguracji środowiska.
W elektrociepłowni skutki byłyby poważne. Systemy wsparcia produkcji, aplikacje zarządzające, infrastruktura domenowa – wszystko mogłoby zostać unieruchomione. W kontekście infrastruktury krytycznej mówimy nie tylko o stracie finansowej, ale o ryzyku dla ciągłości dostaw.
Próby uruchomienia DynoWipera podjęto trzykrotnie. Każda została zablokowana.
4. Dlaczego ESET PROTECT zatrzymał atak
W środowisku działało rozwiązanie klasy EDR/XDR – ESET PROTECT.
Kluczowa była analiza behawioralna. System nie czekał na sygnaturę znanego zagrożenia. Zareagował na wzorzec zachowania charakterystyczny dla destrukcji danych.
W momencie aktywacji wipera pojawiły się masowe operacje nadpisywania plików, gwałtowny wzrost operacji I/O oraz nietypowa aktywność procesu działającego w kontekście kont uprzywilejowanych. Dla klasycznego antywirusa, szczególnie przy nieznanej próbce, identyfikacja mogłaby być opóźniona.
EDR analizuje kontekst. Jeżeli proces zaczyna wykonywać operacje niespójne z profilem środowiska, może zostać zablokowany w czasie rzeczywistym. W tym przypadku destrukcja została zatrzymana zanim osiągnęła krytyczny poziom.
To różnica między ochroną reaktywną a architekturą opartą na detekcji zachowań. W środowiskach objętych regulacjami NIS2 takie podejście przestaje być opcją. Staje się wymogiem minimalnym.
5. Co ten incydent mówi o dojrzałości bezpieczeństwa
Schemat jest czytelny. Błąd w konfiguracji FortiGate. Uzyskanie dostępu administracyjnego. Lateral movement i przejęcie domeny. Próba sabotażu poprzez wiper. Zatrzymanie destrukcji dzięki EDR.
W praktyce najczęstszym błędem nie jest brak technologii, lecz brak spójnej architektury. Firewall działa, VPN działa, antywirus jest zainstalowany. Problem w tym, że te elementy nie są projektowane jako warstwy wzajemnie się uzupełniające.
Z naszej praktyki wynika, że w wielu organizacjach hasła administracyjne są współdzielone między środowiskami, a interfejsy management nadal są dostępne globalnie. To nie są zaawansowane błędy. To podstawowa higiena bezpieczeństwa.
6. Jak BOIT projektuje warstwową ochronę
W BOIT nie traktujemy FortiGate jako urządzenia do postawienia i zapomnienia. Każdy projekt zaczynamy od analizy ekspozycji. Sprawdzamy, czy interfejs zarządzania jest odseparowany w dedykowanej sieci management, czy dostęp jest ograniczony do konkretnych adresów IP oraz czy MFA jest wymuszone dla wszystkich administratorów.
Weryfikujemy polityki VPN, segmentację między IT i OT, logowanie operacji administracyjnych oraz retencję logów. Hardening obejmuje także testy dostępu z zewnątrz oraz symulację prób lateralnego ruchu.
Wdrożenie ESET PROTECT traktujemy jako projekt architektoniczny. Analizujemy krytyczność systemów, konfigurujemy zaawansowaną detekcję behawioralną, włączamy automatyczną izolację hosta i testujemy scenariusze typu ransomware oraz wiper. Integrujemy ochronę z serwerami fizycznymi, wirtualnymi oraz Microsoft 365.
Celem nie jest alarmowanie. Celem jest zatrzymanie destrukcji.
Źródła i dalsza lektura
- Raport incydentu – CERT Polska
- Analiza techniczna DynoWipera – ESET
- Dokumentacja hardeningu FortiGate – Fortinet
