Archiwa: Firewall - Strona 15 z 24 - Security Bez Tabu

WatchGuard ostrzega przed aktywnie wykorzystywaną luką RCE w Firebox (CVE-2025-14733)

Wprowadzenie do problemu / definicja luki

WatchGuard opublikował ostrzeżenie dotyczące krytycznej podatności umożliwiającej zdalne wykonanie kodu (RCE) w zaporach Firebox. Luka została oznaczona jako CVE-2025-14733 i dotyczy komponentu iked w systemie Fireware OS (obsługa negocjacji IKE/IPsec, w szczególności IKEv2). Co ważne: producent potwierdził próby aktywnej eksploatacji „w naturze” (in the wild).

Z perspektywy obrony sieciowej to „klasa” podatności, której nie można traktować jak typowego błędu aplikacyjnego: przejęcie firewalla/VPN gatewaya często oznacza przejęcie „najbardziej uprzywilejowanego” punktu w infrastrukturze.


W skrócie

  • CVE: CVE-2025-14733
  • Typ: Out-of-bounds write → potencjalne RCE bez uwierzytelniania (pre-auth) w procesie iked
  • Warunki narażenia: konfiguracje Mobile User VPN (IKEv2) oraz Branch Office VPN (IKEv2) z dynamic gateway peer; dodatkowo podatność może się utrzymywać nawet po usunięciu konfiguracji (patrz sekcja techniczna).
  • Skala: dotyczy wielu gałęzi Fireware (11.x, 12.x, 2025.1) i szerokiej gamy modeli Firebox (w tym wirtualnych/chmurowych)
  • Ocena: WatchGuard podaje CVSS 9.3 (CVSS v4), a NVD prezentuje także CVSS 3.1 = 9.8.
  • Fix: aktualizacja do wersji naprawionych (m.in. 2025.1.4, 12.11.6, 12.5.15, 12.3.1 Update 4) – szczegóły niżej.
  • Sygnały ataku (przykłady): nietypowe logi IKE_AUTH/certyfikatów oraz zawieszenia/crashe procesu iked; WatchGuard opublikował też IP powiązane z aktywnością atakujących.
  • KEV: CISA poinformowała o dodaniu CVE-2025-14733 do katalogu Known Exploited Vulnerabilities (KEV).

Kontekst / historia / powiązania

Wątek „RCE w IKE/IKEv2 na bramach VPN” wraca cyklicznie w branży – jest to atrakcyjny wektor, bo usługa VPN bywa wystawiana do internetu i obsługuje złożone formaty danych (negocjacje, certyfikaty, payloady). W przypadku WatchGuard warto zauważyć, że firma wcześniej łatała bardzo podobny problem RCE w Firebox (CVE-2025-9242), a później obserwowano dużą liczbę urządzeń pozostających podatnych.

Dla obrony oznacza to jedno: nawet jeśli Twoja organizacja „zwykle patchuje”, urządzenia brzegowe trzeba traktować jako absolutny priorytet (bo okno pomiędzy publikacją poprawek a masową eksploatacją bywa krótkie).


Analiza techniczna / szczegóły luki

Co dokładnie jest podatne?

Podatność jest opisana jako out-of-bounds write w procesie iked w WatchGuard Fireware OS. Taki błąd to w praktyce korupcja pamięci, która w sprzyjających warunkach może prowadzić do wykonania kodu (RCE).

Jakie konfiguracje są krytyczne?

WatchGuard wskazuje, że problem dotyczy:

  • Mobile User VPN z IKEv2, oraz
  • Branch Office VPN z IKEv2 skonfigurowanych z dynamic gateway peer.

Istotny „haczyk”: jeśli Firebox wcześniej miał skonfigurowany Mobile User VPN IKEv2 lub BOVPN IKEv2 do dynamicznego peera, a potem te wpisy usunięto, urządzenie wciąż może pozostać podatne, jeżeli nadal skonfigurowany jest BOVPN do static gateway peer. To sugeruje, że sama „czystość” konfiguracji w GUI nie zawsze domyka powierzchnię ataku (np. pozostają aktywne ścieżki kodu/usługi).

Wersje podatne i wersje naprawione

Zgodnie z opisem producenta oraz wpisem w NVD, podatne są m.in. zakresy:

  • 11.10.2 → 11.12.4_Update1
  • 12.0 → 12.11.5
  • 2025.1 → 2025.1.3

Wersje naprawione (wg tabeli „Resolution” WatchGuard):

  • 2025.1 → 2025.1.4
  • 12.x → 12.11.6
  • 12.5.x (modele T15 i T35) → 12.5.15
  • 12.3.1 (FIPS) → 12.3.1_Update4 (B728352)
  • 11.x → End of Life (czyli bez dalszych poprawek).

IOC/IoA – jak wygląda telemetria ataków?

WatchGuard opublikował „Indicators of Attack”, które są szczególnie przydatne operacyjnie, bo pozwalają szybciej triagować incydent:

Adresy IP powiązane z aktywnością atakujących – WatchGuard podkreśla, że połączenia wychodzące do tych IP są mocnym wskaźnikiem kompromitacji, a przychodzące mogą sugerować rekonesans/eksploatację:

  • 45.95.19[.]50
  • 51.15.17[.]89
  • 172.93.107[.]67
  • 199.247.7[.]82

Przykładowe logi IKE (IoA):

  • komunikat o zbyt długim łańcuchu certyfikatów („…longer than 8…”) przy IKE2 Auth payload z >8 certyfikatami, oraz
  • log IKE_AUTH z nienaturalnie dużym CERT payload (wskazany próg >2000 bajtów).

Zachowanie urządzenia (telemetria):

  • podczas udanej eksploatacji proces iked może się zawieszać (zrywanie negocjacji/rekey),
  • po próbie udanej lub nieudanej proces iked może crashować i generować fault report.

Praktyczne konsekwencje / ryzyko

Jeśli atakujący uzyska możliwość zdalnego wykonania kodu na firewallu/VPN gatewayu, konsekwencje zwykle wykraczają poza „jeden serwer mniej”:

  • przejęcie punktu styku z internetem (brzeg infrastruktury),
  • pivot do sieci wewnętrznej i segmentów „za firewallem”,
  • potencjalna manipulacja regułami, trasowaniem, a nawet obserwacja/zakłócanie tuneli VPN,
  • ryzyko kradzieży danych uwierzytelniających przechowywanych lokalnie oraz eskalacji do domeny/SSO (zależnie od integracji). (To są typowe scenariusze dla kompromitacji bram VPN; konkretne kroki zależą od tego, co napastnik zrobi po uzyskaniu kontroli).

NHS England ocenia dalszą eksploatację jako prawdopodobną i rekomenduje pilne zastosowanie poprawek zgodnie z advisory producenta.


Rekomendacje operacyjne / co zrobić teraz

Poniżej checklista „co robić dziś”, ułożona pod realia SOC/infra.

1) Patch (priorytet #1)

  • Zidentyfikuj wersje Fireware w całej flocie (również instancje wirtualne/chmurowe).
  • Aktualizuj do wersji naprawionych: 2025.1.4 / 12.11.6 / 12.5.15 / 12.3.1_Update4 (zgodnie z gałęzią).
  • Jeśli masz 11.x – to EOL. Tu „patch” może oznaczać migrację/upgrade sprzętu/wersji, bo poprawki nie będą dostępne.

2) Ogranicz ekspozycję IKEv2 (jeśli musisz chwilę poczekać z patchem)

Jeśli z powodów operacyjnych patchowanie wymaga okna serwisowego:

  • ogranicz dostęp do usług VPN/IKEv2 tylko do zaufanych adresów/peerów (polityki/ACL, geofencing jeśli pasuje do profilu ryzyka),
  • przejrzyj konfiguracje dynamic gateway peer i usuń/wyłącz nieużywane,
  • rozważ czasowe wyłączenie najbardziej ryzykownych ścieżek (zależnie od tego, jak masz zestawione BOVPN).

WatchGuard opisuje też tymczasowe działania dla środowisk z BOVPN, gdy nie da się natychmiast zaktualizować (m.in. wyłączenie dynamic peer BOVPN i korekta polityk).

3) Hunting/IR: sprawdź IoA/IOC

  • Przeskanuj logi pod kątem komunikatów o „peer certificate chain > 8” oraz IKE_AUTH z dużym CERT payload.
  • Sprawdź firewall/flow/EDR/NDR pod kątem połączeń wychodzących do wskazanych IP (to ma być „mocny” sygnał kompromitacji).
  • Zwróć uwagę na nietypowe crashe/zawieszenia iked (zrywanie renegocjacji, rekey, fault reports).

4) Rotacja sekretów po wykryciu śladów aktywności

Jeśli potwierdzisz podejrzaną aktywność/kompromitację, producent rekomenduje rotację lokalnie przechowywanych sekretów na podatnych urządzeniach (PSK, hasła, klucze/certy – zależnie od użycia).

5) Priorytetyzacja ryzyka

CISA sygnalizuje, że CVE-2025-14733 trafiło do katalogu KEV, co w praktyce oznacza: „to nie jest teoretyczne, to jest wykorzystywane”. W wielu organizacjach to automatycznie powinno podbić priorytet w procesie zarządzania podatnościami.


Różnice / porównania z innymi przypadkami

Najbliższym punktem odniesienia jest wspomniana wcześniej podatność CVE-2025-9242 – również dotycząca Firebox/Fireware i również opisywana jako bliska „rodzina” problemów RCE w okolicach IKE/iked. BleepingComputer zwraca uwagę, że obecna luka pojawia się niedługo po tamtym incydencie i że historycznie liczba niezałatanych urządzeń bywała wysoka.

Wniosek praktyczny: jeśli w Twojej organizacji Firebox jest traktowany jako „appliance, którego nie ruszamy”, to jest dokładnie ten moment, by zmienić podejście (SLA na łatki dla edge).


Podsumowanie / kluczowe wnioski

  • CVE-2025-14733 to krytyczna, aktywnie wykorzystywana podatność typu out-of-bounds write w iked (IKEv2) w WatchGuard Fireware OS, umożliwiająca pre-auth RCE.
  • Ryzyko dotyczy szerokiego spektrum wersji i urządzeń; szczególnie problematyczne są środowiska na 11.x (EOL).
  • WatchGuard udostępnił konkretne IoA (logi, zachowanie procesu, IP), które warto natychmiast wykorzystać w SOC.
  • Najszybsza i najpewniejsza droga redukcji ryzyka to aktualizacja do wersji naprawionych i ograniczenie ekspozycji IKEv2 tam, gdzie to możliwe.

Źródła / bibliografia

  1. WatchGuard PSIRT – WGSA-2025-00027 (CVE-2025-14733, wersje podatne/naprawione, IoA/IOC). (WatchGuard)
  2. BleepingComputer – informacja o aktywnej eksploatacji, kontekst (m.in. CVE-2025-9242) i działania tymczasowe. (BleepingComputer)
  3. NVD (NIST) – wpis CVE (opis, zakres wersji, metryki, daty publikacji). (nvd.nist.gov)
  4. NHS England Digital – alert o eksploatacji i zalecenia remediacji. (NHS England Digital)
  5. CISA Cyber (X) – komunikat o dodaniu CVE-2025-14733 do KEV. (X (formerly Twitter))

Ponad 25 tys. urządzeń Fortinet z włączonym FortiCloud SSO wystawionych na zdalne ataki – co oznaczają CVE-2025-59718 i CVE-2025-59719

Wprowadzenie do problemu / definicja luki

W grudniu 2025 r. zwrócono uwagę na bardzo niebezpieczny scenariusz: tysiące urządzeń Fortinet (m.in. FortiOS/FortiGate, FortiProxy, FortiSwitchManager oraz FortiWeb) ma włączoną funkcję “Allow administrative login using FortiCloud SSO” i jednocześnie wystawiony na Internet panel administracyjny. Internetowe skany wskazały ponad 25 000 takich adresów IP, co przy aktywnych próbach nadużyć przekłada się na realne ryzyko przejęcia kont administracyjnych i wycieku konfiguracji.

Rdzeniem problemu są dwie podatności:

  • CVE-2025-59718 – dotyczy wielu produktów (w praktyce: FortiOS/FortiProxy/FortiSwitchManager) i pozwala ominąć uwierzytelnianie FortiCloud SSO,
  • CVE-2025-59719 – analogiczny wektor dla FortiWeb.

W obu przypadkach chodzi o błędną weryfikację podpisu kryptograficznego w przepływie SAML (klasa błędu CWE-347), co umożliwia atakującemu obejście logowania SSO bez posiadania prawidłowych poświadczeń.


W skrócie

  • Skala ekspozycji: Shadowserver raportował >25 tys. IP z “odciskiem” FortiCloud SSO; w samych USA ~5,4 tys., w Indiach ~2 tys.
  • Aktywne nadużycia: Arctic Wolf obserwował intruzje z użyciem “malicious SSO logins” od 12 grudnia 2025.
  • Typowy ciąg ataku: udane logowanie admin przez SSO → eksport/ściągnięcie pliku konfiguracji przez GUI.
  • Priorytet naprawy: CISA dodała CVE-2025-59718 do KEV 16 grudnia 2025, a w NVD widać termin działań do 23 grudnia 2025 (kontekst KEV).

Kontekst / historia / powiązania

Warto podkreślić jedną rzecz, która ułatwia przeoczenie ryzyka w organizacjach: FortiCloud SSO nie musi być włączone “od zawsze”.

CERT Polska zwraca uwagę, że funkcja jest domyślnie wyłączona, ale w praktyce bywa automatycznie włączana podczas rejestracji urządzenia w FortiCare z poziomu GUI, jeśli administrator nie odznaczy odpowiedniej opcji.

W tym samym czasie (grudzień 2025) obserwujemy typowy “pattern” dla urządzeń brzegowych (edge): szybkie przejście od publikacji poprawek do masowych skanów i prób nadużyć, szczególnie gdy panel administracyjny jest dostępny z Internetu. W omawianym incydencie potwierdzono także, że liczba instancji z włączonym SSO i widocznym GUI jest zaskakująco duża.


Analiza techniczna / szczegóły luki

Na czym polega podatność?

Z technicznego punktu widzenia obie podatności sprowadzają się do tego, że urządzenie akceptuje spreparowaną odpowiedź SAML w procesie FortiCloud SSO, ponieważ weryfikacja podpisu kryptograficznego jest niewłaściwa (CWE-347). Skutkiem jest obejście uwierzytelniania – atakujący może uzyskać sesję administracyjną bez prawidłowego logowania.

Co robią atakujący w praktyce?

BleepingComputer oraz Arctic Wolf opisują spójny schemat:

  1. logowanie do panelu jako admin metodą SSO z nietypowego adresu źródłowego,
  2. następnie akcja przez GUI typu download/export system configuration,
  3. a dalej – analiza konfiguracji (interfejsy, polityki, usługi wystawione na Internet, hashe haseł).

Arctic Wolf opublikował też przykładowe adresy źródłowe (IOC) powiązane z obserwowanymi, złośliwymi logowaniami SSO oraz wskazał, że ruch pochodził z wybranych dostawców hostingu.

Jakie wersje są podatne i jakie są “fixed”?

Kanadyjskie Cyber Centre podaje jednoznacznie, do jakich wersji należy zaktualizować systemy (przykłady):

  • FortiOS: 7.6.4+, 7.4.9+, 7.2.12+, 7.0.18+
  • FortiProxy: 7.6.4+, 7.4.11+, 7.2.15+, 7.0.22+
  • FortiSwitchManager: 7.2.7+, 7.0.6+
  • FortiWeb: 8.0.1+, 7.6.5+, 7.4.10+

Praktyczne konsekwencje / ryzyko

Najbardziej “toksyczny” element tego typu incydentów to pobranie konfiguracji. Taki plik potrafi ujawnić:

  • topologię i podsieci (network layout),
  • reguły firewall / polityki,
  • listę usług wystawionych na Internet,
  • konta administracyjne i artefakty uwierzytelniania (w tym hashe, które w sprzyjających warunkach da się łamać offline).

W praktyce oznacza to, że nawet jeśli atakujący “tylko” zaloguje się i ściągnie konfigurację, konsekwencje mogą być długofalowe: dalsza eskalacja, pivot do sieci wewnętrznej, przygotowanie kampanii ransomware albo trwałe utrzymanie dostępu.


Rekomendacje operacyjne / co zrobić teraz

Poniżej playbook w kolejności, która zwykle działa najlepiej operacyjnie:

  1. Zidentyfikuj ekspozycję GUI
    • Czy panel administracyjny (HTTPS/GUI) jest dostępny z Internetu?
    • Jeśli tak: ogranicz dostęp (VPN / allowlista / segmentacja), zanim przejdziesz dalej.
  2. Natychmiast aktualizuj do wersji naprawionych
    • Kieruj się listą “Solution/Upgrade to …” podaną przez Cyber Centre (sekcja powyżej).
  3. Tymczasowo wyłącz logowanie FortiCloud SSO (jeśli nie możesz od razu zaktualizować)
    • CERT Polska oraz Arctic Wolf wskazują możliwość wyłączenia FortiCloud SSO także z CLI:config system global set admin-forticloud-sso-login disable end
  4. Sprawdź logi pod kątem wzorca nadużycia
    • Szukaj zdarzeń typu “admin login successful” z metodą sso oraz krótkiej sekwencji działań administracyjnych po logowaniu (np. pobranie konfiguracji przez GUI).
    • Porównaj adresy źródłowe z IOC publikowanymi przez Arctic Wolf.
  5. Higiena poincydentowa (jeśli widzisz oznaki kompromitacji)
    • rotacja haseł admin, przegląd kont i uprawnień,
    • weryfikacja zmian w konfiguracji i regułach,
    • jeśli plik konfiguracyjny mógł wyciec: traktuj to jako wyciek informacji wrażliwych i dostosuj model zagrożeń (np. zmiana kluczy/sekretów, przegląd ekspozycji usług).

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

W tym przypadku szczególnie istotne są dwie różnice względem “klasycznych” luk w GUI/SSL-VPN:

  • Warunek aktywacji wektora: atak dotyczy sytuacji, gdy jest włączona funkcja FortiCloud SSO dla logowania administracyjnego (co może się stać “przy okazji” rejestracji w FortiCare).
  • Wektor SAML/SSO: zamiast błędu w endpointach webowych, problem siedzi w obsłudze i weryfikacji SAML, co ułatwia tworzenie “logic exploitów” (obejścia), a niekoniecznie typowych exploitów pamięciowych.

Podsumowanie / kluczowe wnioski

  • Jeśli masz produkty Fortinet i kiedykolwiek rejestrowałeś je w FortiCare, sprawdź, czy nie jest włączone FortiCloud SSO dla logowania admina.
  • Traktuj tę sprawę jako pilną: potwierdzono aktywne nadużycia (od 12 grudnia 2025), a CVE-2025-59718 trafiło do kontekstu KEV (16 grudnia 2025; termin działań do 23 grudnia 2025 w NVD).
  • “Must-have” to: patch + ograniczenie dostępu do GUI + weryfikacja logów pod kątem logowań SSO i eksportów konfiguracji.

Źródła / bibliografia

  1. BleepingComputer – skala ekspozycji i kontekst Shadowserver/SSO fingerprinting (BleepingComputer)
  2. Arctic Wolf – obserwacje nadużyć, IOCs, przykładowe logi oraz wersje naprawione (Arctic Wolf)
  3. CERT Polska (moje.cert.pl) – opis warunku włączenia SSO i rekomendacje + CLI (moje.cert.pl)
  4. NVD (NIST) – opis CVE-2025-59718 oraz adnotacja dot. KEV/due date (nvd.nist.gov)
  5. Canadian Centre for Cyber Security – alert AL25-019 z listą wersji i zaleceń (Canadian Centre for Cyber Security)

Fortinet łata krytyczne luki „FortiCloud SSO login auth bypass” (CVE-2025-59718, CVE-2025-59719). Co musisz zrobić teraz

Wprowadzenie do problemu / definicja luki

Fortinet opublikował poprawki dla dwóch krytycznych podatności, które umożliwiają ominięcie uwierzytelniania FortiCloud SSO w wielu produktach: FortiOS, FortiProxy, FortiSwitchManager (CVE-2025-59718) oraz FortiWeb (CVE-2025-59719). Atak możliwy jest z sieci (bez uwierzytelnienia) poprzez spreparowany komunikat SAML, który zostaje błędnie uznany za prawidłowo podpisany kryptograficznie.

W skrócie

  • Wektor: sieć / brak uwierzytelnienia; ominięcie logowania SSO FortiCloud przez fałszywe odpowiedzi SAML.
  • Produkty: FortiOS, FortiProxy, FortiSwitchManager (CVE-2025-59718) oraz FortiWeb (CVE-2025-59719).
  • Ciężar: CVSS v3.1 9.8 (Critical) (dla CVE-2025-59719 wg NVD).
  • Domyślna ekspozycja: funkcja FortiCloud SSO nie jest domyślnie włączona; może się aktywować w procesie rejestracji do FortiCare, jeśli administrator nie wyłączy przełącznika.
  • Mitigacja natychmiastowa: wyłącz FortiCloud SSO do czasu aktualizacji do wersji niepodatnych.

Kontekst / historia / powiązania

Urządzenia Fortinet są regularnie wykorzystywane w kampaniach APT i ransomware (często jako zero-day). W 2025 r. głośne były m.in. masowe nadużycia błędów FortiWeb (CVE-2025-64446/58034). Dzisiejsze luki w SSO wpisują się w ten trend – funkcje tożsamości i zdalnego zarządzania to atrakcyjny cel dla napastników.

Analiza techniczna / szczegóły luki

Sednem obu CVE jest „improper verification of cryptographic signature” (CWE-347) w ścieżce przetwarzania SAML. Odpowiedź SAML, która powinna być podpisana przez zaufanego IdP, może zostać zaakceptowana mimo fałszerstwa – to prowadzi do ominięcia FortiCloud SSO i uzyskania dostępu administracyjnego.
Zakres wersji podatnych (wybór najważniejszych gałęzi wg NVD / agregatorów):

  • CVE-2025-59718 (FortiOS/FortiProxy/FortiSwitchManager):
    FortiOS 7.6.0–7.6.3, 7.4.0–7.4.8, 7.2.0–7.2.11, 7.0.0–7.0.17;
    FortiProxy 7.6.0–7.6.3, 7.4.0–7.4.10, 7.2.0–7.2.14, 7.0.0–7.0.21;
    FortiSwitchManager 7.2.0–7.2.6, 7.0.0–7.0.5.
  • CVE-2025-59719 (FortiWeb):
    FortiWeb 8.0.0; 7.6.0–7.6.4; 7.4.0–7.4.9.

Fortinet podkreśla, że FortiCloud SSO nie jest włączone w ustawieniach fabrycznych. Włącza się podczas rejestracji do FortiCare, o ile administrator nie odznaczy przełącznika „Allow administrative login using FortiCloud SSO”. To krytyczna informacja dla oceny ekspozycji.

Praktyczne konsekwencje / ryzyko

Jeśli FortiCloud SSO jest aktywne, dowolny z Internetu atakujący może ominąć logowanie i uzyskać pełne uprawnienia administracyjne w dotkniętym urządzeniu (firewall/WAF/proxy/switch manager). To otwiera drogę do:

  • zmiany konfiguracji i reguł filtracji,
  • wdrożenia backdoorów (np. zmian w politykach lub skryptach),
  • pivotu do innych segmentów sieci i eksfiltracji danych.

Rekomendacje operacyjne / co zrobić teraz

  1. Wyłącz FortiCloud SSO (jeśli włączone) natychmiast, a następnie zaplanuj aktualizację do wersji niepodatnych wg PSIRT.
    • GUI: System → Settings → przełącz “Allow administrative login using FortiCloud SSO” na Off.CLI: config system global set admin-forticloud-sso-login disable end
  2. Zaktualizuj FortiOS/FortiProxy/FortiSwitchManager/FortiWeb do wydań z poprawką dla FG-IR-25-647. Gdy strona PSIRT będzie dostępna, zweryfikuj konkretne „Solution” wersje i matryce zgodności.
  3. Przegląd audytowy:
    • Sprawdź, gdzie faktycznie włączono FortiCloud SSO (nie zakładaj ustawień domyślnych po rejestracji do FortiCare).
    • Przejrzyj logi uwierzytelniania i administracyjne pod kątem anomalii (logowania bez korelacji z IdP).
    • Wymuś rotację haseł/tokenów administratorów oraz odśwież SAML metadata na IdP po aktualizacji.
  4. Twardnienie dostępu zarządczego:
    • Ogranicz trusted hosts i segmentację dla interfejsów zarządczych.
    • Wymuś MFA poza SSO (lokalne konto break-glass, out-of-band).
    • Rozważ tymczasowe odseparowanie portów zarządczych od Internetu (VPN z certyfikatami + allow-list).
  5. Atak powierzchniowy – redukcja: jeśli musisz utrzymać SSO, włącz monitoring integralności SAML i alerty korelujące błędy weryfikacji podpisu/issuer.
  6. Zarządzanie ryzykiem dostawcy: uwzględnij nowe CVE w asset discovery i inwentaryzacji – skanery (np. RunZero/Tenable) już wykrywają podatne wersje.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

  • Wcześniejsze głośne incydenty Fortinet (np. FortiWeb CVE-2025-64446) dotyczyły błędów w panelach zarządzania prowadzących m.in. do tworzenia kont admina. Nowe CVE uderzają w warstwę federacji tożsamości (SAML/SSO) – skutkiem jest ominięcie logowania bezpośrednio na bramie, co bywa jeszcze trudniejsze do wykrycia, jeśli logi IdP nie pokazują próby logowania.

Podsumowanie / kluczowe wnioski

  • Dwie krytyczne luki (CVE-2025-59718/59719) pozwalają ominąć FortiCloud SSO w wielu produktach Fortinet.
  • Ekspozycja występuje tylko, gdy FortiCloud SSO jest włączone – ale może zostać automatycznie aktywowane podczas rejestracji do FortiCare, jeśli nie odznaczono przełącznika.
  • Działanie natychmiastowe: wyłącz SSO FortiCloud i aktualizuj do wersji podanych w FG-IR-25-647; zweryfikuj logi i wzmocnij dostęp administracyjny.

Źródła / bibliografia

  1. BleepingComputer – „Fortinet warns of critical FortiCloud SSO login auth bypass flaws”, 9 grudnia 2025. (BleepingComputer)
  2. NVD – CVE-2025-59718 (FortiOS/FortiProxy/FortiSwitchManager): opis i zakres wersji. (NVD)
  3. NVD – CVE-2025-59719 (FortiWeb): opis, CVSS, zakres wersji. (NVD)
  4. Fortinet PSIRT (FG-IR-25-647) – strona doradcza (matryca rozwiązań; chwilowo zdarzają się błędy 5xx). (fortiguard.com)
  5. runZero – szybka identyfikacja aktywów Fortinet dotkniętych CVE-2025-59718/59719 (listy wersji). (runZero)

Cloudflare: globalna awaria spowodowana „React2Shell” — co poszło nie tak i co robić teraz

Wprowadzenie do problemu / definicja luki

5 grudnia 2025 r. Cloudflare doświadczył globalnej degradacji usług po wdrożeniu awaryjnych reguł WAF mających zablokować krytyczną lukę w React Server Components, znaną jako React2Shell (CVE-2025-55182). Błąd umożliwia nieautoryzowane RCE i jest aktywnie wykorzystywany — m.in. przez grupy powiązane z Chinami — co zmusiło dostawców do szybkich (i ryzykownych) mitygacji.

W skrócie

  • Co się stało? Zmiana w sposobie parsowania żądań przez WAF Cloudflare (mitigacje na React2Shell) spowodowała krótki brak dostępności sieci i błędy HTTP 500 na wielu serwisach. Nie był to atak.
  • Kiedy? 5 grudnia 2025 r.; Reuters podaje okno od 08:47 do 09:13 GMT (09:47–10:13 czasu polskiego).
  • Dlaczego tak krytyczne? CVE-2025-55182 ma CVSS 10.0, dotyczy popularnych RSC i jest eksploatowane „w godzinach” od publikacji.
  • Czy są łatki? Tak — zaktualizowano linie React 19.x oraz frameworki korzystające z RSC; Cloudflare ogłosił automatyczne reguły WAF dla klientów.

Kontekst / historia / powiązania

Po ujawnieniu luki 3 grudnia, społeczność dostała zalew PoC-ów, a zespoły threat-intel (m.in. AWS) zaobserwowały szybkie kampanie skanowania i prób eksploatacji przez aktorów państwowych. W odpowiedzi duzi dostawcy (Cloudflare, AWS i inni) wprowadzali protekcje po stronie brzegowej. To wprost poprzedzało piątkową awarię Cloudflare, która — według doniesień głównych mediów — była efektem „twardych” mitygacji, a nie wrogiej akcji.

Analiza techniczna / szczegóły luki

CVE-2025-55182 dotyczy React Server Components (RSC) i błędów logiki w protokole wymiany danych („Flight”), co w pewnych domyślnych konfiguracjach pozwala napastnikowi na zdalne wykonanie kodu bez uwierzytelnienia. Zasięg jest duży, bo RSC są zaadoptowane w popularnych frameworkach (np. Next.js 15/16). Publiczne exploity pojawiły się szybko po disclosure.

Cloudflare 3 grudnia ogłosił, że automatycznie wdrożył reguły WAF chroniące przed atakami na tę klasę błędów — to te reguły, po doraźnych modyfikacjach 5 grudnia, doprowadziły do incydentu dostępności.

Praktyczne konsekwencje / ryzyko

  • Ryzyko natychmiastowe: masowe skanowanie i próby RCE, w tym przez aktorów „China-nexus” wskazanych przez AWS. Ryzyko dotyczy serwisów internetowych korzystających z RSC — nawet jeśli nie wystawiają świadomie endpointów funkcji serwerowych.
  • Ryzyko wtórne (operacyjne): szybkie, globalne mitygacje w WAF/CDN mogą wywołać regresję i niedostępność (jak u Cloudflare), jeśli nie są wdrażane etapowo i z canary/„safe rollout”.

Rekomendacje operacyjne / co zrobić teraz

  1. Patchuj natychmiast: zaktualizuj React 19.x do wersji z poprawką i frameworki wykorzystujące RSC (np. Next.js). Sprawdź noty wydawnicze własnej linii. Równolegle zaimplementuj back-porty, jeśli pełna aktualizacja jest chwilowo niemożliwa.
  2. Włącz/zweryfikuj reguły WAF: upewnij się, że Twoje WAF/CDN (Cloudflare i inne) mają aktywne reguły blokujące wektory React2Shell — oraz że wdrażasz je stopniowo (canary, staged rollout, region-by-region) z telemetrią błędów 4xx/5xx.
  3. Monitoring i detekcja: dodaj reguły wykrywające anomalie w ruchu RSC/Flight (nietypowe nagłówki/ładunki), skoki w odpowiedziach 500 oraz nowe procesy potomne w warstwie aplikacyjnej. Odwołuj się do IOC i wskazówek od vendorów (AWS/Tenable itd.).
  4. Segmentacja i zasada najmniejszych uprawnień: uruchamiaj komponenty serwerowe w izolacji, z minimalnymi uprawnieniami i egress-kontrolą, aby ograniczyć skutki ewentualnego RCE.
  5. Plan awaryjny dla WAF/CDN: procedury „break-glass”, szybki rollback konfiguracji i testy chaos-engineering dla zmian bezpieczeństwa wpływających na ścieżkę danych w produkcji.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

W odróżnieniu od typowych „konfig-awarii” CDN, piątkowy incydent został bezpośrednio wywołany zmianami bezpieczeństwa w reakcji na aktywnie eksploatowaną lukę 0-day-like. Dla porównania, niedawne wcześniejsze awarie Cloudflare (i innych dostawców) wynikały z błędów konfiguracyjnych lub aktualizacji infrastruktury bez presji natychmiastowego zagrożenia. Tutaj presja czasu zwiększyła ryzyko regresji.

Podsumowanie / kluczowe wnioski

  • React2Shell to krytyczny RCE z szybkim „weaponization”; priorytetem są łatki i mitygacje brzegowe.
  • Zmiany bezpieczeństwa też psują — wprowadzaj je kontrolowanie (canary, automatyczny rollback, SLO-aware).
  • WAF ≠ panaceum: konieczne są aktualizacje kodu oraz telemetria wykrywania nadużyć specyficznych dla RSC/Flight.
  • Komunikacja i odporność: ćwicz scenariusze „hot-patch under fire”, aby nie powielać efektu domina z 5 grudnia.

Źródła / bibliografia

  • SecurityWeek: „Cloudflare Outage Caused by React2Shell Mitigations” (5 XII 2025) — potwierdza związek awarii z mitygacjami. (SecurityWeek)
  • Blog Cloudflare: „WAF proactively protects against React vulnerability” (3 XII 2025) — tło mitygacji WAF. (The Cloudflare Blog)
  • Reuters: czas trwania i przyczyna (zmiana firewall/WAF), brak oznak ataku. (Reuters)
  • BleepingComputer: opis błędów 500 i wyjaśnienie Cloudflare po incydencie. (BleepingComputer)
  • AWS Security Blog: obserwacje eksploatacji przez aktorów „China-nexus”. (Amazon Web Services, Inc.)

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)

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”

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.