Cyberatak na polski wodociąg: ryzyko kont technicznych

10 lutego 2026 roku Centralne Biuro Zwalczania Cyberprzestępczości poinformowało o zatrzymaniu osoby podejrzanej o atak na system operatora infrastruktury wodno-kanalizacyjnej. To ważny polski przypadek, ponieważ dotyczy podmiotu zaliczonego do infrastruktury krytycznej, a oficjalny komunikat ujawnia konkretny łańcuch zdarzeń: nieautoryzowane wejście do sieci, logowanie do konta technicznego, pobranie danych i ich publikację w darknecie z użyciem anonimizacji ruchu.

CBZC podało, że dane udało się zlokalizować i usunąć. Podejrzanemu przedstawiono zarzuty z art. 267 § 2 Kodeksu karnego oraz art. 107 ust. 1 ustawy o ochronie danych osobowych. Sprawę prowadzi Prokuratura Okręgowa w Poznaniu. Na tym etapie mówimy o zarzutach, nie prawomocnym wyroku.

Dlaczego konto techniczne jest tu najważniejszym szczegółem

Konto techniczne nie służy zwykle konkretnej osobie. Uruchamia usługę, integruje systemy albo umożliwia zdalny serwis. Właśnie dlatego bywa niebezpieczne: jego hasło nie podlega rytmowi zmian pracowniczych, uprawnienia są szersze niż potrzeba, a logowanie nie zawsze wymaga MFA. Gdy kilka osób korzysta z tego samego sekretu, z dziennika wynika jedynie, że działało konto — nie kto faktycznie wykonał operację.

W środowisku wodno-kanalizacyjnym takie tożsamości mogą łączyć system rozliczeniowy, telemetrię, zdalny serwis lub warstwę zarządzającą. Oficjalny komunikat nie twierdzi, że napastnik przejął sterowniki PLC albo zmienił proces technologiczny. Nie należy tego dopowiadać. Potwierdzony jest dostęp do sieci i danych; sam fakt dotknięcia infrastruktury krytycznej wystarcza jednak, by potraktować incydent jako ostrzeżenie dla IT i OT.

Jak powinien wyglądać model ochrony

Pierwszy krok to pełna inwentaryzacja tożsamości maszynowych: właściciel biznesowy, cel, systemy docelowe, ostatnie użycie i data rotacji sekretu. Konto bez właściciela powinno zostać zablokowane albo objęte formalnym wyjątkiem. Drugim krokiem jest przejście z trwałych haseł na sekrety pobierane z sejfu, certyfikaty lub krótkotrwałe tokeny.

Połączenia administracyjne powinny przechodzić przez bastion z nagrywaniem sesji. W sieci OT dostęp zdalny należy włączać na czas zgłoszenia, ograniczać do konkretnego hosta i protokołu oraz zamykać po wykonaniu pracy. Segmentacja musi być weryfikowana technicznie — opisujemy to szerzej w analizie testów segmentacji sieci wewnętrznej.

Monitoring powinien alarmować co najmniej na:

• logowanie konta technicznego z nowego źródła lub poza oknem serwisowym,
• interaktywną sesję dla konta używanego dotąd wyłącznie przez usługę,
• masowe odczyty, eksporty i tworzenie archiwów,
• ruch do sieci anonimizujących oraz nietypowy transfer wychodzący,
• zmianę uprawnień, klucza API albo konfiguracji logowania.

Dane usunięte z darknetu nie kończą ryzyka

Usunięcie odnalezionej kopii ogranicza ekspozycję, lecz nie dowodzi, że nie powstały inne kopie. Organizacja musi ustalić zakres rekordów, czas dostępu i osoby, których dane dotyczą, a następnie podjąć decyzje prawne oraz komunikacyjne. Do tego potrzebne są kompletne logi, kopie konfiguracji i szybkie zabezpieczenie dowodów — dlatego plan reagowania na incydenty musi powstać przed atakiem.

Wniosek jest praktyczny: infrastruktury krytycznej nie chroni sama etykieta „OT”. Najczęściej pierwszym celem jest zwykłe konto, portal serwisowy albo system administracyjny. Test bezpieczeństwa powinien rozpocząć się od pytania, czy przejęcie jednej tożsamości technicznej pozwala odczytać dane, przeskoczyć między strefami i ukryć tożsamość operatora.

Co sprawdzić w tym tygodniu

Wyeksportuj listę kont nieosobowych, znajdź te bez MFA i rotacji, odtwórz ich faktyczne ścieżki sieciowe i porównaj z dokumentacją. Następnie wykonaj kontrolowany test dostępu oraz scenariusz eksfiltracji z nieszkodliwym znacznikiem. Jeśli alert nie powstaje, problemem nie jest wyłącznie konto — problemem jest brak obserwowalności. BreachRoad może zweryfikować ten łańcuch w bezpiecznym teście.

Model incydentu krok po kroku

Bez dopowiadania nieznanych szczegółów można zbudować bezpieczny model analityczny. Faza pierwsza to uzyskanie dostępu do sieci: przez usługę zewnętrzną, przejętą stację, poświadczenie albo relację dostawcy. Faza druga to odnalezienie konta technicznego i jego użycie. Faza trzecia obejmuje odczyt oraz przygotowanie danych, a czwarta — transfer i publikację. Każda faza powinna mieć osobną kontrolę i źródło dowodowe.

Na granicy sieci potrzebne są logi VPN, firewalla i uwierzytelnienia. Przy użyciu konta — logi katalogu, PAM i systemu docelowego. Dla pobrania danych — audyt zapytań, dostępów do plików oraz wolumenu. Dla eksfiltracji — proxy, DNS, NetFlow i telemetria endpointu. Jeśli organizacja zachowuje tylko jeden z tych poziomów, po incydencie zna wynik, ale nie potrafi udowodnić drogi.

FAQ dla operatora infrastruktury krytycznej

Czy wystarczy zmienić hasło? Nie. Trzeba unieważnić aktywne sesje, obrócić powiązane sekrety, sprawdzić miejsca użycia konta i przeanalizować działania z całego okresu możliwej kompromitacji.

Czy odcięcie internetu rozwiązuje problem? Zmniejsza część ryzyka, ale może przerwać monitoring i serwis. Potrzebna jest kontrolowana segmentacja z dozwolonymi przepływami, nie „płaska sieć” albo całkowita izolacja jako jedyne dwa tryby.

Jak mierzyć poprawę? Czasem wykrycia nietypowej sesji, liczbą kont bez właściciela, udziałem sekretów automatycznie rotowanych i wynikiem ćwiczenia, w którym zespół ma ustalić pełen zakres dostępu.

---

Źródła pierwotne: CBZC — „Odpowie za cyberatak na infrastrukturę krytyczną”, ISAP — Kodeks karny.