Archiwa: Windows - Strona 39 z 65 - Security Bez Tabu

PowerShell w Windows ostrzega przy użyciu Invoke-WebRequest. Co to zmienia dla bezpieczeństwa i automatyzacji?

Wprowadzenie do problemu / definicja luki

Microsoft dodał do Windows PowerShell 5.1 nowy mechanizm ostrzegania, który wyświetla potwierdzenie bezpieczeństwa podczas uruchamiania skryptów wykorzystujących Invoke-WebRequest (IWR) do pobierania treści WWW. Celem jest ograniczenie ryzyka wykonania złośliwych skryptów osadzonych w pobieranych stronach. Zmiana została dostarczona w pakietach z Patch Tuesday 9 grudnia 2025 r. i jest powiązana z podatnością CVE-2025-54100 (wstrzyknięcie poleceń / command injection w Windows PowerShell).

W skrócie

  • Co się zmieniło? Invoke-WebRequest w PowerShell 5.1 może wyświetlić prompt z ostrzeżeniem o ryzyku wykonania skryptu z pobieranej strony. Użytkownik może kontynuować lub anulować operację.
  • Dlaczego? Aby zamknąć wektor ataku opisany jako CVE-2025-54100 (wysoka skala zagrożenia, CVSS 7.8 wg NVD/MSRC).
  • Jak obejść prompt w automatyzacji? Użyć parametru -UseBasicParsing w IWR (w PowerShell 5.1), który pobiera treść bez parsowania i bez wykonywania skryptów w odpowiedzi HTTP.
  • Kogo dotyczy? Administratorów, DevOpsów i autorów skryptów działających na Windows PowerShell 5.1 (wbudowany w Windows), w tym skryptów uruchamianych bez nadzoru.

Kontekst / historia / powiązania

Invoke-WebRequest to popularny cmdlet do pobierania zasobów HTTP/HTTPS, który parsuje HTML i zwraca zbiory elementów (linki, obrazy itp.). W starszym mechanizmie parsowania mogło dojść do niepożądanego uruchomienia skryptu po stronie klienta podczas przetwarzania odpowiedzi, co stało się osią wektora podatności CVE-2025-54100. Microsoft zaadresował problem w grudniowych aktualizacjach, a media branżowe opisały nowy prompt bezpieczeństwa jako dodatkową „barierę tarcia” dla złośliwego kodu.

Analiza techniczna / szczegóły luki

  • Identyfikator: CVE-2025-54100
  • Klasyfikacja: Command Injection (CWE-77)
  • Wpływ: lokalne wykonanie kodu przy udziale użytkownika (UI:R), wysokie skutki dla poufności, integralności i dostępności.
  • Wektor: pobranie i przetworzenie treści WWW przez IWR w sposób, który umożliwia wykonanie złośliwej skryptowej zawartości osadzonej w odpowiedzi.
  • Ocena ryzyka: CVSS v3.1 7.8 (High) wg NVD; Microsoft udostępnił poprawki w ramach Patch Tuesday.

Nowe zachowanie PowerShell 5.1:
Przy wywołaniu Invoke-WebRequest bez parametru -UseBasicParsing PowerShell 5.1 wyświetla dialog/komunikat potwierdzenia, informując, że parsowanie treści strony może uruchomić skrypt. Użytkownik wybiera Kontynuuj lub Anuluj. Dokumentacja Microsoft zaleca -UseBasicParsing dla scenariuszy nieinteraktywnych (CI/CD, zadań harmonogramu), aby pominąć parsowanie i tym samym uniknąć potencjalnego wykonania skryptu.

Praktyczne konsekwencje / ryzyko

  • Automatyzacja/CI: pipeline’y i zadania, które używają IWR bez -UseBasicParsing, mogą teraz się zatrzymać na potwierdzeniu, co spowoduje błędy w trybie bezobsługowym. Należy zaktualizować skrypty.
  • Eksploatacja w dziczy: luki w PowerShell bywały wykorzystywane przez malware do pobierania payloadów (np. kampanie opisane w raportach o Patch Tuesday). Nowy prompt utrudnia „ciche” wykonanie osadzonych skryptów z WWW.
  • Zgodność: skrypty polegające na starym, „bogatym” parsowaniu HTML mogą wymagać modyfikacji, jeśli przejdą na -UseBasicParsing.

Rekomendacje operacyjne / co zrobić teraz

  1. Zainstaluj grudniowe poprawki (09.12.2025) na wszystkich wspieranych wersjach Windows. Zmiana IWR jest częścią wielu pakietów zbiorczych (KB z 9 grudnia 2025 r.).
  2. Przejrzyj skrypty: wszędzie tam, gdzie wywołujesz Invoke-WebRequest w PowerShell 5.1, dodaj -UseBasicParsing dla zadań automatycznych / bezinteraktywnych.
  3. Waliduj i sanityzuj URL-e/odpowiedzi: ograniczaj pobieranie tylko z zaufanych domen, stosuj walidację treści (np. sprawdzanie hashów plików). (Dobra praktyka ogólna; spójna z charakterem luki.)
  4. Monitoruj telemetry: w SIEM/EDR filtruj procesy z powershell.exe i wzorce zawierające Invoke-WebRequest. Raporty popatchowe podkreślają potrzebę obserwacji tego cmdletu w detekcjach.
  5. Rozważ PowerShell 7+ w nowych projektach: nowsze wersje mają unowocześnioną implementację IWR i inny model parsowania; mimo to zawsze stosuj zasady najmniejszych uprawnień i podpisywanie skryptów.

Minimalny przykład (PowerShell 5.1)

  • Pobranie pliku bez promptu i bez parsowania HTML:
    Invoke-WebRequest -Uri "https://example.com/tool.exe" -OutFile "tool.exe" -UseBasicParsing

Różnice / porównania z innymi przypadkami

  • Przed aktualizacją: IWR mógł parsować odpowiedź HTML w sposób, który w określonych warunkach prowadził do niezamierzonego wykonania skryptu; brakował „hamulec bezpieczeństwa” po stronie użytkownika.
  • Po aktualizacji (PS 5.1): pojawia się prompt ostrzegawczy; -UseBasicParsing wyłącza parsowanie i eliminuje ryzyko wykonania skryptu oraz interakcji użytkownika.
  • PowerShell 7.x: inny stos sieciowy i dokumentowana funkcja IWR; zalecane praktyki bezpieczeństwa pozostają aktualne (brak promptu w 7.x, ale bezpieczne wzorce korzystania).

Podsumowanie / kluczowe wnioski

  • Grudniowy Patch Tuesday 2025 przyniósł istotną zmianę w Windows PowerShell 5.1ostrzeżenie i potwierdzenie przy użyciu Invoke-WebRequest. To reakcja na CVE-2025-54100 (command injection).
  • Administratorzy muszą zaktualizować systemy i dostosować skrypty, w szczególności dodając -UseBasicParsing tam, gdzie wymagany jest tryb bezobsługowy.
  • Równolegle należy wzmacniać monitoring pod kątem wywołań IWR i stosować zasadę „zaufaj, ale weryfikuj” dla pobieranych treści.

Źródła / bibliografia

  1. BleepingComputer — „Windows PowerShell now warns when running Invoke-WebRequest scripts” (09.12.2025). (BleepingComputer)
  2. Microsoft Support — „PowerShell 5.1: Preventing script execution from web content” (KB — instrukcje oraz obejście -UseBasicParsing). (Microsoft Support)
  3. MSRC — karta podatności CVE-2025-54100. (msrc.microsoft.com)
  4. NVD — opis i metryka CVE-2025-54100 (CVSS 7.8, CWE-77). (NVD)
  5. BleepingComputer — „Microsoft December 2025 Patch Tuesday fixes 3 zero-days, 57 flaws” (kontekst aktualizacji). (BleepingComputer)

CISA dodaje dwie luki do katalogu KEV: Windows Cloud Files Mini Filter (CVE-2025-62221) i WinRAR Path Traversal (CVE-2025-6218)

Wprowadzenie do problemu / definicja luk

9 grudnia 2025 r. CISA dodała dwie nowe pozycje do katalogu Known Exploited Vulnerabilities (KEV) na podstawie dowodów aktywnej eksploatacji w środowiskach produkcyjnych. Są to:

  • CVE-2025-62221Windows Cloud Files Mini Filter: błąd use-after-free prowadzący do eskalacji uprawnień (EoP) do SYSTEM. Pozycja otrzymała w KEV datę dodania 2025-12-09 i termin na wdrożenie poprawek 2025-12-30.
  • CVE-2025-6218WinRAR Path Traversal: podatność path traversal umożliwiająca RCE przy interakcji użytkownika (otwarcie spreparowanego archiwum/odwiedzenie strony). Również dodana 2025-12-09 z terminem 2025-12-30.

W skrócie

  • Status: obie luki są aktywnie wykorzystywanepriorytet krytyczny w zarządzaniu podatnościami.
  • Wpływ:
    • CVE-2025-62221 – lokalna EoP do SYSTEM po zdobyciu wstępnego dostępu; wykorzystywana w 0-day wg przeglądów Patch Tuesday.
    • CVE-2025-6218 – zdalne RCE na koncie bieżącego użytkownika po otwarciu złośliwego archiwum.
  • Działania CISA (BOD 22-01): wymagane zastosowanie poprawek/łagodzeń do 30.12.2025 (FCEB). Rekomendacja CISA: identyczne podejście także w sektorze prywatnym.

Kontekst / historia / powiązania

Dodanie CVE-2025-62221 zbiegło się z grudniowym Patch Tuesday Microsoftu – to aktywnie wykorzystywany zero-day w komponencie Cloud Files Mini Filter. Niezależne przeglądy (Tenable, ZDI, media branżowe) wskazują na wysoki priorytet aktualizacji systemów Windows.

W przypadku WinRAR (CVE-2025-6218), podatność została opisana i skoordynowana przez Trend Micro ZDI już w czerwcu 2025 r., a producent wydał aktualizacje (WinRAR ≥ 7.12). Obecne dodanie do KEV oznacza potwierdzoną eksploatację „w dziczy”.

Analiza techniczna / szczegóły luki

CVE-2025-62221 – Windows Cloud Files Mini Filter (EoP)

  • Klasa błędu: Use-After-Free (CWE-416).
  • Wektor: lokalny; napastnik musi mieć niski poziom uprawnień (PR:L), brak interakcji użytkownika (UI:N).
  • Skutek: eskalacja uprawnień do SYSTEM.
  • Oceny/deskryptory: CVSS 3.1 (w publikacjach branżowych określana jako istotna EoP), 0-day.
  • Patch/porady: publikowane w ramach Patch Tuesday, wpis w MSRC.

CVE-2025-6218 – WinRAR Path Traversal (RCE)

  • Klasa błędu: CWE-22 (path traversal) w obsłudze ścieżek wewnątrz archiwów.
  • Wektor: zdalny, wymagana interakcja (otwarcie pliku/odwiedzenie strony).
  • Skutek: zdalne wykonanie kodu z uprawnieniami bieżącego użytkownika.
  • Łatki: WinRAR ≥ 7.12; dorobek analityczny i oś czasu ujawnienia w ZDI.

Praktyczne konsekwencje / ryzyko

  • Łańcuchy ataku:
    • Windows EoP (CVE-2025-62221) – typowy drugi etap po początkowym naruszeniu (phishing, makro, przeglądarka, sterownik). Eskalacja do SYSTEM ułatwia trwałość, wyłączenie EDR, zrzuty LSASS i lateral movement.
    • WinRAR (CVE-2025-6218) – realny wektor dostarczania przez e-mail/www (fałszywe archiwa .rar/.zip). „Klikalność” użytkowników i powszechność WinRAR czynią z tego vektora atrakcyjny nośnik malware.
  • Zasięg środowisk: Windows klient/serwer (EoP) oraz stacje użytkowników z WinRAR (RCE). Ryzyko rośnie w organizacjach z wysokim odsetkiem BYOD i brakiem centralnych aktualizacji aplikacji. (Wpisy KEV i przeglądy Patch Tuesday).

Rekomendacje operacyjne / co zrobić teraz

1) Łatanie i łagodzenia

  • Windows: niezwłocznie wdrożyć grudniowe poprawki – szczególnie dla komponentu Cloud Files Mini Filter (CVE-2025-62221). Priorytet: systemy z kontami uprzywilejowanymi i hosty brzegowe/jumphony.
  • WinRAR: wymusić wersję ≥ 7.12. Rozważyć odinstalowanie WinRAR tam, gdzie nie jest wymagany biznesowo. Blokada uruchamiania starszych binariów przez AppLocker/WDAC.

2) Kontrole detekcyjne i twardnienie

  • Monitorować nietypowe zdarzenia EoP i tworzenie usług/scheduler tasks po aktualnych exploitach (telemetria EDR/Sysmon). (Korelacja z datą 2025-12-09).
  • Dla WinRAR: filtrować załączniki .rar/.zip z podejrzanymi ścieżkami, sandboxing dynamiczny, reguły YARA dla znanych łańcuchów nadużyć ZDI.
  • Wymusić MOTW/SmartScreen/ASR dla pobranych archiwów; blokować makra i skrypty z katalogów tymczasowych.

3) GRC / zarządzanie podatnościami

  • Oznaczyć oba CVE jako „KEV – priorytet 1” i domknąć SLA ≤ 21 dni (zgodnie z BOD 22-01 – dla FCEB termin 30.12.2025). Dokumentować wyjątki i kompensacje.

Różnice / porównania z innymi przypadkami

  • EoP vs. RCE: Windows CVE-2025-62221 wymaga wstępnego dostępu, ale daje SYSTEM; CVE-2025-6218 może doprowadzić do RCE z uprawnieniami użytkownika – oba komponują się w kill chain (najpierw RCE na stacji, potem EoP).
  • Okno dowozu: Obie pozycje trafiły do KEV tego samego dnia, co usuwa dyskusję „co pierwsze” – łatamy oba przed końcem grudnia.

Podsumowanie / kluczowe wnioski

  • Dwie nowe pozycje KEV (9.12.2025): CVE-2025-62221 (Windows EoP) i CVE-2025-6218 (WinRAR RCE).
  • Termin CISA: 30.12.2025 – realny, krótki horyzont wdrożeniowy.
  • Plan minimum: natychmiastowy rollout poprawek Windows, aktualizacja/wycofanie WinRAR, wzmocnienie filtracji archiwów i telemetrii EDR.

Źródła / bibliografia

  1. NVD (CVE-2025-62221) – wpis z adnotacją KEV, daty dodania i terminu. (NVD)
  2. NVD (CVE-2025-6218) – wpis z adnotacją KEV, daty dodania i terminu; referencje ZDI i WinRAR. (NVD)
  3. ZDI-25-409 – szczegóły techniczne WinRAR Path Traversal i oś czasu. (zerodayinitiative.com)
  4. Tenable – Patch Tuesday (grudzień 2025) – podsumowanie i priorytetyzacja, wzmianka o CVE-2025-62221. (Tenable®)
  5. Zero Day Initiative / ZDI Blog & ZDI listy oraz ZDI/Qualys/ZDI-partnerzy – przekrojowe omówienia grudniowych łatek (wspomagające priorytetyzację). (zerodayinitiative.com)

SAP łata trzy krytyczne luki w wielu produktach (grudzień 2025)

Wprowadzenie do problemu / definicja luki

9 grudnia 2025 r. SAP opublikował biuletyn Security Patch Day z 14 nowymi notami bezpieczeństwa, w tym trzema lukami o randze „Critical”. Poprawki obejmują m.in. SAP Solution Manager, SAP Commerce Cloud (komponenty Tomcat) oraz SAP jConnect (SDK for ASE). SAP zaleca natychmiastowe wdrożenie aktualizacji we wszystkich środowiskach.

W skrócie

  • CVE-2025-42880 (CVSS 9.9)code injection w SAP Solution Manager ST 720; błąd walidacji wejścia może prowadzić do pełnego przejęcia systemu po stronie serwera przez uwierzytelnionego atakującego.
  • CVE-2025-55754 (CVSS 9.6) — podatności w Apache Tomcat wykorzystywanym przez SAP Commerce Cloud (powiązana także CVE-2025-55752); problem z nieprawidłowym „ucieczkowaniem” sekwencji ANSI w logach konsolowych. Zalecana aktualizacja Tomcat do 9.0.109 / 10.1.45 / 11.0.11.
  • CVE-2025-42928 (CVSS 9.1)deserialization w SAP jConnect (SDK for ASE 16.0.4, 16.1); w określonych warunkach użytkownik z wysokimi uprawnieniami może osiągnąć RCE przygotowanym wejściem.

Kontekst / historia / powiązania

Zestaw poprawek wpisuje się w trend intensywnego łatana krytycznych błędów w ekosystemie SAP. W 2025 r. obserwowano już ataki in-the-wild na inną lukę typu wstrzyknięcie kodu w SAP (CVE-2025-42957), co zwiększa ryzyko szybkiego instrumentowania świeżo ujawnianych usterek.
Niezależne analizy (Onapsis) wskazują, że część z grudniowych „HotNews” dotyczy komponentów o dużym zasięgu i złożonych zależnościach (np. Tomcat w SAP Commerce Cloud), co komplikuje priorytetyzację i wymusza spójne zarządzanie wersjami.

Analiza techniczna / szczegóły luki

CVE-2025-42880 — SAP Solution Manager (ST 720), CVSS 9.9

Brak właściwej sanitacji danych wejściowych przy wywołaniu remote-enabled function module umożliwia uwierzytelnionemu atakującemu wstrzyknięcie kodu i przejęcie kontroli nad systemem (CIA: H/H/H; wektor AV:N/AC:L/PR:L/UI:N/S:C).

CVE-2025-55754 (+ CVE-2025-55752) — Apache Tomcat w SAP Commerce Cloud, CVSS 9.6

Tomcat niepoprawnie przetwarza sekwencje ANSI w logach; na konsolach Windows wspierających kolorowanie możliwa jest manipulacja konsolą/Schowkiem i nakłonienie administratora do uruchomienia poleceń. SAP agreguje podatności w notę #3683579 dla wersji HY_COM 2205, COM_CLOUD 2211, COM_CLOUD 2211-JDK21. Naprawa: podniesienie Tomcat do wersji 9.0.109 / 10.1.45 / 11.0.11.

CVE-2025-42928 — SAP jConnect (SDK for ASE 16.0.4/16.1), CVSS 9.1

Błąd deserializacji niezaufanych danych (CWE-502) pozwala, „w określonych warunkach”, użytkownikowi o wysokich uprawnieniach wywołać RCE poprzez specjalnie przygotowane dane wejściowe (wektor AV:N/AC:L/PR:H/UI:N/S:C).

Praktyczne konsekwencje / ryzyko

  • Przejęcie instancji SolMana i eskalacja w całym krajobrazie SAP (monitoring, konfiguracja, integracje), co może skutkować trwałym naruszeniem integralności procesów biznesowych.
  • Ryzyka łańcuchowe w e-commerce — podatny Tomcat w SAP Commerce Cloud zwiększa powierzchnię ataku na krytyczne procesy (konta klientów, zamówienia, ceny, integracje ERP/CRM).
  • RCE w warstwie łącznikowej (jConnect) może ułatwić atakującym pivot do systemów bazodanowych i exfiltrację danych o wysokiej wartości.

Rekomendacje operacyjne / co zrobić teraz

  1. Priorytetyzacja wg wpływu i ekspozycji:
      1. CVE-2025-42880 (SolMan ST 720) — natychmiastowe wdrożenie noty #3685270.
      1. CVE-2025-55754/55752 — aktualizacja Tomcat do 9.0.109 / 10.1.45 / 11.0.11 w komponentach SAP Commerce Cloud (nota #3683579). Zweryfikuj wszystkie instancje (również EOL).
      1. CVE-2025-42928 — zastosuj notę #3685286; przejrzyj łańcuchy połączeń i uprawnienia kont używanych przez jConnect.
  2. Tymczasowe osłony (jeśli patch window jest ograniczone):
    • Ogranicz dostęp do funkcji zdalnych w SolMan (RFC), segmentacja sieci, dodatkowa MFA dla kont technicznych.
    • W Commerce Cloud: wyłącz uruchamianie w konsoli, przekieruj logi Tomcat do plików/siem, wymuś aktualne runtimes.
    • Dla jConnect: allow-list źródeł połączeń, walidacja danych, monitorowanie nietypowych ładunków serializacyjnych.
  3. Detekcja i monitoring:
    • Szukaj w SIEM m.in. nieoczekiwanych wywołań RFC/RFM w SolMan, nietypowych wzorców w logach Tomcat (sekwencje ESC[), anomalii w ruchu JDBC/jConnect. (Mapowanie do CVE wg biuletynu SAP i NVD).
  4. Higiena wersji:
    • Porównaj wersje Tomcat z tabelami „Security” producenta; utrzymuj min. 9.0.109/10.1.45/11.0.11.
  5. Procesy DevSecOps:
    • Dodaj testy regresyjne pod kątem deserializacji/escape sequences w CI, włącz skanowanie zależności i SCA.

Różnice / porównania z innymi przypadkami

  • Atakowalność: SolMan (PR:L) jest groźny, bo uderza w centralny system ALM z wysokimi uprawnieniami i szerokimi integracjami. jConnect wymaga PR:H, ale skutki RCE są systemowe. Tomcatowe CVE w Commerce Cloud ma profil bardziej „admin-tricking” (manipulacja konsolą), jednak w środowiskach operacyjnych może prowadzić do wykonania poleceń przez operatora.
  • Porównanie z tegorocznymi kampaniami: w 2025 r. widzieliśmy już aktywną eksploatację innej krytycznej luki SAP (CVE-2025-42957) — to sygnał, że „time-to-exploit” dla ekosystemu SAP skraca się po publikacji poprawek.

Podsumowanie / kluczowe wnioski

  • Grudniowy Patch Day SAP przynosi 3 krytyczne luki o szerokim wpływie na krajobraz SAP (ALM, e-commerce, warstwa łącznikowa DB). Patchuj niezwłocznie.
  • Dla SAP Commerce Cloud aktualizacje Tomcat do 9.0.109/10.1.45/11.0.11 są kluczowe, a zarządzanie wersjami powinno objąć wszystkie środowiska.
  • Utrzymuj detekcję anomalii i kontrolę uprawnień — wcześniejsze incydenty pokazują, że luki SAP szybko trafiają na radar aktorów zagrożeń.

Źródła / bibliografia

  • SAP Security Patch Day — December 2025 (lista not, wersje, CVSS). (SAP Support Portal)
  • BleepingComputer: „SAP fixes three critical vulnerabilities across multiple products”. (omówienie i kontekst). (BleepingComputer)
  • NVD: CVE-2025-42880 (Solution Manager), CVE-2025-42928 (jConnect), CVE-2025-55754 (Tomcat). (NVD)
  • Apache Tomcat Security — wersje naprawcze 9.0.109 / 10.1.45 / 11.0.11. (tomcat.apache.org)
  • Onapsis — Patch Day (grudzień 2025) — analiza i priorytetyzacja „HotNews”. (Onapsis)

Microsoft łata 57 luk (w tym 3 zero-day). Co wiemy o grudniowym Patch Tuesday 2025?

Wprowadzenie do problemu / definicja luki

Grudniowy Patch Tuesday (9 grudnia 2025) domyka rok paczką poprawek Microsoftu. Firma załatała 57 podatności, w tym trzy zero-day (jedna aktywnie wykorzystywana) — liczby te mogą się minimalnie różnić w zależności od metodologii liczenia poszczególnych serwisów (56–57 CVE). Najpoważniejsza z nich to CVE-2025-62221 w Windows Cloud Files Mini Filter Driver, która umożliwia podniesienie uprawnień do SYSTEM.

W skrócie

  • Liczba poprawek: 57 wg SecurityWeek/BleepingComputer; część analiz operuje liczbą 56 CVE (różnice w wliczaniu komponentów Chromium/Edge/Mariner).
  • Zero-day (3):
    • CVE-2025-62221 – Cloud Files Mini Filter (EoP), aktywnie wykorzystywana.
    • CVE-2025-64671GitHub Copilot for JetBrains (RCE), publicznie ujawniona.
    • CVE-2025-54100PowerShell (RCE/command injection), publicznie ujawniona.
  • Najwięcej klas: podniesienie uprawnień (EoP) oraz RCE (w tym Office/Outlook).

Kontekst / historia / powiązania

Końcówka 2025 r. stoi pod znakiem licznych EoP po stronie Windows oraz rosnącej liczby błędów w ekosystemie narzędzi AI/IDE (przykład: Copilot dla JetBrains z podatnością na cross-prompt injection prowadzącą do command injection). Trend ten był sygnalizowany w analizach ZDI oraz mediów branżowych przez cały rok.

Analiza techniczna / szczegóły luki

1) CVE-2025-62221 – Windows Cloud Files Mini Filter Driver (EoP)

  • Typ: Use-After-Free w sterowniku mini-filtra Cloud Files.
  • Skutek: lokalne podniesienie uprawnień do SYSTEM; idealny łącznik w łańcuchach RCE→EoP.
  • Status: aktywnie wykorzystywana na wolności; brak szczegółów TTP od Microsoftu.

Dodatkowo Microsoft załatał pokrewne EoP w tym samym komponencie (np. CVE-2025-62454), które są „likely to be exploited”. Wskazuje to na szerszą klasę błędów w Cloud Files.

2) CVE-2025-64671 – GitHub Copilot for JetBrains (RCE)

  • Przyczyna: command injection wyzwalany m.in. przez cross-prompt injection w nieufnych plikach lub serwerach MCP; możliwe do wykorzystania lokalnie, ale realnie z wektorem socjotechnicznym.

3) CVE-2025-54100 – PowerShell (RCE)

  • Przyczyna: nieprawidłowa neutralizacja danych z sieci; Invoke-WebRequest mógł wykonywać skrypt osadzony w pobieranej stronie.
  • Zmiana: dodano ostrzeżenie i rekomendację użycia -UseBasicParsing.

Office/Outlook i inne komponenty

  • Office RCE: m.in. CVE-2025-62554 i CVE-2025-62557 (wektor Preview Pane).
  • Outlook RCE: CVE-2025-62562, w specyficznych warunkach oceniona jako krytyczna.
  • Azure/AMA, RRAS, ReFS: poprawki obejmują też AMA (RCE), RRAS (RCE/Info Disclosure) i ReFS (RCE).

Praktyczne konsekwencje / ryzyko

  • Eskalacja uprawnień (zwłaszcza przez CVE-2025-62221) znacząco obniża barierę przejścia z początkowego footholda (np. makro, złośliwy skrót .LNK, exploit w przeglądarce) do pełnej kompromitacji hosta.
  • Łańcuchy z AI/IDE: błąd w Copilot for JetBrains pokazuje, że prompt injection może być punktem wejścia do command injection w lokalnym środowisku deweloperskim.
  • PowerShell jako narzędzie ofensywne: podatność łączy się z powszechnymi TTP (living-off-the-land), zwiększając ryzyko „cichego” wykonania kodu podczas automatyzacji/parsingu treści web.

Rekomendacje operacyjne / co zrobić teraz

  1. Priorytetyzuj wdrożenie poprawek dla Windows/Office oraz CVE-2025-62221 (Cloud Files), CVE-2025-64671 (Copilot for JetBrains) i CVE-2025-54100 (PowerShell).
  2. Stacje deweloperskie:
    • Wyłącz auto-approve komend w terminalu IDE.
    • Ogranicz zaufanie do plików/serwerów MCP; egzekwuj polityki „trusted workspace”.
  3. PowerShell hardening:
    • Wymuś Constrained Language Mode tam, gdzie to możliwe; monitoruj użycie Invoke-WebRequest i wymagaj -UseBasicParsing.
    • Zbieraj i koreluj logi Script Block/Module Logging.
  4. Higiena Windows:
    • Włącz Attack Surface Reduction (ASR), Credential Guard i bieżące reguły Defendera.
    • Segmentuj uprawnienia administratorów lokalnych, minimalizuj konta z prawami instalacji sterowników/filtrów. (Wnioski zgodne z analizami ZDI/DR dot. przewagi EoP).
  5. Office/Outlook:
    • Ogranicz Preview Pane i zablokuj automatyczne przetwarzanie zawartości zewnętrznej.
    • Wdróż reguły transportowe DLP/AV dla załączników typowych w atakach socjotechnicznych.

Różnice / porównania z innymi przypadkami

  • Rozbieżność 56 vs 57 CVE: Tenable/ZDI wskazują 56 (bez części elementów Chromium/Edge/Mariner), podczas gdy media (SecurityWeek/BleepingComputer/Dark Reading) raportują 57 – to różnica metodologiczna, nie merytoryczna. Ważniejsze są trzy zero-day i ich priorytety.
  • Kontynuacja trendu: podobnie jak w poprzednich miesiącach, dominują EoP i komponenty Office/Outlook; październik/listopad również zawierały głośne luki łączone w łańcuchy ataków.

Podsumowanie / kluczowe wnioski

  • Patch now: załataj CVE-2025-62221 (aktywnie wykorzystywana), CVE-2025-64671 (Copilot/JetBrains) i CVE-2025-54100 (PowerShell).
  • Zadbaj o stacje dev i PowerShell: wyłącz automaty, które mogą „dokleić” komendy; loguj i ograniczaj PowerShell.
  • Traktuj EoP jako „must-fix”: to spoiwo dla większości udanych łańcuchów ataku w Windows w 2025 r.

Źródła / bibliografia

  • SecurityWeek: „Microsoft Patches 57 Vulnerabilities, Three Zero-Days” (09.12.2025). (SecurityWeek)
  • BleepingComputer: „Microsoft December 2025 Patch Tuesday fixes 3 zero-days, 57 flaws” (09.12.2025). (BleepingComputer)
  • Trend Micro ZDI: „The December 2025 Security Update Review” (09.12.2025). (zerodayinitiative.com)
  • Tenable: „Microsoft’s December 2025 Patch Tuesday Addresses 56 CVEs” (09.12.2025). (Tenable®)
  • Dark Reading: „Microsoft Fixes Exploited Zero Day in Light Patch Tuesday” (09.12.2025). (Dark Reading)

JS#SMUGGLER: jak atak przez zaufane witryny instaluje NetSupport RAT (pełna analiza i zalecenia)

Wprowadzenie do problemu / definicja luki

Badacze potwierdzili nową kampanię JS#SMUGGLER, która wykorzystuje skompromitowane strony WWW jako wektor dystrybucji malware. Atak przebiega wieloetapowo: obfuskowany JavaScript wstrzyknięty w witrynę uruchamia zdalny HTA (HTML Application) przez mshta.exe, a następnie odszyfrowany PowerShell pobiera i uruchamia NetSupport RAT – narzędzie zdalnej administracji nadużywane do pełnej kontroli stacji roboczych ofiary.


W skrócie

  • Wejście: ukryte iframy i przekierowania z zaufanych (lecz skompromitowanych) serwisów do obfuskowanego loadera phone.js.
  • Egzekucja: loader dynamicznie dobiera ścieżkę (mobile vs desktop), buduje URL-e kolejnych etapów i uruchamia HTA przez mshta.exe.
  • Payload: zaszyfrowane (AES + Base64/GZIP) stager’y PowerShell usuwają swoje artefakty i pobierają NetSupport RAT z utrzymaniem trwałości.
  • Cel: trwała zdalna kontrola, kradzież danych, operacje plikowe i wykonywanie poleceń.
  • Technika: nadużycie mshta.exe (MITRE ATT&CK T1218.005 – Mshta) jako signed binary proxy execution.

Kontekst / historia / powiązania

Nadużywanie legalnych narzędzi RMM i binariów systemowych (Living-off-the-Land) jest trendem utrzymującym się w 2024–2025 – NetSupport był wielokrotnie dostarczany w kampaniach e-mail i „fake update”/ClickFix. Organizacje raportowały przesunięcie akcentu: od fałszywych aktualizacji do socjotechniki ClickFix i dostarczania RMM jako „pierwszego etapu”.


Analiza techniczna / szczegóły luki

Etap 1 – Loader JS (phone.js):

  • Wstrzyknięty w skompromitowaną witrynę, korzysta z ukrytych iframe’ów i cichych przekierowań.
  • Zawiera „śmietnikowe” komentarze i tablice rotowane runtime’em; dekoduje łańcuchy przez funkcje indeksujące, utrudniając statyczną analizę.
  • Używa localStorage do jednorazowego odpalenia logiki (redukcja szumu detekcyjnego).
  • Rozgałęzia ścieżkę w zależności od urządzenia (mobile: fullscreen iframe; desktop: dociągnięcie skryptu 2. fazy).

Etap 2 – HTA przez mshta.exe:

  • Loader konstruuje w locie URL HTA i uruchamia go wykorzystując mshta.exe – zaufany komponent Windows wykorzystywany do proksowania wykonania kodu (MITRE T1218.005).
  • HTA uruchamia zaszyfrowane stager’y PowerShell, minimalizuje okna i ukrywa artefakty, by ograniczyć ślad forensyczny.

Etap 3 – PowerShell → NetSupport RAT:

  • Stager’y AES-256-ECB + Base64/GZIP pobierają, rozpakowują i uruchamiają NetSupport RAT, konfigurując persistencję (m.in. skróty w Autostarcie).
  • NetSupport daje atakującym m.in. zdalny pulpit, transfer plików, egzekucję poleceń, proxy i kradzież danych.

Praktyczne konsekwencje / ryzyko

  • Omijanie zabezpieczeń: wykorzystanie zaufanych domen (kompromitowanych serwisów) i signed binariów (mshta.exe) utrudnia detekcję sygnaturową i reputacyjną.
  • Eskalacja wpływu: po instalacji NetSupport umożliwia trwałą obecność, eksfiltrację danych oraz „hands-on-keyboard”.
  • Szeroki zasięg: kampania celuje w użytkowników korporacyjnych przeglądających zwykłe strony, co zwiększa powierzchnię ataku poza e-mailem.

Rekomendacje operacyjne / co zrobić teraz

Twarde kontrole:

  1. Blokady LoLBin: ogranicz/zasady SRP/AppLocker dla mshta.exe, wscript.exe, cscript.exe – przynajmniej poza zaufanymi kontenerami. (MITRE T1218.005)
  2. CSP i nagłówki przeglądarkowe: wymuś Content-Security-Policy (blok skryptów z nieautoryzowanych domen, frame-ancestors), X-Frame-Options dla własnych serwisów.
  3. Egress i DNS: kontrola wyjścia do świeżo zarejestrowanych domen / nietypowych TLD; segmentacja i proxy z inspekcją TLS. (wnioskowane na bazie łańcucha C2)
  4. Ochrona endpointów: włącz PowerShell Constrained Language Mode, Script Block/Module Logging, AMSI i rejestrowanie zdarzeń 4104.
  5. Monitorowanie mshta/HTA: reguły EDR/SIEM na zdalne HTA uruchamiane przez mshta.exe (np. event + command line zawierający URL/HTA). Dostępne gotowe reguły detekcyjne wskazują na wartość takiego use-case’u.

Detekcje (przykładowe sygnały):

  • Process = mshta.exe AND CommandLine CONTAINS http/https OR *.hta. (MITRE T1218.005)
  • powershell.exe z ciągami FromBase64String, GZIP, AES, Expand-Archive, New-Object Net.WebClient.
  • Tworzenie skrótów w %AppData%\Microsoft\Windows\Start Menu\Programs\Startup\.
  • Połączenia do domen/ścieżek podobnych do */call/phone.js i nietypowych hostów wskazanych w analizie.

Higiena i reagowanie:

  • Hardening przeglądarek i serwerów WWW, skan integracyjny pod kątem wstrzyknięć JS/iframe.
  • Playbook IR dla NetSupport/RMM nadużywanych – odcięcie hosta, usunięcie autostartu, inwentaryzacja kont i sesji, rotacja poświadczeń, przegląd ruchu proxy/VPN. (wspierane wcześniejszymi obserwacjami kampanii z NetSupport)
  • Uświadamianie użytkowników w zakresie fałszywych „napraw kliknięciem” (ClickFix) oraz ostrzeżeń o skryptach PowerShell.

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

W odróżnieniu od mailowych kampanii z NetSupport (częste u graczy finansowo motywowanych), JS#SMUGGLER omija e-mail i wchodzi przez skompromitowane strony oraz łańcuch web-owy (JS→HTA→PowerShell). To zbliża go do ataków fake update/ClickFix, ale tutaj kluczową rolę gra mshta.exe jako signed binary oraz warunkowe branching po stronie JS (mobile vs desktop), co utrudnia replikację i detekcję.


Podsumowanie / kluczowe wnioski

  • JS#SMUGGLER to dojrzała, warstwowa operacja web-malware z naciskiem na stealth i selektywność ekzekucji.
  • Krytycznym elementem jest nadużycie mshta.exe (T1218.005) i zaszyfrowane stager’y PowerShell, które dostarczają NetSupport RAT.
  • Obrona musi łączyć polityki wykonywania, telemetrię PowerShell, kontrole przeglądarkowe (CSP) i monitoring LoLBin – same blokady domen nie wystarczą.

Źródła / bibliografia

  1. The Hacker News – „Experts Confirm JS#SMUGGLER Uses Compromised Sites to Deploy NetSupport RAT”, 8 grudnia 2025. (The Hacker News)
  2. Securonix Threat Research – „JS#SMUGGLER: Multi-Stage – Hidden iframes, Obfuscated JavaScript, Silent Redirectors & NetSupport RAT Delivery”, 3 grudnia 2025. (Securonix)
  3. MITRE ATT&CK – „T1218.005 Mshta (Signed Binary Proxy Execution)”. (attack.mitre.org)
  4. Proofpoint – „Remote Monitoring and Management (RMM) tooling increasingly attackers’ first choice”, 7 marca 2025. (kontekst NetSupport/RMM) (proofpoint.com)
  5. eSentire – „Unpacking NetSupport RAT Loaders Delivered via ClickFix”, 23 października 2025. (tło i taktyki z 2025) (eSentire)

LockBit 5: „nowa, bezpieczna domena bloga” i… błyskawiczny wyciek infrastruktury

Wprowadzenie do problemu / definicja luki

LockBit 5.0 ogłosił „nową, bezpieczną domenę bloga z wielowarstwową ochroną przed wszechmocnym FBI”. Zaledwie kilkadziesiąt godzin później OSINT-owcy i media branżowe powiązali tę infrastrukturę z konkretną domeną i adresem IP, ujawniając wrażliwe szczegóły konfiguracji serwera. To kolejny przykład kompromitacji higieny operacyjnej (opsec) gangu po jego powrocie na scenę.

W skrócie

  • Nowa infrastruktura LockBit 5.0 została powiązana z domeną karma0[.]xyz oraz adresem IP 205.185.116.233 (AS53667 – PONYNET/FranTech).
  • Serwer wykazywał otwarte porty wysokiego ryzyka (m.in. 3389/TCP – RDP, 5985 – WinRM), co przeczy narracji o „wielowarstwowej ochronie”.
  • Na nowym DLS (data leak site) pojawiły się recyklingowane wpisy ofiar – część ofiar miała pochodzić z wcześniejszych wycieków i innych grup (Weyr0/RansomHouse).
  • Równolegle monitorujący leak-sitów odnotowali nowy onion dla „bezpiecznego bloga”.
  • W szerszym tle: po Operation Cronos (luty 2024) gang odbudował się i w 2025 r. wypuścił LockBit 5.0 z technicznymi usprawnieniami.

Kontekst / historia / powiązania

Operacja służb „Cronos” w lutym 2024 r. uderzyła w infrastrukturę i panele LockBit, co znacząco ograniczyło jego możliwości – ale nie zakończyło działalności afiliantów. W 2025 r. gang ogłosił wersję 5.0 i stopniowo odbudował ekosystem RaaS. Dzisiejsza wpadka z domeną i IP wpisuje się w pasmo problemów opsec po serii wcześniejszych ekspozycji zaplecza grupy.

Analiza techniczna / szczegóły luki

  • Punkty wiązania (pivoty): badacze powiązali „nowy bezpieczny blog” z domeną karma0[.]xyz (zwracała stronę z brandingiem „LOCKBITS.5.0”) oraz adresem 205.185.116.233 w AS53667 (PONYNET/FranTech). Dane te zostały publicznie opublikowane na X (Twitter) przez analityka OSINT i następnie opisane w serwisach branżowych.
  • Konfiguracja usług: skany zewnętrzne wskazywały na wiele otwartych portów, m.in. 21/FTP, 80/HTTP (Apache/2.4.58 + PHP 8.0.30), 3389/RDP, 5000/HTTP, 5985/WinRM, 47001/HTTP i 49666 (usługa plików). Obecność RDP/3389 i WinRM/5985 na hostach przestępczych to rzadko spotykany błąd opsec, ułatwiający identyfikację, fingerprinting i potencjalne zakłócenia. (Uwaga: lista portów pochodzi z publikacji branżowej; nie stanowi niezależnie zweryfikowanego skanu.)
  • Metadane rejestracyjne: w materiałach pojawia się rozbieżność dat WHOIS (część źródeł podaje rejestrację 2 listopada 2025, inne – 12 kwietnia 2025 i użycie nameserverów Cloudflare). To typowe w przypadku prywatności WHOIS i zmian rejestratora; należy traktować te daty jako niejednoznaczne.
  • Nowy onion / DLS: wpis monitorujący leak-sity wskazuje nowy adres .onion opisany przez LockBit jako „new secure blog domain with a multi-layered protection system”.

Praktyczne konsekwencje / ryzyko

  • Ryzyko eskalacji DDoS i ingerencji: publiczne powiązanie adresu IP i domeny zwiększa szansę na działania obronne (blokady, zgłoszenia nadużyć) oraz kolizję z innymi gangami/crowd-sourcowanymi atakami.
  • Podważona wiarygodność DLS: sygnały o recyklingu ofiar podkopują presję negocjacyjną LockBit (ofiary i negocjatorzy mogą uznać nowe „publikacje” za blef).
  • Wymierne IOCs dla obrony: karma0[.]xyz, 205.185.116.233, AS53667 i nowy onion to artefakty do blokowania i korelacji w telemetrii SOC/TI.
  • Nieprzerwany rozwój narzędzi TTP: mimo wpadek opsec, LockBit 5.0 pozostaje technicznie dojrzały (wieloplatformowość: Windows/Linux/ESXi, obfuscation, utrudnianie analizy, szybkie szyfrowanie), co przekłada się na wciąż wysokie ryzyko dla organizacji.

Rekomendacje operacyjne / co zrobić teraz

Blokady i detekcje (prewencja):

  • Dodać do polityk blokowania: karma0[.]xyz, 205.185.116.233, segmenty AS53667; monitorować ewentualne rotacje IP/domen.
  • Aktualizować listy domen/URL DLS/CS w secure web gateway/EDR/NDR.
  • W regułach IDS/IPS oraz SIEM dodać korelację na nowy onion (jeśli telemetrycznie widoczny w ruchu TOR).

Twardnienie środowisk:

  • Egzekwować MFA + restrykcje sieciowe na RDP/WinRM/SSH/VPN; dla RDP – preferować RD Gateway + Just-In-Time + przesiadka na tunelowane połączenia bastionowe.
  • Wyłączyć SMB v1, ograniczyć „shadow copy” i włączyć tamper protection w EDR.
  • Wdrożyć application allowlisting dla hostów serwerowych, segmentację sieci (zwłaszcza ESXi/hiperwizory) i kopie zapasowe 3-2-1 z testem odtwarzania.

Detekcje TTP (przykłady):

  • Wykrywanie masowego rename + nietypowe rozszerzenia plików, wyłączenia ETW, zabijania usług AV/EDR, zrzutów LSASS, eksfiltracji poprzez tunelowanie HTTP(S)/TOR.
  • Korelowanie artefaktów LockBit 5.0 ze wskaźnikami znanymi z badań (np. obfuskacja, dynamiczne rozwiązywanie API, wsparcie ESXi).

Reakcja i komunikacja:

  • Przy incydentach z „LockBit 5.0” ocenić autentyczność wpisu na DLS – weryfikować, czy nie jest to recykling. Nie płacić za „stare” dane.

Różnice / porównania z innymi przypadkami

W przeszłości wycieki infrastruktury dotyczyły m.in. paneli afiliańckich i czatów LockBit (2025), ale obecny incydent jest nietypowy, bo uderza w „nową, wzmocnioną” domenę PR-owo reklamowaną przez gang – i to niemal natychmiast po starcie. W materialne technicznym 5.0 widać progres po stronie malware’u, podczas gdy opsec i warstwa publikacyjna pozostają piętą achillesową operacji.

Podsumowanie / kluczowe wnioski

  • LockBit 5.0 traci narrację o „nietykalności”: domena karma0[.]xyz i 205.185.116.233 szybko trafiły do publicznych IOCs, a serwer wyglądał na słabo utwardzony.
  • Recykling ofiar dodatkowo podważa presję szantażową gangu.
  • Dla obrońców to moment na blokady, korelacje i hunting z użyciem świeżych wskaźników, pamiętając, że technicznie LockBit 5.0 pozostaje niebezpieczny.

Źródła / bibliografia

  1. DataBreaches.net: „LockBit 5’s ‘new secure blog domain’ infra leaked already” (07.12.2025). (DataBreaches.Net)
  2. CyberSecurityNews: „LockBit 5.0 Infrastructure Exposed in New Server, IP, and Domain Leak” (07.12.2025). (Cyber Security News)
  3. Ransomware.live: wpis „new blog domain lockbit 5.0” (05.12.2025). (Ransomware Live)
  4. Europol: „Law enforcement disrupt world’s biggest ransomware operation” (20.02.2024). (Europol)
  5. Trend Micro Research: „New LockBit 5.0 Targets Windows, Linux, ESXi” (25.09.2025). (www.trendmicro.com)

Anubis RaaS: niedoceniane zagrożenie dla sektora medycznego. Co wiemy i jak się bronić

Wprowadzenie do problemu / definicja luki

W czasie gdy część grup ransomware ogranicza się do podwójnego wymuszenia (exfiltracja + publikacja danych), Anubis pozostaje wierny klasycznej enkrpycji systemów – a dodatkowo dorzuca funkcję niszczenia danych (wiper). Ten Ransomware-as-a-Service (RaaS) coraz częściej pojawia się na leak-sitach z ofiarami z sektora ochrony zdrowia w USA, co potwierdzają najnowsze doniesienia o ataku na praktykę Mid South Pulmonary & Sleep Specialists (MSPS) w Tennessee.

W skrócie

  • Anubis RaaS łączy szyfrowanie z opcjonalnym /WIPEMODE, który trwale usuwa zawartość plików – znacząco obniżając szanse odzysku.
  • Grupa działa od końca 2024 r., wywodzi się z projektu „Sphinx”, celuje m.in. w Windows/Linux/NAS/ESXi, a wśród branż figuruje ochrona zdrowia.
  • Na leak-site Anubisa w listopadzie pojawiło się co najmniej pięć podmiotów medycznych z USA, z ujawnionym PHI; w wielu przypadkach brak publicznych notyfikacji i wpisów w narzędziu HHS.
  • Atak na MSPS: dostęp uzyskany 10 listopada, tydzień rekonesansu, szyfrowanie środowiska Nutanix, exfiltracja ~860 GB danych, część już wyciekła. (Deklaracje gangu, potwierdzane przez przegląd drzewa plików).
  • Obrona: segmentacja i EDR/XDR, niezmienne kopie (immutable) z 3-2-1-1-0, hardening hypervisorów i konsol, MFA wszędzie, plan IR zgodny z CISA Stop Ransomware.

Kontekst / historia / powiązania

Według analiz, Anubis to nowa operacja RaaS aktywna od grudnia 2024 r., która w warstwie technicznej i brandingowej ewoluowała z „Sphinx”. Rozwija elastyczny program afiliacyjny i – w przeciwieństwie do „exfil-only” – regularnie szyfruje zasoby ofiar.

Analiza techniczna / szczegóły luki

Łańcuch ataku i TTPs (wybrane):

  • Wejście: spear-phishing z linkami/załącznikami; użycie ważnych kont (T1566, T1078).
  • Wykonanie: parametry uruchomieniowe, m.in. "/KEY=", "/elevated", "/WIPEMODE", "/PATH=", "/PFAD=".
  • Eskalacja i unikanie: sprawdzanie uprawnień admina, próby podniesienia do SYSTEM, manipulacja tokenami (T1134.002).
  • Uderzenie: kasowanie VSS (vssadmin delete shadows), zatrzymywanie usług backup/DB/AV, szyfrowanie ECIES (Golang), opcjonalne wipowanie zawartości, rozszerzenie .anubis, notatka RESTORE FILES.html.

Specyfika „wipera”: przełącznik /WIPEMODE umożliwia zniszczenie treści plików po (lub zamiast) szyfrowania – utrwalając szkodę i wymuszając zapłatę nawet przy poprawnych procedurach backupu, jeśli kopie nie są odporne na modyfikacje.

Praktyczne konsekwencje / ryzyko

  • Bezpośrednie ryzyko dla ciągłości opieki: paraliż HIS/EHR, laboratoria, grafiki zabiegowe, systemy billingowe; przy wiperze – długotrwała utrata danych.
  • Ryzyko regulacyjne (HIPAA/HITECH): wyciek PHI ⇒ obowiązki notyfikacyjne; brak szybkich zgłoszeń uwypukla lukę komunikacyjną pomiędzy ofiarami a HHS/OCR.
  • Ryzyko reputacyjne i prawne: dług ogłoszeń, pozwy zbiorowe, presja płatników i ubezpieczycieli.
  • Ryzyko infrastrukturalne: ataki na hypervisor/VM/NAS/ESXi/Nutanix i systemy kopii zapasowych – jeżeli nie są izolowane/niemodyfikowalne, wiper je unieszkodliwi.

Rekomendacje operacyjne / co zrobić teraz

  1. Kopie niemodyfikowalne i odseparowane (immutable + air-gap)
    • Zastosuj 3-2-1-1-0 (co najmniej jedna kopia offline/immutable, weryfikacja odzysku bez błędów).
    • Testuj DR pod scenariusz „ransomware + wiper” (RTO/RPO).
  2. Segmentacja i zasada najmniejszych uprawnień
    • Mikrosegmentacja sieci klinicznych (EHR/PACS/IoMT) i odseparowanie konsol zarządczych (Nutanix/VMware/NAS).
  3. Hardening hypervisorów i konsol
    • MFA na SSH/API/konsolach, rotacja i escrow kluczy, zamrożenie ścieżek administracyjnych „break-glass”, blokada dostępu zdalnego „z internetu”.
  4. EDR/XDR + telemetria
    • Polowania na wskaźniki: nietypowe vssadmin, masowe Stop-Service, procesy z parametrami "/WIPEMODE"/"/elevated", nietypowe operacje na \\.\PHYSICALDRIVE0.
  5. Twarde MFA i higiena kont
    • Wyłącz konta lokalne, klucze FIDO2 dla administratorów, „Privileged Access Workstations” dla operacji na hypervisorach.
  6. E-mail i tożsamość
    • Zaawansowana filtracja (DMARC/DKIM/SPF), izolacja URL/załączników, szkolenia o spear-phishingu.
  7. Plan reagowania (IR) zgodny z CISA Stop Ransomware
    • Gotowe playbooki: triage, izolacja, powiadomienia, ścieżka prawna/HIPAA, komunikacja z pacjentami/regulatorami.

Różnice / porównania z innymi przypadkami

  • LockBit/BlackCat/BianLian często kładą nacisk na exfiltrację i presję medialną; Anubis dodatkowo eskaluje presję przez wiper – co przy braku immutable-backupów czyni incydent bardziej destrukcyjnym. (Wniosek na podstawie porównań TTP i funkcji technicznych opisanych przez badaczy).
  • Targeting: w ostatnich tygodniach Anubis wyraźnie listuje podmioty medyczne z USA (przykład: MSPS), co odróżnia go od grup polujących szerzej w sektorach przemysłowych.

Podsumowanie / kluczowe wnioski

  • Anubis to „hybrydowy” RaaS z wiperem – zagraża ciągłości opieki i odzyskowi danych nawet w dobrze prowadzonych środowiskach, jeśli kopie nie są niezmienialne.
  • W listopadzie leak-site gangu wypełnił się podmiotami ochrony zdrowia z USA, a komunikacja kryzysowa bywa opóźniona.
  • Priorytetem są: immutable backupy, hardening warstwy wirtualizacji/NAS, EDR/XDR z detekcją „wiperowych” TTP, MFA wszędzie oraz playbook CISA.

Źródła / bibliografia

  • DataBreaches.net — They’ve escaped a lot of media attention, but Anubis RaaS is a threat to the medical sector (MSPS, listopadowe listingi HPH, PHI). (DataBreaches.Net)
  • Trend Micro — Anubis: A Closer Look at an Emerging Ransomware with Built-in Wiper (TTP, parametry, ECIES, profil ofiar). (www.trendmicro.com)
  • KPMG CTI — Anubis Ransomware – Weaponizing Wipers for Extortion (pochodzenie „Sphinx”, /WIPEMODE, platformy, branże).
  • Ransomware.live — wpis ofiary Mid South Pulmonary & Sleep Specialists (claim Anubis, data). (Ransomware Live)
  • CISA — Stop Ransomware: Ransomware Guide (prewencja i checklisty reakcji). (CISA)