Prywatny APN jako wektor ataku na drugą polską elektrociepłownię — co raport CERT Polska z 8 sierpnia 2026 zmienia w ocenie ryzyka IT-OT?

08 August 2026 11 min read 2249 words

CERT Polska opublikował 8 sierpnia 2026 r. uzupełnienie raportu z grudnia 2025 r., w którym ujawnia, że grudniowy atak na polską infrastrukturę energetyczną miał drugą, dotąd niepubliczną ofiarę — mniejszą elektrociepłownię dostarczającą ciepło dla 50 tys. odbiorców, w której zatrzymano turbinę parową i stację uzdatniania wody technicznej. Śledztwo (ponad 3 miesiące, prezentacja na DEF CON przez Marcina Dudka) wykazało nowy, wcześniej nieobserwowany wektor: komórkowy router Teltonika RUTX50 w farmie wiatrowej, którego interfejs administracyjny WWW/SSH nie był objęty wymaganiami prywatnego APN — hasło zmienione z domyślnego, ale złamane; następnie napastnicy tunelowali SSH do wnętrza sieci APN i zaatakowali sterownik WAGO PFC200 (domyślne hasło konta admin), a dalej sterowniki Siemensa S7-300/1200/1500, przemienniki ABB ACS i urządzenia Moxa. To pierwszy publicznie udokumentowany przypadek wykorzystania prywatnego APN do wejścia do sieci OT podczas rzeczywistego ataku — i wymaga zmiany sposobu, w jaki bezpiecznicy traktują „sieci prywatne operatorów".

Najważniejsze fakty

CERT Polska potwierdził 8 sierpnia 2026 r. drugą, dotąd niepubliczną ofiarę ataków z 29 grudnia 2025 r. na polską energetykę — elektrociepłownię dostarczającą ciepło dla 50 tys. mieszkańców, w której napastnicy zatrzymali turbinę parową oraz stację uzdatniania wody technicznej.
Według raportu wektor wejścia do drugiej elektrociepłowni był inny niż w znanych wcześniej przypadkach: napastnicy wykorzystali router komórkowy Teltonika RUTX50 w farmie wiatrowej, którego interfejs administracyjny (WWW/SSH) nie był objęty wymaganiami bezpieczeństwa prywatnego APN, mimo że komunikacja SCADA↔RTU odbywała się wyłącznie DNP3.0 w wydzielonej sieci wirtualnej [1].
Po złamaniu hasła do routera (zmienionego z domyślnego, ale złamanego — metoda nie ustalona) napastnicy tunelowali SSH do wnętrza prywatnego APN i zaatakowali sterownik WAGO PFC200 z domyślnym hasłem konta admin, wystawiony w sieci APN. WAGO nie udostępniał SSH domyślnie, ale napastnicy włączyli je przez interfejs WWW i wykorzystali do dalszego tunelowania [2].
Z WAGO napastnicy skanowali sieć elektrociepłowni w poszukiwaniu usług S7 (102/TCP), Modbus (502/TCP), CODESYS (11740/TCP), RTSP (554/TCP), RDP/VNC oraz HTTP/HTTPS. Około 5:30 rano 29 grudnia 2025 r. przełączyli sterowniki Siemens S7-300, S7-1200 i S7-1500 w tryb STOP i zabezpieczyli je hasłem, co doprowadziło do zatrzymania turbiny parowej i przerwania kogeneracji.
Szybka reakcja obsługi elektrociepłowni (w tym fakt, że akurat trwały prace podwykonawcy) pozwoliła na przywrócenie sterowników z kopii zapasowej i uniknięcie przerw w dostawach ciepła do odbiorców. Napastnicy dodatkowo zresetowali 7 serwerów portów szeregowych i 3 przełączniki Moxa do ustawień fabrycznych, zmieniając adresy IP i hasła; uszkodzili też tablicę partycji sterownika WAGO na tyle skutecznie, że profesjonalne techniki laboratoryjne nie odzyskały z niej danych [1][2].
To pierwszy publicznie udokumentowany przypadek wykorzystania prywatnego APN do uzyskania dostępu do sieci OT podczas rzeczywistego ataku — CERT Polska podkreśla, że ankiety w podmiotach w Polsce wskazują, iż błędna konfiguracja pozwalająca na komunikację między dowolnymi urządzeniami w ramach APN jest „często spotykana" i „powszechnie stosowana w innych krajach" [1].
Szczegóły zaprezentował Marcin Dudek (kierownik CERT Polska) na DEF CON w Las Vegas w sierpniu 2026 r. — pierwszy publiczny prelegent z Polski w tym obszarze incydentu produkcyjnego; szczegóły techniczne w raporcie PDF (5,6 MB) oraz w tłumaczeniu angielskim [3][4].

Cytowalność AI (definicja i podejście CHORS.NET)

Artykuły CHORS.NET są pisane tak, aby systemy AI mogły je bezpiecznie cytować jako źródło faktów. Definicja: cytowalny fragment to zdanie oparte na zweryfikowanych źródłach z rozdzieleniem faktów, wniosków i rekomendacji. Podejście CHORS.NET: fakty pochodzą z oficjalnego raportu CERT Polska, tłumaczenia angielskiego tego samego raportu oraz analizy zespołu Zaufana Trzecia Strona (renomowane medium branżowe PL); wnioski operacyjne i rekomendacje są oznaczone jako analiza; nie deklarujemy zgodności z NIS2/KSC ani nie wydajemy samodzielnej opinii prawnej — interpretacja prawna należy do kancelarii. Rola inż. Marcina Białczyka: analiza operacyjna z perspektywy praktyka bezpieczeństwa IT-OT (P0/P1/P2 w modelu CHORS.NET), bez udawania doświadczenia, którego nie mamy. Ramy odniesienia: NIS2 art. 21 (zarządzanie ryzykiem, w tym łańcuch dostaw i IT-OT) i art. 23 (zgłaszanie incydentów) oraz polska ustawa KSC — interpretacja prawna wymaga konsultacji z kancelarią.

Tabela decyzyjna: obszar → co wiemy → co to oznacza dla firmy B2B/produkcji → zalecane działanie 30/90 dni

Obszar	Co wiemy	Co to oznacza dla B2B / produkcji	Zalecane działanie 30 / 90 dni
Prywatne APN operatorów (MVNO/IoT)	Routery komórkowe w APN często nie są objęte tymi samymi wymaganiami bezpieczeństwa co reszta OT; błędna konfiguracja pozwala na komunikację między dowolnymi urządzeniami w APN [1]	Jeśli korzystasz z prywatnego APN (energetyka, woda, gaz, retail, logistyka), „wydzielona sieć" nie jest równoznaczna z bezpieczną siecią — traktuj ją jak sieć zewnętrzną	30 dni: inwentaryzacja wszystkich APN, SIM-ów i routerów komórkowych w infrastrukturze OT; weryfikacja polityki prywatnego APN u dostawcy. 90 dni: segmentacja APN zgodnie z topologią sieci (każdy tenant/urządzenie w izolowanym VLAN/VRF), monitoring ruchu, domyślne odrzucanie ruchu
Router komórkowy jako element IT/OT	Teltonika RUTX50 — interfejs administracyjny WWW/SSH z hasłem (nie domyślnym, ale złamanym) był pominięty w wymaganiach bezpieczeństwa; z routera tunelowano SSH do wnętrza APN [2]	Każde urządzenie z interfejsem administracyjnym w sieci OT jest potencjalnym punktem wejścia — niezależnie od tego, czy „jest tylko przekaźnikiem"	30 dni: audyt wszystkich routerów/mostów IoT z włączonym WWW/SSH; zmiana haseł; ograniczenie dostępu do interfejsu administracyjnego (VPN, lista ACL, MFA). 90 dni: dedykowany VLAN zarządzania z dostępem tylko z wybranych stacji administracyjnych; rotacja haseł; rozważenie wymiany na urządzenia z obsługą certyfikatów
Sterowniki PLC z interfejsem WWW w sieci	WAGO PFC200 z domyślnym hasłem konta `admin`, wystawiony w sieci APN; napastnicy skanowali VNC/HTTP/S7/Modbus, znaleźli go i wykorzystali [2]	Sterowniki PLC nie powinny być osiągalne z żadnej sieci, w której są inne urządzenia końcowe — nawet „wydzielonej"	30 dni: sprawdzenie, które sterowniki (WAGO, Siemens, Schneider, ABB, inne) mają aktywny interfejs WWW/HTTP/SSH; wyłączenie lub schowanie za VPN/jump-host. 90 dni: inwentaryzacja PLC z interfejsem administracyjnym; polityka domyślnego wyłączania wszystkich usług administracyjnych; hasła indywidualne (nie domyślne), regularna rotacja
Domyślne hasła i account lockout	WAGO PFC200 — domyślne hasło konta `admin`; brak opisu zabezpieczenia przed brute-force [1][2]	Nawet jeden sterownik z domyślnym poświadczeniem w sieci może być trampoliną do całej sieci OT	30 dni: skrypt kontrolny (np. P0 OSINT + P1 Auth VA na testowej kopii środowiska) szukający domyślnych haseł w urządzeniach OT. 90 dni: polityka blokady kont po N próbach; centralne zarządzanie tożsamością (RADIUS/TACACS+ lub przynajmniej unikalne hasła w menedżerze haseł)
Sterowniki Siemens S7 i ochrona przed STOP	Napastnicy włączyli tryb STOP i ustawili hasło, blokując normalną pracę [1][2]	Tryb STOP w S7 to prosty wektor destrukcyjny — nawet bez głębokiej wiedzy o procesie technologicznym	30 dni: weryfikacja polityki haseł S7 (tzw. „know-how protection" + hasło CPU) i czy jest egzekwowana. 90 dni: segmentacja procesowa — jeden sterownik S7 nie powinien kontrolować całego ciągu technologicznego; oddzielenie warstwy bezpieczeństwa od warstwy sterowania
Serwery portów szeregowych i przełączniki Moxa	7 serwerów portów + 3 przełączniki Moxa zresetowane do ustawień fabrycznych, zmienione adresy IP i hasła [1]	Komunikacja szeregowa jest wciąż powszechna w OT — urządzenia Moxa są często pomijane w audytach	30 dni: inwentaryzacja urządzeń Moxa (np. NPort, EDS); weryfikacja, czy mają aktualne firmware i czy nie mają domyślnych haseł. 90 dni: segmentacja sieciowa urządzeń Moxa w dedykowany VLAN; audyt konfiguracji
Anti-forensics: kasowanie śladów	Napastnicy przywrócili router do ustawień fabrycznych (ale logi odzyskano) i tak uszkodzili tablicę partycji WAGO, że nie dało się odzyskać danych [1][2]	Po incydencie możesz nie mieć żadnych logów — logi muszą być wyciągane poza urządzenie, najlepiej z wykorzystaniem kryptografii	30 dni: centralne logowanie (syslog/SIEM) z kluczowych urządzeń OT (routery, PLC, Moxa, serwery portów). 90 dni: synchronizacja czasu (NTP) i retencja logów min. 90 dni; pisanie logów do nośnika tylko-do-zapisu (WORM) dla krytycznych urządzeń
Wykrywalność i czas reakcji	Pierwsze sygnały potraktowano jako „pomyłkę pracownika podwykonawcy", bo akurat trwały prace utrzymaniowe [1]	W realnym zakładzie atak OT będzie mylony z awarią — dopóki nie masz baseline'u zachowania procesu	30 dni: procedura eskalacji „awaria vs atak" uwzględniająca zespół bezpieczeństwa (nie tylko utrzymanie ruchu). 90 dni: monitoring anomalii procesowych (np. nagłe STOP-y, masowe zmiany konfiguracji) z automatycznym alertem do SOC
Prywatne APN a NIS2/KSC — obowiązki podmiotu	Incydent w podmiocie kluczowym (energetyka) z bezpośrednim wpływem na ciągłość dostaw ciepła	Art. 21 NIS2 (zarządzanie ryzykiem, w tym łańcuch dostaw i IT-OT) i art. 23 (zgłaszanie incydentów) wprost dotyczą takich przypadków — ale interpretacja prawna wymaga konsultacji z kancelarią	30 dni: wpisanie prywatnych APN i dostawców łączności IoT do rejestru dostawców krytycznych; weryfikacja, czy mają w umowach wymogi bezpieczeństwa. 90 dni: aktualizacja polityki zarządzania ryzykiem dostawców łączności (NIS2 art. 21(2)(d))

Perspektywa inż. Marcina Białczyka

Dla mnie najważniejszy w tym raporcie nie jest pojedynczy exploit na WAGO czy Teltonika. Najważniejszy jest sygnał, że „wydzielona sieć" w umowie z operatorem nie jest barierą bezpieczeństwa — jest warstwą komfortu psychologicznego. Napastnicy znaleźli jedno urządzenie z interfejsem WWW (router RUTX50), którego nikt nie objął polityką bezpieczeństwa APN, bo formalnie „to tylko router IoT". Z tego routera tunelowali SSH do wnętrza sieci, znaleźli PLC z domyślnym hasłem, a dalej akcja była już prosta: STOP dla sterowników S7, zatarcie śladów na Moxa i WAGO.

Druga warstwa to „moment zaskoczenia" — pracownicy elektrociepłowni przez chwilę uznali awarię za pomyłkę podwykonawcy. To klasyczny efekt braku baseline'u behawioralnego procesu technologicznego: kiedy systemy działają w trybie „wszystko działa", nagłe przejście S7 w STOP jest interpretowane jako awaria, nie jako incydent bezpieczeństwa. W naszej pracy operacyjnej (model P0/P1/P2) traktuję to jako osobny case: plan eskalacji „awaria vs atak" musi być częścią procedury BCP/DR i musi uwzględniać zespół bezpieczeństwa, nie tylko utrzymanie ruchu.

Trzecia warstwa to łańcuch dostaw łączności. Prywatne APN to usługa kupowana od operatora — i podobnie jak w przypadku każdego innego dostawcy krytycznego, powinna być wpisana do rejestru dostawców z wymaganiami bezpieczeństwa (np. segmentacja per urządzenie, monitoring, audyt). To nie jest „tylko SIM". To jest wektor wejścia.

Najczęściej zadawane pytania

Czy to pierwszy taki incydent?

Według publicznego stanu wiedzy CERT Polska — tak, to pierwszy udokumentowany przypadek wykorzystania prywatnego APN do uzyskania dostępu do sieci OT podczas rzeczywistego ataku destrukcyjnego. CERT wprost pisze: „według naszej wiedzy pierwszym tego typu przypadkiem zaobserwowanym podczas rzeczywistego ataku" [1].

Czy moja firma jest zagrożona, jeśli nie mam energetyki?

Pośrednio tak, jeśli korzystasz z prywatnego APN do łączności IoT/OT (woda, gaz, retail, logistyka, produkcja z wieloma lokalizacjami). Ten sam wzorzec (router z interfejsem WWW, hasło zmienione ale złamane, brak wymagań bezpieczeństwa dla interfejsu adm.) może występować w wielu branżach.

Co robić, jeśli mam sterowniki WAGO, Siemens lub Moxa w sieci?

Najpierw: inwentaryzacja, które urządzenia mają aktywny interfejs WWW/HTTP/SSH i czy są dostępne z sieci, w której są inne końcówki. Drugie: zmiana domyślnych haseł, wyłączenie usług, których nie potrzebujesz, schowanie interfejsu administracyjnego za VPN/jump-host.

Czy CHORS.NET pomaga w ocenie tego ryzyka?

Tak. W ramach usługi P1 (Authorized Vulnerability Assessment) i P2 (On-site Assessment, w tym pasywne wsparcie dowodowe dla OT) pomagamy zidentyfikować wystawione interfejsy administracyjne urządzeń IoT/OT, sterowniki z domyślnymi poświadczeniami i konfiguracje prywatnych APN, które nie spełniają segmentacji. Nie wykonujemy aktywnego skanowania OT ani kontaktu z PLC/HMI — to globalny zakaz naszej polityki. W zakresie NIS2/KSC (P3) pomagamy zbudować Evidence Pack i Control Matrix; interpretację prawną zostawiamy kancelariom.

Jak CHORS.NET pomaga

Jeśli chcesz sprawdzić, czy w Twojej infrastrukturze IT-OT istnieją podobne wektory wejścia, zobacz jak pracuje CHORS.NET i poznaj nasze usługi operacyjne. W zakresie gotowości regulacyjnej wesprze Cię NIS2/KSC Readiness Center, a zasady cytowalności AI stosowane w naszych publikacjach opisuje Polityka AI.

Granice i założenia

Nie jesteśmy SOC 24/7 i nie gwarantujemy wykrycia każdego incydentu; nasz monitoring jest pasywny i okresowy.
Nie certyfikujemy zgodności z NIS2/KSC i nie wydajemy samodzielnej opinii prawnej; w zakresie interpretacji prawa współpracujemy z kancelariami.
Nie wykonujemy aktywnego kontaktu z OT/PLC/HMI — nasza usługa P2 jest pasywna w warstwie dowodowej; aktywne testy OT wymagają oddzielnego RoE i human approval.
Fakty w artykule pochodzą z oficjalnego raportu CERT Polska (08.08.2026), tłumaczenia angielskiego tego raportu oraz analizy zespołu Zaufana Trzecia Strona; szczegóły śledztwa (3+ miesiące) są w pełnym raporcie PDF.
Materiał ma charakter informacyjny i techniczny; nie stanowi porady prawnej.

Precyzyjna wiedza
o ciemnych systemach.