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 natomiast 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. W praktyce 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 jednak egzotycznej podatności zero-day. Zamiast tego 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. Po pierwsze, nie ograniczono dostępu do wybranych adresów IP. Po drugie, 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. W rezultacie firewall przestał być barierą. Ostatecznie stał się punktem pivotowania.
Z raportu wynika, że infiltracja była rozłożona w czasie. To szczególnie istotne. Natomiast 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. Co istotne, w tym momencie klasyczne mechanizmy perymetryczne przestają mieć znaczenie. Tym samym 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. W konsekwencji tworzy to ś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. W konsekwencji odbudowa wymaga pełnego odtworzenia z kopii zapasowych i rekonfiguracji środowiska.
W elektrociepłowni skutki byłyby poważne. Co więcej, 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. W praktyce 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. Tymczasem 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. Dzięki temu 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ą. Ostatecznie 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 polega jednak na 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. Faktycznie 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. Dlatego 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
