Koreańska Policja Krajowa (NPA) zatrzymała cztery osoby podejrzane o zhakowanie ponad 120 000 kamer IP zainstalowanych w domach i przedsiębiorstwach, a następnie sprzedaż części pozyskanych nagrań na zagranicznej witrynie z treściami pornograficznymi. Według komunikatu rządowego dochodzenie obejmuje również operatorów serwisu oraz nabywców i widzów materiałów, a poszkodowanym zapewniono działania ochronne i instrukcje usuwania treści.
W skrócie
4 podejrzanych, działających niezależnie, wykorzystywało kamery IP do pozyskiwania i monetyzacji nagrań o charakterze seksualnym; dwóch z nich sprzedało łącznie setki nagrań za kryptoaktywa o wartości kilkudziesięciu tys. USD.
Policja zidentyfikowała dziesiątki lokalizacji ofiar i zaleciła reset haseł; równolegle prowadzone są działania wobec operatorów strony oraz nabywców treści.
Sprawa nagłaśnia chroniczny problem słabej konfiguracji kamer i używania domyślnych/łatwych haseł.
Kontekst / historia / powiązania
W Korei Południowej cyberprzestępczość związana z „ukrytymi kamerami” (tzw. molka) od lat wywołuje napięcia społeczne. Media przypominają wcześniejsze afery z wykorzystaniem mediów społecznościowych i serwisów wymiany wideo, które skutkowały surowymi wyrokami oraz wzmożonymi działaniami organów ścigania. Obecna sprawa wpisuje się w ten szerszy trend, ale akcentuje słabości urządzeń IoT w środowisku domowym.
Analiza techniczna / szczegóły luki
Z informacji śledczych wynika, że atakujący przejmowali dostęp do kamer IP, a następnie produkowali i dystrybuowali setki materiałów. W komunikacie rządowym zestawiono skalę działań poszczególnych podejrzanych (od setek do dziesiątek tysięcy przejętych urządzeń), a płatności realizowano w kryptoaktywach. Organy ścigania wskazują, że duża część przesyłanych treści na jednym z zagranicznych serwisów pochodziła właśnie od dwóch z tych sprawców.
Kluczowym czynnikiem umożliwiającym ataki były słabe lub domyślne hasła, zdalny dostęp niepotrzebnie wystawiony do Internetu oraz brak aktualizacji firmware’u — to wektor nadużywany globalnie w segmencie kamer IP. Standard ETSI EN 303 645 wprost zakazuje uniwersalnych domyślnych haseł, zalecając unikalne poświadczenia per urządzenie i wymuszanie silnych haseł przy pierwszej konfiguracji.
Praktyczne konsekwencje / ryzyko
Prywatność i bezpieczeństwo fizyczne: wycieki z kamer domowych (sypialnie, salony, gabinety) skutkują trwałą utratą kontroli nad wizerunkiem i ryzykiem wtórnej wiktymizacji.
Ryzyko prawne: w tej sprawie policja prowadzi działania nie tylko wobec sprawców, ale też nabywców i widzów nielegalnych treści, co potwierdza rosnącą presję egzekucyjną.
Ryzyko korporacyjne: firmy korzystające z kamer IP (recepcje, magazyny, punkty usługowe) narażają się na naruszenia RODO/ustaw o ochronie danych oraz straty reputacyjne i regulacyjne. (Wnioski na podstawie praktyk branżowych i standardów.)
Rekomendacje operacyjne / co zrobić teraz
Dla użytkowników domowych i SMB:
Usuń domyślne loginy/hasła; ustaw długie (min. 14+ znaków), unikalne hasła, najlepiej generowane i przechowywane w menedżerze haseł.
Wyłącz zdalny dostęp (P2P/UPnP), jeśli nie jest konieczny; włączaj tylko przez VPN lub za NAT z kontrolą dostępu. (Dobry zwyczaj zalecany w wytycznych CISA/ENISA).
Aktualizuj firmware i aplikacje mobilne kamer; wybieraj dostawców zapewniających wsparcie i biuletyny bezpieczeństwa.
Segmentuj sieć domową (oddzielna sieć/SSID dla IoT), egzekwuj WPA2/WPA3, wyłącz dostęp urządzeń IoT do sieci firmowej.
Monitoruj logi i powiadomienia kamer (nietypowe logowania, zmiany konfiguracji), okresowo resetuj poświadczenia i sprawdzaj listę kont. (Dobre praktyki wg CISA/ENISA).
Dla zespołów bezpieczeństwa w firmach:
Wymagaj zgodności z ETSI EN 303 645 (brak uniwersalnych haseł, bezpieczne aktualizacje OTA, minimalizacja usług wystawionych do Internetu).
Wprowadzaj politykę przyłączeń dla IoT (asset inventory, NAC/MAC allowlist, VLAN dla kamer, skanowanie pod kątem domyślnych/znanych poświadczeń). (Wnioski na bazie standardów ETSI/ENISA/CISA).
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
W przeciwieństwie do spraw, w których przestępcy wymuszają tworzenie treści (np. głośne śledztwa wokół kanałów na komunikatorach), tutaj oś ataku stanowiła techniczna kompromitacja IoT i pasywna obserwacja użytkowników przez przejęte kamery. Wspólnym mianownikiem pozostaje jednak monetyzacja treści poprzez serwisy zagraniczne i płatności krypto.
Podsumowanie / kluczowe wnioski
Skala (120 000 kamer) potwierdza, że niedostateczna higiena bezpieczeństwa IoT ma realne, masowe skutki dla prywatności.
Organy ścigania koncentrują się nie tylko na sprawcach, ale też na ekosystemie popytu (nabywcy/widzowie), co może mieć efekt prewencyjny.
Minimalne wymogi bezpieczeństwa (brak domyślnych haseł, aktualizacje, segmentacja) są dziś standardem — warto je formalizować w politykach i umowach z dostawcami.
Źródła / bibliografia
Korea.kr – oficjalny komunikat Policji Krajowej (01.12.2025). (Korea.kr)
BleepingComputer: „Korea arrests suspects selling intimate videos from hacked IP cameras” (02.12.2025). (BleepingComputer)
The Washington Post: „Hacking scheme targeted 120,000 home cameras for sexual footage” (02.12.2025). (The Washington Post)
The Korea Herald: „120,000 private cameras hacked…” (2025). (Korea Herald)
ETSI EN 303 645 v3.1.3 – Consumer IoT Security (09.2024). (ETSI)
Google opublikował Android Security Bulletin (ASB) – grudzień 2025. Najnowsze poprawki bezpieczeństwa mają dwa poziomy: 2025-12-01 oraz 2025-12-05. Najpoważniejsza usterka to krytyczny DoS w komponencie Framework (zdalny atak bez uprawnień), a w sekcji Kernel pojawiają się krytyczne EoP (m.in. pKVM, IOMMU). Google potwierdza też dwie luki wykorzystywane celowo (limited, targeted exploitation).
W skrócie
Poziomy poprawek: 2025-12-01 i 2025-12-05 (drugi obejmuje wszystkie wcześniejsze).
Najpoważniejsze błędy:
Framework: zdalny DoS (CVE-2025-48631) + liczne EoP/ID/DoS (wysoka ważność).
Kernel: kilka krytycznych EoP (pKVM, IOMMU).
Eksploatowane w praktyce:CVE-2025-48633 (ID w Framework) i CVE-2025-48572 (EoP w Framework).
Project Mainline (GPSU): w tym miesiącu brak poprawek bezpieczeństwa.
Kontekst / historia / powiązania
ASB dostarcza bazowe łatki dla całego ekosystemu Android, a producenci SoC i OEM-i publikują uzupełniające biuletyny (np. Pixel, Samsung, Qualcomm). Grudzień to jeden z kwartalnych „większych” dropów, kiedy część zmian trafia także do AOSP w 24–48 h po wydaniu.
Analiza techniczna / szczegóły luki
Framework (poziom 2025-12-01)
CVE-2025-48631 (DoS, Critical) – zdalne wywołanie awarii bez dodatkowych uprawnień.
Szereg EoP (np. CVE-2025-48572), ID (np. CVE-2025-48633) i DoS o wysokiej ważności, obejmujących Android 13–16.
Dwie pozycje (CVE-2025-48633, CVE-2025-48572) oznaczone jako wykorzystywane w ograniczonych, ukierunkowanych kampaniach.
System (poziom 2025-12-01)
Dominują EoP i ID o wysokiej ważności (m.in. historyczne CVE-2023-40130 utrzymywane w matrycy poprawek).
Kernel (poziom 2025-12-05)
Krytyczne EoP w pKVM (CVE-2025-48623, -48637, -48638) oraz IOMMU (CVE-2025-48624).
Dodatkowo EoP/ID o wysokiej ważności w subsystemach sieciowych, epoll i KVM.
Zaktualizowano także LTS 5.4 → min. 5.4.292 (zależnie od wersji startowej urządzenia).
Komponenty dostawców
Arm (Mali) i Imagination (PowerVR) – kilka podatności High.
MediaTek/Unisoc – liczne problemy głównie w Modem/IMS/Preloader (High).
Qualcomm (w tym closed-source) – pozycje High i Critical (m.in. kernel/bootloader).
Praktyczne konsekwencje / ryzyko
Atak zdalny (DoS) na Framework może powodować zawieszanie/wyłączenie usług i potencjalne okna dla dalszych wektorów.
Krytyczne EoP w kernelu (pKVM/IOMMU) to eskalacja uprawnień i izolacja VM zagrożona — istotne w kontekście work-profile/COPE i MDM.
Modemy (MediaTek/Unisoc): ryzyko przechwycenia/zakłócenia komunikacji lub RCE/EoP w warstwie baseband przy specyficznych bodźcach radiowych.
Dwie luki „in the wild” wymagają pilnego wdrożenia poprawek na urządzeniach wysokiego ryzyka (VIP, dziennikarze, sektor publiczny).
Rekomendacje operacyjne / co zrobić teraz
Cel wdrożenia: patch level 2025-12-05 (zawiera kompletny zestaw). W MDM ustaw politykę „minimum patch level = 2025-12-05”.
Pixel/Samsung i inni OEM: monitoruj biuletyny producentów; dla Samsunga grudniowy SMR Dec-2025 agreguje łatki Google + SVE.
Priorytetyzacja floty:
Najpierw urządzenia z Android 15–16 używane do pracy z danymi wrażliwymi.
Następnie terminale z SoC MediaTek/Unisoc (ze względu na modem).
Hardening tymczasowy (do czasu patcha):
Ogranicz uprawnienia i Background Activity Launch dla aplikacji o podwyższonym ryzyku.
W MDM włącz blokadę instalacji spoza Play i Play Protect skanowanie na żądanie.
W sieci mobilnej wymuś DNS filtrujący i tunnel split minimalny dla urządzeń z dostępem zdalnym/VPN.
Detekcja/IR:
Koreluj crash-loop/ANR usług z nietypowym ruchem sieciowym (DoS w Framework może być symptomem rekonesansu).
Poluj na wskaźniki naruszeń izolacji VM/KVM (np. nietypowe błędy vCPU, logi pKVM).
Różnice / porównania z innymi przypadkami
Względem biuletynów z XI 2025 r., grudzień akcentuje kernel (pKVM/IOMMU) oraz większą liczbę poprawek dostawców SoC/GPU.
W odróżnieniu od części poprzednich miesięcy, Project Mainline w grudniu nie wnosi osobnych łatek bezpieczeństwa (tylko platforma/OEM).
Podsumowanie / kluczowe wnioski
Instaluj 2025-12-05 ASAP — pełne pokrycie luk, w tym krytyczne EoP w kernelu.
Zarządzaj ryzykiem do czasu aktualizacji: twarde polityki MDM, ograniczenia uprawnień, monitoring anomalii.
Śledź biuletyny OEM/SoC — część poprawek (Qualcomm/MediaTek/Unisoc/Arm/Imagination) jest publikowana poza AOSP.
Źródła / bibliografia
Android Security Bulletin — December 2025 (AOSP), publikacja 1 grudnia 2025 r. (Android Open Source Project)
Android Security Bulletins – Overview (AOSP): cykl wydawniczy, dostępność łatek w AOSP. (Android Open Source Project)
Samsung Mobile SMR – Firmware Updates (Dec-2025): agregacja poprawek Google + SVE. (Samsung Mobile Security)
CVE‑2021‑26829 to stored XSS w ScadaBR pozwalający zapisać złośliwy JavaScript w ustawieniach systemu (system_settings.shtm). W praktyce bywa wykorzystywany do deface’u HMI, manipulacji widokiem oraz wyłączania logów/alertów – CISA dodała go do KEV z dowodami aktywnej eksploatacji. Monitoruj żądania do /ScadaBR/system_settings.shtm z podejrzanymi ładunkami (<script, onerror=, javascript:), alarmuj zmiany konfiguracji/alarms, egzekwuj WAF/IPS i ogranicz ekspozycję HMI.
Krótka definicja techniczna
Stored XSS w ScadaBR polega na zapisaniu złośliwego kodu JS (np. w polu opisu/ustawień), który uruchamia się w przeglądarce operatora przy otwarciu strony. Wektor według NVD: AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N, co oznacza atak z sieci, niski nakład, wymagane niskie uprawnienia i interakcja użytkownika; wpływ dotyczy gł. poufności i integralności.
Gdzie występuje / przykłady platform
Windows / Linux: ScadaBR (HMI/SCADA) uruchamiane zazwyczaj na Apache Tomcat (aplikacja Java/JSP).
Środowiska OT/ICS: panele HMI, wizualizacja procesu, często błędnie wystawiane do Internetu lub z dostępem zdalnym. (Mapowanie ATT&CK ICS poniżej).
Ślady/logi: logi Tomcata (localhost_access_log*.txt, catalina.out) oraz logi WAF/IPS/proxy.
Szczegółowy opis techniki (jak działa, cele, skuteczność)
Atakujący z niskimi uprawnieniami loguje się do ScadaBR (często z domyślnymi danymi) i wprowadza payload JS w polach renderowanych później w interfejsie (np. opis na stronie ustawień systemu). Gdy operator otwiera stronę (system_settings.shtm), przeglądarka wykonuje złośliwy skrypt, co pozwala m.in. na deface, manipulację widokiem, kradzież sesji (jeśli brak HttpOnly), czy uruchamianie akcji w imieniu operatora (CSRF‑like). W prawdziwym incydencie 2025 r. (honeypot OT) operatorzy Forescout obserwowali: deface loginu („Hacked by …”), usuwanie źródeł PLC, zmianę setpointów i wyłączenie logów/alarmów – część działań zrealizowano właśnie przez możliwość uruchomienia skryptu w HMI.
Artefakty i logi (co i gdzie szukać)
Źródło
Co szukać (przykłady wzorców)
Lokalizacja / produkt
Uwagi / mapowanie
Tomcat AccessLog
Żądania do */ScadaBR/system_settings.shtm* z ładunkami "<script", "%3Cscript", onerror=, javascript:
Zmiany Ingress/ConfigMap/Secret dot. publicznej ekspozycji HMI
kube-apiserver-audit.log
Pośrednio – redukcja ekspozycji na T1190.
M365
N/D
—
Brak związku funkcjonalnego.
Detekcja (praktyczne reguły)
Sigma (webserver)
title: ScadaBR system_settings.shtm Stored XSS Attempt
id: 7b7a1a6b-0d7a-4c1b-9a78-7a8d9b7f4f21
status: experimental
description: Wykrywa próby XSS na stronie /ScadaBR/system_settings.shtm
logsource:
category: webserver
detection:
target:
cs-uri-stem|contains: "/ScadaBR/system_settings.shtm"
payload_query:
cs-uri-query|contains:
- "<script"
- "%3Cscript"
- "onerror="
- "onload="
- "javascript:"
payload_body:
request_body|contains:
- "<script"
- "%3Csvg%20onload"
condition: target and (payload_query or payload_body)
fields:
- src_ip
- http_method
- status
- cs-useragent
- cs-referrer
falsepositives:
- testy administratorów/HMI z dozwolonym HTML (rzadkie)
level: high
tags:
- attack.T1491.001
- attack.T1190
- ics.T0838
Splunk (SPL)
index=web sourcetype IN ("tomcat:access","apache:access","nginx:access")
uri_path="/ScadaBR/system_settings.shtm"
| eval q=coalesce(uri_query,request_body)
| where like(q,"%<script%") OR like(q,"%onerror=%") OR like(q,"%javascript:%")
OR like(q,"%<svg%onload%") OR like(q,"%25%33%43script%") /* %3Cscript */
| stats count min(_time) max(_time) by src_ip, http_method, status, useragent, uri_query, request_body
KQL (Azure / CEF w Sentinel)
CommonSecurityLog
| where RequestURL has "/ScadaBR/system_settings.shtm"
| where RequestURL contains "<script" or RequestURL contains "%3Cscript"
or RequestURL contains "onerror=" or RequestURL contains "javascript:"
| summarize cnt=count() by SourceIP, RequestMethod, RequestURL, DeviceVendor, bin(TimeGenerated, 5m)
AWS — CloudWatch Logs Insights (AWS WAF)
fields @timestamp, httpRequest.clientIp as src_ip, httpRequest.uri, httpRequest.args, httpRequest.httpMethod as method, action, terminatingRuleId
| filter httpRequest.uri like /\/ScadaBR\/system_settings\.shtm/
| filter httpRequest.args like /(<script|%3[cC]script|onerror=|javascript:)/
| stats count() by src_ip, method, httpRequest.uri, action, terminatingRuleId, bin(@timestamp, 5m)
Elastic (Kibana KQL)
(event.dataset:"tomcat.access" OR event.dataset:"apache.access" OR event.dataset:"nginx.access")
AND url.path:"/ScadaBR/system_settings.shtm"
AND (url.query:*"<script"* OR url.query:"*%3Cscript*" OR http.request.body.content:*"onerror="* OR url.full:*"javascript:"*)
User‑Agent / automaty:python-requests/nietypowe UA w krótkich odstępach vs sesje interaktywne operatorów. (por. obserwacje honeypota).
Źródła IP: hostingi/VPS (np. wzorce z raportu o TwoNet) + brak historycznego ruchu do HMI.
Anomalie konfiguracji: alerty na nagłe serie zmian ustawień HMI (alarmy, źródła PLC, opisy).
False positives / tuning
Administracyjne testy UI (rzadkie) – białe listy źródeł admina i godzin zmian; dopuszczalne są proste tagi HTML (np. <b>), ale niescript/onerror/javascript: – filtruj regexem.
Skrypty monitoringu generujące 4xx na ścieżce – odfiltrować status ≠ 200/302 dla attempt vs success.
Proxy zdrowia – wykluczyć User-Agent health‑checks.
Playbook reagowania (IR)
Triage & containment
Odłącz publiczną ekspozycję HMI / ogranicz do VPN/allowlist (NGFW/WAF block reguły XSS).
Wymuś log‑out wszystkich sesji ScadaBR; reset haseł i wyłącz konta nieznane (T1078).
Analiza
Przejrzyj AccessLogValve i catalina.out pod kątem żądań do /ScadaBR/system_settings.shtm z ładunkami XSS.
Zrzut bazy ScadaBR i skan na <script (przykład MySQL — lab only): SELECT table_schema, table_name, column_name FROM information_schema.columns WHERE data_type IN ('text','varchar') AND table_schema LIKE 'scadabr%'; -- Dla każdej tabeli/kolumny tekstowej: SELECT * FROM <tbl> WHERE <col> LIKE '%<script%';
Zweryfikuj zmiany alarmów/setpointów (T0838/T0831) i kont z ostatnich 24–72 h.
Eradykacja & naprawa
Usuń payloady z pól UI, przywróć konfigurację alarmów i źródeł PLC z backupu.
Ustaw CSP, HttpOnly/Secure dla sesji, walidację/encoding pól (Server‑side).
Zaktualizuj ScadaBR/Tomcat/JDK, włącz WAF reguły XSS (virtual patch).
Lessons learned
Zmiana architektury dostępu (Zero Trust, segmentacja OT/DMZ).
Przykłady z kampanii / case studies
Honeypot OT (2025): napastnik (grupa TwoNet) zalogował się (m.in. domyślne poświadczenia), następnie wykorzystał CVE‑2021‑26829 do deface’u strony logowania (alert JS), usunął źródła PLC, zmienił parametry i wyłączył logi/alerty. Brak prób eskalacji na hosta – nacisk na warstwę HMI.
KEV: CISA formalnie dodała podatność do katalogu 11/28/2025 z wymaganiem zastosowania mitigacji/wycofania produktu do 12/19/2025.
Lab (bezpieczne testy)
Wyłącznie w odizolowanym środowisku testowym. Celem jest sprawdzenie detekcji/logowania, nie eksploatacja środowisk produkcyjnych.
28 listopada 2025 r. CISA dodała do katalogu KEV (Known Exploited Vulnerabilities) lukę CVE-2021-26829 w OpenPLC ScadaBR – podatność typu stored XSS (Cross-Site Scripting), która umożliwia wstrzyknięcie kodu JavaScript poprzez stronę system_settings.shtm. Afera jest istotna dla środowisk OT/ICS, bo błąd dotyczy paneli HMI używanych do nadzoru i sterowania procesami. Wpis w KEV oznacza potwierdzoną eksploatację w środowisku rzeczywistym i dla agencji FCEB wyznacza termin wdrożenia środków zaradczych do 19 grudnia 2025 r.
W skrócie
CVE-2021-26829: stored XSS w OpenPLC ScadaBR (Windows ≤ 1.12.4, Linux ≤ 0.9.1), CVSS 3.1: 5.4 (Medium).
Status: dodane do CISA KEV 28.11.2025 r. z obowiązkiem działań do 19.12.2025 r. dla FCEB.
Eksploatacja: m.in. przez grupę hacktywistyczną TwoNet w incydencie na wabiku (honeypot) stylizowanym na oczyszczalnię wody – defacement HMI, manipulacja ustawieniami, wyłączanie logów i alarmów.
Trend: skoordynowane skanowanie i eksploatacja setek CVE z wykorzystaniem prywatnej infrastruktury OAST działającej w Google Cloud, z regionalnym ukierunkowaniem na Brazylę.
Kontekst / historia / powiązania
Badacze Forescout/Vedere Labs opisali we wrześniu 2025 r. atak grupy TwoNet na ich pułapkę OT – agresorzy najpierw zalogowali się na HMI domyślnymi danymi, a następnie użyli CVE-2021-26829 do osadzenia złośliwego skryptu wyświetlającego komunikat „HACKED BY BARLATI” oraz modyfikowali ustawienia systemu (w tym wyłączenie logów i alarmów). To potwierdza realny wpływ XSS na bezpieczeństwo operacji, mimo że formalnie ma on „średni” rating.
Równolegle VulnCheck wykrył długotrwale działającą, atakującą infrastrukturę OAST (*.i-sh.detectors-testing[.]com na IP 34.136.22.26) hostowaną w Google Cloud. Zarejestrowano ok. 1,4 tys. prób dotyczących ponad 200 CVE, kierowanych głównie przeciw systemom w Brazylii, co wskazuje na skanowanie „masowe, ale ukierunkowane”. Taki model ułatwia sprawcom weryfikację skuteczności exploitów i maskowanie ruchu w chmurze.
Analiza techniczna / szczegóły luki
Wektor: stored XSS w system_settings.shtm – użytkownik o uprawnieniach aplikacyjnych może wprowadzić treść, która zostanie renderowana w HMI i wykona skrypt w przeglądarce operatora. S: Changed, PR: Low, UI: Required.
Zakres dotkniętych wersji: Windows ≤ 1.12.4, Linux ≤ 0.9.1. Brak dowodów, że starsze forki lub niestandardowe buildy są odporne.
Skutki techniczne:
Defacement interfejsu HMI i wstrzyknięcie złośliwych treści (np. pop-upy, przekierowania).
Kradzież sesji/CSRF lub pułapki operatorskie (ang. UI redressing), które mogą prowadzić do błędnych decyzji operatorskich.
Modyfikacja widoków i formularzy skutkująca np. fałszywymi parametrami procesu. (W incydencie TwoNet mix: defacement + manipulacja ustawieniami i wyłączenie alarmów).
Praktyczne konsekwencje / ryzyko
W środowiskach OT/ICS skutki XSS wykraczają poza klasyczne „phishing UI”. Manipulacja widokiem HMI może:
ukryć rzeczywiste alarmy,
zafałszować setpointy/telemetrię,
skłonić operatora do niebezpiecznych działań (np. zmiany parametrów).
Incydent Forescout pokazał, że od pierwszego dostępu do działań destrukcyjnych minęło ~26 godzin, a atakujący skoncentrował się wyłącznie na warstwie webowej HMI, bez eskalacji na hosta – co czyni tego typu ataki ciche, szybkie i możliwe do przeoczenia przez klasyczne EDR.
Rekomendacje operacyjne / co zrobić teraz
Natychmiastowa weryfikacja ekspozycji
Zidentyfikuj instancje OpenPLC ScadaBR (Windows/Linux) i ich wersje; sprawdź bezpośrednią ekspozycję do Internetu (Shodan/asset inventory).
Aktualizacje i środki tymczasowe
Jeśli dostępne łatki/vendor-fix – wdrożyć; w przeciwnym wypadku filtracja treści, encoding output i sanityzacja pól konfiguracyjnych system_settings.shtm.
Dla środowisk FCEB: dotrzymaj terminu 19.12.2025 z wpisu KEV.
Twardnienie interfejsów HMI (zalecenia Vedere Labs):
Eliminacja słabych/dom yślnych haseł, MFA dla adminów.
Segmentacja (oddzielenie strefy HMI od IT/Internetu), przepływy jednokierunkowe tam, gdzie to możliwe.
Usunięcie zbędnej ekspozycji (VPN z mTLS zamiast publicznego HMI).
Monitoring i detekcja specyficzna dla OT
DPI z rozumieniem Modbus/S7 i regułami na: próby exploitów, nieautoryzowane zapisy, zmiany w HMI, tworzenie kont (np. „BARLATI”).
Blokowanie i hunting na wskaźniki OAST
Monitoruj/blokuj wywołania do domen *.i-sh.detectors-testing.com i aktywność z adresów Google Cloud wymienionych przez VulnCheck (np. 34.136.22.26 dla hosta OAST). Uważaj na fałszywie dodatnie – kontekst sieci i geolokalizacja są kluczowe.
Bezpieczne SDLC dla HMI/SCADA
Systematyczny output encoding, CSP, sanitizacja danych, testy DAST/SAST i testy XSS (stored/reflected/DOM) w pipeline.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
W przeciwieństwie do typowych XSS w aplikacjach biurowych, XSS w HMI/SCADA:
oddziałuje na proces przemysłowy przez interakcję z operatorem,
bywa „wystarczający” do manipulacji setpointami i wyłączenia alarmów, nawet bez RCE na hoście,
częściej jest łączony z domyślnymi hasłami i błędną segmentacją sieci (co pokazał przypadek TwoNet).
Z kolei kampania opisana przez VulnCheck obrazuje industrializację skanowania – prywatne OAST na chmurze, stare i nowe szablony Nuclei, szeroka lista CVE i regionalne ukierunkowanie. To inny wektor niż ręczny atak na HMI, ale oba trendy się uzupełniają: masowe wykrywanie podatnych hostów + celowana eksploatacja w OT.
Podsumowanie / kluczowe wnioski
CVE-2021-26829 w OpenPLC ScadaBR trafiła do CISA KEV z powodu realnej eksploatacji – to nie tylko „estetyczny” XSS.
Incydent TwoNet pokazuje, że XSS w HMI może prowadzić do defacementu, manipulacji i ukrycia alarmów w ciągu ~26 godzin od pierwszego dostępu.
OAST w chmurze (Google Cloud) napędza skalowalną eksploatację setek CVE – to trend, który ułatwia przeciwnikom maskowanie aktywności.
Organizacje OT/ICS powinny natychmiast zidentyfikować instancje ScadaBR, wdrożyć łatki/mitigacje, utwardzić HMI i wprowadzić monitoring DPI z regułami pod XSS/OAST.
Źródła / bibliografia
NVD: CVE-2021-26829 (opis, wersje, CVSS, informacja o włączeniu do CISA KEV z datami 28.11.2025 / 19.12.2025) – National Vulnerability Database. (nvd.nist.gov)
VulnCheck: The Mystery OAST Host Behind a Regionally Focused Exploit Operation (OAST na Google Cloud, ~1400 prób, >200 CVE, 27.11.2025). (VulnCheck)
The Hacker News: CISA Adds Actively Exploited XSS Bug CVE-2021-26829 in OpenPLC ScadaBR to KEV (kontext i agregacja informacji, 30.11.2025). (The Hacker News)
BlueKeep (CVE‑2019‑0708) to przed‑autentykacyjna podatność RCE w usłudze Remote Desktop Services/TermService (RDP) w starszych Windows (XP, Vista, 7; Server 2003/2008/2008 R2). Umożliwia zdalne wykonanie kodu bez interakcji użytkownika i ma potencjał „wormowalny”. NLA redukuje ryzyko automatycznej propagacji, ale nie eliminuje RCE jeśli atakujący ma ważne poświadczenia — łatka jest obowiązkowa (np. KB4499164/KB4499175, KB4499180, KB4500331). CVSS v3.1: 9.8 (Critical).
Krótka definicja techniczna
CVE‑2019‑0708 to błąd w implementacji RDP w komponencie jądra (m.in. termdd.sys/RDS), który pozwala niezalogowanemu napastnikowi na wysłanie specjalnie przygotowanych PDU w fazie zestawiania kanałów RDP i osiągnięcie zdalnego wykonania kodu w kontekście systemowym. W praktyce umożliwia to wejście (Initial Access) lub ruch boczny (Lateral Movement) przez RDP.
Gdzie występuje / przykłady platform
Windows XP SP3 (x86/x64/Embedded), Server 2003 (SP2/R2), Vista SP2, Windows 7 SP1, Windows Server 2008 / 2008 R2 — podatne bez aktualizacji. Microsoft wydał poprawki, łącznie dla systemów EoL. Windows 8/10/11 nienarażone.
Środowiska chmurowe (AWS/Azure/GCP) — ryzyko ekspozycji dotyczy głównie instancji z otwartym 3389/TCP na Internet (Security Groups/NSG). To mapuje się do T1190/T1021.001 i wymaga kontroli reguł sieciowych. (Źródło ogólne — ATT&CK).
AD/ESXi/K8s/M365 — sama podatność dotyczy Windows; dla tych platform istotne są punkty ekspozycji RDP (jump/bastion), polityki segmentacji i bram RDP.
Szczegółowy opis techniki (jak działa, cele, dlaczego jest skuteczna)
BlueKeep wykorzystuje błąd w przetwarzaniu kanałów/strumienia RDP podczas handshake’u (przed uwierzytelnieniem). Atakujący nawiązuje połączenie do 3389/TCP i wysyła sekwencję PDU, które prowadzą do korupcji pamięci jądra i przejęcia kontroli nad wykonaniem. Skuteczność wynika z:
Pre‑auth RCE (brak logowania / brak interakcji),
Wormowalności (możliwa automatyczna propagacja),
Powszechnej ekspozycji RDP w sieciach firmowych oraz często w Internecie. NLA wymaga uwierzytelnienia przed dotarciem do podatnej ścieżki i utrudnia automatyczne rozprzestrzenianie, ale nie chroni, jeśli napastnik ma ważne poświadczenia (np. z wycieku). Dlatego aktualizacja pozostaje jedyną trwałą mitigacją.
Artefakty i logi (tabela)
Źródło
Artefakt / pole
Co obserwować
Wartość dla detekcji
Windows/System
Event ID 56, Provider: TermDD
„The Terminal Server security layer detected an error in the protocol stream…”; skoki liczby błędów z jednego źródłowego IP
Indykator skanów/nieudanych exploitów BlueKeep; korelować z 3389/TCP i restartami usług.
Windows/Security
4624/4625 (LogonType=10)
Udane/nieudane logowania RDP; źródłowe IP
Do odróżnienia legalnych adminów od zewnętrznych adresów; koreluj z ekspozycją portu.
title: Windows RDP TermDD Protocol Errors Burst (BlueKeep/Scan)
id: 2f2f8e8a-6a1a-45d2-9b6f-td56-burst
status: experimental
description: Wykrywa nagłe skoki błędów TermDD (EventID 56) sugerujące skany lub nieudane próby eksploatacji CVE-2019-0708.
author: Badacz CVE
logsource:
product: windows
service: system
detection:
selection:
EventID: 56
Provider_Name: 'TermDD'
timeframe: 5m
condition: selection
# Uwaga: Agregacje zależą od backendu. Zalecane korelowanie: >=20 zdarzeń/5min z jednego SourceIP/hostu.
level: medium
tags:
- attack.T1210
- attack.T1021.001
- cve.2019-0708
B) Wyłączenie NLA — modyfikacja rejestru (Sysmon)
title: RDP NLA Disabled via Registry
id: 3a6eaeee-1f6b-4592-a1a1-nla-off
status: stable
description: Wykrywa ustawienie UserAuthentication=0 dla RDP-Tcp (wyłączenie NLA).
author: Badacz CVE
logsource:
product: windows
service: sysmon
detection:
sel_path:
EventID: 13
TargetObject|endswith: '\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\UserAuthentication'
sel_val:
Details|contains: 'DWORD (0x00000000)'
condition: sel_path and sel_val
level: high
tags:
- attack.T1021.001
- attack.T1112
falsepositives:
- Rzadkie legalne zmiany GPO/Intune
(NLA/UserAuthentication = 1 włącza NLA; 0 ją wyłącza).
Splunk (SPL)
A) Skoki TermDD (Event 56):
index=wineventlog sourcetype="WinEventLog:System" EventCode=56 SourceName=TermDD
| stats count by host, Message, _time, ComputerName, dest
| timechart span=5m count by host
B) RDP sukcesy spoza prywatnych adresów (4624, LogonType=10):
index=wineventlog sourcetype="WinEventLog:Security" EventCode=4624 Logon_Type=10
| eval isPublic=if(cidrmatch("10.0.0.0/8", Source_Network_Address) OR cidrmatch("172.16.0.0/12", Source_Network_Address) OR cidrmatch("192.168.0.0/16", Source_Network_Address), 0, 1)
| search isPublic=1
| stats count values(Source_Network_Address) as src_ip by ComputerName, Target_User_Name
| where count>0
KQL (Azure/Microsoft Sentinel)
A) Udane logowania RDP spoza prywatnych podsieci:
SecurityEvent
| where EventID == 4624 and LogonType == 10
| extend SrcIp = iff(isempty(IpAddress), tostring(parse_xml(EventData).EventData.Data[?(@.Name=="IpAddress")][0]."#text"), IpAddress)
| where SrcIp !startswith "10." and SrcIp !startswith "172.16." and SrcIp !startswith "192.168."
| summarize dcount(SrcIp) by Computer, TargetUserName, bin(TimeGenerated, 1h)
B) Zmiany NSG otwierające 3389 na Internet (Azure Activity):
AzureActivity
| where OperationNameValue =~ "MICROSOFT.NETWORK/NETWORKSECURITYGROUPS/SECURITYRULES/WRITE"
| extend p=parse_json(Properties)
| extend src=tostring(p.responseBody.properties.sourceAddressPrefix),
dport=tostring(p.responseBody.properties.destinationPortRange),
access=tostring(p.responseBody.properties.access)
| where dport in ("3389","*") and src in ("Internet","0.0.0.0/0","Any") and access == "Allow"
| project TimeGenerated, Caller, ResourceGroup, Resource, src, dport, access
CloudTrail query (CloudWatch Logs Insights)
Otwieranie 3389/TCP na 0.0.0.0/0 (EC2 Security Groups):
fields @timestamp, userIdentity.arn, sourceIPAddress, eventName, requestParameters
| filter eventSource="ec2.amazonaws.com"
| filter eventName in ["AuthorizeSecurityGroupIngress","ModifySecurityGroupRules","UpdateSecurityGroupRuleDescriptionsIngress"]
| filter requestParameters like /3389/ and requestParameters like /0\.0\.0\.0\/0/
| sort @timestamp desc
Elastic / EQL
A) Wyłączenie NLA w rejestrze (Elastic EQL):
registry where
registry.path :
"*\\System\\CurrentControlSet\\Control\\Terminal Server\\WinStations\\RDP-Tcp\\UserAuthentication" and
registry.data.strings : ("0","0x00000000")
B) RDP z Internetu (Elastic Query DSL – Beats flow):
network where destination.port == 3389 and
not cidrmatch(source.ip, ["10.0.0.0/8","172.16.0.0/12","192.168.0.0/16"])
Heurystyki / korelacje (co łączyć)
Wejście → błąd protokołu → restart usługi: Inbound 3389 z nowego publicznego IP + TermDD/56 burst + SCM/7031 dla TermService ⇒ podejrzenie skanów/nieudanych exploitów BlueKeep.
Wejście → sukces logowania → nietypowe procesy: 3389 z Internetu + 4624/LogonType=10 + svchost.exe (TermService) spawnujący cmd.exe/powershell.exe ⇒ post‑exploitation.
NLA: zmiana UserAuthentication na 0 + wzrost 4625/LogonType=10 ⇒ próby brute‑force lub przygotowanie do eksploatacji (chociaż BlueKeep jest pre‑auth, wyłączenie NLA bywa celem operatorów, aby ułatwić dalsze działania).
False positives / tuning
Event 56 (TermDD) może wynikać z błędów sieciowych/starych klientów RDP — filtrować progiem (np. ≥20/5min per źródłowe IP) i utrzymywać listę zaufanych skanerów.
4624/10: legalne logowania adminów/jumphostów — whitelisty dla źródeł ASN/VPN, kont serwisowych i okien serwisowych.
7031: restart różnych usług — koreluj wąsko z TermService i 56.
Zmiany rejestru: wdrożenia GPO/Intune — taguj „change windows” i weryfikuj źródło (PID/Signer).
Playbook reagowania (IR)
Triaging & izolacja
Odłącz host od sieci lub przełącz do VLAN kwarantanny.
Listopad 2019 — pierwsze potwierdzone wykorzystanie BlueKeep in‑the‑wild do kryptominera (kampania masowa, niestabilne exploity).
Fortinet/Microsoft potwierdzają ataki oraz apelują o natychmiastowe łatanie.
Szacunki ekspozycji: setki tysięcy hostów publicznie podatnych po publikacji (2019). (kontekst historyczny)
Lab (bezpieczne testy)
Wyłącznie w odizolowanym labie. Brak exploitów. Celem jest weryfikacja ekspozycji i telemetrii.
Sprawdzenie stanu RDP/NLA na hoście:
# Czy RDP jest włączone
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections
# Czy NLA jest włączona
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication
Weryfikacja łatek (Win7/2008 R2):
Get-HotFix -Id KB4499164,KB4499175
Skan bezpieczny z zewnątrz (wersja RDP, bez exploitów):
CVE‑2019‑11510 to krytyczna podatność typu pre‑auth arbitrary file read w Ivanti/Pulse Connect Secure (PCS). Umożliwia niezalogowanemu napastnikowi odczyt plików z urządzenia VPN poprzez specjalnie przygotowane żądanie HTTP, co w praktyce prowadzi do kradzieży konfiguracji, kluczy i tokenów sesji oraz dalszych włamań z pominięciem MFA. Z punktu widzenia ATT&CK odpowiada to T1190 (Initial Access), a po eksfiltracji sekretów typowo obserwujemy *T1552. (Unsecured Credentials)**, T1539 (Steal Web Session Cookie) i później T1078 (Valid Accounts). Patching do wersji naprawiających (np. 8.2R12.1, 8.3R7.1, 9.0R3.4 i nowsze) jest obowiązkowy, a urządzenia należy weryfikować narzędziem Integrity Checker Tool (ICT) oraz logami WAF/ALB.
Krótka definicja techniczna
CVE‑2019‑11510: w Pulse Connect Secure (PCS) do wersji 8.2<8.2R12.1, 8.3<8.3R7.1 i 9.0<9.0R3.4 błąd w walidacji ścieżek umożliwia nieuwierzytelniony odczyt dowolnych plików poprzez spreparowany URI. CVSS v3.1 = 10.0 (CRITICAL).
Gdzie występuje / przykłady platform
Network/Appliance: Ivanti/Pulse Connect Secure (sprzęt/VM) — wektor pierwotny.
Windows / AD: po wycieku haseł/kluczy możliwy dalszy dostęp i lateral movement (T1078).
AWS: ślady/ochrona w AWS WAF (logi httpRequest.*) i ALB access logs.
Azure: Application Gateway WAF / Front Door — telemetryka wbicia i blokad. [brak oficjalnego cytatu — ogólna praktyka]
GCP: Cloud Armor / Chronicle parser dla Pulse Secure (syslog).
K8s / ESXi / M365: nie dotyczy bezpośrednio (pośredni wpływ poprzez kompromitację tożsamości).
Szczegółowy opis techniki (jak działa, cele, dlaczego skuteczna)
Błąd pre‑auth file read umożliwia z poziomu Internetu pobieranie plików z urządzenia PCS. Atakujący używa spreparowanego żądania HTTP (z elementami przechodzenia po katalogach), aby ominąć autoryzację i uzyskać dostęp do zasobów urządzenia. Następnie eksfiltruje m.in. pliki konfiguracyjne, klucze i artefakty sesji, które mogą pozwolić na przejęcie aktywnych sesji, logowanie jak legalni użytkownicy (T1078) lub dalszą penetrację sieci. Podatność była szeroko wykorzystywana (CISA KEV), a technicznie wpisuje się w ATT&CK T1190.
Artefakty i logi
Źródło
Pole/artefakt
Wskaźnik
Komentarz
Pulse Secure syslog (Events/User/Admin)
log message / URI
nietypowe żądania do endpointów HTML5 + sekwencje traversal
Upewnij się, że eksportujesz syslog (WELF/Custom).
Reverse proxy / WAF
URI, query, status, UA, src IP
obecność wzorców path traversal, słowa‑klucze związane z HTML5 gateway
Dobre miejsce do korelacji i rate‑limitu.
AWS WAF (CloudWatch Logs)
httpRequest.uri, action, terminatingRuleId
żądania z ../ i słowami kluczowymi; akcja ALLOW/BLOCK
Wzorzec „Guacamole” oraz traversal jest wskazywany w publicznych regułach Sigma dla CVE‑2019‑11510.
Splunk (SPL)
(index=web OR index=proxy OR index=waf OR sourcetype=pulse* OR sourcetype=aws:waf)
| eval uri=coalesce(cs_uri_stem, request, uri_path, url), q=coalesce(cs_uri_query, uri_query, query_string)
| where (like(uri, "%/dana%") OR like(uri, "%dana-na%"))
AND (like(uri, "%guacamole%") OR like(q, "%guacamole%"))
AND (like(uri, "%../%") OR like(q, "%../%") OR like(uri, "%..%2F%") OR like(q, "%..%2F%"))
| stats count dc(src) AS src_ips values(user) AS users by uri, q, user_agent, dest
| where count > 0
KQL (Microsoft Sentinel / Log Analytics)
let IOCUri = dynamic(["/dana", "dana-na"]);
let Kw = "guacamole";
(union isfuzzy=true
CommonSecurityLog
| extend uri = coalesce(RequestURL, RequestURI, concat(URL, URLQuery)), src = SourceIP, ua = RequestClientApplication
, AzureDiagnostics
| where Category has "ApplicationGatewayFirewallLog"
| extend uri = requestUri_s, src = clientIp_s, ua = userAgent_s
)
| where uri has_any (IOCUri) and uri contains Kw and (uri contains "../" or uri contains "..%2F")
| summarize cnt=count(), make_set(src), make_set(ua) by bin(TimeGenerated, 5m), tostring(uri)
AWS CloudWatch Logs Insights (AWS WAF)
# Log Group: /aws/waf/<twoj-webacl>
fields @timestamp, httpRequest.clientIp, httpRequest.method, httpRequest.uri, action, terminatingRuleId
| filter httpRequest.uri like /dana/ and httpRequest.uri like /\.\./ and httpRequest.uri like /guacamole/
| stats count() as hits by httpRequest.clientIp, action, terminatingRuleId, httpRequest.uri
| sort hits desc
Pola httpRequest.*, action, terminatingRuleId pochodzą z oficjalnego schematu logów AWS WAF.
Elastic (KQL + EQL)
KQL (http logs / ecs):
url.path:/dana* AND url.path:*guacamole* AND (url.path:*../* OR url.query:*..%2F*)
EQL (sieć/HTTP):
network where network.protocol == "http"
and wildcard(url.path, "/dana*")
and stringcontains(url.path, "guacamole")
and (stringcontains(url.path, "../") or stringcontains(url.query, "..%2F"))
Seria prób z różnych IP/ASN + wspólny UA (skaner) ⇒ obniż priorytet lub taguj jako „scanner/bot”.
Po próbach: nowe sesje VPN z nieznanych ASN, nietypowa geografia (impossible travel), zmiana fingerprintu TLS → koreluj z logowaniem do AD/VPN. (CISA wskazywała takie objawy przy kampaniach na PCS.)
False positives / tuning
Legalny ruch HTML5 (Guacamole) bez traversal powinien być akceptowany — warunek na ../ / %2e%2e jest kluczowy.
Skany bezpieczeństwa / bug‑bounty generują podobne wzorce — whitelistuj znane zakresy.
Deduplikuj zdarzenia na 5–10 min, grupując po srcIP + UA + URI.
Playbook reagowania
Triaż i izolacja: jeśli reguły z §7 wskazują udane trafienia (200/206), natychmiast odetnij dostęp administracyjny do PCS / wstaw przed nim regułę WAF blokującą wzorce traversal.
Weryfikacja stanu PCS: uruchom Ivanti Integrity Checker Tool (ICT) (wbudowany lub zewnętrzny) i zarchiwizuj wynik.
Forensyka: zgraj logi (Events/User/Admin), eksport syslog z SIEM, logi WAF/ALB. (Dokumentacja logowania PCS.)
Patching / remediacja: zaktualizuj PCS do wersji naprawiających CVE‑2019‑11510 (≥8.2R12.1, ≥8.3R7.1, ≥9.0R3.4). Jeśli ICT wykrył modyfikacje — rozważ reinstalację obrazu i rotację kluczy/certyfikatów.
Reset/rotacja: wymuś reset haseł VPN/AD, rotuj certyfikaty/klucze używane przez PCS, unieważnij aktywne sesje. (Powiązanie z T1552.*).
Hunting post‑exploitation: szukaj logowań z nowych ASN, użycia skradzionych ciasteczek/tokens (T1539), nietypowych mapowań ról.
Twardnienie: stałe reguły WAF blokujące traversal, MFA wszędzie, segmentacja i ograniczenie dostępu do konsoli administracyjnej PCS.
Zgłoszenia i KEV: traktuj jako KEV i raportuj zgodnie z procesem (CISA KEV).
Przykłady z kampanii / case studies
REvil/Sodinokibi (2019–2020) — raporty łączyły wątki ransomware z wykorzystaniem PCS w wektorze wejścia.
„Fox Kitten” (APT z Iranu, 2019–2020) — szeroka eksploatacja VPN (w tym Pulse) jako początkowego dostępu; utrzymywanie backdoorów.
CISA alerty (2020+) — ostrzeżenia o kontynuowanej eksploatacji niezałatanych PCS; zalecenia aktualizacji i hardeningu.
Lab (bezpieczne testy) — przykładowe komendy
Tylko w odizolowanym labie. Celem jest wytworzenie logów do weryfikacji reguł, bez uderzania w realny PCS.
Symulacja logów na NGINX (Docker)
docker run -d --name nginx -p 8080:80 nginx:alpine
# Generowanie „szumu” traversal + słowo-klucz (log only):
for p in "/test/guacamole/../../etc/hosts" "/dana-na/../test/guacamole/..%2F..%2Ffile" ; do
curl -s "http://127.0.0.1:8080${p}?q=check" >/dev/null
done
Weryfikacja detekcji — załaduj logi access.log do SIEM i uruchom reguły z §7.
Test WAF — utwórz regułę blokującą sekwencje traversal i sprawdź, czy zapisy AWS WAF rejestrują akcję BLOCK oraz terminatingRuleId.
30 listopada 2025 r. na portalu agregującym wycieki pojawiła się karta ofiary Division 10 Inc. (Memphis, Tennessee) przypisana do grupy DragonForce. Wpis wskazuje datę wykrycia i szacowaną datę ataku jako 30.11.2025 oraz zawiera metadane DNS domeny firmy. To typowy schemat „naming & shaming”, którego celem jest presja na zapłatę okupu po eksfiltracji danych.
W skrócie
Sprawca: DragonForce – rosnący „cartel” RaaS (Ransomware-as-a-Service) aktywny od końca 2023 r., działający w modelu afiliacyjnym i „white-label”.
Ofiara: Division 10 Inc. (USA), sektor dostaw wyposażenia budowlanego. Wpis w serwisie wyciekowym z 30.11.2025.
Kontekst: TTPs DragonForce bywają łączone z działalnością operatorów Scattered Spider, według wspólnego alertu CISA i partnerów.
Ryzyko: przerwy operacyjne, wtórne ataki na partnerów w łańcuchu dostaw, szantaż publikacją danych, możliwa podwójna (a nawet potrójna) ekstorsja. Przykłady wpływu na handel detaliczny pokazały głośne incydenty 2025 r. (np. M&S).
Kontekst / historia / powiązania
DragonForce ewoluował z klasycznej grupy ransomware do „kartelu” RaaS: rekrutuje afiliantów, oferuje brandowalne ładunki, a w 2025 r. prowadził otwartą rywalizację z innymi gangami o wpływy. W analizach branżowych wskazuje się m.in. kampanie na rynkach od Azji po Europę oraz szybkie poszerzanie listy ofiar. W osobnym nurcie raporty rządowe i prasowe łączyły użycie ładunków DragonForce z operacjami grupy Scattered Spider – socjotechnika + przejęcia tożsamości, a następnie wdrożenie ransomware/ekstorsji, co potwierdza letni alert CISA 2025. Skalę skutków biznesowych pokazał m.in. atak na Marks & Spencer, gdzie straty w zysku operacyjnym oszacowano na setki milionów funtów, a powrót kluczowych usług trwał tygodnie.
Analiza techniczna / szczegóły luki
Wejście/Initial Access
Socjotechnika ukierunkowana na helpdeski, SIM-swap/push-bombing, kradzież poświadczeń; nierzadko także exploity VPN/SSO oraz słabe MFA. (Powiązane wzorce opisane w doradztwach nt. Scattered Spider, które w praktyce bywają wykorzystywane przez afiliantów DragonForce).
Ruch boczny i eskalacja
Wykorzystanie narzędzi „living off the land” (RDP/WinRM/PowerShell), dump LSASS/AD, psexec/SMB, kradzież tokenów i sesji SSO.
Eksfiltracja i ekstorsja
Standard „double extortion”: zrzut danych na chmurę/TOR i presja medialna poprzez portal wyciekowy; w 2025 r. obserwowano także przejęcia/deface’y serwisów konkurencji i „white-label” warianty ładunków.
Szyfrowanie
Klasyczny crypto-ransomware z selektywnym wykluczaniem lokalizacji (m.in. WNP), co sygnalizują profile zagrożeń; mechanizmy przyspieszania szyfrowania (wątkowość), użycie usług przechwytywania VSS i wyłączania AV/EDR skryptami afiliantów.
Praktyczne konsekwencje / ryzyko
Przestój operacyjny w produkcji, logistyce i montażu (firmy budowlane podlegają sezonowości i karom umownym).
Wtórne narażenie partnerów: specyfikacje projektów, oferty, dane kontrahentów mogą zostać użyte do spear-phishingu łańcucha dostaw.
Presja reputacyjna i prawna: publikacja danych klientów/pracowników, obowiązki notyfikacyjne i inspekcje (RODO/FTC/stanowe).
Ryzyko re-ekstorsji – spory gangów RaaS i „podkradanie” ofiar zwiększają prawdopodobieństwo wielokrotnego szantażu.
Rekomendacje operacyjne / co zrobić teraz
1) Zabezpieczenie tożsamości i dostępu
Wymuś phishing-resistant MFA (FIDO2/WebAuthn) na VPN/SSO/Helpdesk; wyłącz SMS/voice MFA.
Just-in-time/least privilege + rotacja kluczy/sekretów po każdym incydencie.
Zamknij luki w zdalnym dostępie: blokada RDP z Internetu, segmentacja i bastiony.
2) Twardnienie punktów końcowych
EDR z regułami blokowania LOLBins/skrótów do narzędzi admina; blokada makr, AppLocker/WDAC.
Backup 3-2-1-1-0 z izolacją (immutability), regularne testy odtworzeniowe.
DragonForce (RaaS/cartel) vs LockBit/ALPHV (BlackCat): podobny model afiliacyjny, ale DragonForce w 2025 r. agresywnie promuje white-label i wchodzi w otwarte konflikty z rywalami, co zwiększa ryzyko re-ekstorsji i „przejmowania” ofiar.
W porównaniu z Cl0p (eksfiltracja bez szyfrowania w kampaniach masowych) DragonForce częściej łączy pełny crypto-lock z presją medialną DLS.
Podsumowanie / kluczowe wnioski
Wpis o Division 10 Inc. na portalu wyciekowym wskazuje na trwającą kampanię DragonForce wymierzoną w firmy z sektora budowlanego i pokrewnych.
TTPs łączą elementy socjotechniki tożsamościowej (wzorce znane ze Scattered Spider) z klasycznym double extortion.
Organizacje powinny priorytetyzować MFA odporne na phishing, segmentację, egress/DLP oraz testy odtworzeniowe – to najszybszy zwrot z inwestycji w kontekście tego aktora.
Źródła / bibliografia
Karta ofiary Division 10 – ransomware.live (30.11.2025). (ransomware.live)
