Przegląd subiektywnie najciekawszych informacji powiązanych ze światem OT Security z ostatniego tygodnia, a w nim między innymi:
- Cyberatak na głównego wykonawcę tunelu między Danią a Niemcami zakłócił prace przy jednej z największych inwestycji infrastrukturalnych w Europie.
- Dwa ciekawe materiały o AI w środowiskach przemysłowych. Jeden o amerykańskim Booz Allen, w którym sprawdzono jak współczesne modele radzą sobie z rozpoznawaniem urządzeń i poruszaniem się po sieci przemysłowej. Drugi o FERC zwracającym z kolei uwagę na narzędzia AI, które są już używane wewnątrz infrastruktury elektroenergetycznej.
- W przeglądzie również informacje o aktualizacji MITRE ATT&CK for ICS oraz o ciekawych podatnościach w modułach Rockwell ArmorBlock i bibliotece OPC UA Eclipse Milo.
Wydarzenia i analizy
1. Cyberatak zakłócił budowę tunelu między Danią a Niemcami
Femern Link Contractors, główny wykonawca tunelu Fehmarnbelt, został zaatakowany w nocy z 11 na 12 października. Firma potwierdziła atak na systemy IT oraz jego wpływ na prace na budowie.
Po incydencie wyłączono znaczną część infrastruktury sieciowej, a pracownicy zostali poinstruowani, aby nie korzystać z komputerów oraz Wi-Fi. Przestały działać m.in. systemy kontroli dostępu, a część jednostek pracujących na wodzie straciła dostęp do narzędzi i danych potrzebnych do pracy.
16 października inwestor poinformował, że część robót została wznowiona. Wróciła część prac betonowych i produkcja zbrojenia, ale zakład w Rødbyhavn, w którym powstają elementy tunelu, nadal nie pracował normalnie.
Nie ma potwierdzenia przejęcia systemów sterowania, jednak po raz kolejny widzimy że nie trzeba dostać się bezpośrednio do OT, żeby zatrzymać systemy fizyczne.
Incydent bada duńska National Special Crime Unit.
Źródło: Femern – contractor resumes work after cyberattack
2. AI przedarło się do sieci przemysłowej w 16 minut
Booz Allen (amerykańska firma zajmująca się m.in. cyberbezpieczeństwem) przeprowadził serię testów modeli AI w odizolowanym laboratorium odwzorowującym środowisko produkcyjne.
W jednym ze scenariuszy AI potrzebowało nieco ponad 16 minut, żeby przejść od pierwszego przejętego systemu do działań wewnątrz sieci przemysłowej.
W innym przypadku model rozpoznał przemysłowe ramię robota, ustalił, w jaki sposób można nim sterować, i doprowadził do wykonania ruchu. Nie dostał wcześniej dokumentacji urządzenia ani żadnych instrukcji jego obsługi.
Był to kontrolowany eksperyment. Działania mogące wywołać efekt fizyczny wymagały zgody człowieka.
W kontekście paniki na temat zagrożeń AI jeden komentarz – typowe zabezpieczenia nie przestały nagle działać tylko dlatego, że po drugiej stronie pojawiło się AI. Lokalny tryb pracy blokował sterowanie zdalne, część poleceń była odrzucana, a segmentacja sieci i ochrona stacji roboczych utrudniały dalszy atak.
AI nie zmienia więc podstaw. Segmentacja, ograniczanie komunikacji, monitorowanie i reagowanie dalej utrudniają lub nawet uniemożliwiają skuteczne przeprowadzenie ataku.
Gorzej wyglądać może z kolei liczenie na zawiłości naszej infrastruktury (ang. obfuscation), czyli to, że „nikt nie zna tego urządzenia” albo „nikt nie będzie wiedział, jak tym sterować”. Atakujący nie muszą sami znać konkretnego protokołu czy urządzenia, jeżeli część tej wiedzy może dostać od modelu AI.
Źródło: Booz Allen – Frontier AI reaches OT systems
3. Amerykański regulator energetyki zwraca uwagę na AI i zdalny dostęp
FERC (amerykański federalny regulator energetyki) opublikował wnioski z audytów dotyczących NERC CIP (obowiązkowych w USA zasad cyberbezpieczeństwa dla ważnych systemów elektroenergetycznych).
Jeden z opisanych problemów dotyczy zdalnego dostępu. Pojedynczy generator może być traktowany jako obiekt o niewielkim znaczeniu, ale ten sam zewnętrzny dostawca może mieć możliwość monitorowania albo sterowania wieloma takimi obiektami. Patrząc na każdy z nich osobno, problem może wyglądać niewielki. Patrząc na cały dostęp skupiony w jednym miejscu – już niekoniecznie.
FERC zwraca też uwagę na chatboty, asystentów i automatyczne narzędzia analityczne działające już wewnątrz takich środowisk.
To wszystko sprowadza się do kwestii higieny cyfrowej: do czego taki system ma dostęp, jakie ma uprawnienia, kto ten dostęp zatwierdził i czy jego działania są monitorowane. AI jest nowym narzędziem, ale problem z kontrolowaniem dostępu jest stary.
Źródło: FERC – Lessons Learned from Cimmission-Led CIP Audits
4. MITRE aktualizuje ATT&CK for ICS
MITRE ATT&CK for ICS (baza opisująca sposoby działania atakujących w systemach przemysłowych) dostał dużą aktualizację.
Dodano m.in. wykorzystanie PowerShella, Pythona oraz standardowych narzędzi systemowych Windows i Linux. Rozszerzono też opis sposobów komunikacji używanych przez atakujących.
Do bazy trafiła również tegoroczna kampania przeciw amerykańskim wodociągom, w której atakujący uzyskiwali zdalny dostęp m.in. do sterowników MicroLogix i zmieniali hasła, powodując utratę monitorowania i sterowania. Ten temat był już wcześniej opisywany na BIPiK.
Widać tu dość wyraźnie, że atak na OT nie musi oznaczać wykorzystania jakichś wyjątkowo egzotycznych narzędzi. Po drodze bardzo często pojawiają się dokładnie te same rzeczy, które znamy ze zwykłych ataków na IT.
Źródło: MITRE ATT&CK – October 2026 Updates
Podatności i ostrzeżenia
1. Rockwell ArmorBlock – możliwość przejęcia konta administratora bez uwierzytelnienia
CVE-2026-12655 dotyczy modułów Rockwell Automation 1732E ArmorBlock (rozproszone moduły I/O montowane bezpośrednio przy maszynach i komunikujące się przez EtherNet/IP).
Nieuwierzytelniony atakujący może zmienić hasło do interfejsu WWW urządzenia, przejąć konto administratora i później zmieniać jego konfigurację.
Łatwość wykorzystania tej podatność i przejęcia wspomnianego modułu zależy od tego, gdzie w architekturze sieci jest on umieszczony. Reagować należy przede wszystkim wtedy gdy jest wystawiony do sieci zewnętrznych (choć najlepiej żeby w ogóle nie był), bądź gdy nie mamy odpowiedniej segmentacji i występuje on np. w sieci mieszanej IT/OT.
Rockwell udostępnił poprawkę w firmware 3.013. Nie ma informacji o aktywnym wykorzystaniu podatności.
Źródło: Rockwell – Automation Security Advisories
2. Eclipse Milo – sześć podatności w bibliotece OPC UA
Eclipse Milo (otwarta biblioteka do tworzenia klientów i serwerów OPC UA w Javie) ma sześć nowych podatności.
Milo może być częścią bramy komunikacyjnej, platformy IIoT albo innej aplikacji korzystającej z OPC UA, więc niekoniecznie będzie widoczne w inwentarzu jako osobny produkt.
Opisane problemy obejmują m.in. możliwość wykonania operacji bez odpowiednich uprawnień, odczytu informacji o innych sesjach, odzyskania hasła oraz doprowadzenia usługi do awarii.
Opisana podatność dotyczy zarówno niezabezpieczonej komunikacji OPC UA jak i połączeń korzystających z certyfikatów i trybu SignAndEncrypt (tzw. OPC UA Secure). Samo używanie certyfikatów nie oznacza więc automatycznie, że temat nas nie dotyczy.
WAŻNE: Jest to biblioteka a nie osobny produkt. Milo może być więc zaszyte wewnątrz produktu czy aplikacji i czasami możemy nawet nie wiedzieć, że ta biblioteka jest wykorzystywana w naszych systemach.
Poprawki znalazły się w Milo 1.1.5. Starsza rodzina 0.6.x wymaga przejścia na nowszą wersję.
Źródło: CISA – Eclipse Milo
