Archiwa: Ransomware - Strona 71 z 81

CISA dodaje luki w Gladinet CentreStack/Triofox i Control Web Panel do katalogu KEV. Patchuj do 25 listopada 2025

Wprowadzenie do problemu / definicja luki

Amerykańska CISA dodała do katalogu Known Exploited Vulnerabilities (KEV) dwie aktywnie wykorzystywane luki: CVE-2025-11371 w Gladinet CentreStack/Triofox oraz CVE-2025-48703 w Control Web Panel (CWP, dawniej CentOS Web Panel). Agencje FCEB mają czas na wdrożenie poprawek lub środki zaradcze do 25 listopada 2025 r.. Informację nagłośnił m.in. The Hacker News.

W skrócie

Gladinet CentreStack/Triofox – CVE-2025-11371 (LFI): nieauthoryzowany Local File Inclusion umożliwia odczyt plików systemowych w domyślnej instalacji; obserwowane wykorzystanie w atakach. W praktyce może prowadzić do eskalacji do RCE, np. przez wyciek kluczy i łańcuchowanie z innymi słabościami.
Control Web Panel – CVE-2025-48703 (RCE): OS Command Injection w parametrze t_total żądania filemanager changePerm daje nieautoryzowane RCE (wystarczy znać dowolną nie-root nazwę użytkownika). Zalecana wersja: ≥ 0.9.8.1205. Aktywnie wykorzystywana.
Termin CISA (FCEB): 25.11.2025 jako deadline na działania naprawcze.

Kontekst / historia / powiązania

Luka CVE-2025-11371 była opisana przez zespoły monitorujące incydenty (Huntress) jako 0-day wykorzystywany „na wolności” przeciw instancjom CentreStack/Triofox, z naciskiem na to, że dotyczy domyślnej konfiguracji i najnowszych wówczas wydań. CISA włączyła podatność do KEV po potwierdzeniu aktywnej eksploatacji.
W przypadku CWP podatność CVE-2025-48703 została szeroko udokumentowana (NVD, społeczność), z publicznymi PoC-ami i dyskusją o łańcuchu ataku wymagającym znajomości nazwy użytkownika. CISA ostrzega, że wektory tego typu są częstym celem atakujących.

Analiza techniczna / szczegóły luki

Gladinet CentreStack/Triofox — CVE-2025-11371 (LFI)

Wpływ: nieautoryzowany LFI → odczyt plików (np. web.config, klucze, sekrety). Dotyczy domyślnej instalacji/konfiguracji wersji do i włącznie z 16.7.10368.56560.
Eksploatacja: napastnik żąda ścieżek systemowych, uzyskuje konfiguracje/sekrety → możliwe RCE pośrednie (np. przejęcie kluczy, łańcuchowanie z deserializacją). Huntress potwierdza ataki „in the wild”.

Control Web Panel — CVE-2025-48703 (OS Command Injection / RCE)

Wpływ: pre-auth RCE (wymagana znajomość dowolnej poprawnej nazwy użytkownika); wektor to wstrzyknięcie metaznaków powłoki w parametrze t_total podczas filemanager&acc=changePerm.
Zasięg: wersje < 0.9.8.1205. Napastnik może wykonać dowolne polecenia systemowe w kontekście aplikacji/panelu.

Praktyczne konsekwencje / ryzyko

Gladinet: wyciek kluczy/sekretów → pełne przejęcie aplikacji lub serwera przez łańcuchowanie (np. podpisywanie payloadów, manipulacja sesjami). Wysokie ryzyko dla MSP i środowisk z publikacją portali do Internetu.
CWP: zdalne wykonanie kodu na hostach panelu → pivot na serwery klientów (Apache/Nginx/MySQL), kradzież danych, implanty, ransomware. Publiczne PoC-e zwiększają tempo skanowania i masowej eksploatacji.

Rekomendacje operacyjne / co zrobić teraz

Wspólne:

Ogranicz ekspozycję do paneli/portali (ACL, VPN, IP allowlist, geofencing).
WAF/IPS: reguły blokujące LFI i metaznaki powłoki (;, `, |, &&) w ścieżkach/parametrach.
Telemetria: monitoruj nietypowe żądania do endpointów portalu (Gladinet) i modułu filemanager (CWP); alertuj na odczyty plików konfiguracyjnych i żądania z t_total.
IR: przeszukaj logi pod kątem prób LFI i poleceń; rotuj klucze/sekrety, tokeny i hasła jeśli portal/panel był wystawiony.

Gladinet CentreStack/Triofox (CVE-2025-11371):

Zaktualizuj do najnowszej dostępnej wersji i zastosuj mitigacje dostawcy; jeśli aktualizacja jest niemożliwa, tymczasowo wyłącz publiczny dostęp portalu. Monitoruj pod kątem odczytu web.config i podobnych wrażliwych plików.

Control Web Panel (CVE-2025-48703):

Aktualizuj do ≥ 0.9.8.1205 niezwłocznie; jeśli aktualizacja nie jest możliwa — odetnij porty CWP od Internetu, włącz 2FA na panelach, wymuś zmianę wszystkich haseł.

Terminy dla FCEB: wdrożenie poprawek/mitigacji do 25 listopada 2025 r. (KEV due date).

Różnice / porównania z innymi przypadkami

LFI (Gladinet) to głównie wyciek informacji z potencjałem na RCE przez łańcuchowanie;
Command Injection (CWP) to bezpośrednie RCE po spełnieniu lekkiego warunku (znajomość nazwy użytkownika).
Obie luki są w KEV z uwagi na realne, potwierdzone ataki.

Podsumowanie / kluczowe wnioski

Dwie różne klasy błędów (LFI vs. OS Command Injection), wspólny mianownik: aktywna eksploatacja i publiczne techniki ataku.
Priorytet: aktualizacje (Gladinet do najnowszych wydań; CWP do ≥ 0.9.8.1205), redukcja ekspozycji, monitoring i rotacja sekretów.
Deadline CISA (FCEB): 25.11.2025 — dobry punkt odniesienia dla wszystkich organizacji.

Źródła / bibliografia

CISA KEV — wpisy i termin działań (dodane 4 listopada 2025): due date 25.11.2025. (CISA)
The Hacker News: „CISA Adds Gladinet and CWP Flaws to KEV Catalog…” (05.11.2025). (The Hacker News)
NVD: CVE-2025-11371 — Gladinet CentreStack/Triofox LFI (opis, zakres). (NVD)
NVD: CVE-2025-48703 — CWP OS Command Injection (RCE). (NVD)
Huntress: „Active Exploitation of Gladinet CentreStack and Triofox LFI” — potwierdzenie ataków, techniczne tło. (Huntress)

Rosyjska grupa Curly COMrades ukrywa malware w linuksowych VM-ach Hyper-V, by omijać EDR

Wprowadzenie do problemu / definicja techniki

Badacze opisali nową technikę operacyjną grupy Curly COMrades: po kompromitacji hosta z Windows napastnicy włączają Hyper-V i importują ukrytą, minimalistyczną maszynę wirtualną z Alpine Linux, w której uruchamiają własne implanty. Dzięki izolacji wykonywania w VM unikają detekcji przez rozwiązania EDR działające na hoście.

W skrócie

Atakujący tworzą lekki VM (ok. 120 MB dysku, 256 MB RAM) na Hyper-V i nazywają go „WSL”, aby zlał się z otoczeniem.
Wewnątrz VM działają CurlyShell (reverse shell przez HTTPS, persystencja cron) i CurlCat (reverse proxy/SSH→HTTPS).
VM używa Default Switch Hyper-V, więc cały ruch wygląda jakby pochodził z IP hosta. To utrudnia sieciową detekcję C2.
Kampania była obserwowana m.in. latem 2025 r.; badania prowadził Bitdefender z udziałem CERT Gruzja.

Kontekst / historia / powiązania

Curly COMrades to aktor APT działający co najmniej od 2024 r., powiązany z celami zgodnymi z interesami Rosji. Wcześniejsze aktywności obejmowały m.in. sektor publiczny w Gruzji i energetykę w Mołdawii. Najnowsza publikacja rozszerza znane TTP o trwałą obecność w VM Hyper-V na hostach ofiar.

Analiza techniczna / szczegóły luki

Wejście i przygotowanie środowiska

Napastnicy zdalnie włączają rolę Hyper-V i wyłączają interfejs zarządzania, używając poleceń DISM; następnie importują prekonfigurowaną VM (VMCX/VHDX) i startują ją PowerShellem: Import-VM oraz Start-VM -Name WSL. Pliki VM trafiają pod mylącą ścieżkę w C:\ProgramData\Microsoft\AppV\app\.

Konfiguracja VM

VM z Alpine Linux jest skrojony „pod ofiarę” (m.in. wpisy /etc/hosts, niestandardowy DNS w /etc/resolv.conf). Sieć ustawiona na Default Switch (NAT), co tuneluje ruch przez stos sieciowy hosta.

Implanty i persystencja

CurlyShell (ELF, C++, libcurl) – reverse shell przez HTTPS, uruchamiany okresowo via cron; ukrywa I/O, stosuje niestandardową bazę Base64 w protokole C2. Przykładowy hash: MD5 c6dbf3de8fd1fc9914fae7a24aa3c43d.
CurlCat (ELF, C++, libcurl) – lekki tunnel/ProxyCommand w ~/.ssh/config, pakuje SSH w HTTP/HTTPS; przykład MD5: 1a6803d9a2110f86bb26fcfda3606302.

Dalsze operacje

Skrypty PowerShell do lateral movement/persystencji (m.in. wstrzyknięcia biletów Kerberos do LSASS oraz zadania GPO zakładające lokalne konta).

Praktyczne konsekwencje / ryzyko

Omijanie EDR host-based: wykonanie i artefakty procesu są „przeniesione” do VM, a ruch C2 bywa widoczny jedynie jako zwykły HTTPS z IP hosta. Bez inspekcji na granicy host↔VM anomalia może pozostać niewidoczna.
Trwałość i pivot: reverse proxy ułatwia skryte łącza zwrotne i przesiadki w sieci, także gdy host jest pozornie „czysty”.
Mylenie obrony: nazwanie VM jako „WSL” i ulokowanie plików w ProgramData\Microsoft\AppV\ ma obniżyć czujność operatorów SOC.

Rekomendacje operacyjne / co zrobić teraz

Inwentaryzacja i kontrola wirtualizacji
- Wymuś politykę: Hyper-V wyłączone na stacjach/serwerach, gdzie nie jest potrzebne. Alarmuj na nagłe włączenie roli Hyper-V (zapis DISM), import/start VM (logi Hyper-V/VMMS) oraz tworzenie VMCX/VHDX w nietypowych ścieżkach (ProgramData\Microsoft\AppV\...).
Telemetria host↔VM i sieć
- Monitoruj interfejs vEthernet (Default Switch), nietypowe połączenia wychodzące przez 443 z hostów bez roli serwerowej, a także HTTP/HTTPS z długimi sesjami i stałą entropią (tunnel). Stosuj egress filtering i listy dozwolonych kierunków.
Hunting
- Szukaj: Start-VM -Name WSL, Import-VM na hostach użytkowników; śladów RAR/WinRAR rozpakowujących VM z archiwów; obecności katalogu AppV\app\Virtual Machines\*.vmcx. W logach PowerShell – nietypowe I/O redirection typu | cmd > %ProgramData%\WindowsUpdateTask_*.tmp.
EDR/EDR+NDR
- Uzupełnij EDR o host-based network inspection (np. sensoring ruchu z interfejsów wirtualnych) i detekcje HTTPS-tunnel. Bez takiej warstwy VM-based C2 może pozostać niewidoczny.
Twardnienie i polityki
- Blokuj możliwość Import-VM/Start-VM dla zwykłych użytkowników; kontroluj WinRM/PowerShell Remoting, używaj Credential Guard/LSA Protection, ogranicz Kerberos ticket manipulation.
IR: triage VM-ów
- Jeśli wykryto ślady: zrzut konfiguracji Hyper-V (VM list, switch, NAT), snapshot dysku VHDX do analizy (montaż read-only), sprawdzenie cronów w /etc/crontabs i plików /bin/init_tools, /root/updater, ~/.ssh/config. Hashy CurlyShell/CurlCat porównaj z IOC z publikacji.

Różnice / porównania z innymi przypadkami

Kryminaliści/ransomware wcześniej wykorzystywali VM-y (np. do szyfrowania z wnętrza maszyny), jednak Curly COMrades idzie dalej: VM stanowi bazę operacyjną C2 z customowymi implantami i trwałą łącznością, a nie tylko jednorazowym narzędziem. Nowością jest też agresywne „udawanie” WSL i prekonfigurowany tunel SSH→HTTPS oparty na własnym komponencie (CurlCat).

Podsumowanie / kluczowe wnioski

Wirtualizacja to nie „bezpieczna strefa” – to wektor ukrywania operacji.
Widoczność w warstwie Hyper-V (zdarzenia, konfiguracje, pliki) i inspekcja ruchu z interfejsów wirtualnych stają się krytyczne.
Implementuj zasadę najmniejszych uprawnień dla operacji Hyper-V, monitoruj Default Switch i poluj na artefakty „WSL” w Hyper-V.

Źródła / bibliografia

Bitdefender: „Curly COMrades: Evasion and Persistence via Hidden Hyper-V Virtual Machines” (04.11.2025) – analiza techniczna, TTP, IoC. (Bitdefender)
BleepingComputer: „Russian hackers abuse Hyper-V to hide malware in Linux VMs” (04.11.2025) – omówienie kampanii. (BleepingComputer)
Dark Reading: „Pro-Russian Hackers Use Linux VMs to Hide in Windows” (04.11.2025) – kontekst i wnioski. (darkreading.com)
The Register: „Russian spies pack custom malware into hidden VMs on Windows” (04.11.2025) – streszczenie i cytaty z badań. (The Register)

Zdalny dostęp to nowe “towary” – cyberprzestępcy kradną fizyczne ładunki przez przejęcia w sektorze TSL

Wprowadzenie do problemu / definicja luki

Nowy raport Proofpoint opisuje rosnący trend kampanii ukierunkowanych na przewoźników i brokerów w transporcie drogowym: atakujący kompromitują konta na giełdach ładunków oraz skrzynki e-mail, by dostarczyć legalne narzędzia zdalnego zarządzania (RMM) i przejąć systemy. Następnie, korzystając z dostępu, składają oferty na prawdziwe zlecenia przewozowe i kradną fizyczny towar. To cyber-enabled cargo theft w wersji 2025.

W skrócie

Przestępcy włamują się do firm TSL (od małych rodzinnych flot po duże podmioty) i instalują RMM (m.in. ScreenConnect, SimpleHelp, PDQ Connect, Fleetdeck, N-able, GoTo Resolve).
Wejście uzyskują przez: przejęte konta na load boardach, wstrzykiwanie wątku e-mail (thread hijacking) oraz masowe kampanie e-mail z linkami do plików .msi/.exe.
Po uzyskaniu zdalnego dostępu prowadzą rozpoznanie i kradną poświadczenia (np. przez WebBrowserPassView), aby pogłębić dostęp i wyłudzać ładunki pod cudzym szyldem.
Straty z kradzieży ładunków wzrosły w 2024 r. o 27% i mają wzrosnąć o kolejne 22% w 2025 r., co potwierdzają dane NICB/CargoNet.

Kontekst / historia / powiązania

Kradzieże ładunków istniały od dziesięcioleci, ale digitalizacja łańcuchów dostaw (load boardy, portale przewoźników, systemy TMS/telematyka) stworzyła nowe wektory nadużyć. Zjawisko opisane przez Proofpoint wpisuje się w obserwowany od 2024 r. zwrot cyberprzestępców ku nadużywaniu legalnych narzędzi RMM jako ładunku pierwszego etapu – to pozwala „przelecieć pod radarem” EDR i filtrów. Trend ten potwierdzają także przeglądy roku od Cisco Talos.

Równolegle środowisko TSL mierzy się z rosnącą liczbą oszustw brokerskich/BEC (podszywanie się pod przewoźników, brokerów, spedytorów), co FBI klasyfikuje jako jedną z kluczowych kategorii oszustw biznesowych.

Analiza techniczna / szczegóły luki

Łańcuch ataku opisany w badaniu wygląda następująco:

Przejęcie konta na giełdzie ładunków (load board) → 2) publikacja fałszywego zlecenia → 3) odpowiedź realnego przewoźnika → 4) wysyłka wiadomości z linkiem do instalatora RMM (.msi/.exe) → 5) stały zdalny dostęp, rozpoznanie i kradzież poświadczeń → 6) składanie ofert i rezerwacja realnych kursów na przejęte dane → 7) fizyczny odbiór ładunku i zniknięcie towaru.

Ładunki pierwszego etapu: ScreenConnect, SimpleHelp, PDQ Connect (często używany do doinstalowania innych RMM), Fleetdeck, N-able, GoTo Resolve, a w starszych kampaniach także NetSupport; obok nich spotykane stealer’y (Lumma, StealC, DanaBot) – wszystkie służą ostatecznie do zdalnego dostępu i kradzieży danych.

Techniki dostarczenia:

Compromised load boards – linki do „umów przewoźnik-broker” hostowanych na domenach podszywających się pod branżowe serwisy.
Email thread hijacking – wstrzyknięcie złośliwego URL w trwającą korespondencję.
Masowe kampanie e-mail do operatorów TSL.
Wszystkie prowadzą do pobrania podpisanych instalatorów RMM, co utrudnia detekcję i podnosi współczynnik instalacji.

Po kompromitacji napastnicy wyłączają powiadomienia, podsłuchują komunikację, przekierowują telefony dispatchera i pod tożsamością ofiary rezerwują kursy. Proofpoint wskazuje przypadki, gdzie atakujący usuwali istniejące zlecenia i podstawiali własne środki do odbioru.

Praktyczne konsekwencje / ryzyko

Realna utrata towaru o średniej wartości przekraczającej 200 tys. USD na incydent; roczne straty biją rekordy.
Zakłócenia łańcucha dostaw i koszty wtórne: kary SLA, wzrost składek ubezpieczeniowych, utrata kontraktów i reputacji.
Ryzyko przeniesienia ataku do systemów pokrewnych (TMS, ELD, fakturowanie), gdyż RMM daje szerokie uprawnienia i bywa akceptowane przez polityki bezpieczeństwa.

Rekomendacje operacyjne / co zrobić teraz

1) Zarządzanie RMM (allow-list i monitoring)

Zablokuj instalację jakiegokolwiek RMM spoza listy zatwierdzonych narzędzi; wymuś podpisy/aprobaty IT oraz wdroż zasady kontroli aplikacji (WDAC/AppLocker).
Monitoruj DNS/HTTP(S) pod kątem domen i sygnatur RMM (ET/IDS); Proofpoint publikuje konkretne reguły ET dla ScreenConnect, SimpleHelp, PDQ, N-able, Fleetdeck, GoTo Resolve.

2) E-mail i tożsamość

Włącz i egzekwuj MFA odporne na phishing (FIDO2/WebAuthn) do poczty i aplikacji load-board/TMS; wymuś DMARC z p=reject, SPF, DKIM; blokuj załączniki/URL prowadzące do plików .msi/.exe.
Szkol personel ds. sprzedaży/dispatch i kierowców w rozpoznawaniu wstrzykiwania wątków i podszywania się; raportuj każde podejrzane „porozumienie przewoźnik-broker” przesyłane jako link do instalatora.

3) Procesy branżowe (wg NMFTA Framework)

Weryfikacja tożsamości przewoźnika/brokera (cross-check SCAC/MC/DOT, weryfikacja telefoniczna z niezależnego numeru, „call-back” na numer z oficjalnych rejestrów).
Segregacja obowiązków przy publikacji/akceptacji ładunków; wymóg drugiej pary oczu przy zmianie danych płatniczych lub odbioru.
Kontrole w load boardach: alerty anomalii (nagłe zmiany banku, nowy numer telefonu), zautomatyzowane blokady dla nowych domen e-mail.

4) Telemetria i reagowanie

Zbieraj logi z RMM (instalacje, połączenia, zdalne sesje); zdefiniuj reguły EDR/NDR i runbook izolacji hosta, resetu haseł oraz wyłączenia zdalnych pluginów.
Testuj procedurę „fake load drill” – symulację podejrzanego zlecenia i ścieżki eskalacji do CSIRT.

5) Ubezpieczenia i ciągłość działania

Zweryfikuj zakres polis cargo pod kątem incydentów cyber-enabled i wymogów dowodowych (telemetria, potwierdzenia odbioru, łańcuch kontaktów). Dane o eskalacji szkód potwierdza NICB/CargoNet.

Różnice / porównania z innymi przypadkami

Ransomware vs. cargo theft: tu celem nie są dane ani okup, lecz zysk z fizycznego towaru – dlatego TTP skupia się na wiarygodności (legalny RMM, prawdziwe zlecenia), a nie na destrukcji.
Klasyczny RAT vs. RMM: legalne RMM mają podpisane instalatory i infrastrukturę SaaS, co obniża skuteczność filtrów reputacyjnych i wzbudza mniejszą czujność użytkownika. Ten wektor jest szeroko obserwowany w szerszym krajobrazie zagrożeń.
BEC w TSL: elementy BEC (podszywanie się, zmiany płatności) występują równolegle, ale w omawianym schemacie główną monetą jest ładunek, nie przelew.

Podsumowanie / kluczowe wnioski

Atakujący łączą socjotechnikę specyficzną dla TSL z nadużyciem legalnych narzędzi RMM, by wynieść realne towary.
Obrona wymaga nie tylko kontroli technicznych (allow-list RMM, EDR/ET, MFA), ale też dyscypliny procesowej: twardej weryfikacji tożsamości i higieny pracy na giełdach ładunków.
Dane z rynku (NICB/CargoNet) wskazują, że 2025 r. przyniesie dalszy wzrost kradzieży – organizacje muszą uszczelnić punkty styku IT-OT-logistyka już teraz.

Źródła / bibliografia

Proofpoint: Remote access, real cargo: cybercriminals targeting trucking and logistics (03.11.2025). (Proofpoint)
NICB: Cargo Theft (aktualizacja 2025; statystyki +27% w 2024, prognoza +22% w 2025). (nicb.org)
NMFTA: Cybersecurity Cargo Crime Reduction Framework v1.0 (12.06.2025). (Regulations.gov)
Cisco Talos: 2024 Year in Review – trendy nadużyć RMM/tożsamości. (Cisco Talos Blog)
FBI/IC3: 2024 Internet Crime Report – kontekst BEC i oszustw płatniczych. (ic3.gov)

Hakerzy atakują brytyjskich dostawców wody pitnej. Co ujawniają raporty do DWI i co zmieni nowe prawo?

Wprowadzenie do problemu / definicja luki

Brytyjskie przedsiębiorstwa wodociągowe zgłosiły do Drinking Water Inspectorate (DWI) łącznie 15 incydentów w okresie 1.01.2024–20.10.2025, z czego pięć dotyczyło cyberataków – ujawnia analiza wniosków FOI opisana przez Recorded Future News. Ataki nie zakłóciły dostaw ani jakości wody, ale uderzały w systemy organizacji wspierające ciągłość usług. Sprawa odsłania lukę w przepisach NIS: obowiązkowe jest raportowanie tylko tych zdarzeń, które rzeczywiście przerwały świadczenie usługi – co w praktyce może zaniżać obraz ryzyka prepozycjonowania i działań APT.

W skrócie

5 cyberincydentów zgłoszonych „poza zakresem NIS” (dobrowolnie), łącznie 15 raportów do DWI od 2024 r.
Obecne Regulacje NIS wymagają zgłoszenia tylko wtedy, gdy dojdzie do realnej niedostępności usługi kluczowej.
Rząd zapowiada Cyber Security and Resilience Bill, który ma obniżyć próg raportowania i wzmocnić obowiązki dla infrastruktury krytycznej.
Wektor OT pozostaje wrażliwy (np. Unitronics PLC); w 2023–2024 r. ostrzegały o tym wspólne alerty CISA/NCSC.
Trwałe prepozycjonowanie (np. Volt Typhoon) podbija ryzyko, które regulacje „reaktywne” mogą przeoczyć.

Kontekst / historia / powiązania

W sektorze wodnym historycznie dominowały incydenty w IT/biurze (np. ransomware), rzadziej bezpośrednio w OT/ICS. Tendencję potwierdzają przypadki w Europie (m.in. brytyjski South Staffs Water czy hiszpańskie Aigües de Mataró), przy czym sam proces uzdatniania i dystrybucji zwykle nie został naruszony. Raport DWI pokazuje jednak, że dostawcy mimo braku formalnego obowiązku zaczynają dzielić się informacjami o cyberzdarzeniach wpływających na „odporność dostaw” – to krok w stronę kultury wymiany danych o zagrożeniach.

Analiza techniczna / szczegóły luki

Dlaczego obecny próg NIS jest problematyczny? Regulacje w wersji obowiązującej w Wielkiej Brytanii koncentrują się na incydentach, które doprowadziły do przerwy w usłudze (ang. essential service). W efekcie:

Ciche naruszenia (np. rekonesans, uzyskanie trwałego dostępu, zmiana konfiguracji bez skutku operacyjnego) mogą nie być zgłaszane.
Z perspektywy OT/ICS jest to krytyczne: prepozycjonowanie APT w sieci zakładu, segmentacji lub w kontrolerach PLC może trwać miesiącami bez widocznej awarii.

Przykład wektora: w 2023 r. CISA ostrzegła przed aktywną eksploatacją PLC Unitronics w zakładach wod-kan; NCSC równolegle wskazało na ryzyko w sektorze wodnym i potrzebę twardszej separacji IT/OT oraz twardej konfiguracji urządzeń. To typowe punkty zaczepienia dla aktorów państwowych i przestępczych.

Praktyczne konsekwencje / ryzyko

Ryzyko systemowe: brak pełnej widoczności zdarzeń poniżej progu NIS utrudnia świadomość sytuacyjną – zarówno u operatorów, jak i organów państwowych.
Ryzyko dla OT: nawet jeśli wody „nie zabrakło”, ataki na „out-of-NIS-scope systems” (systemy pomocnicze, zaplecze IT, telemetria) mogą degradować zdolność reagowania, utrzymania i bezpieczeństwo pracy.
Ryzyko geopolityczne: kampanie pokroju Volt Typhoon celują w infrastrukturę krytyczną, gdzie utrzymanie dostępu jest ważniejsze niż szybki efekt – co wymaga innej strategii detekcji i raportowania.

Rekomendacje operacyjne / co zrobić teraz

Raportowanie „poniżej progu” jako standard – podążaj za dobrym przykładem branży i zgłaszaj do DWI/NCSC także incydenty niewywołujące przerwy, zwłaszcza w warstwie OT/telemetrii.
Twarda segmentacja IT/OT i zasada najmniejszych uprawnień – mikrosegmentacja, odrębne domeny, kontrola przepływów (firewall L7, allow-list) między strefami. Rekomendacja spójna z wytycznymi NCSC.
Higiena PLC/RTU – odłącz nieużywane interfejsy, zmień domyślne hasła, włącz MFA i VPN dla zdalnego dostępu, monitoruj anomalie protokołów przemysłowych; zastosuj zalecenia z alertu CISA ws. Unitronics.
Łowy na zagrożenia (threat hunting) pod kątem prepozycjonowania – identyfikuj techniki mapowane do MITRE ATT&CK for ICS (np. Tactics: Initial Access/Discovery/Lateral Movement) wskazywane w doradztwach nt. Volt Typhoon/NCSC.
Ćwiczenia scenariuszowe – tabletop’y obejmujące varianty „no-impact yet”, np. znajdowanie web-shelli w DMZ SCADA, nietypowe polecenia na HMI, podejrzane zmiany w konfiguracji PLC.
Zarządzanie dostawcami – inwentaryzacja zewnętrznych serwisów (telemetria, łączność, ICS managed services), umowy z obowiązkami notyfikacji i testami 3rd-party.

Różnice / porównania z innymi przypadkami

IT vs OT: większość europejskich incydentów wodnych w ostatnich latach dotyczyła IT, co ograniczało wpływ na fizyczny proces (np. przypadki opisywane przez media branżowe). Ryzyko OT materializuje się rzadziej, ale gdy do niego dochodzi, skutki są natychmiast odczuwalne – co potwierdzają międzynarodowe ostrzeżenia dotyczące PLC i ICS.
NIS (UK) vs podejście „proaktywne”: podejście oparte wyłącznie na skutku operacyjnym różni się od praktyk, które zachęcają do reportowania faz wczesnych (rekonesans, dostęp wstępny). Zapowiadany Cyber Security and Resilience Bill ma zbliżyć regulacje do modelu proaktywnego (szybsze zgłaszanie, szerszy zakres).

Podsumowanie / kluczowe wnioski

Sektor wodny w Wielkiej Brytanii jest aktywnie atakowany, ale obecnie nie obserwuje się powszechnych przerw w dostawach – co nie znaczy, że ryzyko jest niskie.
Próg raportowania w NIS wymaga aktualizacji do realiów prepozycjonowania i ataków na łańcuch dostaw OT/ICS.
Nowe prawo (Cyber Security and Resilience Bill) ma potencjał, by zamknąć luki regulacyjne i zwiększyć odporność CNI – kluczowe będzie wdrożenie i egzekwowanie.
Operacyjnie należy traktować incydenty „poniżej progu” jak czerwone flagi i budować detekcję pod wczesne fazy ataku w OT.

Źródła / bibliografia

Recorded Future News – raport o zgłoszeniach do DWI (FOI) i atakach na brytyjskich dostawców wody (03.11.2025). (The Record from Recorded Future)
DWI – „The Network and Information Systems (NIS) Regulations 2018” (wymogi i zgłaszanie). (Drinking Water Inspectorate)
GOV.UK – „Cyber Security and Resilience Bill” (kolekcja materiałów dot. projektu ustawy). (GOV.UK)
CISA – „Exploitation of Unitronics PLCs used in Water and Wastewater Systems” (28.11.2023). (cisa.gov)
NCSC – ostrzeżenia dot. PRC/Volt Typhoon i prepozycjonowania w CNI (07.02.2024; 30.11.2023). (ncsc.gov.uk)

ASKUL potwierdza wyciek danych po ataku ransomware. Co wiemy i jak się przygotować?

Wprowadzenie do problemu / definicja luki

Japoński sprzedawca artykułów biurowych i operator popularnych platform e-commerce (ASKUL, LOHACO, Soloel Arena) potwierdził wyciek danych po incydencie ransomware, który wywołał poważną awarię systemów i wstrzymał część operacji logistycznych. Firma przekazała, że naruszenie objęło m.in. dane kontaktowe oraz treści zapytań klientów, a także informacje dostawców przechowywane na serwerach wewnętrznych. Do ataku przypisała się grupa RansomHouse, która twierdzi, że wykradła duże wolumeny danych.

W skrócie

Detekcja incydentu: 19 października 2025 r. wykryto infekcję ransomware i odłączono dotknięte sieci.
Skala zakłóceń: czasowe wstrzymanie zamówień/wydań na kilku serwisach, utrudnienia w łańcuchu dostaw partnerów (np. MUJI).
Potwierdzony wyciek: ASKUL 31 października potwierdził wyciek danych (m.in. imiona, nazwiska, e-maile) i uruchomił dedykowaną infolinię od 4 listopada.
Atrybucja przestępcza: RansomHouse opublikował komunikat o kradzieży danych; niezależne trackery odnotowały wpis grupy dot. ASKUL.

Kontekst / historia / powiązania

Awaria uderzyła nie tylko w sklepy własne ASKUL, ale też w klientów B2B korzystających z jej logistyki. Japońskie media informowały o czasowym wstrzymaniu sprzedaży online przez MUJI i o szerokim wpływie na łańcuch dostaw w kraju. W pierwszych dniach (20–22 października) firma publikowała kolejne aktualizacje o stanie usług, a 29 października ruszyły ograniczone „trialowe” wysyłki m.in. dla instytucji medycznych (ręczne procesy FAX). 30–31 października odnotowano publiczne deklaracje RansomHouse i wstępne potwierdzenie wycieku.

Analiza techniczna / szczegóły luki

ASKUL wskazuje na złośliwy dostęp zewnętrzny zakończony infekcją ransomware, po czym odizolowano segmenty sieci. Publiczne komunikaty nie zawierają nazw wariantu ani wektora wejścia; modus operandi RansomHouse w poprzednich kampaniach zwykle obejmuje exfiltrację dużych porcji danych i wymuszenie bez szyfrowania lub z ograniczonym szyfrowaniem („double extortion”). W sprawie ASKUL grupa twierdzi, że zdobyła nawet ~1,1 TB danych (informacje klientów, historii zakupów, dokumenty firmowe), choć skala i kompletność tych zasobów nie zostały jeszcze potwierdzone przez spółkę. Tracker ransomware.live odnotował roszczenie grupy i szacuje datę ataku na 19 października.

Jakie dane wyciekły? Oficjalnie potwierdzone są: dane kontaktowe klientów (np. imię, nazwisko, e-mail) oraz treści zapytań składanych przez formularze online, a także informacje części dostawców. Firma kontynuuje weryfikację pełnego zakresu incydentu.

Praktyczne konsekwencje / ryzyko

Ryzyko phishingu i spoofingu: Ujawnienie e-maili i danych kontaktowych ułatwi ataki BEC, podszycia pod ASKUL/LOHACO i socjotechnikę na dostawców.
Naruszenia w łańcuchu dostaw: Zakłócenia logistyki pokazały wrażliwość partnerów detalicznych (np. MUJI) na ataki u operatorów fulfillmentu.
Wyciek zapytań klientów: Treści korespondencji mogą zawierać dane adresowe/identyfikacyjne; przy publikacji porzuconych „paczek danych” rośnie ryzyko doxingu. (Wniosek na podstawie charakteru wykradzionych pól i typowych publikacji RansomHouse).
Ryzyka regulacyjne: ewentualny zakres danych może implikować obowiązki notyfikacyjne i roszczenia cywilne na rynku japońskim oraz – jeśli dotyczy – transgraniczne.

Rekomendacje operacyjne / co zrobić teraz

Dla klientów i kontrahentów ASKUL/LOHACO:

Uruchom filtry DMARC/DKIM/SPF w polityce „reject/quarantine” oraz tagowanie zewnętrznej korespondencji; egzekwuj 2FA do paneli B2B.
Wdrażaj playbooki reagowania na phishing/BEC, w tym numerowane kanały weryfikacji płatności.
Użyj monitoringu wycieków (haveibeenpwned + komercyjne) i resetów haseł wszędzie tam, gdzie adres e-mail był loginem.
Po stronie pracowników: alert o kampaniach podszywających się pod ASKUL – zwiększona czujność na faktury, „aktualizacje zamówień”, zmiany rachunków.
Zgłaszaj incydenty do właściwych organów i korzystaj z dedykowanej infolinii ASKUL (czynna od 4 listopada 2025 r.).

Dla działów bezpieczeństwa (w szerszym ujęciu supply chain):

Segmentacja i zasada najmniejszych uprawnień w środowiskach fulfillment/e-commerce; izolacja stref EDI/WMS/TMS.
EDR/XDR + NDR z analityką wycieku danych (DLP) i korelacją anomalii ruchu (duże transfery do chmur/anonymizerów).
Twarde MFA bez SMS dla kont uprzywilejowanych i dostępów zewnętrznych; rotacja kluczy API.
Back-upy offline testowane pod przywracanie RTO/RPO oraz drille table-top z partnerami.
Third-party risk: przegląd kontraktów (RTO, SLO, wymogi SOC2/ISO 27001), skany ASV, ocena „blast radius” dla kluczowych operatorów.

Różnice / porównania z innymi przypadkami

W odróżnieniu od wielu ataków, które zaczynają się od szyfrowania i dopiero potem grożą publikacją, RansomHouse często stawia na ekstrakcję danych i presję reputacyjną – co potwierdzają komunikaty o udostępnianiu ogromnych paczek danych (tu: deklarowane ~1,1 TB). To zbliża ich taktykę do grup nastawionych na „pure extortion”. Wpływ na MUJI podkreśla natomiast charakter ataków na łańcuch dostaw, gdzie „single point of failure” (operator logistyczny) powoduje przestoje u wielu marek.

Podsumowanie / kluczowe wnioski

Incydent w ASKUL to klasyczny scenariusz double extortion z potwierdzonym wyciekiem danych kontaktowych i zapytań klientów oraz danymi dostawców. Skala pełnego wycieku wciąż jest weryfikowana.
Łańcuch dostaw retail/e-commerce pozostaje miękkim celem: konsekwencje awarii u operatora rozlewają się na wiele marek.
Organizacje powinny wzmocnić kontrolę nad partnerami i przygotować playbooki BEC/phishing po wyciekach danych, bo to najbliższa fala nadużyć.

Źródła / bibliografia

The Record (Recorded Future News): „Japanese retailer Askul confirms data leak after cyberattack” – szczegóły potwierdzonych kategorii danych i oświadczenie spółki (31.10–03.11.2025). (The Record from Recorded Future)
PR Times (oficjalne komunikaty ASKUL): „Informacja o wycieku i przeprosiny” + harmonogram działań i infolinia od 4.11.2025. (プレスリリース・ニュースリリース配信シェアNo.1｜PR TIMES)
Jiji Press via Nippon.com: potwierdzenie wycieku (nazwy, e-maile) i tło incydentu (31.10.2025). (Nippon)
The Register: wpływ na MUJI po ataku na dostawcę logistycznego ASKUL (21.10.2025). (theregister.com)
Ransomware.live: wpis o roszczeniu RansomHouse i oszacowaniu daty ataku (30.10.2025). (ransomware.live)

Amerykańscy specjaliści ds. cyberbezpieczeństwa oskarżeni o ataki ransomware BlackCat (ALPHV)

Wprowadzenie do problemu / definicja sprawy

3 listopada 2025 r. media branżowe ujawniły akt oskarżenia wobec trzech obywateli USA — w tym dwóch byłych negocjatorów ds. ransomware i menedżera IR — którym zarzucono działanie jako afilianci gangu ALPHV/BlackCat oraz przeprowadzenie serii ataków na co najmniej pięć firm w USA (służba zdrowia, farmacja, inżynieria, UAV). Według śledczych sprawcy włamali się do sieci, wykradli dane, wdrożyli szyfrator BlackCat i żądali okupu w kryptowalutach. Jedna z ofiar — producent urządzeń medycznych z Tampy — miała zapłacić ok. 1,27 mln USD.

W skrócie

Kim są oskarżeni: Ryan Clifford Goldberg (były IR Manager w Sygnia), Kevin Tyler Martin (były negocjator w DigitalMint) oraz nieujawniony z nazwiska współsprawca.
Zakres działań: włamania, kradzież danych, wdrożenie ransomware ALPHV/BlackCat oraz wymuszenia (maj–listopad 2023; w dokumentach są też uzupełnienia procesowe z 2025 r.).
Kary: za zarzuty dot. wymuszeń i celowego uszkodzenia systemów grożą im dziesiątki lat więzienia; część podejrzanych przebywała w areszcie, inni nie przyznali się do winy.
Model przestępstwa: klasyczny Ransomware-as-a-Service (RaaS) — operatorzy ALPHV dostarczają narzędzia, a afilianci (tu: oskarżeni) prowadzą włamania i dzielą się zyskami.

Kontekst / historia / powiązania

ALPHV/BlackCat to jedna z najaktywniejszych rodzin ransomware od końca 2021 r., znana z ataków na podmioty ochrony zdrowia i infrastrukturę krytyczną oraz z podwójnego (a czasem potrójnego) wymuszania. W 2024 r. FBI, CISA i HHS publikowały wspólne ostrzeżenia techniczne z aktualnymi IOC i TTP.

Analiza techniczna / szczegóły sprawy

Wejście do sieci i eskalacja: Z aktu oskarżenia i doniesień wynika, że sprawcy uzyskiwali nieuprawniony dostęp do środowisk ofiar, eksfiltrowali wrażliwe dane, a następnie wdrażali szyfrator BlackCat. Ofiary obejmowały m.in. firmę medtech z Florydy (Tampa), producenta farmaceutycznego z Maryland, praktykę lekarską i biuro inżynieryjne w Kalifornii oraz wytwórcę dronów w Wirginii. Kwoty żądań mieściły się od 300 tys. do 10 mln USD.

Rola „insiderów branżowych”: Szczególnie alarmujący jest fakt, że oskarżeni pracowali w firmach świadczących usługi IR i negocjacji okupów. Według sądu i materiałów prasowych co najmniej jeden z podejrzanych miał pozostać w areszcie, a drugi nie przyznał się do winy; firmy, w których pracowali, podkreśliły współpracę z organami ścigania i brak wiedzy o przestępstwach.

Model RaaS w praktyce: Zgodnie z opisem TechCrunch, ALPHV/BlackCat funkcjonuje w modelu RaaS: operatorzy tworzą malware i infrastrukturę, a afilianci prowadzą penetrację i eskalację, dzieląc się okupem z operatorem. To klasyczny układ, który obniża barierę wejścia dla atakujących i utrudnia atrybucję.

Praktyczne konsekwencje / ryzyko

Erozja zaufania do łańcucha dostaw bezpieczeństwa: gdy osoby z firm IR/negocjacyjnych stają się afiliantami RaaS, standardowe due-diligence dostawców przestaje wystarczać.
Ryzyko nadużyć informacji wrażliwych: dostęp do artefaktów incydentów, procedur, runbooków i danych klientów może ułatwiać planowanie ataków „pod klienta”. (W sprawie padają przykłady celowania w sektory o wysokiej skłonności do płatności).
Presja regulacyjna i ubezpieczeniowa: zgodność z wytycznymi #StopRansomware (FBI/CISA/HHS) i warunkami polis cyber stanie się bardziej rygorystyczna po tym precedensie.

Rekomendacje operacyjne / co zrobić teraz

Zarządzanie dostawcami i personelem:

KYE (Know Your Employee/Expert) i KYS (Know Your Supplier): ponowna weryfikacja kluczowych konsultantów IR/negocjatorów, kontrole konfliktu interesów, NDA z klauzulami o zakazie afiliacji z RaaS.
Segregacja ról: negocjacje okupowe i IR prowadzone przez oddzielne zespoły/firmy; dostęp „just-in-time” i „least privilege” dla zewnętrznych konsultantów.
Monitoring działań konsultantów: dzienniki EDR/SIEM obejmujące konta dostawców; wymóg sesji uprzywilejowanych przez PAM z pełnym nagraniem.

Higiena techniczna:

Hardening tożsamości: MFA niefiszowalne (FIDO2/Passkeys) dla VPN/RDP/M365; polityki Conditional Access i monitorowanie anomalii logowania.
Segmentacja i EDR: segmentacja sieci + EDR z regułami behawioralnymi dla znanych TTP ALPHV (np. Living-off-the-Land, exfil+encrypt). Wytyczne IOC/TTP patrz #StopRansomware.
Kopia „3-2-1-1-0”: kopie zapasowe offline/immutability + regularne testy odtwarzania scenariusza „exfil + wiper”.
DLP i egress control: kontrola wycieku (S3/SharePoint/SMTP), ograniczenia do domen zaufanych, szyfrowanie i tokenizacja danych wrażliwych.

Proces i prawo:

Runbook „bez płatności z zaskoczenia”: rada kryzysowa, ścieżka zgłoszeń do organów ścigania, ocena sankcyjna; minimalizuj rozmowy 1:1 z „negocjatorami z ulicy”.
Kontrakty: klauzule o audytowalności, „right-to-monitor”, odpowiedzialności i karach umownych przy naruszeniach etycznych.

Różnice / porównania z innymi przypadkami

Wcześniej głośne były sprawy „pośredników” i firm odzysku danych ukrywających płatności dla gangów. Tu jednak rdzeniem jest aktywna afiliacja RaaS przez osoby z branży IR/negocjacji, co stanowi jakościowo bardziej niebezpieczny precedens — wprost podważa to model zaufania do dostawców reagowania na incydenty.

Podsumowanie / kluczowe wnioski

Akt oskarżenia z 3 listopada 2025 r. pokazuje, że wektor „insider-affiliate” przestał być scenariuszem teoretycznym.
Organizacje muszą traktować dostawców IR/negocjacji jak użytkowników uprzywilejowanych, z pełną telemetrią i kontrolą.
Utrzymuj zgodność z najnowszymi wytycznymi #StopRansomware i stale weryfikuj partnerów bezpieczeństwa.

Źródła / bibliografia

BleepingComputer — „US cybersecurity experts indicted for BlackCat ransomware attacks” (03.11.2025). (BleepingComputer)
Reuters — „US prosecutors say cybersecurity pros ran cybercrime operation” (03–04.11.2025). (Reuters)
CyberScoop — „Prosecutors allege incident response pros used ALPHV/BlackCat to commit string of ransomware attacks” (03.11.2025). (CyberScoop)
TechCrunch — „DOJ accuses US ransomware negotiators of launching their own ransomware attacks” (03.11.2025). (TechCrunch)
CISA/FBI/HHS — „#StopRansomware: ALPHV BlackCat” (2024 – aktualizacje IOC/TTP). (cisa.gov)

Najczęściej Wykorzystywane Podatności CVE W Atakach Cybernetycznych

CVE, które przeszły do historii

Altualne na dzień 3.11.2025 – Artykuł będzie aktualizowany planowo 2 razy do roku.

Analizy firm z branży cyberbezpieczeństwa (m.in. Mandiant, Rapid7, Recorded Future, MITRE ATT&CK, Palo Alto Unit 42) oraz instytucji rządowych (CISA, FBI) wskazują na listę podatności, które były najczęściej wykorzystywane przez grupy APT oraz cyberprzestępców w latach 2010–2024.

Czytaj dalej