Marquis Software Solutions – dostawca oprogramowania i usług marketingowo-analitycznych dla sektora finansowego w USA – poinformował o naruszeniu bezpieczeństwa, które dotknęło co najmniej 74 banki i unie kredytowe. Do incydentu doszło 14 sierpnia 2025 r. po włamaniu przez urządzenie SonicWall, a atak miał charakter ransomware. W plikach skradzionych z systemów Marquis znajdowały się dane osobowe klientów instytucji finansowych (m.in. SSN/Tax ID, daty urodzenia, adresy, numery kont) – na razie bez dowodów na ich publiczne ujawnienie.
W skrócie
Skala: ponad 74 instytucje, >400 tys. klientów w różnych stanach USA.
Wejście: kompromitacja dostępu przez SonicWall (SSL VPN / firewall).
Wektor powiązany z trendem: od 2024/2025 gang Akira intensywnie nadużywa podatności CVE-2024-40766 i wykradzionych sekretów do logowania przez VPN, czasem mimo MFA.
Ryzyko dla klientów: kradzież tożsamości, fraudy finansowe, dalsze spear-phishingi.
Status: Marquis rozsyła zawiadomienia w imieniu klientów-instytucji; część pism AG (prokuratorów generalnych stanów) jest publicznie dostępna.
Kontekst / historia / powiązania
Marquis obsługuje >700 banków, unii i pożyczkodawców hipotecznych w USA jako zewnętrzny dostawca narzędzi CRM, analityki danych, zgodności i marketingu. Oznacza to klasyczny scenariusz ryzyka łańcucha dostaw (third-party risk): incydent u jednego vendora skutkuje seriami notyfikacji po stronie wielu niezależnych instytucji. W pierwszych publicznych materiałach pojawiły się wzmianki, że Marquis zapłacił okup (informacja z pisma jednej z unii; wzmianka następnie usunięta z publicznego notice, ale odnotowana przez media).
Analiza techniczna / szczegóły luki
Według zgłoszeń do urzędów stanowych, atak rozpoczął się 14.08.2025 od „nieautoryzowanego dostępu” przez firewall/VPN SonicWall, po czym napastnicy wynieśli wybrane pliki i wdrożyli ransomware. Zawiadomienia wymieniają typowe PII: imię i nazwisko, adres, telefon, SSN/ITIN, numery kont (bez kodów dostępu), daty urodzenia. Niektóre instytucje publikują własne listy typów danych i wielkości populacji objętej powiadomieniem.
Od strony „pierwszej bramy” do sieci wielu ofiar widzimy ciągłość z kampaniami Akira: wykorzystanie CVE-2024-40766 (błąd kontroli dostępu w SonicOS/SSLVPN, ogłoszony w VIII 2024 r.) oraz ponowne logowania przy użyciu wcześniej wykradzionych poświadczeń / nasion OTP, nawet przy włączonym MFA. Vendor potwierdzał korelację z CVE-2024-40766 oraz zalecał reset haseł i sekretów MFA po aktualizacji.
Praktyczne konsekwencje / ryzyko
Klienci banków/uni: realne ryzyko kradzieży tożsamości (otwieranie kont na cudze dane, zwroty podatkowe, wnioski kredytowe), account takeover oraz targetowane oszustwa (phishing na podstawie dokładnych danych).
Instytucje finansowe: koszty notyfikacji i monitoringu (często Epiq/inne pakiety 12–24 mies.), obsługa sporów KYC/AML, potencjalne postępowania regulacyjne, wzrost obciążenia SOC.
Ekosystem: kolejny dowód, że urządzenia perymetryczne i ich sekrety uwierzytelniania są dziś jednym z najsłabszych ogniw łańcucha bezpieczeństwa.
Rekomendacje operacyjne / co zrobić teraz
Dla banków/uni i innych klientów Marquis (i podobnych vendorów):
IR & notyfikacje: zsynchronizować treści pism z vendor-em; ująć precyzyjny zakres danych i daty (od 14.08.2025). Zweryfikować, czy notice w danym stanie nie wymaga dodatkowych elementów.
Zarządzanie dostępem do VPN/Firewalli:
Upewnić się, że SonicWall ma wersje eliminujące CVE-2024-40766 oraz pozostałe poprawki.
Zresetować: hasła VPN/Local Admin, seed/sekrety OTP i klucze API; wymusić MFA z phishing-resistant (FIDO2/Passkeys, gdzie możliwe).
Włączyć geo-IP filtering, lockout policy, dłuższą retencję logów oraz listy blokad C2 (zgodnie z praktykami opisywanymi w notyfikacjach).
Telemetria i myślenie o „dwell time”: hunting pod kątem nietypowych logowań SSLVPN (również z legalnymi kredencjałami), korelacja ze zmianami konfiguracji, enumeracją AD i exfiltracją.
Procesy vendor-risk: wymagać od dostawców: regularnego rotowania sekretów, planów „credential refresh” po każdej kampanii na urządzenia brzegowe, oraz testów odtworzeniowych kopii zapasowych pod scenariusze ransomware.
Dla klientów indywidualnych:
Założyć zamrożenie kredytowe (credit freeze) i alerty w biurach kredytowych; skorzystać z oferowanego monitoringu tożsamości.
Uważać na wiadomości podszywające się pod bank/unię – nadmiar wiedzy (SSN, data urodzenia) pozwala tworzyć bardzo wiarygodne spear-phishingi.
Różnice / porównania z innymi przypadkami
W odróżnieniu od incydentów czysto „aplikacyjnych”, tutaj o skuteczności ataku przesądził kompromitowany dostęp perymetryczny (SSLVPN) i sekrety MFA, co wpisuje się w ewolucję ransomware: logowanie jak „prawowity” użytkownik, szybki rekonesans/eskalacja, exfiltracja, a dopiero potem szyfrowanie/okup. Dodatkowo, z racji roli Marquis jako vendora dla setek podmiotów, powstał efekt kaskadowy – wiele odrębnych notyfikacji w stanach, choć incydent źródłowo dotyczył jednego środowiska.
Podsumowanie / kluczowe wnioski
Incydent w Marquis to kolejny case łańcucha dostaw – pojedynczy vendor = dziesiątki dotkniętych instytucji i setki tysięcy osób.
Wektor wejścia koreluje z kampaniami przeciw SonicWall (CVE-2024-40766) i przejętymi sekretami MFA, co potwierdza, że samo „MFA” nie wystarczy bez rotacji seedów i pełnego „credential hygiene”.
Priorytetem jest rotacja wszystkich sekretów związanych z perymetrem, twarde MFA (FIDO2), pełne logowanie i monitoring dostępu VPN oraz dojrzały program vendor-risk.
Źródła / bibliografia
BleepingComputer: „Marquis data breach impacts over 74 US banks, credit unions”, 3 grudnia 2025. (BleepingComputer)
Reuters: „Fintech firm Marquis notifies affected business after ransomware breach”, 3 grudnia 2025. (Reuters)
Maine AG – rekord „Marquis Management LLC” (Data Breach Notifications). (maine.gov)
New Hampshire AG – pismo CoVantage CU dot. incydentu u Marquis (PDF). (mm.nh.gov)
SonicWall / NVD – CVE-2024-40766 (opis i zalecenia) oraz advisory o korelacji incydentów SSLVPN. (NVD)
Japoński detalista i operator platform e-commerce Askul (m.in. Askul, Lohaco, Soloel Arena) 19 października 2025 r. padł ofiarą ataku ransomware, który wywołał szeroką awarię systemów i zatrzymał nowe zamówienia oraz wysyłki. Po ~6 tygodniach przestoju firma wznowiła limitowane przyjmowanie zamówień online, zapowiadając stopniowe przywracanie usług.
W skrócie
Data incydentu: 19 października 2025 r. (wykrycie i odcięcie systemów).
Aktualny status: ograniczone wznowienie przyjmowania zamówień online; pełne przywrócenie ma następować stopniowo, Lohaco dla klientów indywidualnych ruszy później.
Komunikaty spółki: oficjalne zawiadomienia giełdowe i raporty incydentowe (EN) potwierdzają ransomware i działania naprawcze.
Kontekst / historia / powiązania
Atak na Askul wpisuje się w falę destrukcyjnych kampanii ransomware wymierzonych w duże japońskie firmy w 2025 r. (np. Asahi). W efekcie łańcuchy dostaw i sprzedaż online w Japonii były w ostatnich tygodniach szczególnie podatne na zakłócenia.
Analiza techniczna / szczegóły incydentu
Wektor i efekt: w oficjalnych raportach Askul potwierdził infekcję ransomware i odcięcie systemów w celu ograniczenia propagacji. Skutkiem był paraliż zamówień, logistyki i części procesów back-office.
Zakres usług: wstrzymane zostały trzy główne serwisy (Askul – B2B, Lohaco – B2C, Soloel Arena – klienci korporacyjni).
Odbudowa: po 45 dniach firma zaczęła stopniowo odblokowywać funkcje zakupowe (najpierw B2B), utrzymując ograniczenia asortymentu i przepustowości.
Uwaga: na moment publikacji brak jednoznacznego, oficjalnego wskazania grupy odpowiedzialnej w komunikatach Askul; doniesienia branżowe o potencjalnej afiliacji traktujemy jako niepotwierdzone i dlatego nie opieramy na nich wniosków. (Stan na 4 grudnia 2025 r.)
Praktyczne konsekwencje / ryzyko
Operacje i przychody: długi przestój (ponad 6 tygodni) oznacza realne straty sprzedaży i koszty odtworzenia usług, a także ryzyko opóźnień dostaw do partnerów-sprzedawców.
Łańcuch dostaw: atak na dostawcę/logistykę uderza w marki zależne od infrastruktury Askul (efekt kaskadowy).
Ryzyko wtórne: możliwość wycieku danych i nadużyć (phishing na bazie historii zamówień/zwrotów) – brak jest jednak publicznych potwierdzeń skali wycieku w oficjalnych raportach giełdowych spółki w chwili obecnej.
Rekomendacje operacyjne / co zrobić teraz
Dla firm współpracujących z Askul (sprzedaż/zakupy/logistyka):
Segmentuj ryzyko dostawcy: tymczasowo wprowadź podwójne ścieżki zamówień (drugi operator / manualne obejścia) i limity wolumenów do czasu pełnej stabilizacji.
Weryfikuj komunikację: potwierdzaj zmiany kont płatniczych, terminy dostaw i RMA kanałem niezależnym (voice back).
Monitoruj kompromitację: wdroż brand & supply-chain monitoring (np. wzmianki o Twojej domenie/markach w kampaniach phishing).
Twarde SLA i runbooki: dopisz do umów z dostawcami RTO/RPO, zasady tabletopów i wspólne testy odtwarzania.
Dla zespołów bezpieczeństwa:
Segmentacja i „kill switch”: mikrosegmentacja sieci, listy blokad lateral movement (SMB, RDP), oraz gotowy do użycia playbook izolacji.
Backupy testowane pod presją czasu: polityka 3-2-1 + testy bare-metal restore i recovery aplikacji z zależnościami (DB, kolejki, pliki).
EDR + zasady blokady makr/skryptów: wzmocniona telemetria, kontrola PowerShell/WSH, ASR/WDAC, blokowanie wbudowanych narzędzi (LOLBins).
MFA/PAM dla kont serwisowych: rotacja tajemnic i just-in-time access dla adminów oraz integracji B2B.
Ćwiczenia z komunikacji kryzysowej: gotowe szablony do klientów/partnerów i spójny kanał statusowy.
Różnice / porównania z innymi przypadkami
Askul (handel, platformy e-commerce): silny efekt łańcucha dostaw (partnerzy, marki zależne), długi czas odbudowy funkcji sprzedażowych.
Asahi (produkcja FMCG): równoległy trend w Japonii – zakłócenia logistyki i potencjalne naruszenia danych na dużą skalę, ale inna branża i profil systemów OT/ERP. (Kontekst do fali ataków w kraju).
Podsumowanie / kluczowe wnioski
Atak ransomware na Askul potwierdza, że dostawcy logistyczno-e-commerce są dziś jednymi z najbardziej krytycznych „punktów nacisku” w łańcuchach dostaw.
Czas odtworzenia (RTO) liczony w tygodniach nie jest wyjątkiem – plany ciągłości działania muszą przewidywać manualne obejścia i alternatywnych operatorów.
Transparentne raportowanie i stopniowy powrót do pełni usług sugerują, że odporność operacyjna staje się równie ważna jak sama prewencja.
Źródła / bibliografia
The Record: wstrzymanie usług po ataku (20.10.2025) oraz wznowienie ograniczonego przyjmowania zamówień (04.12.2025). (The Record from Recorded Future)
Oficjalny raport ASKUL do inwestorów (EN), 20.10.2025 (ransomware i działania naprawcze). (Yahoo Finance)
The Register: powrót sprzedaży online po 45 dniach od ataku. (The Register)
The Japan Times: wznowienie przyjmowania zamówień i kolejność przywracania serwisów (B2B przed B2C/Lohaco). (The Japan Times)
Po „nietypowej wypłacie” z gorącego portfela Upbit — największej giełdy krypto w Korei Południowej — urzędnicy państwowi wskazali na północnokoreańską grupę Lazarus jako prawdopodobnego sprawcę. Według doniesień, napastnicy wyłudzili lub przejęli uprawnienia administracyjne i wytransferowali ok. 44,5 mld KRW (~30 mln USD), po czym giełda zamroziła depozyty i wypłaty oraz przeniosła środki do cold walletów. Upbit zapowiedział pokrycie strat klientów.
W skrócie
Cel: Upbit (Korea Płd.), gorący portfel.
Skala: ~30 mln USD wyprowadzonych aktywów.
Atrybucja wstępna: TTP wskazujące na Lazarus (KR/DPRK).
Działania obronne: wstrzymanie operacji on-chain, migracja do cold wallet, próby zamrożenia części środków.
Tło rynkowe: dzień wcześniej Naver Financial ogłosił przejęcie operatora Upbit (Dunamu) za ~10 mld USD; w toku incydentu odnotowano „abnormal withdrawal”.
Kontekst / historia / powiązania
Upbit był już celem głośnego włamania w 2019 r. (342k ETH, ~42–49 mln USD wówczas), które południokoreańska policja w 2024 r. formalnie powiązała z północnokoreańskimi grupami Lazarus/Andariel. Bieżący atak ma „podobny podpis” do sprawy z 2019 r., co wzmocniło hipotezę o DPRK.
W skali globalnej DPRK-APT (m.in. Lazarus/APT38) odpowiadały w ostatnich latach za rekordowe kradzieże krypto – np. Bybit, luty 2025: ~1,5 mld USD, oficjalnie wskazane przez FBI jako operacja powiązana z „TraderTraitor”.
Analiza techniczna / szczegóły luki
Wektor wejścia. Według urzędników napastnicy „podszyli się pod administratorów” Upbit i zainicjowali transfery, co sugeruje kompromitację kont uprzywilejowanych (phishing/OAuth/SSO abuse, kradzież kluczy) lub obejście kontroli transakcyjnych w hot walletach. Ten modus operandi — nadużycie tożsamości adminów i szybkie odprowadzenie środków do mieszarek/chain hopping — był wielokrotnie obserwowany przy operacjach Lazarusa.
Łańcuchy prania. Historycznie Lazarus stosował segmentację przepływów, równe porcjowanie transakcji, cross-chain swapy i miksery (np. Sinbad / wcześn. Blender), co odnotowywały firmy analityczne i organy ścigania. W sprawie Upbit śledczy próbowali śledzić i zamrażać fragmenty środków już w pierwszej dobie.
Wskaźniki i TTP (przykładowe):
Impersonacja admina / kradzież sesji / złośliwe podpisy transakcyjne (blind-signing) – technika używana także w Bybit 2025.
Porcjowanie wypłat na powtarzalne kwoty i wielowarstwowe miksy.
Praktyczne konsekwencje / ryzyko
Ryzyko dla użytkowników: krótkoterminowe wstrzymania wypłat/depozytów, opóźnienia w rozliczeniach i możliwe skoki fee. Upbit deklaruje pokrycie strat, ale presja płynnościowa może utrzymywać się do czasu pełnej rekonsyliacji.
Ryzyko systemowe: ataki na warstwę operacyjną giełd (tożsamość i uprawnienia) omijają typowe zabezpieczenia smart-kontraktów.
Ryzyko regulacyjne: nowe wytyczne dot. kluczy admina, cold-/warm-wallet policy, obowiązkowe „withdrawal throttling” i adresy-dozwolone (allowlist) są coraz bardziej prawdopodobne po serii incydentów 2024–2025. Trend potwierdza skala Bybit 2025 i statystyki DPRK z raportów analitycznych.
Rekomendacje operacyjne / co zrobić teraz
Dla giełd i kustodianów
Zerowy zaufanie dla operacji admina: U2F/WebAuthn + FIDO2 dla kont uprzywilejowanych, polityka „two-person rule” dla podpisów > X USD i obowiązkowe timelocki dla wypłat z hot/warm walleta.
Segmentacja kluczy i horyzontów czasowych: dziel klucze na role (init/sign/approve), ogranicz okna ważności sesji i stosuj „just-in-time access”.
Automatyczne reguły AML on-chain: blokady heurystyczne na znane węzły prania DPRK, eskalacja KYC i natychmiastowe freeze requesty do partnerów.
Runbooki kryzysowe: gotowe playbooki z listą kontaktów (LEA, analityka blockchain, giełdy partnerskie), „war room” i wstępnie uzgodnione komunikaty.
Monitoring nieinteraktywny kluczy: HSM + polityki nieopuszczania klucza, separacja środowisk podpisu, detekcja anomalii w patternach wypłat (równe porcje, cicliczne batch’e).
Ćwiczenia red-team/blue-team z scenariuszem DPRK TraderTraitor.
Dla użytkowników
Trzymaj większe środki w self-custody (hardware wallet), włącz allowlisty adresów i limity dobowych wypłat.
Weryfikuj komunikaty giełdy wyłącznie w oficjalnych kanałach i wstrzymaj się z dużymi transferami, dopóki giełda nie zakończy pełnej rekonsyliacji po incydencie.
Różnice / porównania z innymi przypadkami
Upbit 2019 vs. Upbit 2025: wspólne elementy to atak na warstwę operacyjną giełdy i wzorce wypłat przypisywane DPRK; różni się skala (2019: ~42–49 mln USD, 2025: ~30 mln USD) oraz dojrzałość mechanizmów zamrażania środków.
Bybit 2025 (1,5 mld USD): inny profil — manipulacja procesem podpisu (blind-signing) i największa znana pojedyncza kradzież, oficjalnie przypisana DPRK przez FBI; pokazuje eskalację zdolności napastnika.
Podsumowanie / kluczowe wnioski
Wstępna atrybucja do Lazarus (KR) jest spójna z historią ataków na Upbit i globalną aktywnością DPRK w 2024–2025.
Wektor tożsamościowy/administracyjny pozostaje najsłabszym ogniwem dużych giełd — „smart” kontrola wypłat musi iść w parze z twardymi procedurami dla kont uprzywilejowanych.
Rynek powinien traktować runbooki incident-response i automatyczne freeze’y jako standard branżowy.
Statystyki z 2024–2025 (1,34 mld USD skradzione przez KR-APT w 2024; 1,5 mld USD w pojedynczym incydencie 2025) wskazują, że ryzyko systemowe nie maleje mimo spadku części wskaźników rynkowych.
Źródła / bibliografia
The Record: „Officials accuse North Korea’s Lazarus of $30 million theft from crypto exchange” (01.12.2025). (The Record from Recorded Future)
Reuters: „Naver’s payment arm to acquire Dunamu (Upbit) in $10 bln deal” + wzmianka o „abnormal withdrawal” (27.11.2025). (Reuters)
Reuters (za Yonhap): „South Korea suspects North Korea behind hack of crypto exchange Upbit” (28.11.2025). (Reuters)
Chainalysis: „Bybit hack… DPRK stole ~$1.34B across 47 incidents in 2024” (24.02.2025). (Chainalysis)
Co można zrobić po przeskanowaniu sieci i znalezieniu otwartych portów HTTP/HTTPS? Załóżmy, że Nmap pokazał nam hosty nasłuchujące na porcie 80 lub 443 – chcemy teraz szybko sprawdzić, jakie aplikacje webowe tam działają. Oczywiście można ręcznie wklepać każdy adres w przeglądarce, ale inżynierska ciekawość i lenistwo podsuwają lepsze rozwiązanie: użyjmy możliwości Nmap Scripting Engine (NSE).
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.