Archiwa: Admin - Strona 19 z 33 - Security Bez Tabu

Wycieki danych w Marquis uderzają w ponad 74 banki i unie kredytowe w USA

Wprowadzenie do problemu / definicja luki

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):

  1. 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.
  2. 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).
  3. 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ą.
  4. 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

  1. BleepingComputer: „Marquis data breach impacts over 74 US banks, credit unions”, 3 grudnia 2025. (BleepingComputer)
  2. Reuters: „Fintech firm Marquis notifies affected business after ransomware breach”, 3 grudnia 2025. (Reuters)
  3. Maine AG – rekord „Marquis Management LLC” (Data Breach Notifications). (maine.gov)
  4. New Hampshire AG – pismo CoVantage CU dot. incydentu u Marquis (PDF). (mm.nh.gov)
  5. SonicWall / NVD – CVE-2024-40766 (opis i zalecenia) oraz advisory o korelacji incydentów SSLVPN. (NVD)

Askul wznawia ograniczone przyjmowanie zamówień po ataku ransomware: co wiemy i jak reagować

Wprowadzenie do problemu / definicja luki

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).
  • Skala zakłóceń: wstrzymane zamówienia, anulacje wysyłek, niedostępna obsługa klienta; tymczasowo przyjmowano zamówienia… faksem.
  • 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):

  1. 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.
  2. Weryfikuj komunikację: potwierdzaj zmiany kont płatniczych, terminy dostaw i RMA kanałem niezależnym (voice back).
  3. Monitoruj kompromitację: wdroż brand & supply-chain monitoring (np. wzmianki o Twojej domenie/markach w kampaniach phishing).
  4. 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)

Lazarus (KR): urzędnicy łączą $30 mln kradzież z giełdy Upbit z północnokoreańskimi hakerami

Wprowadzenie do problemu / definicja incydentu

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

  1. 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.
  2. 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”.
  3. Automatyczne reguły AML on-chain: blokady heurystyczne na znane węzły prania DPRK, eskalacja KYC i natychmiastowe freeze requesty do partnerów.
  4. Runbooki kryzysowe: gotowe playbooki z listą kontaktów (LEA, analityka blockchain, giełdy partnerskie), „war room” i wstępnie uzgodnione komunikaty.
  5. Monitoring nieinteraktywny kluczy: HSM + polityki nieopuszczania klucza, separacja środowisk podpisu, detekcja anomalii w patternach wypłat (równe porcje, cicliczne batch’e).
  6. Ć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

  1. The Record: „Officials accuse North Korea’s Lazarus of $30 million theft from crypto exchange” (01.12.2025). (The Record from Recorded Future)
  2. Reuters: „Naver’s payment arm to acquire Dunamu (Upbit) in $10 bln deal” + wzmianka o „abnormal withdrawal” (27.11.2025). (Reuters)
  3. Reuters (za Yonhap): „South Korea suspects North Korea behind hack of crypto exchange Upbit” (28.11.2025). (Reuters)
  4. Chainalysis: „Bybit hack… DPRK stole ~$1.34B across 47 incidents in 2024” (24.02.2025). (Chainalysis)
  5. FBI (IC3 PSA): „North Korea Responsible for $1.5 Billion Bybit Hack” (26.02.2025). (Internet Crime Complaint Center)

Rekonesans HTTP/HTTPS W Praktyce: Nmap i skrypty NSE

Od czego zaczyna się rekonesans webowy

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).

Czytaj dalej „Rekonesans HTTP/HTTPS W Praktyce: Nmap i skrypty NSE”

CISA dodaje do KEV aktywnie wykorzystywaną lukę XSS (CVE-2021-26829) w OpenPLC ScadaBR

Wprowadzenie do problemu / definicja luki

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

  1. Natychmiastowa weryfikacja ekspozycji
    • Zidentyfikuj instancje OpenPLC ScadaBR (Windows/Linux) i ich wersje; sprawdź bezpośrednią ekspozycję do Internetu (Shodan/asset inventory).
  2. 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.
  3. 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).
  4. 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”).
  5. 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.
  6. 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)

CVE‑2019‑0708 „BlueKeep”

TL;DR

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łoArtefakt / poleCo obserwowaćWartość dla detekcji
Windows/SystemEvent 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 IPIndykator skanów/nieudanych exploitów BlueKeep; korelować z 3389/TCP i restartami usług.
Windows/Security4624/4625 (LogonType=10)Udane/nieudane logowania RDP; źródłowe IPDo odróżnienia legalnych adminów od zewnętrznych adresów; koreluj z ekspozycją portu.
Windows/TerminalServices‑RemoteConnectionManager/Operational1149„User authentication succeeded” (i czasem niektóre nieudane)Linia czasu sesji RDP; łączyć z 4624 i źródłowym IP.
Windows/System7031 (Service Control Manager)Nieoczekiwane restarty Remote Desktop ServicesCzęsto przy niestabilnych exploitach/handshake’ach; korelować z Event 56 i portem 3389.
EDR„RDP service spawning child”svchost.exe (TermService) → nietypowe dzieci (cmd/powershell)Rzadkie w admin rutynie; mocny sygnał post‑exploitation. (wiedza ogólna)
Sieć/Firewall/ProxyPołączenia TCP/3389 z InternetuNowe źródła, wysokie wolumeny, nietypowe ASNWczesne ostrzeżenie o skanach/atakach.
AWS CloudTrailAuthorizeSecurityGroupIngress (EC2)Reguły SG z 3389 do 0.0.0.0/0Ekspozycja RDP w chmurze (Initial Access/T1190).
Azure ActivityMICROSOFT.NETWORK/NETWORKSECURITYGROUPS/SECURITYRULES/WRITENSG otwierające 3389 na „Internet/Any”Jak wyżej (chmura).
K8s audit / M365[nie dotyczy]

Detekcja (praktyczne reguły)

Sigma (gotowe reguły)

A) TermDD burst — możliwy skan/eksploit BlueKeep

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.
  • Chmura: zdarzenia SG/NSG otwierające 3389 ⇒ natychmiastowe skanowanie Internetu; łączyć z logami RDP.
  • 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)

  1. Triaging & izolacja
  • Odłącz host od sieci lub przełącz do VLAN kwarantanny.
  • Zanotuj netstat -ano | find ":3389" oraz tasklist /svc | find /I "TermService".
  1. Weryfikacja podatności/łatek
  • Sprawdź OS i łatki:
    • Windows 7/2008 R2: Get-HotFix -Id KB4499164,KB4499175
    • Vista/2008: Get-HotFix -Id KB4499180
    • XP/2003: wmic qfe | find "4500331"
      Jeśli brak — patch ASAP (odpowiednie KB dla wydania).
  1. Twardnienie
  • Włącz NLA:
    Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication -Value 1 (restart RDS).
  • Ogranicz 3389 do VPN/jumphost (SG/NSG/Firewall), wyłącz ekspozycję 0.0.0.0/0.
  1. Hunting
  • Przejrzyj Event 56/7031 (skoki), 4624/10 (źródła publiczne), 1149 (osi czasu).
  • Sprawdź anomalia procesów od svchost.exe -k termsvcs i autostarty.
  1. Eradykacja & recovery
  • Zastosuj poprawki, wymuś restart RDS/hosta, zmień hasła adminów, wymuś MFA do zdalnych dostępl.
  1. Lessons learned
  • Segmentacja, JIT RDP (Azure), bastiony, skanowanie podatności.

Przykłady z kampanii / case studies

  • 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):
nmap -Pn -p3389 --script rdp-enum-encryption,rdp-ntlm-info <cel>
  • Generowanie zdarzeń do detekcji: krótka sesja RDP z jump‑hosta (udane/nieudane logowania) → potwierdź 4624/4625(LogonType=10), 1149, brak nadmiarowych 56.

Mapowania (Mitigations, powiązane techniki)

Mitigations (wg MITRE, powiązane z T1210):

  • M1051 Update Software (patch management), M1042 Disable or Remove Feature or Program (wyłącz/ogranicz RDP), M1030 Network Segmentation, M1035 Limit Access to Resource Over Network (gateway/JIT), M1048 Application Isolation/Sandboxing, M1050 Exploit Protection, M1016 Vulnerability Scanning, M1026 Privileged Account Management.

Powiązane techniki ATT&CK:

  • T1133 External Remote Services (ekspozycja zewnętrzna), T1562 (Defense Evasion — wyłączanie zabezpieczeń/NLA), T1112 (Modify Registry), T1021 (Remote Services — rodzina). (mapowanie merytoryczne na podstawie opisów ATT&CK).

Źródła / dalsza literatura

  • Microsoft MSRC: Prevent a worm by updating RDS (CVE‑2019‑0708) — o NLA i „wormowalności”. (Microsoft)
  • Microsoft Support: Customer guidance for CVE‑2019‑0708 — listy platform i KB (w tym EoL). (Microsoft Support)
  • Microsoft KB: KB4499164 (Monthly Rollup Win7/2008 R2), KB4499175 (Security‑only). (Microsoft Support)
  • NVD: CVE‑2019‑0708 (CVSS 9.8, zmiany 2024). (NVD)
  • CISA Advisory AA19‑168A. (CISA)
  • MITRE ATT&CK (v18): T1210, T1021.001, T1190 (wersje i daty). (MITRE ATT&CK)
  • Microsoft Tech Community: TermDD Event ID 56 — protokół RDP error. (TECHCOMMUNITY.MICROSOFT.COM)
  • Unit 42: analiza wewnętrzna RDP/BlueKeep. (Unit 42)
  • Tenable/Microsoft/Kryptos Logic: pierwsze ataki i telemetria. (Tenable®)
  • Informacja kontekstowa o nienarażonych Windows 8/10/11. (Wikipedia)

Checklisty dla SOC / CISO

SOC – codzienna kontrola

  • Alerty na Event 56 (TermDD) bursty + korelacja z 3389/TCP.
  • Monitor 4624/10 i 1149 z publicznych IP; whitelisty dla jump‑hostów.
  • Wykrywanie NLA=OFF (UserAuthentication=0) i zmian SG/NSG otwierających 3389.
  • Regularne skany podatności/asset inventory dla hostów z RDP.

CISO – decyzje i governance

  • Polityka: RDP tylko przez VPN/jumphost/JIT; brak 0.0.0.0/0.
  • SLA na Patch Tuesday + raport KB (KB4499164/KB4499175/KB4499180/KB4500331).
  • NLA wymagane (GPO/Intune), MFA dla zdalnego dostępu.
  • Segmentacja (M1030), regularny red/blue tabletop dla RDP‑borne incydentów.

CVE-2019-11510 → pre‑auth arbitrary file read

TL;DR

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łoPole/artefaktWskaźnikKomentarz
Pulse Secure syslog (Events/User/Admin)log message / URInietypowe żądania do endpointów HTML5 + sekwencje traversalUpewnij się, że eksportujesz syslog (WELF/Custom).
Reverse proxy / WAFURI, query, status, UA, src IPobecność wzorców path traversal, słowa‑klucze związane z HTML5 gatewayDobre miejsce do korelacji i rate‑limitu.
AWS WAF (CloudWatch Logs)httpRequest.uri, action, terminatingRuleIdżądania z ../ i słowami kluczowymi; akcja ALLOW/BLOCKPola wg dokumentacji AWS WAF.
ALB Access Logs (S3)request, elb_status_code, target_status_code200/206 dla nietypowych żądańW połączeniu z WAF daje pełny obraz.
SIEM parsers (Chronicle/QRadar/itd.)Normalizowane pola URLdopasowania na tokenach ścieżki i traversalPrzykłady konfiguracji dla PCS.
ICT (Integrity Checker Tool)wynik skanunowe/zmodyfikowane pliki na urządzeniuDo potwierdzenia kompromitacji obrazu urządzenia.
EID / K8s audit / M365n/dPodatność dotyczy appliance, nie tych źródeł.

Detekcja (praktyczne reguły)

Sigma (web / reverse proxy / WAF)

title: Pulse Connect Secure — CVE-2019-11510 Attempt (Guacamole + Traversal)
id: 1c6d2c1a-7a4e-4b6c-9f0b-3a2c2f7a9f10
status: experimental
logsource:
  category: webserver
  product: proxy
detection:
  sel_dana:
    request|contains:
      - "/dana"
      - "dana-na"
  sel_guac:
    request|contains: "guacamole"
  sel_trav:
    request|contains:
      - "../"
      - "..%2f"
      - "%2e%2e"
  condition: sel_dana and sel_guac and sel_trav
falsepositives:
  - Ruch HTML5 gateway bez traversal (powinien nie zawierać '../')
level: high
tags:
  - attack.t1190
  - cve.2019-11510

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"))

Heurystyki / korelacje

  • URI + traversal + słowo‑klucz (HTML5 gateway) + HTTP 200/206 ⇒ wysoka pewność.
  • 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

  1. 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.
  2. Weryfikacja stanu PCS: uruchom Ivanti Integrity Checker Tool (ICT) (wbudowany lub zewnętrzny) i zarchiwizuj wynik.
  3. Forensyka: zgraj logi (Events/User/Admin), eksport syslog z SIEM, logi WAF/ALB. (Dokumentacja logowania PCS.)
  4. 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.
  5. Reset/rotacja: wymuś reset haseł VPN/AD, rotuj certyfikaty/klucze używane przez PCS, unieważnij aktywne sesje. (Powiązanie z T1552.*).
  6. Hunting post‑exploitation: szukaj logowań z nowych ASN, użycia skradzionych ciasteczek/tokens (T1539), nietypowych mapowań ról.
  7. Twardnienie: stałe reguły WAF blokujące traversal, MFA wszędzie, segmentacja i ograniczenie dostępu do konsoli administracyjnej PCS.
  8. 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.

  1. 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
  1. Weryfikacja detekcji — załaduj logi access.log do SIEM i uruchom reguły z §7.
  2. Test WAF — utwórz regułę blokującą sekwencje traversal i sprawdź, czy zapisy AWS WAF rejestrują akcję BLOCK oraz terminatingRuleId.

Mapowania (Mitigations, powiązane techniki)

Mitigations (ATT&CK Enterprise):

  • M1051 — Update Software (regularne aktualizacje/łaty).
  • M1016 — Vulnerability Scanning (ciągłe skanowanie i priorytetyzacja).
  • M1036 — Account Use Policies (zasady użycia kont, blokady, sesje).
  • M1031/M1037 — Network Intrusion Prevention / Filter Network Traffic (WAF/IPS przed PCS).

Powiązane techniki:

  • T1552.001 — Credentials in Files (wyciek haseł z plików).
  • T1552.004 — Private Keys (eksfiltracja kluczy).
  • T1539 — Steal Web Session Cookie (przejęcie sesji).
  • T1078 — Valid Accounts (logowanie prawdziwymi poświadczeniami).

Źródła / dalsza literatura

  • NVD: szczegóły CVE‑2019‑11510, wersje naprawiające, CVSS, wpis KEV. (NVD)
  • CISA Alert AA20‑010A/AA20‑107A: kontynuowana eksploatacja PCS. (CISA)
  • MITRE ATT&CK T1190: Exploit Public‑Facing Application (mapowanie i przykłady użycia przez grupy). (MITRE ATT&CK)
  • SigmaHQ: detekcja „Guacamole” dla CVE‑2019‑11510. (detection.fyi)
  • Ivanti (PCS/ICS) — logowanie i monitoring; syslog/filtry. (Ivanti Help)
  • AWS WAF — pola logów (httpRequest.*, action, terminatingRuleId). (AWS Documentation)
  • JPCERT/CC: podsumowanie kampanii na Pulse Connect Secure. (JPCERT/CC Eyes)
  • IBM X‑Force / Sophos: REvil/Sodinokibi a wektory VPN. (IBM)
  • Ivanti/CISA — Integrity Checker Tool (ICT) i użycie w dochodzeniach. (CISA)

Checklisty dla SOC / CISO

SOC (operacyjne):

  • Włączony eksport logów PCS (Events/User/Admin) do SIEM.
  • Reguły detekcji z §7 aktywne w web/WAF/ALB.
  • Korelacje: traversal + 200/206 + „Guacamole” + nowe logowania VPN.
  • Lista zaufanych skanerów/ASN w allowlist (redukcja FP).
  • Dashboard „PCS Exploit Attempts” (źródła, URI, status, ASN).

CISO (strategiczne):

  • Potwierdzony patch level PCS ≥ wersje naprawiające.
  • Procedura ICT po każdym incydencie/aktualizacji.
  • Polityka rotacji kluczy/certyfikatów i tokenów SSO przy incydencie (T1552.*).
  • WAF/IPS z regułami traversal przed PCS; dostęp admin tylko z sieci uprzywilejowanej.
  • Regularny VA/PT urządzeń brzegowych (M1016).