Archiwa: VPN - Strona 65 z 81 - Security Bez Tabu

Tag: VPN

ShadowRay 2.0: nowa fala ataków zmienia klastry Ray w koparki kryptowalut

Wprowadzenie do problemu / definicja luki

Trwa globalna kampania „ShadowRay 2.0”, w której napastnicy przejmują publicznie dostępne klastry Ray (open-source framework do skalowania aplikacji AI/Python) i zamieniają je w samopropagującą się infrastrukturę do kopania Monero. Wektor wejścia to nadal sporna, niewyłatania podatność CVE-2023-48022 w API zadań Ray, umożliwiająca zdalne wykonanie kodu bez uwierzytelnienia przy błędnej ekspozycji usług na Internet. Najnowsza fala kampanii rozszerza się poza cryptojacking – obserwowane są kradzieże danych/poświadczeń i funkcje DDoS.

W skrócie

  • Nowa kampania („ShadowRay 2.0”): ta sama luka, bardziej automatyczny łańcuch ataku; self-spread między węzłami/klastrami.
  • Ekspozycja ekosystemu: badacze szacują dziś >230 tys. serwerów Ray widocznych w Internecie (wcześniej „kilka tysięcy”).
  • CVE-2023-48022: zdalne RCE przez Jobs API; ocena CVSS 9.8 (CRITICAL), status „disputed” – twórcy Ray wskazują, że Ray ma działać w „ściśle kontrolowanym środowisku”.
  • Ładunki: generowane z pomocą LLM (charakterystyczne komentarze/docstringi), moduł XMRig ograniczający użycie CPU do ~60%, utrwalanie przez cron/systemd, reverse-shelle i moduł DDoS (Sockstress).
  • Brak łatki: zalecenia to „best practices” Anyscale – uruchomienie w zaufowanej sieci, filtrowanie portu 8265 (Dashboard), autoryzacja przez proxy, monitoring anomalii.

Kontekst / historia / powiązania

Pierwszą kampanię ShadowRay opisano w marcu 2024 r., wskazując aktywne nadużycia od września 2023 r. Wtedy już raportowano setki skompromitowanych klastrów oraz dominujące użycie koparek (XMRig/NBMiner/Zephyr) i reverse-shelli. Jednocześnie Anyscale podtrzymało, że brak wbudowanego uwierzytelniania to decyzja projektowa, a instancje powinny działać w środowiskach kontrolowanych; firma zapowiadała dodanie auth w przyszłych wersjach.

Analiza techniczna / szczegóły luki

CVE-2023-48022 dotyczy Jobs API w Ray i umożliwia zdalne przesłanie/uruchomienie zadań (Bash/Python) bez uwierzytelnienia, jeśli endpointy są wystawione na świat. NVD klasyfikuje lukę jako krytyczną (CVSS 9.8). Brak łatki wynika z modelu zaufania Ray – framework zakłada izolację sieciową i kontrolę dostępu po stronie operatora. W praktyce tysiące wdrożeń są błędnie wystawione (np. 0.0.0.0) lub pozbawione filtracji, co czyni je łatwym celem.

W ShadowRay 2.0 napastnicy (TRACK: IronErn440) korzystają z CVE-2023-48022 do uruchamiania wielostopniowych łańcuchów Bash/Python. Payloady, z oznakami generowania przez LLM, po zainfekowaniu rozsiewają się na wszystkie węzły klastra poprzez natywne mechanizmy orkiestracji Ray, a nawet klaster-do-klastra. Zaobserwowano dwie fale: starszą z dystrybucją przez GitLab (zakończona 5 listopada) i nową przez GitHub (aktywna od 17 listopada).

Moduły złośliwe obejmują:

  • Cryptojacker (XMRig) – wykrywa CPU/GPU, maskuje procesy (np. dns-filter), limity CPU (ok. 60%), zabija konkurencyjne koparki, blokuje pule w /etc/hosts i iptables, utrzymuje persistencję przez cron/systemd.
  • Dostęp interaktywny – wiele reverse-shelli do infrastruktury C2, z możliwością eksfiltracji danych środowisk ML (sekrety, hasła DB, klucze SSH, tokeny usług).
  • DDoS – komponent oparty o Sockstress do wyczerpywania zasobów TCP.

Praktyczne konsekwencje / ryzyko

  • Utrata mocy obliczeniowej (GPU/CPU) i wzrost kosztów chmurowych przez kopanie kryptowalut.
  • Wycieki sekretów produkcyjnych: hasła DB, klucze SSH, tokeny (OpenAI, HuggingFace, Slack, Stripe), dostęp do kube-API – ryzyko lateral movement i kompromitacji danych klientów.
  • Degradacja dostępności: możliwość użycia zasobów do DDoS oraz wpływ na trening/inferencję modeli.

Rekomendacje operacyjne / co zrobić teraz

  1. Nie wystawiaj Ray na Internet: uruchamiaj wyłącznie w zaufowanej, odseparowanej sieci/VPC/VPN; blokuj ruch przychodzący do komponentów Ray (w tym Dashboard :8265) regułami firewall/SG.
  2. Warstwa autoryzacji przed Dashboard/Jobs API: jeżeli dostęp zdalny jest konieczny, zastosuj reverse proxy z uwierzytelnianiem (mTLS/OIDC) i autoryzacją endpointów. Nie wiąż usług na 0.0.0.0.
  3. Higiena sekretów: rotuj poświadczenia (DB/SSH/API), unieważnij tokeny znalezione w logach/środowiskach i wymuś krótkie TTL. (Wnioski z incydentów ShadowRay.)
  4. Monitoring runtime: alertuj na tworzenie nietypowych zadań, reverse-shelle, połączenia do puli Monero, procesy podobne do xmrig, modyfikacje crontab/systemd. (IOC-e i TTP-y opisane przez Oligo.)
  5. Segmentacja i egress control: ogranicz ruch wychodzący z węzłów Ray do niezbędnych destynacji; blokuj znane pule, domeny pastebin/Git* używane w kampanii.
  6. Plan odzyskania: w razie kompromitacji – odseparuj klaster, zbuduj nowy z zaufanych artefaktów, przeprowadź triage sekretów i przegląd dostępu do chmury.
  7. Śledź komunikaty producenta: Anyscale wcześniej sygnalizowało przyszłe wsparcie auth – wdrażaj gdy dostępne; do tego czasu polegaj na izolacji sieci i kontrolach dostępu.

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

W porównaniu z typowymi kampaniami cryptojacking w klastrach kontenerowych, ShadowRay wyróżnia:

  • Wykorzystanie Jobs API Ray jako „legalnego” mechanizmu wykonania kodu (przy błędnej ekspozycji), co utrudnia detekcję przez skanery SAST/kompilacyjne.
  • Szybkie rozprzestrzenianie w obrębie klastra dzięki wbudowanej orkiestracji Ray oraz automatyczne „cluster-to-cluster spreading” w fali 2.0.
  • Ładunki generowane przez LLM (charakterystyczne artefakty w kodzie), co wskazuje na rosnącą automatyzację po stronie atakujących.

Podsumowanie / kluczowe wnioski

  • ShadowRay 2.0 pokazuje, że błędna ekspozycja usług AI to dziś jeden z najbardziej kosztownych błędów operacyjnych.
  • Brak wbudowanego auth w Ray nie jest „bugiem” w rozumieniu vendor-a, ale ryzyko operacyjne – które trzeba neutralizować segmentacją, filtracją i proxy z autoryzacją.
  • Zespoły ML/AI powinny mieć runbook na wypadek kompromitacji klastrów treningowych/inferencyjnych oraz telemetrykę ukierunkowaną na IOC/TTP ShadowRay.

Źródła / bibliografia

  1. BleepingComputer – „New ShadowRay attacks convert Ray clusters into crypto miners” (18 listopada 2025). (BleepingComputer)
  2. Oligo Security – „ShadowRay: First Known Attack Campaign Targeting AI Workloads…” (26 marca 2024). (oligo.security)
  3. NVD (NIST) – wpis CVE-2023-48022 (RCE w Ray Jobs API, CVSS 9.8, status „disputed”). (NVD)
  4. SecurityWeek – „Ray AI Framework Vulnerability Exploited to Hack Hundreds of Clusters” (27 marca 2024). (SecurityWeek)
  5. The Hacker News – „Critical Unpatched Ray AI Platform Vulnerability Exploited for Cryptocurrency Mining” (27 marca 2024). (The Hacker News)

LG Energy Solution potwierdza incydent ransomware w zagranicznym zakładzie. Grupa Akira twierdzi, że ukradła 1,67 TB danych

Wprowadzenie do problemu / definicja luki

LG Energy Solution (LGES), jeden z największych na świecie producentów baterii litowo-jonowych dla pojazdów elektrycznych i magazynów energii, potwierdził atak ransomware na „konkretny zagraniczny zakład”. Spółka poinformowała, że pozostałe lokalizacje, w tym centrala, nie zostały dotknięte, a zaatakowany obiekt wrócił do normalnej pracy po działaniach naprawczych. Firma prowadzi nadal operacje bezpieczeństwa i dochodzenie zapobiegawcze.

Równolegle na serwisach śledzących wycieki pojawiło się przypisanie incydentu do grupy Akira, która utrzymuje, że wykradła około 1,67 TB dokumentów korporacyjnych i ~46 GB baz SQL i grozi publikacją danych. (Twierdzenia przestępców nie zostały niezależnie zweryfikowane przez redakcję w momencie publikacji).

W skrócie

  • Potwierdzenie incydentu: LGES – atak dotyczył jednego zagranicznego zakładu; produkcja przywrócona; trwają działania prewencyjne.
  • Roszczenia przestępców: Grupa Akira przypisuje sobie włamanie i grozi ujawnieniem 1,67 TB danych. (Deklaracje napastników).
  • Szersze tło: Akira jest aktywnie obserwowana przez CISA/FBI/DC3; najnowsza wspólna publikacja ostrzegawcza zawiera aktualne IOC/TTP i zalecenia.
  • Ryzyko sektorowe: potencjalny wpływ na łańcuchy dostaw EV/ESS, dane pracownicze oraz systemy OT/IT w zakładach produkcyjnych. (Wnioski na podstawie charakterystyki ofiar Akiry i praktyk podwójnego wymuszenia).

Kontekst / historia / powiązania

Akira działa od 2023 r., stosując model double-extortion (kradzież + szyfrowanie) i utrzymując serwis wyciekowy w sieci Tor. W 2024–2025 r. operatorzy rozwijali narzędzie szyfrujące (m.in. warianty dla Windows i Linux), a w kampaniach coraz częściej wykorzystują znane luki w VPN/backupach i narzędzia do zdalnego dostępu. Organy rządowe USA (CISA/FBI/DC3/HHS) 6–13 listopada 2025 r. ponownie wydały zaktualizowaną poradę #StopRansomware dedykowaną Akirze po fali ataków.

Analiza techniczna / szczegóły luki

Poniżej syntetyzujemy obecne TTP Akiry wg najnowszych materiałów CISA oraz badań branżowych:

  • Wejście (Initial Access): nadużycia znanych CVE w urządzeniach brzegowych (np. VPN, firewalle), systemach backupu oraz zdalnym zarządzaniu; kampanie phishingowe i nadużycie poświadczeń; obserwowano wykorzystanie luk pokroju CVE-2023-27532 (Veeam), CVE-2024-40766 (SonicWall) oraz podobnych wektorów.
  • Ruch boczny i eskalacja: użycie legalnych RMM (AnyDesk/LogMeIn), RDP, LSASS dump/credential theft; na hostach Linux/ESXi – ukierunkowane szyfrowanie zasobów produkcyjnych i plików VM.
  • Szyfrowanie/utrudnianie odzysku: w nowszych wariantach Windows wykorzystywany jest m.in. algorytm ChaCha8; usuwanie shadow copies i wyłączanie usług backupu skryptami PowerShell.
  • Eksfiltracja i wymuszenie: stały element operacji; publikacja nazw ofiar i porcji danych na stronie wyciekowej jako presja negocjacyjna.

Uwaga: LGES nie potwierdziło publicznie, że elementem ataku było szyfrowanie czy eksfiltracja określonego wolumenu danych – informacje te pochodzą od sprawców i agregatorów wycieków.

Praktyczne konsekwencje / ryzyko

  • Łańcuch dostaw motoryzacji i energii: nawet lokalny incydent w zakładzie ogniw/packów może powodować opóźnienia logistyczne, a w przypadku wycieku – ryzyko ekspozycji dokumentacji jakościowej, BOM-ów, planów testów czy danych partnerów. (Wniosek sektorowy na podstawie profilu LGES).
  • Ryzyko dla danych osobowych: potencjalna ekspozycja danych pracowniczych/kontrahentów zwiększa prawdopodobieństwo phishingu ukierunkowanego i nadużyć tożsamości. (Jeśli potwierdzi się narracja Akiry o bazach SQL).
  • Efekt domina IT/OT: Akira posiada zdolność atakowania środowisk wirtualizacyjnych i backupów, co może komplikować odtwarzanie i forensykę oraz wpływać na ciągłość produkcji.

Rekomendacje operacyjne / co zrobić teraz

Dla producentów i firm z łańcucha dostaw EV/ESS:

  1. Weryfikacja ekspozycji brzegowej: natychmiastowy audyt urządzeń VPN/UTM, firewall (ASA/FTD), SonicWall, bram RDP i serwerów backupu pod kątem znanych CVE wskazywanych w poradach CISA – z potwierdzeniem wersji i dat zastosowania łat.
  2. Segmentacja i „blast radius”: rozdzielenie IT/OT, kontrola ruchu do stref produkcyjnych (PLC/SCADA) i środowisk wirtualnych (ESXi/Hyper-V/AHV); zasada zero trust dla kont serwisowych.
  3. Twardo zaszyte kopie zapasowe: 3-2-1-1 (w tym izolowana, niezmienialna kopia poza domeną AD) + regularne testy odtwarzania; monitorowanie niepożądanych operacji na repozytoriach backupu.
  4. EDR + MDE/Defender for Server: detekcje TTP Akiry (np. wywołania PowerShell usuwające shadow copies, nietypowe RMM, LSASS dump); reguły blokujące narzędzia Living-off-the-Land.
  5. MFA wszędzie + hardening AD: zwłaszcza kont uprzywilejowanych i dostępów zdalnych; kontrola tokenów i polityki Kerberos/NTLM.
  6. IR playbook zgodny z #StopRansomware: gotowe procedury izolacji, triage artefaktów, kontakt z CERT/LE, polityka decyzyjna nt. okupu; mapowanie do IOCs z najnowszej publikacji CISA/FBI/DC3/HHS.

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

  • Akira vs. ALPHV/BlackCat: obie operacje stosują podwójne wymuszenie i szybkie unieruchamianie kopii zapasowych; Akira w 2024–2025 była aktywnie rozwijana (m.in. ChaCha8, Linux/VM/backup focus), a jej kampanie są obecnie przedmiotem świeżych ostrzeżeń wielu agencji. ALPHV była szeroko zakłócana przez organy ścigania pod koniec 2023 r., co jednak nie przełożyło się na trwały spadek aktywności całego ekosystemu RaaS.

Podsumowanie / kluczowe wnioski

  • LGES potwierdziło ograniczony geograficznie incydent ransomware i przywróciło pracę zakładu; pełna skala i charakter (szyfrowanie/wyciek) pozostają przedmiotem dochodzenia.
  • Grupa Akira przypisała sobie atak i grozi publikacją danych – to element presji negocjacyjnej, który wymaga weryfikacji.
  • Organizacje z sektora produkcji baterii/EV/ESS powinny pilnie przejrzeć ekspozycję na wektory wejścia wykorzystywane przez Akirę zgodnie z najnowszymi wskazówkami CISA/FBI/DC3/HHS i wdrożyć techniczne środki utrudniające destrukcję backupów i ruch boczny.

Źródła / bibliografia

  • The Record (Recorded Future News): „LG battery subsidiary says ransomware attack targeted overseas facility”, 18 listopada 2025. (The Record from Recorded Future)
  • Ransomware.live: wpis o ofierze „LG Energy Solution” przypisany do grupy Akira, 17 listopada 2025. (ransomware.live)
  • CISA/FBI/DC3/HHS: #StopRansomware: Akira Ransomware – zaktualizowana porada, 13 listopada 2025 (wersja PDF z IOC/TTP). (CISA)
  • Cisco Talos: „Akira ransomware continues to evolve”, 21 października 2024 – ewolucja wariantów, TTP. (Cisco Talos Blog)
  • IBM X-Force: „Spotlight on Akira ransomware” – podsumowanie taktyk i obserwacji IR. (IBM)

Fortinet ostrzega: nowa luka w FortiWeb (CVE-2025-58034) jest aktywnie wykorzystywana. Co z krytycznym CVE-2025-64446?

Wprowadzenie do problemu / definicja luki

19 listopada 2025 r. Fortinet potwierdził nową podatność w FortiWeb — CVE-2025-58034 — która jest już wykorzystywana w atakach. Błąd sklasyfikowano jako CWE-78 (command injection) i oceniono na CVSS 6.7 (średnia). Atak wymaga autoryzacji napastnika, ale pozwala wykonywać nieautoryzowane komendy systemowe poprzez spreparowane żądania HTTP lub komendy CLI. Fortinet wydał poprawki w najnowszych wydaniach FortiWeb i zaleca pilną aktualizację.

W skrócie

  • Nowa luka: CVE-2025-58034 (command injection, CVSS 6.7) — aktywnie wykorzystywana. Wymaga autoryzacji.
  • Wpływ: wykonanie poleceń OS na urządzeniu FortiWeb przez autoryzowanego atakującego.
  • Wersje do aktualizacji (wg Fortinet/THN):
    • 8.0.0–8.0.1 → zaktualizuj do 8.0.2+
    • 7.6.0–7.6.5 → zaktualizuj do 7.6.6+
    • 7.4.0–7.4.10 → zaktualizuj do 7.4.11+
    • 7.2.0–7.2.11 → zaktualizuj do 7.2.12+
    • 7.0.0–7.0.11 → zaktualizuj do 7.0.12+
  • Powiązana krytyczna luka: CVE-2025-64446 (path traversal, bez autoryzacji, wykorzystywana w atakach; naprawiona w 8.0.2; dodana do CISA KEV).

Kontekst / historia / powiązania

Zaledwie kilka dni wcześniej społeczność bezpieczeństwa nagłaśniała CVE-2025-64446 w FortiWeb, którą Fortinet naprawił w wersji 8.0.2. Ta luka umożliwia niezalogowanemu napastnikowi uruchamianie poleceń administracyjnych i tworzenie kont admina — stąd jej krytyczność i szybkie dodanie do katalogu CISA KEV. Dzisiejsze ogłoszenie o CVE-2025-58034 dokłada kolejny wektor, tym razem wymagający autoryzacji i klasyfikowany jako command injection. Organizacje powinny traktować oba problemy łącznie i planować skoordynowane działania naprawcze.

Analiza techniczna / szczegóły luki

CVE-2025-58034 (command injection)

  • Mechanizm: niewłaściwa neutralizacja specjalnych znaków w kontekście wywołań systemowych (CWE-78).
  • Warunek: napastnik musi być uwierzytelniony (np. przejęte konto, reuse haseł, inne luki łańcuchowe).
  • Skutek: wykonanie komend OS na urządzeniu FortiWeb przez HTTP/CLI.
  • Zakres wersji: 7.0.0–7.0.11, 7.2.0–7.2.11, 7.4.0–7.4.10, 7.6.0–7.6.5, 8.0.0–8.0.1.

CVE-2025-64446 (path traversal)

  • Mechanizm: błąd typu relative path traversal (CWE-23) w komponentach GUI/CGI FortiWeb.
  • Warunek: brak autoryzacji — atak możliwy z internetu.
  • Skutek: możliwość wykonywania poleceń administracyjnych i dostęp do panelu/websocket CLI; przypadki tworzenia kont admina.
  • Status: aktywnie wykorzystywana; wymagana aktualizacja; CISA KEV.

Praktyczne konsekwencje / ryzyko

  • Lateral movement i trwałość: w obu przypadkach wykonanie komend OS może posłużyć do instalacji backdoorów, pivotu w sieci i kradzieży sekretów/API keys.
  • Podmiana konfiguracji WAF: atakujący mogą wyłączyć reguły, dodać wyjątki, modyfikować polityki — co otwiera drogę do dalszych włamań przez aplikacje chronione przez FortiWeb.
  • Ucieczka z wykrycia: z poziomu OS możliwe jest czyszczenie logów, modyfikacja syslog/forwardingu i ukrywanie aktywności.
  • Ryzyko łańcuchowe: CVE-2025-58034 może być łączona z kradzieżą poświadczeń lub innymi błędami w celu eskalacji (np. przerzucenie się z autoryzowanego na uprzywilejowany kontekst).

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowa aktualizacja FortiWeb do wersji 8.0.2 lub wyższej (dla gałęzi 8.0) oraz odpowiednio: 7.6.6+ / 7.4.11+ / 7.2.12+ / 7.0.12+. Priorytet dla urządzeń z GUI/HTTP wystawionym do internetu.
  2. Ogranicz ekspozycję zarządzania: jeśli nie możesz patchować od razu, zablokuj HTTP/HTTPS na interfejsach zewnętrznych; dostęp administracyjny tuneluj przez VPN/SSH z allow-listą adresów.
  3. Hunting po incydencie (post-patch):
    • przejrzyj logi systemowe i konfigurację pod kątem niespodziewanych zmian;
    • sprawdź nowe/zmodyfikowane konta admina, nieznane obiekty polityk i harmonogramy zadań;
    • porównaj sumy kontrolne plików krytycznych; zweryfikuj integralność obrazów/firmware.
  4. Telemetria i detekcje: ustaw reguły na nietypowe żądania do GUI/CGI (CVE-2025-64446) i anomalie w CLI/websocket; monitoruj komendy systemowe wychodzące z FortiWeb.
  5. Segmentacja i zasada najmniejszych uprawnień: ogranicz, do jakich zasobów FortiWeb ma dostęp (np. bazy sygnatur, repo backupów), aby ograniczyć skutki kompromitacji.

Różnice / porównania z innymi przypadkami

  • Model ataku:
    • CVE-2025-58034 – wymaga autoryzacji, zatem często jest drugi etap łańcucha (po przejęciu konta).
    • CVE-2025-64446 – bez autoryzacji, może być wektorem wejściowym z internetu.
  • Krytyczność: 6.7 vs 9.8 i dodanie do CISA KEV w przypadku 64446 (obowiązek szybkiego patchowania w instytucjach federalnych USA).
  • Skutki ataku: obie luki prowadzą do wykonywania poleceń, ale 64446 łatwiej zautomatyzować i masowo skanować; 58034 zwiększa głębokość kompromitacji po uzyskaniu konta.

Podsumowanie / kluczowe wnioski

  • Dwa równoległe zagrożenia dla FortiWeb — CVE-2025-58034 (auth RCE przez command injection) i CVE-2025-64446 (unauth path traversal → admin commands) — wymagają natychmiastowych aktualizacji.
  • Priorytetyzuj 8.0.2+ (oraz odpowiednie wersje maintenance) i zamykanie publicznego zarządzania do czasu wdrożenia poprawek.
  • Po aktualizacji wykonaj aktywny threat hunting i weryfikację konfiguracji, zwłaszcza kont administracyjnych.

Źródła / bibliografia

  1. The Hacker News — ogłoszenie Fortinet/zakres wersji dla CVE-2025-58034 (19.11.2025). (The Hacker News)
  2. GitHub Advisory — opis CVE-2025-58034 (CWE-78, wersje podatne). (GitHub)
  3. HKCERT — biuletyn: CVE-2025-58034 wykorzystywana w atakach. (hkcert.org)
  4. Rapid7 — analiza: CVE-2025-64446 (nieautoryzowane komendy, tworzenie kont admina, naprawa w 8.0.2). (Rapid7)
  5. CISA KEV — wpis dla CVE-2025-64446 (status: exploited; wymagane terminy łatania). (CISA)

Fortinet FortiWeb: CISA daje tydzień na załatanie krytycznej luki CVE-2025-64446 (aktywnie wykorzystywanej)

Wprowadzenie do problemu / definicja luki

CISA dodała do katalogu KEV krytyczną podatność w Fortinet FortiWeb (WAF) — CVE-2025-64446 — i wyznaczyła agencjom federalnym USA 7 dni na wdrożenie poprawek lub zastosowanie mitigacji. Luka to relative path traversal / path confusion umożliwiająca niezalogowanemu atakującemu wykonanie poleceń administracyjnych poprzez odpowiednio spreparowane zapytania HTTP/HTTPS. Fortinet i CISA potwierdzają aktywną eksploatację tej podatności.

W skrócie

  • Id CVE: CVE-2025-64446
  • Wpływ: zdalne wykonanie poleceń jako admin / przejęcie urządzenia (pre-auth, bez uwierzytelnienia)
  • Ocena ryzyka: CVSS 9.8 (Fortinet CNA)
  • Produkty: FortiWeb w gałęziach 7.0, 7.2, 7.4, 7.6, 8.0 (konkretne wersje niżej)
  • Eksploatacja: od października 2025 r.; dodawanie kont administratora obserwowane in-the-wild
  • Termin CISA (FCEB): do 21 listopada 2025 r.
  • Szybka mitigacja: czasowe wyłączenie HTTP/HTTPS na interfejsach wystawionych do Internetu, następnie aktualizacja do wydań naprawczych.

Kontekst / historia / powiązania

O luce zaczęto głośno mówić na początku października (wzmianki od społeczności i watchTowr), a 14 listopada 2025 r. Fortinet opublikował oficjalne PSIRT i nadano CVE-2025-64446. Tego samego dnia CISA dodała podatność do Known Exploited Vulnerabilities i wydała rzadko spotykane skrócenie terminu łatania do 7 dni (zwykle są to 3 tygodnie). Media branżowe wskazują, że atakujący masowo tworzą nowe konta admina na niezabezpieczonych urządzeniach FortiWeb.

Analiza techniczna / szczegóły luki

  • Klasa: CWE-23 (Relative Path Traversal / path confusion w GUI FortiWeb).
  • Warunek: Brak uwierzytelnienia – podatność działa przed logowaniem.
  • Efekt: możliwość wykonania poleceń administracyjnych przez manipulację ścieżką/trasowaniem żądań, co skutkuje pełną kontrolą nad urządzeniem.
  • Wersje podatne (wg NVD/Fortinet):
    • 8.0.0–8.0.1, 7.6.0–7.6.4, 7.4.0–7.4.9, 7.2.0–7.2.11, 7.0.0–7.0.11.
  • Wersje naprawcze (implikowane przez zakresy): 8.0.2, 7.6.5, 7.4.10, 7.2.12, 7.0.12 lub nowsze.
  • CVSS (CNA Fortinet): 9.8 / AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

Praktyczne konsekwencje / ryzyko

Przejęcie FortiWeb (WAF) daje atakującemu możliwość:

  • utworzenia trwałych kont admina i wyłączenia logowania/monitoringu,
  • modyfikacji reguł WAF (ukrycie dalszych ataków na aplikacje webowe),
  • kradzieży poświadczeń/konfiguracji oraz pivotu do sieci wewnętrznej,
  • przygotowania pod ransomware lub wyciek danych.
    Doniesienia o aktywnej eksploatacji i masowym tworzeniu kont potwierdzają pilność działań.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowy patch – zaktualizuj FortiWeb do 8.0.2 / 7.6.5 / 7.4.10 / 7.2.12 / 7.0.12 (lub nowszych). Zweryfikuj wynik patchowania.
  2. Mitigacja tymczasowa (jeśli patch niezwłocznie niemożliwy): wyłącz HTTP/HTTPS na interfejsach wystawionych do Internetu; ogranicz dostęp administracyjny do zaufanych segmentów/VPN.
  3. Hunting i IR:
    • sprawdź nietypowe konta admina dodane ostatnio; przejrzyj logi systemowe FortiWeb, integracje SIEM;
    • poszukaj nietypowych żądań HTTP/HTTPS wywołujących akcje administracyjne;
    • porównaj konfiguracje WAF/reguły pod kątem nieautoryzowanych zmian. (watchTowr udostępnił artefakty/detektory pomocne w identyfikacji).
  4. Twardnienie ekspozycji:
    • ogranicz panel admina wyłącznie do sieci zarządzających (ACL/VPN),
    • włącz MFA dla dostępu administracyjnego,
    • segmentuj FortiWeb, monitoruj integracje z SIEM/EDR.
  5. Zgodność z CISA KEV: jeśli podlegasz BOD 22-01, dotrzymaj terminu 21.11.2025; inaczej przyjmij ten termin jako wewnętrzny SLA.

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

W 2023–2024 widzieliśmy serię poważnych błędów w urządzeniach perimeterowych (Fortinet, Ivanti, Citrix), ale skrócenie terminu przez CISA do 7 dni jest wyjątkowe i podkreśla skalę nadużyć. W przeciwieństwie do wielu poprzednich RCE wymagających uwierzytelnienia lub dostępu lokalnego, CVE-2025-64446 działa pre-auth i celuje w WAF, czyli element ochronny krytyczny dla aplikacji webowych.

Podsumowanie / kluczowe wnioski

  • To krytyczna, aktywnie wykorzystywana luka w FortiWeb.
  • Patch teraz; jeśli nie możesz — odłącz HTTP/HTTPS na interfejsach publicznych i zawęź dostęp administracyjny.
  • Sprawdź konta admina i konfigurację WAF pod kątem zmian.
  • Traktuj 21 listopada 2025 r. jako twardy termin na remediację.

Źródła / bibliografia

  1. NVD – wpis CVE-2025-64446: opis, zakres wersji podatnych, metryka CVSS, data/due date w KEV. (NVD)
  2. Fortinet PSIRT (FG-IR-25-910) – oficjalny advisory i klasyfikacja (path traversal/path confusion). (FortiGuard)
  3. CISA – Known Exploited Vulnerabilities Catalog (pozycja dla CVE-2025-64446). (CISA)
  4. Rapid7 – analiza i kontekst eksploatacji od października 2025 r. (Rapid7)
  5. The Record – informacja o 7-dniowym terminie CISA, wskazówki i obserwacje dot. tworzenia kont admina. (The Record from Recorded Future)

RondoDox wykorzystuje krytyczną lukę w XWiki (CVE-2025-24893) do przejmowania serwerów

Wprowadzenie do problemu / definicja luki

Nowa fala ataków botnetu RondoDox celuje w serwery XWiki, wykorzystując krytyczną podatność CVE-2025-24893 (CVSS 9.8), która umożliwia zdalne wykonanie kodu bez uwierzytelnienia. Zaatakowane instancje są włączane do sieci botnetu i wykorzystywane w kolejnych kampaniach. Informację o nowej taktyce RondoDox potwierdził m.in. serwis BleepingComputer.

W skrócie

  • Co się dzieje: RondoDox aktywnie skanuje i atakuje niezaktualizowane XWiki, wykorzystując CVE-2025-24893.
  • Dlaczego to groźne: Luka pozwala gościowi (niezalogowanemu) uruchomić kod na serwerze XWiki.
  • Skala/tempo: Eksploatacja tej podatności szybko się upowszechniła — od pojedynczego aktora do wielu grup (botnety, koparki, skanery).
  • Status w KEV: CISA dodała CVE-2025-24893 do katalogu Known Exploited Vulnerabilities 30 października 2025 r.
  • Remediacja: Luka załatana w XWiki 15.10.11, 16.4.1 i 16.5.0RC1.

Kontekst / historia / powiązania

Badacze VulnCheck zwrócili uwagę, że po pierwszych oznakach użycia CVE-2025-24893 do exploitu, w krótkim czasie dołączyły kolejne grupy: botnety, górnicy kryptowalut i oportunistyczni skanerzy. To klasyczny wzorzec „efektu kuli śnieżnej” po publikacji technicznych szczegółów luki.
Równolegle media branżowe raportują o „wzmożonej eksploatacji” XWiki w ostatnich dniach, a BleepingComputer precyzuje, że jednym z beneficjentów tej luki jest właśnie botnet RondoDox.

Analiza techniczna / szczegóły luki

CVE-2025-24893 dotyczy sposobu, w jaki XWiki przetwarza treści szablonów/makro w zapytaniach (m.in. kanał RSS wyszukiwarki Solr). Atakujący mogą wstrzyknąć i wykonać Groovy w kontekście serwera — bez logowania. NVD podaje nawet prosty test na podatność, który wykrywa wykonanie kodu w tytule zwracanego feedu RSS.
Skutkiem jest pełne zdalne wykonanie kodu (RCE). Broadcom/Symantec opisuje to jako możliwość wstrzyknięcia i wykonania dowolnego kodu Groovy przez spreparowane żądania.

Praktyczne konsekwencje / ryzyko

W praktyce przejęty serwer XWiki może zostać:

  • włączony do infrastruktury RondoDox (DDoS, pivot na inne cele, utrzymywanie C2),
  • wykorzystany do doinstalowania dodatkowego malware (koparki, skanery),
  • użyty jako przekaźnik/proxy w kolejnych atakach.
    Szybka, wieloaktorowa adopcja exploitu zwiększa ryzyko masowych kompromitacji w krótkim czasie.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiast aktualizuj XWiki do wersji 15.10.11, 16.4.1 lub 16.5.0RC1 (lub nowszej gałęzi naprawczej zgodnej z Twoją linią).
  2. Zastosuj reguły WAF/IPS blokujące charakterystyczne ciągi/makra w endpointach wyszukiwarki/RSS oraz monitoruj nietypowe wywołania makr (np. {{groovy}}). (Wniosek na podstawie szczegółów NVD i opisów w Broadcom.)
  3. Sprawdź kompromitację: logi aplikacyjne i reverse proxy dla nietypowych zapytań do /xwiki/bin/get/...SolrSearch?media=rss..., nowo utworzone konta, modyfikacje skryptów/makr, zadania cron, nieznane procesy powłoki. (Na bazie wektora z NVD.)
  4. Segmentacja i zasada najmniejszych uprawnień: ogranicz ekspozycję XWiki do zaufanych sieci/VPN, odizoluj serwer od krytycznych segmentów. (Dobra praktyka bezpieczeństwa, wzmacniana przez obserwacje VulnCheck nt. szybkiej adopcji exploitu.)
  5. Śledź KEV CISA i wdrażaj priorytetowe poprawki dla pozycji w katalogu (CISA KEV = aktywnie wykorzystywane).

Różnice / porównania z innymi przypadkami

W odróżnieniu od wielu wcześniejszych błędów XWiki (np. dotyczących właściwości klas czy nadużyć edytora), CVE-2025-24893 zapewnia RCE dla gościa poprzez przetwarzanie treści w publicznych endpointach (np. RSS Solr), co radykalnie zwiększa ryzyko skanów/automatyzacji przez botnety takie jak RondoDox. W efekcie czas od publikacji szczegółów do masowych nadużyć był wyjątkowo krótki.

Podsumowanie / kluczowe wnioski

  • RondoDox aktywnie przejmuje serwery XWiki, wykorzystując CVE-2025-24893.
  • Luka jest prosta do zautomatyzowania i już masowo eksploatowana przez różne grupy.
  • Aktualizacja XWiki do wersji naprawczych i twarde ograniczenie ekspozycji usług to priorytet „na już”.

Źródła / bibliografia

  • BleepingComputer: „RondoDox botnet malware now hacks servers using XWiki flaw” (17 listopada 2025). (BleepingComputer)
  • VulnCheck: „XWiki Under Increased Attack” (listopad 2025). (VulnCheck)
  • NVD: „CVE-2025-24893 – XWiki Platform injection vulnerability” (informacje o patchach i teście podatności). (NVD)
  • CISA: dodanie CVE-2025-24893 do KEV (30 października 2025). (CISA)
  • SecurityWeek: „Widespread Exploitation of XWiki Vulnerability Observed” (20 listopada 2025). (SecurityWeek)

Prokurator Generalny Pensylwanii potwierdza wyciek danych po ataku INC Ransom — co wiemy i co robić

Wprowadzenie do problemu / definicja luki

Biuro Prokuratora Generalnego stanu Pensylwania (Office of Attorney General, OAG) potwierdziło, że po sierpniowym ataku ransomware doszło do nieautoryzowanego dostępu do plików zawierających dane osobowe i medyczne. W komunikacie wskazano, że dla części osób ujawnione informacje mogą obejmować imię i nazwisko, numer Social Security (SSN) i/lub dane medyczne. OAG uruchomiło dedykowaną infolinię dla poszkodowanych (1-833-353-8060).

W skrócie

  • Incydent wykryto 9 sierpnia 2025 r.; początkowo sparaliżował stronę WWW, pocztę i telefony OAG.
  • OAG odmówiło zapłaty okupu; we wrześniu potwierdzono, że był to atak ransomware.
  • Grupa INC Ransom przypisała sobie atak i twierdzi, że wykradła 5,7 TB danych (roszczenie sprawców).
  • Niezależni badacze łączyli możliwy wektor wejścia z publicznie wystawionymi urządzeniami Citrix NetScaler podatnymi na CVE-2025-5777 („CitrixBleed 2”) — to hipoteza, nie potwierdzenie OAG.

Kontekst / historia / powiązania

BleepingComputer opisał 17 listopada 2025 r., że OAG potwierdziło naruszenie danych po sierpniowym ataku oraz wcześniejszą odmowę zapłaty okupu. We wrześniu urząd informował o trwającej niedostępności usług i o tym, że incydent nie powinien wpływać na prowadzone postępowania.

Równolegle, 20–23 września, INC Ransom dodało wpis o OAG na swojej stronie wyciekowej i opublikowało próbki rzekomo skradzionych dokumentów; media branżowe opisały roszczenie sprawców i wspomniały o 5,7 TB danych. OAG wówczas nie potwierdziło skali exfiltracji.

Analiza techniczna / szczegóły luki

  • Możliwy wektor: CitrixBleed 2 (CVE-2025-5777). Według doniesień prasowych i wpisów badaczy, w infrastrukturze OAG miały znajdować się publicznie dostępne urządzenia Citrix NetScaler podatne na CVE-2025-5777, nazwane „CitrixBleed 2” ze względu na podobieństwo do CitrixBleed z 2023 r. (CVE-2023-4966). Uwaga: OAG nie wskazało oficjalnie wektora ataku.
  • Charakterystyka CVE-2025-5777. To błąd prowadzący do odczytu pamięci i przechwycenia sesji w NetScalerach, aktywnie wykorzystywany w 2025 r.; podatność została szeroko opisana w materiałach producenta i firm bezpieczeństwa. (Kontekst i nazewnictwo wg Tenable).
  • TTP INC Ransom. Grupa działa w modelu RaaS od lipca 2023 r., stosuje podwójny wymus (szyfrowanie + exfiltracja/wyciek), wykorzystuje phishing oraz eksploatację znanych luk (w przeszłości m.in. w NetScaler).

Praktyczne konsekwencje / ryzyko

  • Ryzyko kradzieży tożsamości: wyciek SSN i danych medycznych zwiększa prawdopodobieństwo otwierania fałszywych kont, refund fraud w ochronie zdrowia oraz ukierunkowanych kampanii socjotechnicznych. (Zakres danych wg OAG).
  • Długotrwały wpływ operacyjny: nawet po przywróceniu usług, sprawcy mogą wykorzystywać wykradzione informacje do wtórnych ataków (impersonacja urzędników/prawników, spear-phishing). (Roszczenia o 5,7 TB to nadal twierdzenie przestępców).

Rekomendacje operacyjne / co zrobić teraz

Dla obywateli Pensylwanii potencjalnie dotkniętych incydentem:

  1. Skontaktuj się z infolinią OAG (1-833-353-8060) w godzinach 08:00–20:00 ET w dni robocze; sprawdź, czy Twoje dane dotyczące tożsamości/zdrowia mogły być w plikach.
  2. Zamrożenie kredytu (credit freeze) i alert fraudowy u biur kredytowych; monitorowanie raportów kredytowych przez minimum 12–24 mies.
  3. Ostrożność wobec phishingu: spodziewaj się prób podszywania się pod OAG, sądy, ubezpieczycieli.
  4. Monitoruj świadczenia zdrowotne (Explanation of Benefits) i żądaj korekt nadużyć.

Dla organizacji publicznych i przedsiębiorstw:

  1. Natychmiastowa walidacja ekspozycji NetScaler/Edge: jeżeli używasz Citrix NetScaler/ADC/Gateway — potwierdź wersję i zaaplikuj poprawki/mitigacje dla CVE-2025-5777; unieważnij sesje, rotuj ciasteczka/sekrety, wymuś ponowne logowanie.
  2. Hunting po wskaźnikach przejęcia sesji (nietypowe logowania, zmiany IP w aktywnych sesjach, brak MFA-promptów); sprawdź logi WAF/VPN.
  3. Segregacja i hardening systemów prawniczych/archiwów (dostęp wg zasady najniższych uprawnień, SSO z MFA odporne na phishing, DLP).
  4. Plan na wycieki danych: gotowe szablony notyfikacji, kontrakty na monitoring tożsamości dla poszkodowanych, playbook komunikacji kryzysowej.
  5. Testy odtwarzania i tabletop dla scenariusza „podwójnego wymuszenia” (negocjacje ≠ płatność; polityka „no-pay” + koordynacja z LE).

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

To kolejny poważny incydent ransomware wobec instytucji stanowych w Pensylwanii w ostatnich latach (2017, 2020). W odróżnieniu od minionych spraw, obecny atak wpisuje się w falę nadużyć CitrixBleed 2 przeciw urządzeniom brzegowym oraz trend masowej exfiltracji danych przed szyfrowaniem (double extortion).

Podsumowanie / kluczowe wnioski

  • Fakt: OAG potwierdziło wyciek danych i uruchomiło ścieżkę wsparcia dla obywateli.
  • Fakt: Atak miał charakter ransomware, a okup nie został zapłacony.
  • Roszczenie sprawców: INC Ransom przypisuje sobie kradzież 5,7 TB danych — tego OAG nie potwierdziło.
  • Hipoteza badaczy: możliwy wektor to CVE-2025-5777 / CitrixBleed 2 na NetScaler — wymaga traktowania jako priorytetowej poprawki i unieważnienia sesji.

Źródła / bibliografia

  1. BleepingComputer — „Pennsylvania AG confirms data breach after INC Ransom attack”, 17 listopada 2025. (BleepingComputer)
  2. PR Newswire / OAG — „Media Notice: Pennsylvania Office of Attorney General Provides Notice of Data Incident”, 14 listopada 2025. (PR Newswire)
  3. BleepingComputer — „Pennsylvania AG Office says ransomware attack behind recent outage”, 2 września 2025. (BleepingComputer)
  4. Tenable — „FAQ o CVE-2025-5777 (CitrixBleed 2)”, 27 czerwca 2025. (Tenable®)
  5. Comparitech — „Ransomware gang says it hacked Pennsylvania’s Attorney General”, 22 września 2025. (Comparitech)

CVE-2025-59299: luka w Delta Electronics DIAScreen (błąd walidacji plików wejściowych) – analiza, ryzyko i zalecenia

Wprowadzenie do problemu / definicja luki

CVE-2025-59299 to podatność w oprogramowaniu Delta Electronics DIAScreen (narzędzie HMI/SCADA z ekosystemu DIAStudio). Błąd wynika z braku prawidłowej walidacji danych z pliku dostarczonego przez użytkownika, co skutkuje zapisywaniem poza końcem bufora podczas parsowania projektu (CWE-787). Do wykorzystania konieczne jest otwarcie przez użytkownika specjalnie spreparowanego pliku – efekt to wykonanie kodu w kontekście bieżącego procesu. Wersje podatne to wszystkie przed 1.6.1; producent opublikował aktualizację podnoszącą DIAScreen do v1.6.1.

W skrócie

  • Produkt: Delta Electronics DIAScreen
  • CVE: CVE-2025-59299
  • Klasyfikacja: CWE-787 Out-of-Bounds Write (błąd parsowania plików projektu DPA)
  • Wymagania ataku: interakcja użytkownika (otwarcie złośliwego pliku)
  • Skutki: RCE w kontekście procesu DIAScreen (wysokie CIA)
  • Ocena ryzyka: CVSS v3.1 7.8 (High); v4.0 6.8 (Medium) wg CNA
  • Wersje podatne: < 1.6.1; remediacja: aktualizacja do v1.6.1
  • Zakres: środowiska OT/ICS, szczególnie stacje inżynierskie/HMI z DIAStudio

Kontekst / historia / powiązania

Luka została ujawniona w pakiecie czterech podobnych błędów DIAScreen: CVE-2025-59297, -59298, -59299, -59300, wszystkie o charakterze Out-of-Bounds Write w parserze plików projektu. Producent opublikował formalną notę bezpieczeństwa Delta-PCSA-2025-00018 z jednoznaczną rekomendacją aktualizacji do v1.6.1. Zero Day Initiative przypisuje odkrycie badaczowi Natnael Samson (@NattiSamson) i potwierdza wektor: złośliwy plik DPA → parsowanie → OOB write → RCE.

Analiza techniczna / szczegóły luki

Gdzie jest błąd?
W komponencie parsującym pliki projektu .DPA. Plik zawiera strukturę danych, która – przy braku rygorystycznej walidacji długości/pól – może spowodować zapis danych poza zaalokowaną strukturą. To klasyczny heap/stack OOB write (CWE-787), który umożliwia nadpisanie wskaźników/kontrolnych struktur pamięci i w konsekwencji przejęcie przepływu wykonania.

Warunki ataku:

  • Ofiara otwiera złośliwy plik w DIAScreen (wektor „file-based”).
  • Uprawnienia nie są wymagane ponad domyślne (PR:N), ale to atak lokalny z UI:R (użytkownik musi otworzyć plik).
  • Po udanym wywołaniu błędu możliwe jest RCE w kontekście użytkownika uruchamiającego DIAScreen.

Metadane CVSS (NVD):

  • CVSS v3.1: 7.8 (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H)
  • CVSS v4.0 (CNA): 6.8 (UI:A, VA:H, itd.)
    W praktyce, na stacjach inżynierskich OT konsekwencje te często przekładają się na wysokie ryzyko operacyjne (kontekst HMI/SCADA).

Praktyczne konsekwencje / ryzyko

Scenariusze nadużyć w OT/ICS:

  1. Spear-phishing do inżynierów/techników – załącznik „aktualizacja projektu.dpa”; po otwarciu dochodzi do RCE i osadzenia implantu w środowisku HMI.
  2. Wymiana plików przez pamięci USB w strefach z ograniczoną łącznością – wektor popularny w fabrykach i na liniach produkcyjnych.
  3. Złośliwy projekt na serwerze wersji (np. share SMB) – podmiana pliku projektu, kompromitacja kolejnych stacji.

Skutek biznesowy: przejęcie stacji inżynierskiej/HMI może pozwolić na manipulację ekranami sterowania, zmianę receptur/parametrów, czy sabotaż procesu przy dalszym ruchu bocznym. Brak izolacji IT/OT i słaba segmentacja zwiększają prawdopodobieństwo eskalacji.

Źródła potwierdzają wektor i wpływ wprost (RCE po otwarciu pliku) oraz wskazują na pakiet czterech CVE w tej samej klasie błędów.

Rekomendacje operacyjne / co zrobić teraz

1) Patching i inwentarz

  • Zaktualizuj DIAScreen do v1.6.1 lub nowszej na wszystkich stacjach inżynierskich/HMI. To oficjalna i jednoznaczna rekomendacja producenta.
  • Zidentyfikuj instalacje (Windows) i sprawdź wersję aplikacji:
# Wykrywanie zainstalowanego DIAScreen i wersji w rejestrze (Apps & Features)
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
                 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*' `
| Where-Object { $_.DisplayName -match 'DIAScreen' } `
| Select-Object DisplayName, DisplayVersion, Publisher, InstallLocation

Jeżeli skrypt nie zwróci wyniku, przeszukaj dysk pod kątem katalogów DIAStudio/DIAScreen i sprawdź wersję plików binarnych (Właściwości → Szczegóły).

2) „Virtual patching” i twardnienie do czasu aktualizacji

  • Zabroń/ogranicz otwieranie plików .DPA z lokacji ryzykownych (Downloads, %TEMP%, nośniki wymienne) – reguła SRP/AppLocker (Path/Hash).
  • Polityki pocztowe: blokada lub kwarantanna załączników .dpa, tagowanie detekcji w bramce pocztowej (DLP/ATP).
  • Kontrola nośników USB: whitelisting urządzeń, skan AV/EDR, auto-kwarantanna plików .dpa zewnętrznych.
  • Segmentacja sieci OT: stacje z DIAScreen za zaporą, brak dostępu z sieci biurowej; zdalny dostęp tylko VPN i tylko z listy dozwolonych.

3) Monitoring i detekcja (przykłady)

Sigma (Windows) – podejrzane otwarcia plików DPA z lokalizacji wysokiego ryzyka:

title: Suspicious DIAScreen Project Open From Risky Locations
id: 1b1a1e0c-6f6b-4d40-b1e5-7d1f4f5a9da9
status: experimental
logsource:
  category: file_event
  product: windows
detection:
  selection_ext:
    TargetFilename|endswith: '.dpa'
  selection_paths:
    TargetFilename|contains:
      - '\Downloads\'
      - '\Temp\'
      - '\$Recycle.Bin\'
      - '\RemovableDrive\'
  condition: selection_ext and selection_paths
level: medium
tags:
  - attack.initial_access
  - attack.t1204.002  # Malicious File

Sysmon – nietypowe wywołanie DIAScreen po otwarciu projektu:

<!-- Sysmon Event ID 1: Process Create -->
<RuleGroup name="DIAScreen Suspicious Launch" groupRelation="or">
  <ProcessCreate onmatch="include">
    <Image condition="end with">DIAScreen.exe</Image>
    <ParentImage condition="contains">\Temp\</ParentImage>
  </ProcessCreate>
  <ProcessCreate onmatch="include">
    <Image condition="end with">DIAScreen.exe</Image>
    <CommandLine condition="contains">.dpa</CommandLine>
  </ProcessCreate>
</RuleGroup>

EDR/AV: stwórz watchlist na proces DIAScreen.exe otwierający .dpa z „niezaufanych” ścieżek i na crash/exception w procesie (częsty artefakt prób OOB write).

4) Procedury użytkownika / szkolenia

  • Nie otwieraj plików projektu otrzymanych e-mailem/IM bez walidacji źródła.
  • W środowiskach air-gapped – skan nośników przed importem projektów.

Różnice / porównania z innymi przypadkami (pakiet CVE dla DIAScreen)

Zarówno CVE-2025-59297, -59298, -59299, jak i -59300 dotyczą tej samej klasy błędu (CWE-787) w parserze DIAScreen i są naprawione w v1.6.1. Różnią się one lokalizacją w kodzie/ścieżką parsowania i mogą być wyzwalane przez odmienne pola pliku. Z punktu widzenia obrony operacyjnej: te same kontrole (aktualizacja, polityki plików, segmentacja, monitoring) redukują ryzyko dla całego pakietu.

Podsumowanie / kluczowe wnioski

  • To błąd „file-open → RCE”: wystarczy otwarcie złośliwego projektu .DPA.
  • Ryzyko realne w OT/ICS, bo DIAScreen działa na stacjach inżynierskich/HMI.
  • Patch do v1.6.1 jest dostępny i zalecany natychmiast.
  • Do czasu aktualizacji: blokuj .DPA z nieznanych źródeł, egzekwuj segmentację i monitoruj użycie DIAScreen.
  • Wprowadź procedury operacyjne: kontrola nośników, polityki pocztowe, szkolenia użytkowników.

Źródła / bibliografia

  1. Vendor advisory (PDF): „Delta-PCSA-2025-00018 – DIAScreen File Parsing Out-Of-Bounds Write Vulnerabilities” – wersje podatne < 1.6.1, CVSS v3.1=7.8, rekomendacja aktualizacji do v1.6.1. (PDF)
  2. NVD – CVE-2025-59299: opis „lacks proper validation of the user-supplied file”, metryki CVSS v3.1=7.8, wskazanie na wersje do <1.6.1 i link do advisory producenta. (NVD)
  3. ZDI-25-970: „DPA File Parsing Out-Of-Bounds Write RCE”, UI:R, RCE w kontekście bieżącego procesu, timeline i odniesienie do CISA. (zerodayinitiative.com)
  4. Ameeba Exploit Tracker – wpis o CVE-2025-59299: streszczenie luki (wektor plikowy, RCE po otwarciu). (Użyte jako źródło drugorzędne/uzupełniające). (Ameeba)
  5. Strona przeglądowa Delta – Product Cybersecurity Advisory: potwierdza istnienie advisory i politykę publikacji po dostępności poprawek. (deltaww.com)

Uwaga operacyjna: NVD i advisory producenta wprost wskazują v1.6.1 jako próg naprawy; utrzymuj ten numer jako twardy warunek zgodności w CMDB/OT asset management i audytach patch compliance.