Dlaczego Raport Dragos 2026 Powinien Obudzić Każdą Firmę Przemysłową

24 dni do exploita

24 dni. Tyle według Dragos wynosiła w 2025 roku mediana czasu od ujawnienia podatności do pojawienia się publicznego exploita. W IT to już mało. W OT/ICS to czas, w którym wiele organizacji dopiero próbuje ustalić, czy patch nie rozwali procesu, czy dostawca dopuści zmianę, i czy w ogóle ktoś ma okno serwisowe w tym kwartale.

Problem polega na tym, że przeciwnik nie czeka na CAB, okno zmian ani zgodę vendor supportu. On już pracuje na ekspozycji, na zdalnym dostępie, na jump hostach i na tym, co znajdzie na stacji inżynierskiej. Na stronach 6–7 raportu Dragos pada zresztą najważniejsza teza całego dokumentu: atakujący nie tylko zdobywają dostęp, ale uczą się procesu tak, żeby móc wywołać skutek fizyczny.

Ten artykuł nie jest streszczeniem raportu 2026 OT Cybersecurity Year in Review. I dobrze. Streszczenie niczego nie zmieni. Zobaczmy lepiej, co ten raport mówi o realnym stanie cyberbezpieczeństwa OT, dlaczego ransomware w przemyśle wciąż bywa błędnie traktowane jak „problem Windowsa”, i czemu brak widoczności w sieci OT jest dziś większym ryzykiem niż brak kolejnego dashboardu w SOC. Artykuł powstał na podstawie raportu Dragos 2026 OT/ICS Cybersecurity Report.

Nie chodzi o sam exploit. Chodzi o to, co dzieje się po nim

Najłatwiej złapać się na liczbie „24 dni” i zredukować cały raport do wniosku: trzeba szybciej patchować. To za mało. Dragos pokazuje znacznie poważniejszy problem. W 2025 roku około 4% podatności istotnych dla ICS miało publiczny POC i było aktywnie wykorzystywane, około 25% publicznych advisories nie zawierało patcha ani sensownego mitigation guidance, a 15% CVE w danych CISA/NVD miało błędne CVSS. Innymi słowy: nawet kiedy organizacja chce działać szybko, często nie dostaje od ekosystemu podatności wystarczająco dobrych danych, żeby dobrze ustawić priorytety.

W środowisku przemysłowym to robi kolosalną różnicę. Bo pytanie nie brzmi wyłącznie: „czy to jest critical?”. Pytanie brzmi: „czy to jest wystawione do internetu?”, „czy to prowadzi do DMZ albo OT boundary?”, „czy obsługuje vendor access?”, „czy siedzi na ścieżce do engineering workstation?”, „czy po kompromitacji mogę stracić view albo control?”. Dragos bardzo wyraźnie odchodzi tutaj od myślenia czysto CVSS-owego i przechodzi w stronę Now / Next / Never. I słusznie. W OT niska jakość priorytetyzacji boli bardziej niż sama liczba CVE.

Najważniejsza teza raportu: przeciwnik nie tylko wchodzi, ale uczy się procesu

To jest moment, w którym wiele zespołów bezpieczeństwa myśli nadal kategoriami IT. W ich głowie incydent kończy się na tym, że ktoś zalogował się na VPN, zrobił lateral movement i wyciągnął kilka plików. Tyle że w OT te „kilka plików” to często nie dokumenty biurowe. To alarmy, projekty, konfiguracje, instrukcje operacyjne, dane historianów, pliki z HMI i informacje ze stacji inżynierskich.

Dragos opisuje to wprost: część grup przeszła od samego utrzymywania dostępu do mapowania control loops, czyli do rozumienia, skąd wychodzi komenda, przez jakie elementy przechodzi, gdzie są punkty pomiarowe, co steruje aktuatorem i jakie warunki wywołają zatrzymanie procesu. W praktyce to nie wygląda jak filmowy „atak na PLC”. To wygląda dużo bardziej przyziemnie: ktoś identyfikuje HMI, drive, meter, gateway, alarm DB i EWS, a potem składa z tego operacyjny obraz procesu.

To właśnie dlatego engineering workstation staje się aktywem klasy premium dla przeciwnika. Na takiej stacji możesz znaleźć rzeczy, których nie ma w CMDB, nie ma w dokumentacji IT i nie widać z poziomu klasycznego EDR-a. Możesz znaleźć projekty, tagi, alarmy, procedury operatorskie, ścieżki komunikacji, czasem nawet eksporty konfiguracji, które w kilka godzin mówią o zakładzie więcej niż tygodnie zewnętrznego skanowania. Dragos pokazuje to na przykładach aktywności AZURITE i VOLTZITE, które interesują się właśnie danymi OT, a nie tylko „ruchem w domenie”.

Tak wygląda uproszczony łańcuch, który warto mieć z tyłu głowy:

Internet-facing edge / VPN / firewall
        ->
DMZ / vendor access / jump host
        ->
engineering workstation / historian / HMI
        ->
alarm data / config files / OT diagrams
        ->
rozumienie procesu i gotowość do wpływu operacyjnego

To nie jest teoria. To jest praktyczny model działania, który przewija się przez kilka rozdziałów raportu.

Nowy model ataku na OT: jeden zdobywa dostęp, drugi dowozi efekt

Jedna z najmocniejszych obserwacji Dragos dotyczy podziału pracy między grupami. W raporcie wraca ten sam motyw: ktoś buduje initial access, a ktoś inny wchodzi z capability ukierunkowanym na ICS. Taki model obniża barierę wejścia i skraca czas od kompromitacji do gotowości operacyjnej. To już nie jest świat, w którym jedna grupa musi umieć wszystko.

Widać to dobrze na trzech przykładach.

SYLVANITE działa jak wyspecjalizowany dostawca wejścia. W raporcie Dragos grupa ta jest opisana jako operator początkowego dostępu, który masowo eksploatuje internet-facing systems, kradnie credentiale i przekazuje foothold dalej, między innymi do VOLTZITE.

KAMACITE pełni podobną rolę wobec ELECTRUM. Dragos pisze wprost, że to access development team, którego praca ma wartość właśnie dlatego, że końcowy odbiorca ma capability destrukcyjne i doświadczenie operacyjne z infrastruktury krytycznej.

PYROXENE z kolei pokazuje trzeci wariant: supply chain, social engineering, credential harvesting i działania przygotowujące ścieżki IT-to-OT, niekoniecznie przez bezpośredni atak na sam proces od pierwszego dnia.

Dla obrońcy wniosek jest prosty. Nie można już oceniać incydentu wyłącznie przez pytanie: „czy oni mieli malware pod ICS?”. Czasem wystarczy, że mieli poprawny dostęp do właściwego miejsca i zdążyli dobrze zrozumieć środowisko.

Internet-facing OT to dziś najkrótsza droga do problemu

Raport Dragos jest bardzo konkretny w kwestii wejścia. Mówimy tu o VPN-ach, firewallach, web interfaces, cellular gateways, portalach administracyjnych, vendor tunnels i usługach zdalnego dostępu. To nie są egzotyczne powierzchnie ataku. To jest zwykła codzienność większości środowisk przemysłowych. Problem w tym, że właśnie tę codzienność przeciwnik wykorzystuje najlepiej.

Dragos raportuje, że 53% assessmentów zawierało findings związane z internet connectivity albo external-facing issues. Dodatkowo 73% przypadków IR obejmowało aktywne wykorzystanie albo reuse poprawnych credentiali do VPN-ów i jump hostów, a 49% raportów usługowych zawierało istotne problemy z secure remote access. To są liczby, które powinny zaboleć każdą organizację mającą słowo „zdalny” w polityce utrzymania.

I teraz ważna rzecz. Wiele firm ma dziś MFA i uważa sprawę za zamkniętą. Tymczasem Dragos pokazuje bardziej zniuansowany obraz: MFA pomaga, ale nie rozwiązuje problemu źle zarządzanego vendor access, nadmiarowych ścieżek RDP/VNC, nienadzorowanych jump hostów, ekspozycji gatewayów ani reuse skradzionych tożsamości w łańcuchu IT-OT. Sama obecność MFA nie oznacza jeszcze, że remote access jest bezpieczny.

Praktyka: co sprawdziłbym najpierw

Najpierw sprawdziłbym, co naprawdę wystawiasz na zewnątrz. Nie z CMDB. Nie z prezentacji architekta. Z zewnętrznego hosta, który patrzy na ciebie jak przeciwnik.

Przykład prostego testu defensywnego na własnym zasobie:

curl -skI https://vpn.twoja-firma.example
curl -skI https://remote-access.twoja-firma.example
curl -skI https://vendor-gateway.twoja-firma.example

Tu nie chodzi o „hackowanie własnej firmy”. Chodzi o bardzo przyziemne pytanie: czy z internetu nadal widzę stronę logowania, fingerprint urządzenia, certyfikat z nazwą serwera, albo odpowiedź, której nie powinno być. Po zmianach ACL albo po wyłączeniu ekspozycji oczekiwanym wynikiem często powinien być po prostu timeout albo odrzucenie z nieautoryzowanej sieci.

A potem logi. Nie takie „ładne do dashboardu”, tylko takie, z których da się zrobić śledztwo.

Przykładowy wpis, który w środowisku OT-adjacent powinien od razu zapalić lampkę:

date=2026-02-14 time=03:12:44 devname="ot-vpn-gw-01" type="event" subtype="vpn"
user="vendor-maint" srcip=185.203.119.44 dstip=10.20.30.5 action="tunnel-up"
msg="SSL VPN login succeeded" assigned_ip="10.250.17.44"

Sam sukces logowania niczego jeszcze nie dowodzi. Ale jeśli konto vendor-maint zalogowało się o 03:12, z IP spoza normalnego geobehavior, poza oknem serwisowym, a pięć minut później widać ruch do jump hosta i dalej do EWS, to nie jest „ciekawostka operacyjna”. To jest pełnoprawny materiał do analizy incydentu.

Ransomware w przemyśle nie jest „tylko problemem Windowsa”

To jeden z najbardziej praktycznych wniosków z raportu. Dragos wprost pisze, że incydenty ransomware są w organizacjach przemysłowych uporczywie źle klasyfikowane jako IT-only, bo ktoś zobaczył Windowsa i przestał zadawać dalsze pytania. Problem w tym, że ten Windows bardzo często hostuje coś, co jest krytyczne dla operacji: SCADA support server, HMI, historian, engineering workload albo warstwę wirtualizacji, na której to wszystko stoi.

W 2025 roku Dragos śledził 119 grup ransomware uderzających w organizacje przemysłowe i ponad 3300 dotkniętych organizacji. Produkcja odpowiadała za większość ofiar. Raport pokazuje też coś jeszcze ważniejszego: realny skutek operacyjny często nie wynika z malware pod PLC, ale z uderzenia w ESXi, hypervisory i OT boundary systems. Gdy przeciwnik szyfruje warstwę wirtualizacji wspierającą SCADA, HMI czy historian, możesz nie dotknąć ani jednego sterownika i nadal stracić view, control albo ciągłość operacji.

To właśnie dlatego pytanie „czy PLC zostały dotknięte?” bywa źle postawione. Prawidłowe pytania brzmią raczej tak:

• Czy operator stracił widok na proces?
• Czy zniknęła możliwość wydawania poleceń?
• Czy zniknęły alarmy albo dane historyczne?
• Czy odbudowa wymaga stawiania od nowa hostów wspierających OT?
• Czy zatrzymanie linii wynika z problemu „IT”, który w praktyce przeciął zdolność do operowania?

Jeżeli odpowiedź na któreś z nich brzmi „tak”, to przestań mówić o „incydencie IT bez wpływu na OT”.

Krótka checklista po incydencie ransomware w środowisku przemysłowym

Po pierwszej stabilizacji nie kończyłbym analizy na EDR-ze. Sprawdziłbym jeszcze:

1. czy zaszyfrowano lub wyłączono ESXi / vCenter / hosty wirtualizacyjne wspierające OT,
2. czy HMI, historian, alarm server, EWS albo serwer licencji działały na tych hostach,
3. czy były manual fallback procedures i czy faktycznie zadziałały,
4. czy zachowana została integralność projektów, receptur, alarmów i backupów konfiguracji,
5. czy ktoś nie ogłosił „OT nietknięte”, bo nie zobaczył artefaktów na PLC.

To są dwa zupełnie różne poziomy dojrzałości odpowiedzi na incydent.

Największa słabość wielu zakładów nie brzmi APT. Brzmi brak widoczności

Najmocniejsza liczba z raportu nie dotyczy nawet samego przeciwnika. Dotyczy obrońcy. Dragos szacuje, że mniej niż 10% sieci OT na świecie ma visibility i monitoring. Do tego 30% przypadków incident response w 2025 zaczynało się nie od detekcji, ale od stwierdzenia „coś jest nie tak”. To oznacza jedną rzecz: wiele organizacji nie wykrywa incydentu. One zauważają dopiero skutek.

Na tym tle bardzo dobrze wyglądają też dalsze dane z raportu: 46% Architecture Reviews wskazywało istotne braki w visibility i monitoring, 88% tabletop exercises ujawniało zdegradowane zdolności detekcyjne, a mniej niż 5% testowanych środowisk miało włączone PowerShell Execution Logging, mimo że to jeden z najbardziej podstawowych sposobów na zobaczenie living-off-the-land i ruchu bocznego po Windowsach.

To wszystko składa się na prosty, brutalny obraz. Bez telemetry nie wiesz:

• kto wszedł,
• skąd wszedł,
• dokąd przeszedł,
• co wyciągnął,
• czy wydał komendy,
• czy proces był manipulowany,
• i czy możesz ufać temu, co widzisz na ekranie.

Jakie dane naprawdę warto mieć

Nie chodzi o kolejne pudło z napisem NDR. Chodzi o to, żeby z góry wiedzieć, jakich pytań nie będziesz w stanie zadać w czasie incydentu, jeśli dziś nie zaczniesz zbierać danych.

Minimalny zestaw, od którego zacząłbym w środowisku OT/ICS:

• logi z VPN, firewalli, remote access gateways i vendor access,
• audyt logowań na jump hostach,
• logi RDP, WinRM, SMB i SSH w strefach IT/OT boundary,
• PowerShell logging i process creation na systemach Windows wspierających OT,
• flow lub pełny ruch sieciowy w kluczowych punktach przejścia między Level 3 / 3.5 / 4,
• logi zmian kont, grup uprzywilejowanych i konfiguracji zdalnego dostępu,
• monitoring nietypowego ruchu do EWS, historianów, HMI i serwerów GIS/OT docs.

Przykład: czego szukać w logach Windows

Przykładowy wzorzec, który w połączeniu z logami VPN i jump hosta ma dużą wartość śledczą:

EventID=4624 LogonType=10 AccountName=svc_backup WorkstationName=JUMPHOST-OT01 SourceNetworkAddress=10.14.7.22
EventID=4688 NewProcessName=C:\Windows\System32\wsmprovhost.exe ParentProcessName=C:\Windows\System32\svchost.exe
EventID=4688 NewProcessName=C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe CommandLine="powershell -enc <...>"
EventID=7045 ServiceName=UpdaterHost ImagePath="C:\ProgramData\updater\host.exe"

Każdy z tych eventów osobno może mieć niewinne wyjaśnienie. Ale jeśli widzisz je po nietypowym logowaniu na VPN, na koncie technicznym, poza maintenance window, i do tego z ruchem na 5985/5986 albo 3389 w stronę serwera wspierającego OT, zaczyna się prawdziwa analiza, a nie „log review dla compliance”.

Krótki przykład zapytania do SIEM

Na własny użytek obronny zbudowałbym prosty baseline dla zdalnego dostępu:

index=vpn OR index=firewall
| stats dc(src_ip) as uniq_ips values(src_ip) as src_ips count by user
| where uniq_ips > 3
| sort - uniq_ips

To nie jest magia. To jest szybki sposób, żeby wychwycić konta, które nagle zaczynają używać większej liczby adresów źródłowych niż zwykle. A w środowiskach przemysłowych właśnie takie proste odchylenia często są szybszą drogą do detekcji niż gonienie „zaawansowanych IOCs”.

CVSS nie wystarcza. W OT liczy się ekspozycja, pozycja i skutek

Raport Dragos bardzo dobrze rozbija mit, że program vulnerability management w OT można oprzeć na jednym eksporcie z narzędzia skanującego i sortowaniu po CVSS. Nie można. I to nie jest filozofia. To praktyka.

Jeśli urządzenie siedzi głęboko w procesie, nie jest osiągalne z zewnątrz, ruch do niego jest ściśle ograniczony, a jego kompromitacja wymaga kilku wcześniejszych kroków, to nawet wysoki CVSS może nie być pierwszym priorytetem. Ale jeśli „średnia” podatność siedzi na internet-facing gatewayu, VPN appliance, firewallu, serwerze file transfer albo remote management interface, to właśnie ona może być najszybszą drogą do całego środowiska. Dragos pokazuje to na wielu przykładach perimeter-facing technologies i bardzo wyraźnie sugeruje, że exploitability + exposure + operational consequence są ważniejsze niż sama liczba w advisory.

Tu dobrze działa prosta, lokalna macierz priorytetu:

Priorytet OT = ekspozycja zewnętrzna
             + dostęp do IT/OT boundary
             + dostęp do tożsamości uprzywilejowanych
             + wpływ na view/control
             + potwierdzona aktywność przeciwnika / POC

W praktyce oznacza to tyle:

• VPN z błędem pre-auth i vendor access > zwykły serwer w back-office,
• gateway komórkowy prowadzący do field assets > stacja robocza w biurze,
• podatność w systemie file transfer z dokumentacją operacyjną > kolejny finding na kiosku HR.

To właśnie jest myślenie „OT-first”, a nie „IT scanner exported to OT”.

Polska i Europa nie są widownią. Są częścią tego samego pola walki

Dla polskiego czytelnika jedna z ważniejszych części raportu to sekcja dotycząca końca 2025 roku. Dragos opisuje skoordynowaną aktywność wymierzoną w polską infrastrukturę energetyczną, obejmującą CHP i systemy wspierające zarządzanie odnawialnymi źródłami energii. Według raportu nie doszło do customer-facing outage, ale sama natura celu jest ważna: chodzi o systemy, które mają operational leverage, a nie tylko wartość biurową. Dragos ocenia z umiarkowaną pewnością, że tradecraft i cele są spójne z aktywnością ELECTRUM.

To ma szerszy wymiar niż sam incydent. Raport pokazuje też, że rozwijająca się infrastruktura energetyczna — DER, BESS, platformy agregacji, systemy zarządzania rozproszonymi zasobami — rozszerza powierzchnię ataku szybciej, niż rośnie dojrzałość zabezpieczeń. Dragos zwraca uwagę na problemy wokół battery management systems i na fakt, że nowe technologie są wdrażane z tempem, którego praktyki bezpieczeństwa nie nadążają obsłużyć.

Wniosek dla firm przemysłowych jest bardzo praktyczny. Nie trzeba być „strategiczną spółką skarbu państwa”, żeby znaleźć się w tym obrazie. Wystarczy być integratorem, dostawcą, operatorem zdalnego dostępu, MSP, vendor supportem albo producentem mającym ścieżkę do środowiska klienta. Dragos zresztą wyraźnie pokazuje, jak ważny staje się cały ICS supply chain.

Dlaczego to ma znaczenie

Bo w OT konsekwencja incydentu nie kończy się na ekranie ransom note.

Może skończyć się:

• utratą widoku na proces,
• utratą zdolności wydawania poleceń,
• pracą „na ślepo” i decyzjami operacyjnymi opartymi na niepewnej telemetrii,
• awaryjnym przejściem na local/manual,
• przestojem linii,
• wymuszoną odbudową hypervisorów, serwerów wspierających OT i stacji inżynierskich,
• wielodniowym dochodzeniem bez danych potrzebnych do ustalenia root cause.

Dragos pokazuje też, że słabości architektoniczne są nadal banalnie przyziemne: segmentacja IT/OT wypada źle, secure remote access wypada źle, visibility wypada źle, vulnerability management wypada źle. W raportach usługowych 81% przypadków zawierało problemy z network segmentation, 53% wskazywało publiczne lub internet-facing aktywa, 49% miało słabości w remote access, a 80% findings dotyczyło vulnerability management. To nie wygląda jak „wyrafinowany cyberwojenny problem”. To wygląda jak bardzo klasyczne braki higieny, które w OT mają po prostu dużo wyższą cenę.

Pięć ruchów, które mają sens od razu

1. Sprawdź ekspozycję internetu, a nie tylko politykę

Wylistuj wszystko, co jest osiągalne z zewnątrz i ma związek z OT albo OT-adjacent systems: VPN, firewall, cellular gateways, vendor portals, jump hosty, web interfaces, file transfer, remote management. Potem zweryfikuj to z zewnętrznego hosta.

2. Uporządkuj remote access i vendor access

MFA jest potrzebne, ale nie wystarcza. Liczy się jeszcze time-bounded access, pełne logowanie sesji, zatwierdzanie, segmentacja ruchu, brak shared accounts i brak niepotrzebnego RDP/VNC „bo szybciej”.

3. Zbieraj telemetry, które odpowiadają na pytania incydentowe

Nie pytaj „co logować?”. Zapytaj: „jak odpowiem na pytanie, czy ktoś wydał komendę, jeśli dziś nie loguję dostępu do jump hosta, PowerShella i ruchu przez boundary?”.

4. Traktuj EWS, historiany, ESXi i systemy wspierające OT jak aktywa krytyczne

Nie jako „serwery Windows w sieci przemysłowej”. Ich kompromitacja potrafi wywołać równie realny skutek jak bezpośredni atak na sterownik.

5. Priorytetyzuj podatności po ścieżce do skutku, nie po kolorze z CVSS

W OT najbardziej interesują cię podatności, które:

• są wystawione,
• mają POC albo są aktywnie wykorzystywane,
• prowadzą do IT/OT boundary,
• dotykają tożsamości, zdalnego dostępu albo procesów wspierających operacje,
• mogą przynieść utratę view/control.

Checklista techniczna na najbliższe 30 dni

1. Zweryfikuj z zewnątrz wszystkie publiczne punkty wejścia związane z OT.
2. Zrób przegląd kont vendorowych, shared accounts i kont technicznych z dostępem do jump hostów.
3. Sprawdź, czy PowerShell logging, process creation i logi RDP/WinRM są włączone na systemach wspierających OT.
4. Przejrzyj 30 dni logów VPN pod nietypowe godziny, nowe geolokalizacje i wzrost liczby adresów źródłowych per user.
5. Ustal, które ESXi/vCenter hostują SCADA, HMI, historian, EWS i inne krytyczne workloady OT.
6. Zweryfikuj, czy backupy konfiguracji EWS, HMI i historianów są odseparowane i możliwe do szybkiego odtworzenia.
7. Zmapuj wszystkie ścieżki RDP, VNC, SMB, SSH i WinRM między IT, DMZ i OT.
8. Przejrzyj reguły firewalli pod kątem nadmiarowych wyjątków „tymczasowych”, które stały się permanentne.
9. Zrób tabletop exercise nie z „malware na laptopie”, tylko z loss of view / loss of control / compromised remote access.
10. Ustal, kto podejmuje decyzję o przejściu na local/manual, jeśli nie można ufać telemetry.

Podsumowanie

Raport Dragos 2026 nie jest ciekawostką dla threat intel teamów. To bardzo praktyczny dokument o tym, jak wygląda nowa normalność w OT/ICS. Przeciwnik szybciej weaponizuje podatności. Coraz częściej działa w modelu podziału ról. Chętnie wchodzi przez internet-facing edge i zdalny dostęp. Nie musi dotykać PLC, żeby zatrzymać operacje. A po drugiej stronie nadal za często stoi organizacja, która nie ma wystarczającej widoczności, by uczciwie odpowiedzieć, czy incydent był cyber, czy nie był.

Najważniejszy wniosek jest prosty: w firmie przemysłowej nie wygrywa ten, kto ma najładniejszy dashboard. Wygrywa ten, kto potrafi odpowiedzieć na trzy pytania zanim zrobi to przeciwnik: co wystawiam, kto naprawdę ma dostęp i co się stanie z procesem, jeśli stracę view albo control.

Na koniec zrób trzy rzeczy, nie jutro, tylko teraz:

• sprawdź w logach z ostatnich 30 dni nietypowe logowania do VPN, jump hostów, WinRM i RDP,
• przetestuj z hosta spoza sieci firmowej, które OT-adjacent systemy nadal odpowiadają z internetu,
• uruchom krótki warsztat z OT, IT i utrzymaniem ruchu dla scenariusza: utrata widoku po kompromitacji zdalnego dostępu.

Od tego momentu zaczyna się realne bezpieczeństwo OT.