Lokalne konta administratora w ICS - jak zamknąć drzwi przed pass-the-hash i kradzieżą poświadczeń

W grudniu 2023 roku grupa CyberAv3ngers przejęła kontrolę nad sterownikami Unitronics Vision w kilku amerykańskich zakładach wodociągowych. Hasło dostępowe do paneli HMI? Fabryczne “1111”, niezmienione od instalacji. Kilka tygodni wcześniej Dragos opublikował analizę kampanii CHERNOVITE, w której atakujący wykorzystali konto lokalnego administratora Windows na stacji inżynierskiej do wdrożenia malware PIPEDREAM - narzędzia zdolnego manipulować sterownikami Schneider Electric i OMRON bezpośrednio przez protokoły przemysłowe.

Te incydenty nie są wyjątkami. Są objawem systemowego problemu: w środowiskach ICS konta z uprawnieniami administratora lokalnego są wszechobecne, współdzielone i rzadko monitorowane. Stacje HMI, serwery historianów, komputery inżynierskie - wszystkie wymagają podwyższonych uprawnień do interakcji z aplikacjami SCADA, a producenci systemów sterowania często rekomendują uruchamianie oprogramowania z prawami administratora.

Ten artykuł opisuje pełny łańcuch ataku na lokalne konta administratora w ICS - od pozyskania poświadczeń, przez ruch boczny, po manipulację procesem - a następnie przedstawia kompletny zestaw kontroli, który pozwala te ataki powstrzymać.

Dlaczego lokalne konta admin są problemem w OT

W typowej sieci korporacyjnej IT zarządzanie kontami lokalnymi to rozwiązany problem - polityki GPO, LAPS, PAM. W sieciach OT sytuacja wygląda fundamentalnie inaczej z kilku powodów:

Wymogi producentów - wiele aplikacji SCADA i DCS wymaga uruchomienia z prawami lokalnego administratora. Wonderware InTouch, GE iFIX, Siemens WinCC - dokumentacja techniczna tych produktów zawiera instrukcje wyłączania UAC i nadawania pełnych uprawnień kontom serwisowym.

Współdzielenie kont - operatorzy pracujący na zmianach logują się na tych samych stacjach tym samym kontem. W raporcie SANS ICS Survey 2025, 34% respondentów przyznało, że w ich organizacjach konta operatorskie są współdzielone między pracownikami.

Brak rotacji haseł - hasła lokalne na stacjach w strefie produkcyjnej nie zmieniają się latami, bo każda zmiana wymaga koordynacji z dostawcą systemu sterowania i testu regresyjnego.

Izolacja od domeny - wiele stacji OT nie jest podłączonych do Active Directory, co eliminuje możliwość centralnego zarządzania hasłami.

Źródła: SANS ICS Survey 2025, Dragos OT Cybersecurity Year in Review 2026, PwC Global Digital Trust Insights 2026

Anatomia ataku - od hasła do procesu

Zrozumienie pełnego łańcucha ataku jest kluczowe, bo pozwala zidentyfikować, w których miejscach można go przerwać. Oto typowa sekwencja, jaką obserwujemy podczas testów penetracyjnych sieci OT:

Faza 1: Pozyskanie poświadczeń

Atakujący, który uzyskał dostęp do jednej stacji w sieci OT (np. przez skompromitowany VPN, phishing lub zainfekowany nośnik USB), rozpoczyna od ekstrakcji lokalnych poświadczeń:

• Dumping LSASS - narzędzia takie jak Mimikatz lub comsvcs.dll pozwalają wyciągnąć hashe NTLM z pamięci procesu LSASS na stacji Windows
• Odczyt bazy SAM - lokalna baza kont Windows przechowuje hashe NTLM, które można wyekstrahować offline narzędziami typu secretsdump
• Domyślne hasła - baza SCADAPass zawiera ponad 100 produktów ICS z fabrycznymi hasłami (admin/admin, operator/operator, root/root). Dla sterowników Unitronics domyślny PIN to “1111”

Faza 2: Ruch boczny (lateral movement)

Jeśli to samo hasło lokalnego administratora jest ustawione na wielu stacjach - a w środowiskach OT jest to norma - atakujący wykorzystuje technikę pass-the-hash:

• Wyciągnięty hash NTLM pozwala uwierzytelnić się na kolejnych stacjach bez znajomości hasła w postaci jawnej
• Sesja RDP lub PsExec z uprawnieniami administratora daje pełną kontrolę nad kolejną stacją
• Proces powtarza się - z każdej stacji wyciągane są kolejne poświadczenia

Faza 3: Eskalacja uprawnień i dostęp do procesu

Z poziomu stacji HMI lub serwera SCADA atakujący może:

• Modyfikować nastawy procesu przez interfejs operatorski
• Wgrywać zmienioną logikę na sterowniki PLC przez oprogramowanie inżynierskie
• Wyłączać alarmy i manipulować odczytami, by ukryć swoje działania
• Eksfiltrować konfigurację procesu (receptury, schematy sterowania)

Faza ataku	Technika MITRE ATT&CK (ICS)	Kontrola przerywająca łańcuch
Pozyskanie poświadczeń	T0859 - Valid Accounts	LAPS, rotacja haseł, zmiana domyślnych
Ruch boczny	T0812 - Default Credentials, T0859	Unikalne hasła per stacja, segmentacja
Eskalacja	T0890 - Exploitation for Privilege Escalation	Least privilege, aktualizacje OS
Manipulacja procesem	T0836 - Modify Parameter	Monitoring zmian, walidacja na PLC

Kontrole - kompletny zestaw dla środowisk ICS

1. Windows LAPS - automatyczna rotacja haseł

Microsoft LAPS (Local Administrator Password Solution) rozwiązuje problem identycznych haseł lokalnego administratora. Od Windows Server 2019 i Windows 10 LAPS jest wbudowany w system operacyjny (legacy MSI deprecated w Windows 11 23H2).

Jak działa LAPS:

• Automatycznie generuje unikalne, losowe hasło dla konta lokalnego administratora na każdej stacji
• Przechowuje hasło w atrybucie obiektu komputera w Active Directory (zaszyfrowane)
• Rotuje hasło zgodnie z polityką (np. co 30 dni)
• Uprawnienia odczytu hasła są granularnie kontrolowane przez ACL w AD

Wdrożenie LAPS w OT - uwagi:

W czystym środowisku IT wdrożenie LAPS to kwestia jednej polityki GPO. W OT pojawiają się dodatkowe wyzwania:

• Stacje niepodłączone do domeny AD nie mogą korzystać z LAPS - potrzebne jest rozwiązanie lokalne (np. CyberArk Vault, skrypt rotujący hasła z bezpiecznym składowaniem)
• Aplikacje SCADA korzystające z konta lokalnego administratora mogą przestać działać po zmianie hasła - wymaga to testowania z dostawcą systemu
• Hasło LAPS jest dostępne w AD, więc kompromitacja AD oznacza kompromitację wszystkich haseł LAPS - defense-in-depth jest konieczne

2. Eliminacja domyślnych haseł

Problem domyślnych haseł w ICS jest znacznie poważniejszy niż w IT. Wiele sterowników PLC i paneli HMI ma hasła fabryczne wbudowane w firmware, a zmiana wymaga narzędzia inżynierskiego i restartu urządzenia.

Systematyczne podejście:

1. Inwentaryzacja - przegląd każdego urządzenia pod kątem kont z domyślnymi hasłami (PLC, HMI, switche przemysłowe, RTU, bramy protokołowe)
2. Priorytetyzacja - urządzenia dostępne z sieci IT/korporacyjnej mają najwyższy priorytet
3. Zmiana - koordynacja z dostawcą systemu sterowania, zmiana w oknie serwisowym
4. Dokumentacja - bezpieczne przechowywanie nowych haseł (menedżer haseł, sejf fizyczny)

3. Segmentacja i kontrola ruchu bocznego

Nawet jeśli atakujący pozyska poświadczenia, segmentacja sieci może uniemożliwić ruch boczny. W kontekście kont administratora kluczowe są:

• Firewall między stacjami HMI - stacje operatorskie nie powinny móc komunikować się między sobą bezpośrednio (tylko ze sterownikami PLC i serwerem SCADA)
• Blokada SMB/RPC między stacjami - protokoły wykorzystywane przez PsExec i WMI lateral movement powinny być zablokowane na firewallach strefowych
• Dedykowane VLAN dla stacji inżynierskich - dostęp do narzędzi programowania PLC powinien być ograniczony do wydzielonej podsieci

Szczegóły architektury segmentacji opisujemy w artykule Segmentacja sieci w ochronie systemów OT.

4. Monitoring i wykrywanie

Samo zapobieganie nie wystarczy - potrzebne jest wykrywanie prób nadużycia kont administratora:

• Rejestrowanie logowań - Windows Event ID 4624 (logowanie), 4625 (nieudane logowanie), 4672 (przypisanie uprawnień specjalnych)
• Alerty na anomalie - logowanie konta administratora na stacji, na której nigdy wcześniej się nie logował
• Monitoring LSASS - narzędzia EDR wykrywają próby dumpingu pamięci procesu LSASS (Sysmon Event ID 10)
• Network Detection - systemy NDR (np. Nozomi Networks, Dragos Platform) wykrywają nietypowy ruch uwierzytelniający w sieci OT

5. Hardening Active Directory w strefie OT

Jeśli sieć OT korzysta z AD (dedykowanego lasu lub OU w lesie korporacyjnym), kluczowe jest:

Kontrola	Opis	Odniesienie IEC 62443
Tier model	Konta administracyjne OT nie mogą logować się do stacji IT i odwrotnie	SR 1.1 - Human user identification
Protected Users	Konta w grupie Protected Users nie generują haseł NTLM i nie cache’ują poświadczeń	SR 1.5 - Authenticator management
Credential Guard	Windows Credential Guard chroni LSASS przed dumpingiem (wymaga Secure Boot)	SR 3.4 - Software integrity
AdminSDHolder	Audyt uprawnień do obiektów administracyjnych w AD	SR 2.1 - Authorization enforcement
gMSA	Group Managed Service Accounts dla usług SCADA zamiast kont z hasłem statycznym	SR 1.5 - Authenticator management

6. Uwierzytelnianie wieloskładnikowe (MFA)

MFA dla dostępu administracyjnego do stacji OT powinno być standardem, choć w praktyce napotyka ograniczenia:

• Gdzie wdrożyć - jump servery, stacje inżynierskie, zdalne sesje RDP do stref OT
• Gdzie jest trudne - bezpośredni dostęp do HMI na hali produkcyjnej (rozwiązanie: karty smart card lub tokeny FIDO2 dla operatorów)
• Standard - IEC 62443-3-3 SR 1.1 wymaga uwierzytelniania wszystkich użytkowników, SR 1.2 wymaga MFA dla dostępu do stref o wysokim poziomie bezpieczeństwa (SL3+)

Checklista zabezpieczenia kont lokalnych w ICS

• Zmienione wszystkie domyślne hasła na PLC, HMI, switchach przemysłowych, RTU
• Wdrożony LAPS na stacjach Windows przyłączonych do domeny
• Stacje bez domeny mają mechanizm rotacji haseł (PAM, skrypt + vault)
• Konta operatorskie nie współdzielone - każdy operator ma indywidualne poświadczenia
• Wyłączone przechowywanie haseł z szyfrowaniem odwracalnym (GPO)
• Minimalna długość hasła: 14 znaków (zgodnie z NIST SP 800-63B)
• Zablokowany SMB/RPC między stacjami HMI (firewall strefowy)
• Rejestrowanie Event ID 4624, 4625, 4672 na wszystkich stacjach OT
• EDR z monitorem LSASS na stacjach inżynierskich
• MFA na jump serwerach i stacjach inżynierskich
• Credential Guard włączony na stacjach z Windows 10+ i Secure Boot
• Audyt kont w AD z uprawnieniami administracyjnymi do zasobów OT (co kwartał)
• Procedura zmiany hasła administracyjnego po każdym odejściu pracownika z dostępem

Mapowanie do IEC 62443 i NIST 800-82

Kontrole opisane w tym artykule mapują się na konkretne wymagania standardów bezpieczeństwa OT:

Kontrola	IEC 62443-3-3	NIST SP 800-82 Rev. 3	CIS Controls v8
Unikalne hasła per stacja	SR 1.5	5.7 Authenticator Management	5.2
LAPS / rotacja haseł	SR 1.5, SR 1.7	5.7, 5.5	5.2, 5.4
Zmiana domyślnych haseł	SR 1.5	5.7	4.7
Segmentacja ruchu bocznego	SR 5.1	5.3 Network Segmentation	12.2
Monitoring logowań	SR 6.1, SR 6.2	5.14 Audit and Accountability	8.5
MFA	SR 1.1, SR 1.2	5.6 Access Control	6.3
Credential Guard	SR 3.4	5.13 System Integrity	10.5

Reakcja na incydent - co zrobić, gdy doszło do kompromitacji

Jeśli podejrzewasz, że konto lokalnego administratora zostało skompromitowane w sieci OT:

1. Nie wyłączaj stacji - zachowaj pamięć operacyjną do analizy (volatile evidence)
2. Izoluj segment sieciowy - odetnij komunikację stacji z resztą sieci, ale nie z PLC (by nie przerwać procesu)
3. Zmień hasła - na wszystkich stacjach w segmencie, nie tylko na skompromitowanej (bo lateral movement mógł już nastąpić)
4. Przejrzyj logi - Event ID 4624 type 3 (logowanie sieciowe) i type 10 (RDP) na wszystkich stacjach w segmencie
5. Sprawdź integralność - porównaj konfigurację PLC z kopią referencyjną (golden image)
6. Raportuj - w Polsce incydent w infrastrukturze krytycznej wymaga zgłoszenia do CSIRT GOV

Gdzie SEQRED pomaga

SEQRED przeprowadza testy penetracyjne sieci OT, w których jednym z kluczowych scenariuszy jest właśnie eskalacja uprawnień i ruch boczny przez konta lokalne. Nasze testy obejmują weryfikację domyślnych haseł na urządzeniach ICS, ocenę konfiguracji AD w strefie OT oraz sprawdzenie, czy segmentacja rzeczywiście blokuje lateral movement. Na tej podstawie przygotowujemy plan remediacji z priorytetyzacją kontroli - od tych, które dają największy efekt przy najniższym ryzyku przestoju.

Więcej o bezpieczeństwie haseł w kontekście IT i OT opisujemy w artykule Bezpieczeństwo haseł. Zasady bezpiecznego zdalnego dostępu - w tym architekturę jump serverów z MFA - omawiamy w przewodniku Zdalny dostęp do systemów ICS. Hardening Active Directory w kontekście zapobiegania ransomware znajdziesz w artykule Ransomware - zapobieganie i najlepsze praktyki.

Źródła

1. CISA - Alert on Unitronics PLC Default Passwords (2023)
2. Dragos - CHERNOVITE Threat Group Analysis
3. SANS ICS Survey 2025 - State of OT Security
4. Microsoft - Windows LAPS Documentation
5. NIST SP 800-63B - Digital Identity Guidelines
6. IEC 62443-3-3 - System Security Requirements and Security Levels
7. Dragos 2026 OT Cybersecurity Year in Review
8. PwC 2026 Global Digital Trust Insights
9. MITRE ATT&CK for ICS - Credential Access Techniques
10. SCADAPass - Default ICS Passwords Database