Siemens S7 pod aktywnym atakiem: AI obniża próg wejścia do OT

20 sierpnia najważniejszym tematem dla obrony przemysłowej pozostaje wspólny alert NSA, CISA, FBI, DOE i EPA o aktywnym zagrożeniu dla sterowników Siemens S7. Komunikat został wydany 19 sierpnia, ale jego operacyjne znaczenie wymaga osobnej analizy: aktorzy używają skryptów tworzonych z pomocą AI, bibliotek snap7.dll i python-snap7 oraz wyszukiwarek urządzeń dostępnych z Internetu. Narzędzia są maskowane jako legalny monitoring OT, a celem jest rozpoznanie, rozwój zdolności i przygotowanie do przyszłych operacji zakłócających.

To nie jest historia o „AI, które samodzielnie przejęło fabrykę”. Źródło rządowe mówi o użyciu AI do szybszego tworzenia i iterowania kodu na podstawie publicznej wiedzy o protokole i znanych podatnościach. Przyczyną osiągalności pozostają klasyczne błędy: PLC widoczny z Internetu, przestarzały firmware, słabe uwierzytelnianie, brak segmentacji i niekontrolowany dostęp integratora. AI skraca jednak czas między znalezieniem celu a powstaniem działającego narzędzia.

Które sterowniki i sektory są celem

Wspólny advisory wymienia rodziny S7-200, S7-300, S7-400, S7-1200 i S7-1500, w tym warianty F stosowane w funkcjach bezpieczeństwa. Najczęściej obserwowane sektory w USA to produkcja krytyczna, energetyka, wodociągi i ścieki, chemia, żywność i rolnictwo oraz obiekty komercyjne. Te same modele pracują globalnie, dlatego polski właściciel zakładu nie powinien traktować geografii raportu jako mitygacji.

Najważniejsze pytanie brzmi nie „czy mamy Siemens”, lecz „które CPU, z jakim firmware, w jakiej strefie, kto może się z nimi łączyć i czy istnieje trasa z sieci niezaufanej”. Inwentaryzacja musi objąć także stacje inżynierskie z TIA Portal lub STEP 7, urządzenia dostępowe dostawców, reguły NAT, tunele serwisowe, zapasowe sterowniki oraz obrazy odtwarzane po awarii.

Dlaczego port 102 i S7comm są tak istotne

S7comm wykorzystuje TCP/102. Biblioteki Snap7 implementują operacje potrzebne legalnym narzędziom integracyjnym i diagnostycznym, w tym odczyt oraz zapis obszarów pamięci sterownika. Ta funkcjonalność nie jest sama w sobie złośliwa. Problem powstaje, gdy ten sam interfejs jest osiągalny z niewłaściwej strefy i nie ma kontroli pozwalających rozróżnić zatwierdzoną stację inżynierską od automatycznego skryptu.

Według autorów alertu aktorzy prowadzą skanowanie, sprawdzają właściwości CPU, wykonują operacje na blokach danych i doskonalą narzędzia. Odczyt może służyć do poznania procesu, konfiguracji i logiki. Zapis może zmienić parametry, sekwencję albo logikę sterowania. Skutek nie musi wyglądać jak klasyczny ransomware: może nim być subtelna utrata jakości, nietypowe zużycie urządzeń, przerwa produkcyjna lub manipulacja zabezpieczeniem procesu.

Co zmienia pomoc AI

CISA mapuje rozwój kodu do technik ATT&CK T1587.004 i pozyskanie możliwości AI do T1588.007. Praktyczny wniosek jest prosty: publiczna dokumentacja, gotowa biblioteka i model generujący kod pozwalają szybciej dopasować narzędzie do kolejnych modeli oraz odpowiedzi urządzenia. Zespół o mniejszym doświadczeniu może sprawniej poprawiać błędy protokołu, obsłużyć odmienne warianty CPU i maskować skrypt jako monitoring.

AI nie usuwa konieczności posiadania ścieżki sieciowej. Nie omija również automatycznie protection level, segmentacji czy allowlistingu. Dlatego skuteczna odpowiedź nie polega na szukaniu etykiety „AI-generated” w pliku. Trzeba ograniczyć osiągalność, egzekwować tożsamość operatora i stacji, monitorować semantykę S7comm oraz kontrolować integralność logiki.

Detekcja: zachowanie ważniejsze niż nazwa narzędzia

Autorzy alertu zalecają obserwowanie połączeń do TCP/102 spoza zatwierdzonych stacji inżynierskich, nietypowych odczytów bloków danych, komend zapisu poza oknem zmian oraz sekwencyjnego skanowania adresów. Warto korelować je z harmonogramem utrzymania, zleceniem serwisowym i logowaniem do zdalnego dostępu. Sama sesja S7comm może być normalna; sesja bez właściciela i ticketu jest już anomalią.

Program huntingu powinien uwzględniać:

• procesy Python i użycie snap7.dll poza zatwierdzonym zestawem narzędzi;
• połączenia do wielu PLC w krótkim czasie lub enumerację właściwości CPU;
• operacje PUT/GET i zapisy do bloków poza oknem technologicznym;
• aktywność w nocy, z nowych stacji, krajów lub adresów integratora;
• różnice między logiką online a podpisaną kopią referencyjną offline;
• restart, zmianę trybu pracy, błędy procesu i odchylenia parametrów występujące po ruchu sieciowym.

Nie należy polować wyłącznie po nazwach plików. Aktor może zmienić nazwę biblioteki, spakować skrypt albo użyć legalnej stacji. Stabilniejsze są relacje: źródło, cel, funkcja protokołu, czas, zakres odczytu lub zapisu oraz brak odpowiadającej zmiany.

Plan działań na pierwsze 24 godziny

Najpierw sprawdź ekspozycję, ale bez aktywnego skanowania, które mogłoby zakłócić starszy sterownik. Zacznij od konfiguracji firewalli, pasywnego monitoringu, CMDB i danych integratora. Zablokuj TCP/102 na obwodzie i usuń bezpośrednie trasy internetowe. Zdalny serwis powinien przechodzić przez kontrolowany punkt dostępowy w DMZ, z MFA, indywidualnymi kontami, rejestracją sesji i ograniczeniem do czasu pracy.

Następnie ustal wersje firmware oraz biuletyny Siemens ProductCERT dla konkretnych CPU. Aktualizację trzeba przetestować na reprezentatywnym środowisku: w OT nie wolno utożsamiać pilności z chaosem. Sprawdź kompatybilność programu, modułów komunikacyjnych, napędów, HMI, bibliotek i procedury powrotu. Internet-facing i DMZ-resident controllers mają najwyższy priorytet.

Włącz ochronę hasłem i dostępne poziomy read/write protection. Ogranicz TIA Portal oraz STEP 7 do zatwierdzonych stacji przez reguły sieciowe i allowlisting aplikacji. Wyłącz web server, Modbus TCP, PROFINET lub inne usługi, jeśli proces ich nie potrzebuje. Usuń domyślne community SNMP. Każda redukcja funkcji powinna mieć test procesu i akceptację inżynierii.

Integralność ladder logic i kopie referencyjne

Kopia programu nie jest dowodem, jeżeli nie wiadomo, kiedy powstała i kto ją zatwierdził. Organizacja potrzebuje gold copy powiązanej z wersją CPU, checksumą, projektem TIA, listą zależności i podpisaną zmianą. Porównanie online/offline powinno być wykonywane kontrolowanie, a wynik przechowywany poza stacją inżynierską.

Jeśli pojawia się nieautoryzowana zmiana logiki, priorytetem jest bezpieczeństwo ludzi i procesu. Izolacja PLC albo przełączenie trybu musi być uzgodnione z operatorem technologicznym. Zabezpiecz telemetrię sieciową, projekt, logi zdalnego dostępu, historię alarmów, obraz stacji inżynierskiej i informacje o zmianach. Samo wgranie „dobrej” kopii może zniszczyć dowody i nie usunąć dostępu napastnika.

Fakty ze źródła i wnioski Breachroad

Aktywne targetowanie, wskazane modele, sektory, użycie Snap7, techniki ATT&CK oraz rekomendacje dotyczące portu 102 pochodzą ze wspólnego alertu. Autorzy oceniają, że obserwowany wzorzec służy rozpoznaniu, rozwojowi zdolności i przygotowaniu skutków operacyjnych. Nie publikują listy adresów IP ani uniwersalnego exploita i nie twierdzą, że każdy S7 jest naruszony.

Wymóg podpisanej gold copy, korelacja z ticketami, kolejność triage oraz potrzeba ćwiczenia IT–OT są wnioskami Breachroad. Wynikają z tego, że techniczne zabezpieczenie PLC nie zadziała bez wspólnego procesu bezpieczeństwa, utrzymania i produkcji.

Zespół może przećwiczyć tę odpowiedź podczas szkolenia cyberbezpieczeństwa dla organizacji, a następnie zweryfikować segmentację, zdalny dostęp i monitoring w ramach audytu bezpieczeństwa IT. Celem nie jest „testowanie PLC na żywo”, lecz dowód, że każda ścieżka do sterownika ma właściciela, kontrolę i zapis.

Źródła

• CISA, NSA, FBI, DOE i EPA — Defending Against an Active Threat to Siemens S7 Series PLCs (AA26-231A)
• Siemens ProductCERT
• MITRE ATT&CK for ICS