Archiwa: Windows - Strona 91 z 98 - Security Bez Tabu

Tag: Windows

Qilin (dawniej Agenda) nadużywa WSL, aby uruchamiać linuksowe szyfratory w Windows. Co to oznacza dla SOC?

Wprowadzenie do problemu / definicja luki

Operatorzy ransomware Qilin (znani wcześniej jako Agenda) zostali zaobserwowani przy uruchamianiu linuksowych binarek szyfrujących na hostach Windows poprzez Windows Subsystem for Linux (WSL). Ten zabieg utrudnia wykrywanie, bo wiele rozwiązań EDR/NDR ma profil detekcji skupiony na natywnych procesach Windows i klasycznych łańcuchach ataku. Informację nagłośnił 28 października 2025 r. serwis BleepingComputer, opierając się na świeżych obserwacjach z kampanii Qilin.

W skrócie

  • Nowy wektor: uruchamianie linuksowego szyfratora w Windows przez WSL, często dostarczanego z legalnymi narzędziami RMM/transferu plików.
  • Cel atakującego: ominięcie części polityk EDR/AV, które nie śledzą dokładnie artefaktów i syscalls powiązanych z WSL.
  • TTPs w kampaniach Qilin: zdalne zarządzanie (AnyDesk/ScreenConnect/Quick Assist), BYOVD do wyłączania zabezpieczeń, lateral movement po kradzieży poświadczeń.
  • Skala i dotkliwość: Qilin jest aktywną operacją RaaS od 2022 r.; w 2025 r. łączono go m.in. z atakami na podmioty przemysłowe i produkcyjne (np. Asahi Group w Japonii).

Kontekst / historia / powiązania

Qilin wystartował jako Agenda w 2022 r., szybko ewoluując (m.in. wariant Rust, szyfrowanie przerywane, wersje na Linux/ESXi). W 2024 r. amerykańskie HHS opublikowało profil zagrożenia Agenda/Qilin, opisując klasyczne wektory wejścia (phishing, RDP/VPN, kradzież poświadczeń). Dzisiejsze kampanie dodają warstwę „cross-platform” dzięki WSL.

W październiku 2025 r. media informowały o przypisywaniu przez Qilin głośnych incydentów w sektorze produkcyjnym (Asahi Group). To wskazuje, że grupa celuje w operacje o niskiej tolerancji na przestoje, gdzie presja na zapłatę okupu jest większa.

Analiza techniczna / szczegóły ataku

Łańcuch ataku obserwowany w kampaniach Qilin (Agenda):

  1. Dostęp początkowy: phishing, nadużycie RDP/VPN lub skompromitowane konta; następnie instalacja legalnych narzędzi RMM (AnyDesk, ScreenConnect, Quick Assist itd.) dla utrwalenia i ręcznego sterowania.
  2. Przygotowanie środowiska: pobranie komponentów, często z wykorzystaniem BYOVD (Bring Your Own Vulnerable Driver) w celu wyłączenia EDR/AV i eskalacji uprawnień.
  3. Wykorzystanie WSL:
    • Włączenie WSL (jeśli wyłączony) i/lub doinstalowanie dystrybucji,
    • Dostarczenie linuksowego szyfratora ( ELF ),
    • Uruchomienie go w kontekście WSL, co daje dostęp do wolumenów Windows (np. /mnt/c) i udziałów sieciowych.
      Ten krok utrudnia detekcję, jeśli telemetria nie koreluje zdarzeń WSL z aktywnością na NTFS/Samba.
  4. Szyfrowanie i działania końcowe: niszczenie shadow copies/backupów, eksfiltracja i podwójny szantaż. (Warianty Qilin dokumentowano na Windows i Linux/ESXi).

Dlaczego to działa?

  • Procesy w przestrzeni WSL mogą generować IO na dyskach Windows, ale część rozwiązań ochronnych nie ma kompletnej widoczności syscalls/strumieni z warstwy WSL i nie łączy ich z efektami w NTFS. Elastic publikuje konkretne procedury detekcji „Suspicious Execution via WSL” i zaleca korelację telemetryczną (Defender, Sysmon, Endgame).

Praktyczne konsekwencje / ryzyko

  • Zwiększona szansa na „silent failure” detekcji – klasyczne reguły oparte na vssadmin, znanych packerach czy LOLBins Windows mogą nie zadziałać, jeśli właściwy szyfrator działa jako ELF w WSL.
  • Szybsze szyfrowanie zasobów sieciowych – binarka Linux może agresywnie iterować po udostępnionych zasobach (SMB/NFS), redukując czas do pełnego „blast radius”.
  • Ryzyko „false negative” w IR – bez dowodów na klasyczne narzędzia Windows zespoły IR mogą mylnie ocenić źródło szyfrowania i przeoczyć artefakty WSL.

Rekomendacje operacyjne / co zrobić teraz

1) Widoczność i telemetria WSL

  • Włącz logowanie i korelację zdarzeń WSL z IO na NTFS; stosuj gotowe reguły detekcji „Suspicious Execution via WSL” (Elastic) i ich odpowiedniki w SIEM/EDR. Monitoruj uruchomienia wsl.exe, tworzenie nowych dystrybucji i nietypowe procesy potomne.

2) Twarde kontrolki konfiguracyjne

  • Jeśli WSL nie jest potrzebny – wyłącz i egzekwuj to GPO/Intune.
  • Ogranicz instalację/uruchamianie niezatwierdzonych dystrybucji WSL (allow-list).

3) Ochrona przed BYOVD i RMM

  • Blokuj znane podatne sterowniki (WDAC/ Defender Attack Surface Reduction, polityki blokowania sterowników).
  • Wdróż kontrolę legalnych RMM (allow-list + monitorowanie anomalii, m.in. AnyDesk, ScreenConnect, Quick Assist), bo Qilin używa ich do dostarczania ładunku i utrzymania.

4) Backupy i segmentacja

  • Odseparuj repozytoria kopii zapasowych, testuj immutable snapshots i procedury odtwarzania. (Qilin celuje w backupy przed szyfrowaniem).

5) Playbook IR (aktualizacja pod WSL)

  • Dodaj kroki: enumeracja dystrybucji WSL, przegląd procesów ELF, artefaktów w %LOCALAPPDATA%\\Packages\\*Linux*, policji sieciowej WSL (gdy aktywna). Uwzględnij typowe ścieżki montowania (/mnt/c, /mnt/d itd.).

6) Higiena dostępu

  • MFA wszędzie, rotacja haseł po incydencie, zamykanie zbędnych RDP/VPN, polityki najmniejszych uprawnień – to nadal podstawy zgodne z zaleceniami profilu zagrożenia Qilin.

Różnice / porównania z innymi przypadkami

  • Klasyczne ransomware na Windows: bazuje na LOLBins (vssadmin, wmic), API Win32 i anty-debug, które łatwiej profilować.
  • Model Qilin z WSL: cross-platform, mniejsza sygnaturowość w warstwie Windows, inna telemetria, inne artefakty dyskowe i pamięciowe. Wymaga innych punktów obserwacji (mapowanie aktywności WSL ↔ NTFS).

Podsumowanie / kluczowe wnioski

Qilin podnosi poprzeczkę, łącząc Windows z Linuxem na jednym hoście i przesuwając środek ciężkości detekcji do obszarów, które wiele organizacji ignoruje: WSL, BYOVD oraz legalne RMM. Jeżeli nie monitorujesz WSL i nie egzekwujesz polityk RMM/sterowników, zostawiasz widoczną szczelinę w obronie. Priorytetem jest telemetria WSL + kontrola RMM + polityki sterowników + odporne backupy.

Źródła / bibliografia

  1. BleepingComputer – „Qilin ransomware abuses WSL to run Linux encryptors in Windows”, 28 października 2025. (BleepingComputer)
  2. Trend Micro Research – „Agenda Ransomware Deploys Linux Variant on Windows Systems…”, 23 października 2025. (www.trendmicro.com)
  3. Elastic Security – „Suspicious Execution via Windows Subsystem for Linux” (poradnik detekcji). (Elastic)
  4. HHS – „Qilin (Agenda) Threat Profile”, 18 czerwca 2024 (TLP:CLEAR). (HHS.gov)
  5. Reuters – „‘Qilin’ cybercrime gang claims hack on Japan’s Asahi Group”, 7 października 2025. (Reuters)

Wdrożenie NIS2 W Sektorach – Energetyka, Zdrowie I Usługi Cyfrowe

Nowe wymagania dyrektywy NIS2 i szerszy zakres sektorów

Dyrektywa NIS2 (UE 2022/2555) znacząco podnosi poprzeczkę w obszarze cyberbezpieczeństwa, zastępując poprzednią dyrektywę NIS z 2016 roku. Jej zapisy poszerzają listę sektorów objętych obowiązkami z kilku do 18 sektorów krytycznych, w tym m.in. energetykę, ochronę zdrowia oraz szereg usług cyfrowych (jak telekomunikacja, usługi chmurowe, data center). W efekcie liczba podmiotów w Polsce podlegających nowym przepisom wzrosła z ~400 do ponad 10 000.

Czytaj dalej „Wdrożenie NIS2 W Sektorach – Energetyka, Zdrowie I Usługi Cyfrowe”

QNAP ostrzega: NetBak PC Agent dla Windows podatny na krytyczną lukę w ASP.NET Core (CVE-2025-55315)

Wprowadzenie do problemu / definicja luki

QNAP ostrzegł, że jego NetBak PC Agent (narzędzie do kopii zapasowych danych z Windows na NAS QNAP) może być pośrednio podatny na CVE-2025-55315 – krytyczny błąd w ASP.NET Core (serwer Kestrel), który umożliwia ataki HTTP Request Smuggling i obejście mechanizmów kontroli dostępu. NetBak podczas instalacji dołącza komponenty ASP.NET Core, dlatego na stacjach roboczych mogą pozostać podatne wersje frameworka, jeśli systemy nie zostały zaktualizowane.

W skrócie

  • CVE-2025-55315 (CVSS 9.9): błąd w ASP.NET Core/Kestrel prowadzący do Request Smuggling i Security Feature Bypass. W najgorszym scenariuszu możliwa kradzież poświadczeń, modyfikacja plików oraz DoS.
  • Wpływ na QNAP: komputery z NetBak PC Agent mogą zawierać podatne komponenty ASP.NET Core — konieczna aktualizacja .NET lub reinstalacja NetBak (która dociągnie najnowszy runtime).
  • Działania zalecane: zaktualizować ASP.NET Core (.NET 8/9/10 RC1) do najnowszej wersji lub przeinstalować NetBak; dla aplikacji self-contained — przebudowa i redeploy.

Kontekst / historia / powiązania

Microsoft załatał CVE-2025-55315 w aktualizacjach z 14 października 2025 r. i określił tę lukę jako mającą „najwyższy w historii” poziom ważności dla problemów ASP.NET Core. W kolejnych dniach pojawiły się komunikaty branżowe i vendorowe (w tym QNAP), które powiązały tę lukę z realnymi produktami zależnymi od środowiska .NET.

Analiza techniczna / szczegóły luki

Mechanizm ataku. CVE-2025-55315 dotyczy niespójnej interpretacji nagłówków/ciała HTTP pomiędzy komponentami brzegowymi (np. reverse proxy) a serwerem Kestrel. Napastnik może „przemycić” ukryte żądanie w innym żądaniu, co skutkuje zmianą zakresu uprawnień i ominięciem wybranych kontroli (np. autoryzacji, CSRF). Wektory skutków wskazują na C:H / I:H / A:L (wysoka poufność i integralność, mniejszy wpływ na dostępność).

Zakres wersji i łatki. Microsoft dostarczył poprawki dla ASP.NET Core 2.3, 8.0, 9.0 i 10.0 RC1; zaktualizowano też pakiet Microsoft.AspNetCore.Server.Kestrel.Core dla gałęzi 2.x. Rekomendacje obejmują: instalację aktualizacji .NET, ewentualny update pakietów NuGet oraz — w aplikacjach self-contained/single-file — przebudowę i redeploy.

Powiązanie z NetBak PC Agent. Instalator NetBak dołącza komponenty ASP.NET Core; niezałatane środowisko .NET na stacjach Windows, z których wykonywany jest backup na NAS QNAP, podnosi powierzchnię ataku. QNAP zaleca reinstalację NetBak lub ręczną instalację ASP.NET Core Runtime (Hosting Bundle) w najnowszej wersji (.NET 8.0.21 na październik 2025 r.).

Praktyczne konsekwencje / ryzyko

  • Kradzież tożsamości i eskalacja uprawnień — przejęcie sesji/poświadczeń użytkowników korzystających z aplikacji działających na podatnym Kestrel.
  • Modyfikacja zawartości plików — potencjalna ingerencja w dane przetwarzane przez aplikacje webowe .NET (integralność kopii zapasowych, metadanych itp.).
  • SSRF / ominięcie CSRF — możliwość wykonywania wewnętrznych żądań (pivot w sieci) oraz ominięcia ochrony CSRF zależnie od implementacji aplikacji.
  • Ryzyko łańcuchowe — stacje backupowe Windows z NetBak mogą stać się wektorem do ataku na inne systemy, jeśli korzystają z lokalnych usług webowych opartych o podatne ASP.NET Core. (Wniosek na podstawie charakterystyki luki i zależności NetBak od .NET).

Rekomendacje operacyjne / co zrobić teraz

  1. Zweryfikuj ekspozycję CVE-2025-55315
    • Sprawdź, czy na hostach z NetBak PC Agent (Windows) zainstalowane są komponenty ASP.NET Core i w jakiej wersji.
    • Zweryfikuj aplikacje .NET uruchamiane na tych hostach (w tym usługi self-hosted na Kestrel).
  2. Zaktualizuj platformę .NET
    • Zainstaluj najnowsze aktualizacje .NET 8/9/10 RC1 (Windows Update / instalatory .NET).
    • Dla gałęzi 2.3/2.x podnieś pakiet Kestrel.Core do wersji załatanej, przebuduj i wdroż aplikację.
  3. Zaktualizuj NetBak PC Agent
    • Metoda 1 (zalecana przez QNAP): Odinstaluj i zainstaluj ponownie NetBak — instalator dociągnie najnowszy runtime ASP.NET Core.
    • Metoda 2: Ręcznie zainstaluj ASP.NET Core Runtime (Hosting Bundle) z oficjalnej strony (.NET 8.0.21 na 10/2025), następnie restart aplikacji/systemu.
  4. Wymuś polityki hardeningu
    • Dopasuj konfiguracje reverse proxy / WAF (normalizacja nagłówków, spójność Content-Length/Transfer-Encoding).
    • Włącz dodatkowe logowanie anomalii w warstwie HTTP i monitoruj nietypowe wzorce żądań (dublowane/podwójne nagłówki, niezgodności CL/TE). (Dobre praktyki na bazie natury ataku).
  5. Testy regresyjne i skanowanie
    • Uruchom skanery SAST/DAST pod kątem HTTP Request Smuggling na aplikacjach .NET w ekosystemie backupu.
    • Zweryfikuj integralność i spójność procedur backupu po aktualizacjach.

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

  • W odróżnieniu od typowych RCE w serwerach web, CVE-2025-55315 to bypass funkcji bezpieczeństwa przez smuggling — skutki zależą silnie od implementacji aplikacji i łańcucha komponentów (proxy ↔ Kestrel). Stąd wysoka ocena (9.9) przy jednoczesnym zastrzeżeniu Microsoftu, że „najgorszy przypadek” nie zawsze będzie osiągalny w każdej aplikacji.
  • QNAP wcześniej notował problemy bezpieczeństwa w narzędziach backupowych (np. poprawki rsync w HBS 3 w styczniu 2025 r.), ale obecna sytuacja dotyczy komponentu platformowego (ASP.NET Core), a nie bezpośrednio podatności w samym NetBak.

Podsumowanie / kluczowe wnioski

  • Jeśli używasz NetBak PC Agent na Windows, potraktuj hosty jako potencjalnie narażone, zaktualizuj .NET/ASP.NET Core lub przeinstaluj NetBak, aby mieć pewność, że środowisko uruchomieniowe nie jest podatne.
  • CVE-2025-55315 to błąd o wyjątkowo wysokiej ważności w ASP.NET Core/Kestrel, którego skutki zależą od logiki aplikacji — nie ignoruj aktualizacji nawet, jeśli nie widzisz bezpośredniej ekspozycji.
  • Włącz monitoring anomalii HTTP i przegląd konfiguracji proxy/WAF, bo smuggling często wykorzystuje rozbieżności interpretacji żądań.

Źródła / bibliografia

  • BleepingComputer: „QNAP warns of critical ASP.NET flaw in its Windows backup software”, 27 października 2025. (BleepingComputer)
  • QNAP Security Advisory QSA-25-44: „Potential Security Impact of ASP.NET Vulnerability on NetBak PC Agent”, 24 października 2025 (rev. 1.0). (QNAP)
  • Microsoft / BleepingComputer: „Microsoft fixes highest-severity ASP.NET Core flaw ever”, 17 października 2025 (omówienie zaleceń Microsoftu). (BleepingComputer)
  • NVD: „CVE-2025-55315 – ASP.NET Core HTTP Request Smuggling”, 14 października 2025 (wektor CVSS, opis). (NVD)
  • SecurityWeek: „Highest Ever Severity Score Assigned by Microsoft to ASP.NET Core Vulnerability”, 17 października 2025. (SecurityWeek)

CISA nakazuje załatać krytyczną lukę w WSUS na Windows Server (CVE-2025-59287). Trwa aktywne wykorzystywanie

Wprowadzenie do problemu / definicja luki

Amerykańska agencja CISA dodała do katalogu Known Exploited Vulnerabilities krytyczną lukę CVE-2025-59287 w Windows Server Update Services (WSUS) i nakazała federalnym instytucjom załatanie systemów. Podatność umożliwia zdalne wykonanie kodu (RCE) bez uwierzytelnienia na serwerze WSUS, z uprawnieniami SYSTEM. Microsoft wydał aktualizacje out-of-band dla wszystkich wspieranych wersji Windows Server. Luka jest aktywnie wykorzystywana w atakach, także po publikacji PoC.

W skrócie

  • Identyfikator: CVE-2025-59287 (CVSS: krytyczny; RCE bez interakcji użytkownika).
  • Dotyczy: wyłącznie serwerów z włączoną rolą WSUS (domyślnie wyłączona).
  • Wejście/rozprzestrzenianie: podatność potencjalnie „wormowalna” między serwerami WSUS.
  • Status: aktywne skanowanie i realne kompromitacje; dostępne PoC.
  • Działania Microsoft: łatki OOB + zalecane obejścia (tymczasowe wyłączenie WSUS / blokada 8530/8531).
  • Działania CISA: wpis w KEV i nakaz szybkiego patchowania.

Kontekst / historia / powiązania

23–24 października 2025 r. Microsoft opublikował aktualizacje poza standardowym cyklem, po tym jak badacze udostępnili proof-of-concept oraz zaczęły pojawiać się doniesienia o atakach na wystawione publicznie instancje WSUS (standardowe porty 8530/TCP (HTTP) i 8531/TCP (HTTPS)). CISA dorzuciła podatność do KEV, co w praktyce oznacza potwierdzoną eksploatację w środowiskach produkcyjnych.

Analiza techniczna / szczegóły luki

Badacze wskazują, że podatność wynika z niebezpiecznej deserializacji w przestarzałym mechanizmie (BinaryFormatter) w ścieżce przetwarzania ciasteczka autoryzacyjnego. Atakujący może wysłać specjalnie spreparowane dane do endpointu związanym z obsługą cookies (np. GetCookie()), co prowadzi do wykonania arbitralnego kodu jako SYSTEM. To umożliwia przejęcie serwera WSUS bez wcześniejszych uprawnień.

Dodatkowo zespoły reagowania (m.in. Huntress) raportują realne próby i udane włamania na hosty WSUS po publikacji łatki, co jest typowym wzorcem „patch-and-exploit”.

Praktyczne konsekwencje / ryzyko

  • Łańcuch aktualizacji jako wektor rozprzestrzeniania: kompromitacja WSUS może umożliwić podszycie się pod zaufane aktualizacje, ich podpisywanie i dystrybucję złośliwych pakietów do całej floty Windows. W środowiskach z ConfigMgr/SCCM ryzyko jest szczególnie wysokie.
  • Ruch sieciowy i ekspozycja usług: liczne instancje WSUS są zidentyfikowane w Internecie na portach 8530/8531; skanowanie tych portów to popularna technika rozpoznawcza.
  • Uprawnienia SYSTEM = pełne przejęcie: po RCE napastnik może zrzucać poświadczenia, modyfikować zasady aprobaty aktualizacji, pivotować w AD oraz trwale utrzymywać się w infrastrukturze.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiast zainstaluj aktualizacje OOB odpowiednie dla Twojej wersji Windows Server (po instalacji wymagany restart). Przykładowo dla Windows Server 2022: KB5070884. Zastosuj OOB także zamiast zaległej łatki październikowej — Microsoft wskazuje, że OOB ją zastępuje.
  2. Jeśli patch nie jest możliwy „od ręki”: tymczasowo wyłącz rolę WSUS lub zablokuj ruch na 8530/8531/TCP (co zatrzyma dystrybucję aktualizacji, ale usunie wektor ataku). Zaplanuj jak najszybszy powrót do normalnego trybu po patchu.
  3. Inwentaryzacja i ekspozycja: zinwentaryzuj wszystkie serwery WSUS (także downstream) i sprawdź, czy nie są wystawione do Internetu na 8530/8531. W miarę możliwości ogranicz dostęp tylko z sieci zaufanych/VPN. (Porty domyślne potwierdza dokumentacja Microsoft).
  4. Hunting po kompromitacji (jeśli WSUS był wystawiony lub niezałatany):
    • Przejrzyj logi IIS/WSUS pod kątem nietypowych żądań do endpointów autoryzacyjnych.
    • Zweryfikuj łańcuch zaufania i certyfikaty używane do podpisywania lokalnie publikowanych aktualizacji; rozważ ich rotację.
    • Sprawdź listy zatwierdzonych aktualizacji pod kątem nieznanych/niestandardowych pakietów.
    • Przeprowadź skan integralności i EDR sweep serwera oraz wybranych stacji. (Wskazówki operacyjne wynikają z obserwacji zespołów reagowania.)
  5. Hardening na przyszłość: minimalizuj powierzchnię ataku WSUS (brak ekspozycji publicznej, segmentacja, WAF/reverse-proxy), monitoruj anomalie aprobat aktualizacji i integruj WSUS-related telemetry do SIEM/SOAR.

Różnice / porównania z innymi przypadkami

W odróżnieniu od wielu błędów w usługach Windows, CVE-2025-59287 dotyka komponentu zarządzania aktualizacjami. To zwiększa ryzyko supply-chain wewnątrz organizacji: przejęty WSUS może stać się „zaufanym” dystrybutorem złośliwych paczek — podobnie do scenariuszy ataków na narzędzia MDM/aktualizacyjne, ale z niższą barierą wejścia (RCE bez uwierzytelnienia). Doniesienia branżowe wskazują też, że pierwotne poprawki z Patch Tuesday były niewystarczające, dlatego Microsoft wydał aktualizacje OOB.

Podsumowanie / kluczowe wnioski

  • Patch teraz: CVE-2025-59287 jest aktywnie wykorzystywana, a WSUS to „koronny węzeł” dystrybucji aktualizacji w AD.
  • Zamknij 8530/8531 i/lub wyłącz WSUS, jeśli nie możesz od razu zaktualizować — świadomie akceptując przerwę w dostarczaniu łatek.
  • Sprawdź integralność łańcucha aktualizacji (certyfikaty, aprobaty, anomalie publikacji).
  • Ogranicz ekspozycję WSUS do sieci zaufanych i włącz telemetry/hunting.

Źródła / bibliografia

  1. BleepingComputer — nakaz CISA dla agencji federalnych i status eksploatacji. (BleepingComputer)
  2. Microsoft — strona KB (przykładowo WS2022 KB5070884) z informacjami o OOB, restarcie i zmianach funkcjonalnych. (Microsoft Support)
  3. Huntress — obserwacje ataków na WSUS po wydaniu łatek (analiza incydentów). (Huntress)
  4. HawkTrace — szczegóły techniczne PoC (deserializacja, AuthorizationCookie, BinaryFormatter / EncryptionHelper.DecryptData()). (HawkTrace)
  5. NVD (NIST) — potwierdzenie wpisu w CISA KEV dla CVE-2025-59287. (NVD)

Mem3nt0 mori: jak Kaspersky powiązał APT ForumTroll ze szpiegowskim Dante od Memento Labs (ex-Hacking Team)

Wprowadzenie do problemu / definicja luki

Kaspersky opisał dziś kulisy kampanii Operation ForumTroll (marzec 2025), w której kliknięcie spersonalizowanego linku phishingowego prowadziło do cichej infekcji przez przeglądarkę Chrome. Badacze wykryli i zgłosili nową podatność CVE-2025-2783 (sandbox escape w komponencie Mojo), którą Google załatał w stabilnym wydaniu 134.0.6998.177/.178 z 25 marca 2025 r.

W toku dalszej analizy Kaspersky powiązał tę kampanię i pokrewny arsenał z komercyjnym spyware “Dante” rozwijanym przez Memento Labs — firmę, którą świat znał wcześniej jako Hacking Team.

W skrócie

  • Wejście: e-mail phishingowy ze spersonalizowanym, krótkotrwałym URL-em; sama wizyta w witrynie uruchamiała exploit 0-day na Chrome (Windows).
  • Eksploit: CVE-2025-2783 — eskalacja z sandboksa (Mojo/IPC), potwierdzona przez Google i NVD; poprawka 25.03.2025.
  • Łańcuch: validator → exploit → persistent loader → etap LeetAgent → właściwe moduły szpiegowskie (Dante).
  • Atrybucja: zbieżności kodu, TTP, ścieżek FS, mechanizmów trwałości oraz jawne ciągi “Dante” w binariach; kontynuacja linii RCS (Da Vinci/Galileo) po rebrandingu Hacking Team → Memento Labs.

Kontekst / historia / powiązania

Hacking Team to jedna z najbardziej rozpoznawalnych marek rynku spyware (RCS: Da Vinci/Galileo). Po wycieku ~400 GB danych w 2015 r. firma została w 2019 r. przejęta przez InTheCyber i przemianowana na Memento Labs. W 2023 r. na konferencji ISS World MEA firma ujawniła nazwę nowego produktu: DANTE. Według Kaspersky’ego kod RCS ewoluował do 2022 r., gdy został zastąpiony przez Dante.

Szersze mapowanie rynku komercyjnego spyware (NSO/Intellexa/Candiru/Paragon/Quadream/RCS Labs/Memento Labs itd.) potwierdza ciągłość działalności dostawców po rebrandingu.

Analiza techniczna / szczegóły luki

Łańcuch ataku (high-level)

  1. Phishing URL (krótko żyjący, spersonalizowany) → 2. Validator (sprawdza środowisko) → 3. Exploit CVE-2025-2783 (ucieczka z sandboksa Chrome/Windows) → 4. Persistent loader (utrwalenie) → 5. LeetAgent (staging/koordynacja) → 6. Dante (moduły szpiegowskie).

CVE-2025-2783 (Chrome Mojo)

  • Błąd klasy incorrect handle w Mojo IPC na Windows umożliwiający sandbox escape przy udziale złośliwego pliku/strony.
  • Status: wykryty in-the-wild, załatany 25.03.2025; zgłaszający: Boris Larin, Igor Kuznetsov (Kaspersky); wektor CVSS3.1 wg CISA-ADP: AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H (8.3).

Artefakty i IOCs (wybrane wzorce)

  • Folder modułów: w %LocalAppData%, nazwy katalogu i plików bez rozszerzeń to 8-bajtowe Base64; jeden z plików ma nazwę równą katalogowi — to pomocny wzorzec detekcyjny aktywnej infekcji.
  • Próbki: Kaspersky publikuje skróty (loader/LeetAgent/Dante) w sekcji IOCs.

Atrybucja do Dante / Memento Labs

  • Po zdjęciu VMProtect odkryto ciągi “Dante” oraz odniesienie do wersji “2.0” zgodne z nazwą prelekcji ISS World MEA 2023; wykryto liczne podobieństwa kodowe między późnymi próbkami RCS a Dante. Wniosek: nowy produkt zastąpił dotychczasową bazę w 2022 r.

Praktyczne konsekwencje / ryzyko

  • Ataki bezklikalne po kliknięciu linku: samo otwarcie strony w Chrome wystarczało do naruszenia (brak dodatkowej interakcji).
  • Ryzyko pełnego przejęcia hosta: sandbox escape w Chrome połączony z loaderem i modułami daje zdolności pełnego szpiegostwa (zrzuty ekranu, exfiltracja, keylogging, audio/wideo — typowe dla linii RCS/Dante).
  • Cele wysokoprofilowe: charakter kampanii (APT, spear-phishing, krótkotrwała infrastruktura) wskazuje na ukierunkowaną cyber-szpiegowską operację.

Rekomendacje operacyjne / co zrobić teraz

1) Natychmiastowe działania IT/SecOps

  • Zaktualizuj Chrome do ≥ 134.0.6998.177/.178 (Windows); sprawdź kanał Extended Stable.
  • Hunting po artefaktach: przeszukaj %LocalAppData% pod kątem katalogów/plików nazwanych 8-bajtowym Base64 (bez rozszerzeń) oraz zbieżnych mechanizmów trwałości. Zweryfikuj hosty z podejrzanymi folderami.
  • Weryfikacja IOCs: porównaj próbki z hashami opublikowanymi przez Kaspersky (loader/LeetAgent/Dante).

2) Detekcja i twardnienie

  • EDR/XDR: reguły pod CVE-2025-2783 (Mojo/handle dup), ładowanie niezaufanych DLL, nietypowe child-procesy Chrome → LOLBins, tworzenie trwałości przez rzadko używane ścieżki użytkownika. (Wzorce zgodne z opisem łańcucha Kaspersky).
  • Gateway/Proxy: czasowo-ograniczone, spersonalizowane URL-e — wzmacniać detekcję na krótko żyjące domeny, TLS fingerprinting, anomalię HTTP.
  • Kontrola przeglądarki: polityki blokujące ładowanie Mojo IPC z nieznanych źródeł, ograniczanie rozszerzeń, izolacja profili uprzywilejowanych.

3) Zarządzanie podatnościami

  • CVE-2025-2783 znajduje się w CISA KEV — egzekwuj priorytetową poprawkę zgodnie z terminem BOD 22-01 (organizacje publiczne/regulated).

4) Świadomość i procedury

  • Trenuj rozpoznawanie spear-phishingu i politykę bezpiecznego otwierania linków (otwieranie w przeglądarce izolowanej/VDI dla wrażliwych ról).

Różnice / porównania z innymi przypadkami

  • Pegasus/Intellexa/Candiru vs. Dante: ekosystemy różnią się łańcuchami eksploatacji (mobilne vs. desktopowe), ale model biznesowy (ofensywne zdolności dla rządów) i ukrywanie tożsamości w kodzie są wspólne. W przypadku Dante rzadki jest wprost odnaleziony znacznik nazwy w binariach, co ułatwiło atrybucję.
  • RCS (Da Vinci/Galileo) → Dante: ciągłość kodowa i TTP sugeruje ewolucję produktu po rebrandingu Hacking Team → Memento Labs (2022: przejście na Dante).

Podsumowanie / kluczowe wnioski

  • Operation ForumTroll to przykład APT-grade browser exploit chain: phishing → Chrome 0-day (CVE-2025-2783) → staged spyware. Google załatał błąd 25.03.2025.
  • Atrybucja do Dante/Memento Labs została potwierdzona kombinacją cech kodu, TTP i artefaktów — to “powrót” Hacking Team w nowej odsłonie.
  • Organizacje powinny patchować, huntować wg wzorców FS/IOC, wzmacniać EDR/XDR i segmentować ryzyko przeglądarki.

Źródła / bibliografia

  1. Kaspersky Securelist – “Mem3nt0 mori – The Hacking Team is back! / How we linked ForumTroll APT to Dante spyware” (analiza łańcucha, IOCs, atrybucja do Dante/Memento Labs), 27.10.2025. (Securelist)
  2. Google – Chrome Releases: Stable Channel Update for Desktop 134.0.6998.177/.178 (potwierdzenie CVE-2025-2783; “exploited in the wild”), 25.03.2025. (Chrome Releases)
  3. NVD (NIST) – CVE-2025-2783 (opis, odwołanie do CISA KEV, wektor CVSS), aktual. 24.10.2025. (NVD)
  4. Kaspersky Blog – Operation ForumTroll: APT attack with Google Chrome zero-day exploit chain, 25.03.2025. (Securelist)
  5. Atlantic Council – “Mythical Beasts and where to find them: Mapping the global spyware market…” (kontekst rynku, Memento Labs/Hacking Team), 04.09.2024. (Atlantic Council)

Qilin (Agenda) – jak działa jedna z najaktywniejszych operacji ransomware w 2025 r. według Cisco Talos

Wprowadzenie do problemu / definicja luki

Cisco Talos opisał szereg incydentów z 2025 r., które ujawniają aktualny łańcuch ataku Qilin (dawniej Agenda) – jednego z najbardziej „produktywnych” gangów ransomware. Zespół IR Talosa obserwuje ponad 40 publikacji ofiar miesięcznie na stronie wycieków Qilin, ze szczytami aktywności sięgającymi ~100 przypadków (czerwiec i sierpień 2025). Najmocniej cierpi produkcja, a dalej usługi profesjonalne i handel hurtowy.

W skrócie

  • Model RaaS: Qilin działa jako usługa, rozwijając platformę i udostępniając ją afilantom; podwójny szantaż (szyfrowanie + wyciek).
  • Początkowy dostęp: w badanych sprawach częste są nadużycia ważnych kont/VPN bez MFA, czasem zmiany GPO w AD w celu włączenia RDP; obserwowano także spear-phishing i wykorzystanie wycieków haseł.
  • Eksfiltracja: paczkowanie WinRAR, przesył przez legalne narzędzia (np. Cyberduck do Backblaze), „ręczne” przeglądanie danych nawet notatnikiem/mspaint.
  • Ruch boczny i utrzymanie: PsExec, modyfikacje zapory i RDP, instalacje wielu RMM (AnyDesk, ScreenConnect, Chrome Remote Desktop itd.).
  • Szyfrowanie: wariant Qilin.B (Rust) używa AES-256-CTR lub ChaCha20 + RSA-4096 (OAEP), terminacja usług backup/DB/AV, czyszczenie logów i niszczenie VSS.
  • Skala zagrożenia: w II kw. 2025 Qilin był najaktywniejszym ransomware wobec podmiotów SLTT w USA (MS-ISAC).

Kontekst / historia / powiązania

Qilin (wcześniej Agenda) działa od lipca 2022 r., oferując RaaS i prowadząc wycieki danych na własnym portalu. Z czasem ewoluował technicznie (m.in. przepisany na Rust; utrzymano też wersje Linux/ESXi) i organizacyjnie (aktywny rekrut na forach). W 2024 r. HHS/HC3 publikował profil zagrożenia wskazujący na spear-phishing i warianty Windows/Linux; w 2024/2025 Halcyon śledził wariant Qilin.B z usprawnioną kryptografią i ewakuacją kluczowych artefaktów.

W 2025 r. incydenty przypisywane Qilin odnotowano w różnych sektorach i krajach; przykładem jest głośny atak na japoński Asahi Group (zakłócenia produkcji i publikacja danych).

Analiza techniczna / szczegóły luki

Wejście / inicjalny dostęp

  • Nadużycie ważnych kont i brak MFA na VPN; wzmożone próby NTLM po pojawieniu się haseł w darknecie; możliwe zmiany GPO w celu ułatwienia RDP.
  • (Historycznie) spear-phishing, w tym złośliwe załączniki i kradzież poświadczeń.

Rozpoznanie i zbieranie

  • nltest, net user, whoami /priv, tasklist; narzędzia skanowania sieci; dedykowany pakiet do zrzutu haseł (NirSoft, Mimikatz). Modyfikacja WDigest (UseLogonCredential=1) ułatwiająca pozyskanie plaintextów. Dane agregowane skryptami i eksportowane (SMTP, pliki wynikowe z kodowaniem Windows-1251).

Eksfiltracja

  • Archiwizacja WinRAR, inspekcja dokumentów nawet przez notepad.exe/mspaint.exe/iexplore.exe; nadużycie Cyberduck do chmury (Backblaze) z podziałem na części.

Eskalacja uprawnień i ruch boczny

  • Dodawanie napastniczych kont do Local Administrators, wymuszanie RDP, tworzenie udziałów typu net share c=c:\ /grant: everyone,full; rozproszenie przez PsExec. Obserwacje wielu RMM (AnyDesk, ScreenConnect, Distant Desktop, QuickAssist, Chrome Remote Desktop).

Unikanie obrony

  • Silnie zaciemniony PowerShell z wyłączeniem AMSI, obejściem walidacji TLS oraz włączeniem Restricted Admin dla RDP (hash-based auth).

Przygotowanie środowiska i trwałość

  • Wyłączanie/ubijanie procesów AV/backup/DB, czyszczenie logów, tworzenie Scheduled Task („TVInstallRestore”) i wpisów Run podszywających się pod TeamViewer.

Szyfrowanie (Qilin.B)

  • Kombinacja AES-256-CTR (jeśli dostępne AES-NI) / ChaCha20 (fallback) + RSA-4096/OAEP do ochrony kluczy; noty okupu README-RECOVER-[company_id].txt; rozszerzenia plików wg unikalnego ID ofiary. Wykrywana enumeracja udziałów i dysków, ukierunkowanie na ClusterStorage/CSV (Hyper-V/VM/VHDX) przy jednoczesnym unikaniu pętli po symlinkach. Usuwanie VSS i autodestrukcja binarium.

IOCs i detekcje

  • Talos publikuje wykazy IOC (GitHub), Snort SID oraz ClamAV (np. Win.Ransomware.Qilin, SystemBC, Cobalt Strike).

Praktyczne konsekwencje / ryzyko

  • Czas przestoju: ataki celują w środowiska wirtualizacji i plików współdzielonych (CSV/Hyper-V), co zwiększa wpływ na produkcję i usługi krytyczne.
  • Ryzyko reputacyjne i prawne przez systematyczną ekfiltrację (Backblaze/Cyberduck) oraz publikację na stronie wycieków.
  • Trend rynkowy: Qilin był w Q2 2025 najaktywniejszą rodziną wobec SLTT w USA, co potwierdza jego dojrzałość operacyjną i tempo działania.
  • Incydenty głośne medialnie (np. Asahi) pokazują realny wpływ na produkcję i łańcuch dostaw.

Rekomendacje operacyjne / co zrobić teraz

Kontrole prewencyjne

  1. MFA bez wyjątków na VPN, RDP, poczcie i aplikacjach krytycznych; wymuś klient-based MFA dla kont uprzywilejowanych.
  2. Higiena tożsamości: rotacja haseł po wyciekach, blokady na „password spraying” (T1110.003), monitorowanie NTLM.
  3. Twardnienie RDP: wyłącz zdalne logowanie tam, gdzie zbędne; kontrola fDenyTSConnections, ograniczenia sieciowe/Jump Host; Restricted Admin tylko jeśli świadomie zarządzany.
  4. Egress/Exfil kontrola: DLP/CTI-driven blokady dla Backblaze i nietypowych klientów S3/WebDAV; monitoruj użycie Cyberduck, WinRAR w trybie archiwizacji masowej.
  5. Backup i odzyskiwanie: izolowane kopie, testy odtwarzania, ochrona VSS przed usuwaniem; segmentacja Hyper-V/CSV.

Detekcja i reagowanie (SOC/SIEM/EDR)

  • Reguły: Snort/ClamAV zgodnie z publikacją Talos; korelacje dla PsExec, net share c=, WDigest UseLogonCredential=1, zaciemnionego PowerShell wyłączającego AMSI, nietypowego schtasks /Create /SC ONLOGON.
  • Artefakty RMM: wykrywaj instalacje/połączenia AnyDesk/ScreenConnect/Chrome Remote Desktop/QuickAssist poza listą zatwierdzonych rozwiązań.
  • Kryptonotatki/rozszerzenia: alarmy na README-RECOVER-[company_id].txt oraz nowe rozszerzenia „.[company_id]”.

Procedury IR

  • Izolacja i triage hostów z aktywnością WinRAR/Cyberduck, ścieżkami Backblaze, masową terminacją usług bezpieczeństwa/backup.
  • Łańcuch dowodowy: zabezpieczenie logów przed czyszczeniem (wczesna centralizacja, forward-only, write-once).
  • Komunikacja kryzysowa i ocena ryzyka wycieku (PII, IP, dane produkcyjne).

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

  • Qilin vs. „typowy” RaaS 2025: podobnie jak inne operacje, Qilin intensywnie eksfiltruje i używa RMM/LOLBINs; odróżnia go ukierunkowanie na CSV/Hyper-V i szerokie wykorzystanie legalnych narzędzi do eksfiltracji (Cyberduck).
  • Qilin.B (Rust) wyróżnia kombinowany wybór szyfru (AES-NI → AES-CTR, fallback → ChaCha20) i mocną ochronę kluczy RSA-4096/OAEP, co komplikuje odzysk bez kluczy.
  • Wieloplatformowość: raporty z 2025 r. pokazują nawet wdrażanie binarek Linux na systemach Windows przez RMM/BYOVD, co utrudnia detekcję.

Podsumowanie / kluczowe wnioski

Qilin utrzymuje wysokie tempo kampanii i dojrzały łańcuch ataku: kradzież poświadczeń (WDigest/Mimikatz/NirSoft), ruch boczny (PsExec/RDP/RMM), eksfiltracja przez chmurę (Cyberduck→Backblaze), a następnie szyfrowanie zoptymalizowane dla środowisk wirtualnych (CSV/Hyper-V) i agresywna ewakuacja artefaktów. Obrona wymaga dyscypliny IAM/MFA, twardnienia RDP/VPN, kontroli egress/exfil, oraz predefiniowanych detekcji TTP. Publikacje Cisco Talos i analizy branżowe (HHS/HC3, Halcyon, CIS, Trend Micro) dostarczają praktycznych wskaźników i reguł do natychmiastowego wdrożenia.

Źródła / bibliografia

  1. Cisco Talos – Uncovering Qilin attack methods exposed through multiple cases, 26 października 2025 (TTP, IOCs, Snort/ClamAV). (Cisco Talos Blog)
  2. Halcyon – New Qilin.B Ransomware Variant…, 24 października 2024 (kryptografia, mechanika szyfrowania). (Halcyon)
  3. HHS/HC3 – Qilin (aka Agenda) Threat Profile, 18 czerwca 2024 (wektory wejścia, Windows/Linux). (hhs.gov)
  4. CIS (MS-ISAC) – Qilin: Top Ransomware Threat to SLTTs in Q2 2025, 11 września 2025 (trend aktywności). (CIS)
  5. Trend Micro – Agenda Ransomware Deploys Linux Variant on Windows Systems…, 23 października 2025 (nietypowe wdrożenia Linux przez RMM/BYOVD). (www.trendmicro.com)

Techniczne I Organizacyjne Środki Bezpieczeństwa Wymagane Przez NIS2

Dlaczego techniczne i organizacyjne środki bezpieczeństwa są kluczowe dla zgodności z NIS2?

Dyrektywa NIS2 stawia jasne wymagania: organizacje objęte jej zakresem muszą wdrożyć odpowiednie i proporcjonalne środki cyberbezpieczeństwa – zarówno techniczne, jak i organizacyjne. Nie chodzi tu o sztuczną biurokrację czy „odhaczanie” zgodności na papierze. NIS2 wymusza realne zabezpieczenia, które mają chronić krytyczne usługi i dane przed współczesnymi zagrożeniami.

Czytaj dalej „Techniczne I Organizacyjne Środki Bezpieczeństwa Wymagane Przez NIS2”