Archiwa: Phishing - Strona 72 z 99 - Security Bez Tabu

DroidLock: nowe oprogramowanie wymuszające dla Androida blokuje urządzenia i żąda okupu

Wprowadzenie do problemu / definicja luki

10–11 grudnia 2025 r. badacze Zimperium opisali nową kampanię złośliwego oprogramowania na Androida o nazwie DroidLock. Malware blokuje ekran, wymusza kontakt e-mailowy i grozi zniszczeniem danych w 24 godziny, a dodatkowo umożliwia atakującemu niemal pełne przejęcie urządzenia (zdalne sterowanie, zmiana PIN/biometrii, wipe). Celem są głównie użytkownicy hiszpańskojęzyczni, a dystrybucja odbywa się przez fałszywe strony i aplikacje podszywające się m.in. pod operatorów telekomunikacyjnych.

W skrócie

  • Typ zagrożenia: ransomware-locker (bez szyfrowania plików, z blokadą dostępu + groźbą zniszczenia danych).
  • Wejście: phishing stron/apek, dropper → drugi etap z właściwym payloadem.
  • Uprawnienia: nadużycie Accessibility Services i Device Administrator do przejęcia kontroli (lock/wipe/zmiana PIN).
  • Zdalne sterowanie: kanały HTTP/WebSocket, VNC (sharing/stream ekranu).
  • Celowana kampania: użytkownicy hiszpańskojęzyczni (Hiszpania).
  • Wykrywanie: Zimperium zgłasza próbki w ramach App Defense Alliance; Play Protect ma blokować znane warianty.

Kontekst / historia / powiązania

„Lockery” na Androida pojawiają się od lat (np. Android/Locker, DoubleLocker). Klasyczne taktyki to pełnoekranowe nakładki, wymuszenia quasi-policyjne oraz nadużycia Device Admin/Accessibility – dokładnie te elementy widzimy w DroidLock. Historyczne analizy ESET opisują, jak twórcy mobilnego ransomware’u od lat korzystają z tych mechanizmów i jak w 2017–2018 r. zaczęli masowo nadużywać Accessibility do automatycznego nadawania sobie uprawnień.

Analiza techniczna / szczegóły luki

Łańcuch infekcji. Użytkownik trafia na phishingową stronę i pobiera dropper, który dosyła właściwy moduł (drugi etap). Po instalacji malware żąda Accessibility i Device Admin, a gdy ofiara je nada, samo „klika” kolejne zgody, aby uzyskać dostęp do SMS-ów, kontaktów, logów połączeń, audio itp.

Komunikacja i C2. DroidLock ustanawia połączenia HTTP (telemetria) i WebSocket (komendy w czasie rzeczywistym). Obsługuje 15 komend, m.in.: RANSOMWARE (nakładka żądania okupu), BLACK_SCREEN / UPDATE_OVERLAY (fałszywy ekran aktualizacji blokujący interakcje), BLOCK_BIOMETRIC (blokada urządzenia), WIPE (factory reset), MUTE, CAMERA, VNC (zdalne sterowanie), INJECT_APP (nakładki credential harvesting), APP_BLOCK_LOCK_PATTERN (kradzież wzoru blokady), UNINSTALL_APP.

Nakładki i kradzież wzoru blokady. Malware wstrzykuje WebView/HTML nad wybranymi aplikacjami albo wyświetla szybki „lock-pattern overlay” z zasobów APK, by przejąć wzór odblokowania i ułatwić późniejsze sterowanie VNC.

Ransom-overlay i wymuszenie. Po komendzie z C2 wyświetla się pełnoekranowy ekran z instrukcją kontaktu (adres Proton) i ultimatum 24 h. DroidLock nie szyfruje plików, ale łączy blokadę urządzenia z groźbą skasowania danych – co skutecznie wymusza okup.

MITRE ATT&CK (Mobile) – przykłady mapowania:

  • T1660 Phishing (dystrybucja przez strony/apki)
  • T1626.001 Abuse Elevation Control (Device Admin)
  • T1629.002 Device Lockout
  • T1516/T1417 Input Injection/Keylogging (sterowanie/zbieranie danych)
  • T1517 Access Notifications (przechwyt OTP)
  • T1414 Clipboard Data (wyciek schowka)
    Zimperium wskazuje te techniki wprost w raporcie.

Praktyczne konsekwencje / ryzyko

  • Utrata dostępu do telefonu (zmiana PIN/biometrii, lockout) i ryzyko utraty danych (wipe).
  • Kompromitacja kont: przejęcie OTP z powiadomień, keylogging/overlay nad bankowością i komunikatorami.
  • Ryzyko dla firm: urządzenie staje się „wrogim punktem końcowym” wewnątrz sieci (VNC, screen recording, sterowanie UI).

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników (BYOD/indywidualni):

  1. Nie instaluj APK spoza Google Play; jeżeli musisz – tylko od sprawdzonych wydawców. Włącz i nie wyłączaj Google Play Protect.
  2. Zachowaj nieufność wobec żądań Accessibility/Device Admin – szczególnie gdy pojawiają się od razu po instalacji.
  3. Jeśli już jesteś zainfekowany/a:
    • Spróbuj uruchomić telefon w Trybie awaryjnym (Safe Mode) i odinstalować podejrzaną apkę; Safe Mode blokuje aplikacje firm trzecich, co często „zdejmuje” nakładkę.
    • Jeśli nie możesz cofnąć uprawnień Device Admin lub usunąć aplikacji – rozważ przywrócenie ustawień fabrycznych z kopii zapasowej (ostatnia deska ratunku). (Wipe jest też wykorzystywany przez sam malware).
  4. Kopie zapasowe (foto/dokumenty) w chmurze/szyfrowane lokalnie – minimalizują presję okupu. (Wnioski ogólne z badań ESET).

Dla organizacji:

  • MTD/EDR na mobile + runtime behavioral detection (np. wykrywanie nadużyć Accessibility/Admin, overlay, VNC/screen-recording).
  • Polityki MDM/UEM: blokuj sideloading, wymagaj sklepów zarządzanych, ogranicz uprawnienia Accessibility, wymuś regularne aktualizacje i skanowanie urządzeń. (Dobre praktyki zgodne z rekomendacjami branżowymi).
  • Szkolenia phishingowe dla mobile i monitoring anomalii (np. nagłe wyciszenie urządzeń, nagłe żądania admin perms).

Różnice / porównania z innymi przypadkami

  • Bez szyfrowania plików, ale z pełnym przejęciem – DroidLock eskaluje w stronę totalnego sterowania (VNC, screen streaming), co rzadziej występowało w starszych lockerach, które skupiały się na nakładkach/pseudo-policyjnych żądaniach.
  • Nowoczesne nadużycia Accessibility + automatyzacja zgód – trend obserwowany od DoubleLocker, lecz tu rozszerzony o bogaty zestaw komend C2.

Podsumowanie / kluczowe wnioski

DroidLock to świeża kampania locker-ransomware na Androida, która nie szyfruje danych, ale łączy blokadę urządzenia, groźbę kasowania i zdalne sterowanie do skutecznego wymuszenia. Najskuteczniejszą ochroną jest niewłączanie sideloadingu, odmowa podejrzanych uprawnień, aktywne Play Protect oraz MTD/MDM w firmach. W razie infekcji – Safe Mode i deinstalacja często wystarczą; gdy to niemożliwe, przywrócenie fabryczne z kopii zapasowej.

Źródła / bibliografia

  1. Zimperium (raport techniczny, 10 grudnia 2025): „Total Takeover: DroidLock Hijacks Your Device”. (zimperium.com)
  2. BleepingComputer (news, 10 grudnia 2025): „New DroidLock malware locks Android devices and demands a ransom”. (BleepingComputer)
  3. SiliconANGLE (news/omówienie, 10 grudnia 2025): „New DroidLock threat gives attackers near-total control of Android phones”. (SiliconANGLE)
  4. Trend Micro (poradnik, 27 października 2025): „Removing lock-screen type ransomware using Safe Mode on Android device”. (Trend Micro Success)
  5. ESET (whitepaper): „Android Ransomware: From Android Defender to DoubleLocker” – kontekst historyczny i taktyki (Device Admin, Accessibility).

„Spiderman” – nowy phishing-as-a-service na celowniku europejskich banków

Wprowadzenie do problemu / definicja luki

Na podziemnych rynkach pojawił się nowy phishing kit o nazwie „Spiderman”, który umożliwia przestępcom szybkie uruchamianie kampanii podszywających się pod dziesiątki europejskich banków, fintechy (np. Klarna, PayPal) oraz portfele kryptowalut (Ledger, MetaMask, Exodus). Zestaw generuje pikselowe klony stron logowania, gromadzi hasła, kody 2FA/OTP, a nawet dane kart płatniczych – i to w czasie rzeczywistym dzięki panelowi operatorskiemu. Badacze z Varonis wskazują też popularność narzędzia (grupa na Signal ~750 członków), co sugeruje aktywne wykorzystanie na szeroką skalę.

W skrócie

  • Zakres: banki w min. pięciu krajach UE (m.in. Deutsche Bank, ING, Comdirect, Volksbank, Commerzbank, CaixaBank), wybrane usługi fintech i krypto.
  • Funkcje: real-time podgląd sesji ofiary, przechwytywanie OTP/PhotoTAN, pełne formularze KYC/kartowe, eksport danych 1-kliknięciem, filtrowanie geo/ISP/urządzeń, przekierowania „niepożądanych” wizyt.
  • Model: gotowy framework PhaaS, obniżający wymagane umiejętności do „kilku klików”, co zwiększa skalę i tempo ataków.

Kontekst / historia / powiązania

Zestawy Phishing-as-a-Service (PhaaS) od lat demokratyzują oszustwa, jednak „Spiderman” wyróżnia się konsolidacją wielu marek bankowych w jednym interfejsie oraz naciskiem na przechwytywanie OTP. Trend automatyzacji i „klikowego” klonowania portali finansowych jest szeroko opisywany w najnowszych analizach branżowych.

Analiza techniczna / szczegóły luki

Architektura i panel operatorski

  • Panel wyświetla na żywo sesje ofiar (login → kolejne kroki weryfikacji), pozwala wyzwalać dodatkowe żądania (np. prośba o PhotoTAN, numer karty, dane osobowe), oznaczać sesje jako „zakończone” i eksportować zebrane rekordy.
  • Modułowość: nowe banki, portale i metody uwierzytelniania można dokładać w formie modułów, co przyspiesza adaptację do zmian w e-bankowości.

Klonowanie i zbieranie danych

  • Mechanizm „Index This Bank” automatycznie przygotowuje klon strony logowania + widoki 2FA/PhotoTAN i formularze kartowe. Dane (login/hasło, PII, numer telefonu, karta, metadane UA/IP) są przekazywane do panelu w czasie rzeczywistym.

Omijanie zabezpieczeń i ukrywanie się

  • Geo-whitelisting, whitelisty ISP/ASN, filtrowanie urządzeń (desktop/mobile/Android/iOS) oraz customowe przekierowania ograniczają widoczność kampanii w crawlerach i narzędziach TI. To utrudnia wykrycie i analizę automatyczną.

2FA w Europie: PhotoTAN

  • „Spiderman” obsługuje PhotoTAN – mozaikowy obraz skanowany aplikacją bankową, generujący OTP specyficzny dla transakcji. Przechwytywanie PhotoTAN/OTP w czasie rzeczywistym sprawia, że same loginy nie wystarczą do ochrony kont.

Praktyczne konsekwencje / ryzyko

  • Przejęcie kont bankowych (ATO) i fraud transakcyjny – atakujący posiadają komplet: poświadczenia + OTP + dane karty.
  • SIM-swapping / kradzież tożsamości – pełne pakiety PII ułatwiają dalsze nadużycia (kredyty, subskrypcje, wyłudzenia).
  • Multi-platformowy wektor – jednoczesne uderzenia w bankowość i krypto zwiększają skalę szkód.

Rekomendacje operacyjne / co zrobić teraz

Dla SOC/Blue Team (banki, fintechy)

  1. Zasilcie detekcję o wskaźniki kampanii PhaaS: korelacje krótkotrwałych klonów domen, certyfikatów DV, hostingu w ASN-ach „residential proxy” i nietypowych łańcuchach przekierowań (przynęta → filtr → klon).
  2. WAF/EDR + threat intel: reguły na zachowania strony logowania (np. nietypowe pola/żądania PhotoTAN poza standardowym flow), rozpoznawanie fingerprinting JS i anti-bot typowych dla kitów.
  3. Telemetryka 2FA: alertuj niespójności – OTP/PhotoTAN żądany bez akcji użytkownika; wiele żądań OTP w krótkim czasie; logowanie i autoryzacja z różnych AS/urz. w obrębie jednej sesji. (Wskazany przez Varonis real-time model ataku.)
  4. Brand protection/Takedown: szybkie seeding i zgłaszanie nowych klonów, automatyczne crawler-y z residential vantage points (obejście geo/ASN filtrów stosowanych przez kit).
  5. Transakcyjne „risk-based auth”: silniejsze reguły dla receiver novelty (nowy odbiorca), amount anomaly, wymuszony out-of-band potwierdzeń (push z opisem transakcji, nie tylko kod).

Dla działów biznesu/bezpieczeństwa klienta

  • UX komunikatów: w aplikacji i WWW wyświetlaj ostrzeżenia kontekstowe o trwających kampaniach (np. „Uwaga: nie podawaj kodu PhotoTAN, jeśli to nie Twoja akcja”).
  • Aktywne edukacje: krótkie, cykliczne in-app bannery i SMS-y o phishingu na markę – zwłaszcza przy wzmożonej aktywności PhaaS. BleepingComputer podkreśla, że kliknięcie linku do fałszywej domeny jest wciąż warunkiem powodzenia ataku.

Dla użytkowników (polskich i UE)

  • Sprawdzaj domenę przed logowaniem i unikaj linków z SMS/e-mail prowadzących „na skróty”.
  • Nie podawaj PhotoTAN/OTP, jeśli nie inicjowałeś logowania/operacji — to silny sygnał przejęcia.
  • Używaj aplikacji bankowej do wchodzenia na konto (głębokie linki oficjalne), a nie linków z wiadomości.
  • Zgłaszaj podejrzane strony bankowi; w razie wątpliwości zablokuj kartę i zmień hasło.

Różnice / porównania z innymi przypadkami

  • W porównaniu z typowymi kitami „single-brand”, „Spiderman” konsoliduje dziesiątki marek i krajów w jednym panelu, co znacząco podnosi efektywność i rotację kampanii.
  • Na tle wcześniejszych fal oszustw bankowych w Europie, gdzie 2FA omijano głównie przez malware w przeglądarce/na telefonie, tutaj kluczowe jest interaktywne przechwytywanie OTP/PhotoTAN w czystym phishingu (bez infekowania urządzeń). Dziennikarskie relacje branżowe potwierdzają „klikowe” klonowanie i real-time kradzież OTP.

Podsumowanie / kluczowe wnioski

„Spiderman” to zaawansowany PhaaS przystosowany do realiów europejskiej bankowości: obsługa PhotoTAN/OTP, szerokie targetowanie wielomarkowe, anty-analiza (geo/ISP/device), a do tego niski próg wejścia dla napastników. W praktyce oznacza to wzrost wolumenu i skuteczności kampanii podszywania się pod banki oraz większe ryzyko ATO i fraudu. Organizacje finansowe powinny priorytetowo wzmocnić detekcję na poziomie zachowań sesji i 2FA, a klienci – unikać linków i nie autoryzować niczego, czego sami nie zainicjowali.

Źródła / bibliografia

  1. B. Toulas, BleepingComputer: New Spiderman phishing service targets dozens of European banks (10 grudnia 2025). (BleepingComputer)
  2. Varonis Threat Labs: Spiderman Phishing Kit Mimics Top European Banks With A Few Clicks (9 grudnia 2025, aktualizacja). (Varonis)
  3. eSecurityPlanet: Spiderman phishing kit lets attackers clone European banks in seconds (10 grudnia 2025). (eSecurity Planet)
  4. (Dodatkowe tło) Zestawienie wpisów Varonis – sekcja Threat Research. (Varonis)

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)

Storm-0249 przechodzi od brokerstwa dostępu do precyzyjnych ataków ransomware: ClickFix, „fileless” PowerShell i DLL sideloading

Wprowadzenie do problemu / definicja luki

Storm-0249 – dotąd klasyfikowany głównie jako initial access broker (IAB) – eskaluje taktyki i zaczyna samodzielnie przygotowywać grunt pod atak ransomware. Najnowsze obserwacje pokazują łańcuch ataku łączący ClickFix (nakłanianie ofiary do uruchomienia poleceń przez okno „Uruchom”), fileless PowerShell oraz DLL sideloading z wykorzystaniem plików powiązanych z EDR, co utrudnia detekcję i sprzyja ukrytej łączności C2. Te działania sygnalizują przejście z kampanii masowego phishingu do precyzyjnych operacji post-eksploatacyjnych nastawionych na późniejsze szyfrowanie zasobów.

W skrócie

  • TTPs: ClickFix → curl.exe → fileless PowerShell → MSI z uprawnieniami SYSTEM → DLL sideloading (np. wobec binariów agenta EDR) → zaszyta komunikacja C2 z procesu „zaufanego”.
  • Cel: utrzymanie dostępu i „ciche” przygotowanie pod ransomware (m.in. zbieranie identyfikatorów systemu jak MachineGuid do wiązania kluczy szyfrujących).
  • Ewolucja aktora: z IAB obsługującego grupy jak Storm-0501, do operatora prowadzącego własne działania post-eksploatacyjne.
  • ClickFix stał się popularną techniką (potwierdzaną przez wielu dostawców), wykorzystywaną także przez bardziej zaawansowane podmioty.

Kontekst / historia / powiązania

Microsoft już w 2024 r. opisywał model współpracy ransomware, w którym tacy brokerzy jak Storm-0249 sprzedają dostęp grupom szyfrującym (np. Storm-0501). Obecna zmiana – przejście od masowego phishingu do „EDR-aware” operacji – skraca czas do eskalacji i zmniejsza liczbę sygnałów ostrzegawczych w SOC. Równolegle ClickFix ewoluował od prostych „fix your PC” stron do złożonych przynęt z wideo-instrukcjami i automatycznym kopiowaniem komend, co zwiększa konwersję ataków.

Analiza techniczna / szczegóły ataków

  1. ClickFix i wejście do środka
    Ofiara trafia na stronę „pomocy”, gdzie proszona jest o skopiowanie/uruchomienie komendy w Win+R. Wzorzec od Microsoft: phishing/malvertising → landing page → polecenie do schowka → użytkownik uruchamia je sam, omijając część filtrów.
  2. curl → PowerShell (fileless)
    W przykładach przypisywanych Storm-0249 ciąg znaków wykorzystuje curl.exe do pobrania skryptu z podszytego pod Microsoft hosta (np. ścieżka /us.microsoft.com/... na domenie zewnętrznej), po czym pipelinuje zawartość bezpośrednio do PowerShell, który wykonuje kod w pamięci – bez artefaktów na dysku.
  3. MSI z uprawnieniami SYSTEM
    Fileless stager uruchamia MSI działające jako SYSTEM, co pozwala na zrzut komponentów w lokalizacjach użytkownika i ustawienie trwałości z wysokimi uprawnieniami.
  4. DLL sideloading na procesie EDR
    Atakujący umieszczają zaufany plik EXE (np. komponent agenta EDR) wraz ze spreparowaną biblioteką DLL (np. SentinelAgentCore.dll) tak, by EXE załadował agresora „z boku”. Daje to: (a) maskowanie pod sygnowany proces, (b) kanał C2 z „białej listy”, (c) trudniejsze alertowanie o LOLBins/LOLDrivers.
  5. Recon i przygotowanie pod ransomware
    Z poziomu „zaufanego” procesu wykonywane są LOLBins (np. reg.exe, findstr.exe) do odczytu MachineGuid i innych znaczników. Dane te służą m.in. do wiązania kluczy szyfrujących z konkretną maszyną w ramach operacji RaaS.
  6. Łączność C2 i unikanie detekcji
    C2 inicjowany jest z procesu agenta (telemetria EDR), często do świeżo rejestrowanych domen i z pełnym TLS, co utrudnia DPI i systemy reputation-based. Detekcja wymaga bazowania zachowań i anomalii sieciowych dla procesów „zaufanych”.

Praktyczne konsekwencje / ryzyko

  • SOC blind spot: ruch wychodzący „z EDR” wygląda wiarygodnie; klasyczne reguły na PowerShell/curl nie zadziałają, bo aktywność „znika” w pamięci i w telemetrii zaufanych binariów.
  • Szybsza ścieżka do ransomware: zebrane identyfikatory + utrzymanie SYSTEM → szybka eskalacja do szyfrowania, bez głośnego „kill chainu”.
  • ClickFix obchodzi świadomość użytkownika: nawet przeszkoleni pracownicy mogą „sami” uruchomić polecenie, bo komunikat udaje oficjalną pomoc Microsoft.

Rekomendacje operacyjne / co zrobić teraz

Prewencja i twarde polityki

  • Blokady AMSI + Constrained Language Mode dla PowerShell tam, gdzie to możliwe; egzekwuj Script Block Logging i Module Logging.
  • WDAC/AppLocker: wymuś ładowanie DLL wyłącznie z katalogów systemowych dla procesów o wysokim zaufaniu (EDR, backup).
  • DNS/TI: alertuj na połączenia do nowych domen (<30–90 dni) inicjowane przez procesy EDR/AV; baseline znane FQDN agenta i odchylenia.
  • Zasady uruchamiania: blokuj curl.exe/bitsadmin.exe/msiexec.exe wywoływane z Win+R/Shell-Execute bez kontekstu administratora (AppLocker/WDAC).

Detekcja i hunting (przykładowe kierunki)

  • DLL sideloading: szukaj uruchomień zaufanych EXE z prywatnych ścieżek (np. %AppData%) i nienatywnych bibliotek obok EXE.
  • ClickFix: zdarzenia schowka + otwarcia okna Run bez poprzedzającej interakcji z helpdesk/IT; koreluj z wklejeniem długiego ciągu Base64/PowerShell.
  • LOLBins recon: nietypowe zestawienia reg.exe/findstr.exe → odczyty gałęzi z identyfikatorami systemu; koreluj z nowym beaconem TLS.

Twarde reagowanie

  • Traktuj nieautoryzowane MSI uruchomione jako SYSTEM jako incydent wysokiej ważności; wykonaj memory forensics (ETW/AMSI logs, PSReadLine history).
  • EDR self-check: porównaj listę legalnych DLL ładowanych przez agenta vs. obserwowane w telemetry (pref. z hashami/Publisher).
  • Segmentacja i backupy: instant isolates + test odtworzeń; przygotuj playbook pod ekspresową ścieżkę ransomware (MFA-bypass, shadow copies, AD).

Różnice / porównania z innymi przypadkami

  • IAB → operator post-eksploatacyjny: typowa rola IAB (sprzedaż dostępu) zmienia się w „broker + enabler” z pełnym przygotowaniem pod szyfrowanie. To zbieżne z trendem RaaS opisywanym wcześniej w ekosystemie Storm-0501.
  • ClickFix vs. klasyczny phishing:** zamiast pobierania EXE/ZIP ofiara uruchamia komendę sama, co utrudnia AV/Proxy; technika jest opisywana przez wielu dostawców (Microsoft, Proofpoint) i bywa adaptowana także przez aktorów APT.

Podsumowanie / kluczowe wnioski

Storm-0249 łączy socjotechnikę (ClickFix) z „living-off-the-land” i EDR-aware sideloading, przesuwając punkt ciężkości obrony z klasycznych sygnatur na behawior, uprzywilejowane ścieżki ładowania i telemetrię procesów „zaufanych”. Organizacje powinny priorytetowo wdrożyć kontrolę ładowania DLL, monitoring nowych domen i pełne logowanie PowerShell. To trend, który zwiększa prędkość i skuteczność operacji ransomware – zanim zobaczysz klasyczne IOC, bywa już za późno.

Źródła / bibliografia

  • The Hacker News: „Storm-0249 Escalates Ransomware Attacks with ClickFix, Fileless PowerShell, and DLL Sideloading” (09.12.2025). (The Hacker News)
  • ReliaQuest Threat Research: „Threat Spotlight: Storm-0249 Moves from Mass Phishing to Precision EDR Exploitation” (09.12.2025). (ReliaQuest)
  • Microsoft Security Blog: „Think before you Click(Fix): Analyzing the ClickFix social engineering technique” (21.08.2025). (Microsoft)
  • Microsoft Security Blog: „Storm-0501 ransomware… expanding to hybrid cloud; IABs like Storm-0249” (26.09.2024). (Microsoft)
  • BleepingComputer: „Ransomware IAB abuses EDR for stealthy malware execution” (09.12.2025). (BleepingComputer)

Tri-Century Eye Care: wyciek danych po ataku ransomware dotknął ~200 tys. osób

Wprowadzenie do problemu / definicja luki

Tri-Century Eye Care (kliniki okulistyczne w hrabstwie Bucks, Pensylwania) ujawniło incydent bezpieczeństwa będący skutkiem ataku ransomware przypisywanego grupie PEAR. Według rejestru naruszeń HHS/OCR skala zdarzenia szacowana jest na około 200 000 osób (pacjentów i pracowników). Doniesienia o ataku potwierdzają, że sprawcy twierdzą, iż wykradli wieloterabajtowy zbiór plików.

W skrócie

  • Skala: ok. 200 tys. rekordów PHI/PII.
  • Typ zdarzenia: atak ransomware + kradzież danych (tzw. double extortion).
  • Sprawcy: grupa PEAR (deklaracja na stronach śledzących wycieki).
  • Oficjalny status: spółka opublikowała stronę „Notice of Data Security Incident” i wysyła zawiadomienia.
  • Zakres danych: potencjalnie PII/PHI pacjentów i pracowników (m.in. SSN, dane kontaktowe, informacje ubezpieczeniowe – według komunikatów branżowych i kancelarii).

Kontekst / historia / powiązania

Sektor ochrony zdrowia w USA pozostaje jednym z najczęściej atakowanych – motywacją jest wysoka wartość danych medycznych i presja dostępności usług. Incydent w Tri-Century wpisuje się w trwającą od miesięcy serię ataków na placówki medyczne i dostawców usług medycznych. W tym przypadku do zdarzenia doszło jesienią 2025 r., a SecurityWeek powiązał wyciek z roszczeniami grupy PEAR o „>3 TB” skradzionych danych.

Analiza techniczna / szczegóły luki

Tri-Century nie udostępniło publicznie szczegółów wektora wejścia ani wykorzystanych luk, potwierdziło jednak zdarzenie i dystrybucję listów z zaleceniami ochrony tożsamości (kontakt do biur kredytowych, monitoring). Zbieżnie, opisy incydentu w specjalistycznych serwisach i alertach prawnych wskazują na klasyczny schemat ransomware z eksfiltacją: przejęcie środowiska, kradzież danych, szyfrowanie/zagrożenie publikacją. Atrybucja do PEAR pojawia się w materiałach branżowych (Paubox) oraz w agregatorach aktywności grup ransomware (ransomware.live).

Co mogło zostać naruszone (na podstawie typowych wzorców w ochronie zdrowia i komunikatów):

  • Dane identyfikacyjne (imię, nazwisko, adres, data urodzenia),
  • SSN oraz informacje dot. zatrudnienia (dla pracowników),
  • Dane ubezpieczeniowe i elementy PHI (np. identyfikatory pacjenta, informacje rozliczeniowe).

Uwaga: precyzyjny katalog pól dla każdej osoby może różnić się w zależności od rekordu; oficjalna strona Tri-Century kieruje odbiorców do bezpośrednich zaleceń i kontaktów z biurami kredytowymi.

Praktyczne konsekwencje / ryzyko

  • Ryzyko kradzieży tożsamości i fraudu finansowego – dane PII/SSN ułatwiają otwieranie kont, wnioskowanie o kredyt, składanie fałszywych roszczeń ubezpieczeniowych.
  • Phishing i vishing medyczny – personalizowane oszustwa podszywające się pod klinikę, ubezpieczyciela czy laboratorium. (Wzorzec znany z wcześniejszych incydentów w sektorze zdrowia.)
  • Ryzyko wtórnych włamań – ponowne wykorzystanie danych do resetów haseł i przejęć kont.

Rekomendacje operacyjne / co zrobić teraz

Dla pacjentów i pracowników:

  1. Skorzystaj z oferowanego monitoringu tożsamości (jeśli zapewniono) i zamrożenia kredytu (credit freeze) w biurach Equifax, Experian, TransUnion.
  2. Włącz alerty kontowe, obserwuj wyciągi bankowe/ubezpieczeniowe; natychmiast reklamuj nieautoryzowane transakcje.
  3. Uważaj na kontakt „z kliniki/ubezpieczyciela” – weryfikuj kanałem oficjalnym; nie podawaj kodów ani danych logowania.

Dla zespołów IT/bezpieczeństwa w placówkach medycznych (lekcja z incydentu):

  • E-mail i zdalny dostęp: bezwzględne MFA (fob/biometryczne), zakaz SMS OTP w dostępie uprzywilejowanym; rotacja i ograniczanie dostępu do portalów zdalnych.
  • Segmentacja i EDR/XDR: mikrosegmentacja systemów rejestracyjnych/EHR, automatyczne izolowanie hostów z anomaliami (behavioral ransomware detection).
  • Backup i tabletopy: niezmienialne kopie (immutability, WORM) + ćwiczenia odtwarzania usług krytycznych (rejestracja, płatności, e-prescriptions).
  • DLP i egress control: reguły blokujące masowe transfery z serwerów dokumentowych/plików obrazowych (PACS), monitorowanie SFTP/HTTP(S).
  • Logistyka powiadomień: gotowe szablony HIPAA/HITECH + linie wsparcia dla pacjentów.

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

Na tle głośnych incydentów 2024–2025 (np. Change Healthcare – >100 mln osób) skala Tri-Century jest mniejsza, ale profil danych (PHI + SSN) czyni ryzyko jednostkowo wysokim. Wspólny mianownik: eksfiltacja + presja publikacji jako dominujący model przestępczy.

Podsumowanie / kluczowe wnioski

  • Atak na Tri-Century Eye Care to kolejny przykład presji ransomware na sektor ochrony zdrowia: kradzież danych + szantaż.
  • Szacunek ~200 tys. osób wynika z rejestru HHS i bieżących publikacji branżowych.
  • Priorytety: ochrona tożsamości poszkodowanych oraz wzmocnienie kontroli dostępu, segmentacji i detekcji eksfiltracji.

Źródła / bibliografia

  • SecurityWeek: „Tri-Century Eye Care Data Breach Impacts 200,000 Individuals”. (SecurityWeek)
  • Tri-Century Eye Care – „Notice of Data Security Incident” (strona informacyjna dla poszkodowanych). (Tri-Century Eye Care)
  • HHS/OCR – rejestr naruszeń (breach portal). (OCR Portal)
  • Paubox (Healthcare security): opis ataku PEAR na Tri-Century. (Paubox)
  • ransomware.live: wpis o przypisaniu ataku grupie PEAR. (Ransomware.live)

Portugalia tworzy „safe harbor” dla badaczy bezpieczeństwa. Nowe wyjątki w prawie o cyberprzestępczości

Wprowadzenie do problemu / definicja luki

Portugalia zaktualizowała ustawę o cyberprzestępczości (Lei n.º 109/2009), dodając nowy art. 8.º-A: „Akty niepodlegające karze ze względu na interes publiczny w cyberbezpieczeństwie”. Przepis wprowadza prawny „safe harbor” dla badań bezpieczeństwa w dobrej wierze, ograniczając ryzyko karne dla researcherów działających proporcjonalnie i w interesie publicznym. Zmiana została przyjęta w Dekrecie-Ustawie nr 125/2025, który jednocześnie transponuje dyrektywę NIS2 i wchodzi w życie po 120 dniach od publikacji.

W skrócie

  • Co się zmienia? Działania, które normalnie podpadałyby pod „nieuprawniony dostęp” lub „nielegalną intercepcję”, mogą być niekaralne, jeśli spełnione są surowe warunki „good-faith research”.
  • Warunki kluczowe: cel publiczny (ujawnienie i poprawa bezpieczeństwa), brak korzyści majątkowej, niezwłoczne zgłoszenie luki właścicielowi/administratorowi i autorytetowi ds. cyberbezpieczeństwa, działania ściśle proporcjonalne, zakaz DoS, socjotechniki, phishingu, instalacji malware itd.
  • Kiedy prawo zacznie obowiązywać? 120 dni po publikacji (tj. 3 kwietnia 2026 r.).

Kontekst / historia / powiązania

Zmiana jest częścią szerszej reformy wdrażającej NIS2: Dekret-Ustawa 125/2025 ustanawia nowy reżim cyberbezpieczeństwa, rozszerza zakres podmiotowy i kompetencje CNCS (narodowego centrum cyberbezpieczeństwa), a także modyfikuje m.in. prawo o łączności elektronicznej i bezpieczeństwie wewnętrznym. W tym pakiecie rząd po raz drugi nowelizuje ustawę o cyberprzestępczości (109/2009), dodając wspomniany art. 8.º-A. Informację o „safe harbor” nagłośniły media branżowe.

Analiza techniczna / szczegóły luki

Nowy art. 8.º-A precyzuje, kiedy badania bezpieczeństwa nie są karalne (streszczenie najważniejszych punktów):

  1. Cel i intencja – jedynym celem jest identyfikacja podatności w systemach/produktach/usługach IT w celu zwiększenia bezpieczeństwa (m.in. poprzez odpowiedzialne ujawnienie).
  2. Brak korzyści ekonomicznej – badacz nie działa w celu uzyskania zysku ani obietnicy zysku (poza wynagrodzeniem z tytułu zwykłej działalności zawodowej).
  3. Obowiązek niezwłocznego powiadomienia – po odkryciu luki należy natychmiast poinformować właściciela/administratora systemu lub usługodawcę oraz krajową władzę ds. cyberbezpieczeństwa; ta ostatnia kieruje sprawę do Polícia Judiciária (policji sądowej), jeśli zachodzi istotność karna. Należy też przestrzegać RODO/GDPR przy przetwarzaniu danych.
  4. Proporcjonalność i minimalizacja szkód – działania ogranicza się do tego, co niezbędne do identyfikacji luki; zakazane są w szczególności:
    • DoS/DDoS,
    • socjotechnika i wprowadzanie w błąd użytkowników/administratorów,
    • phishing,
    • kradzież haseł lub innych danych wrażliwych,
    • usuwanie/zmiana danych,
    • wyrządzanie szkód systemowi,
    • instalacja i dystrybucja złośliwego oprogramowania.
  5. Dane uzyskane podczas testów – podlegają zasadom ochrony danych; jeśli je pozyskano, należy je usunąć w ciągu 10 dni od usunięcia luki i utrzymać poufność do końca procedury.
  6. Zgoda właściciela – działania wykonane za zgodą właściciela/administratora systemu również są niekaralne, przy zachowaniu obowiązków notyfikacyjnych.

Wejście w życie: Dekret wchodzi w życie po 120 dniach od publikacji w Dzienniku Ustaw; lokalne media wyliczają datę na 3 kwietnia 2026.

Praktyczne konsekwencje / ryzyko

  • Dla researcherów: to realna, ustawowa „bezpieczna przystań”, ale z istotnymi ograniczeniami: zero DoS/socjotechniki, pełna proporcjonalność, brak zysku i twardy reżim zgłaszania. Przekroczenie tych ram może ponownie wprowadzić działania w sferę karną.
  • Dla organizacji: rośnie znaczenie procesu przyjmowania zgłoszeń podatności (VDP) i gotowości do współpracy z CNCS. Brak procedur może skutkować opóźnieniami, wyciekami oraz karami administracyjnymi z reżimu NIS2.
  • Dla rynku: formalizacja „good-faith research” powinna poprawić czas reakcji na luki i jakość komunikacji, o ile firmy ustanowią jasne kanały disclosure. Media branżowe przewidują pozytywny wpływ na ekosystem bezpieczeństwa.

Rekomendacje operacyjne / co zrobić teraz

Dla organizacji w Portugalii i podmiotów obsługujących portugalskich klientów:

  1. Ustanów VDP (Vulnerability Disclosure Policy) z jasnym kanałem kontaktu, SLA triage i polityką prywatności danych badawczych. Odnieś VDP do wymogów art. 8.º-A (powiadomienia, poufność, usuwanie danych).
  2. Wyznacz rolę „VDP ownera” po stronie bezpieczeństwa/IT i powiąż ją z zespołem prawnym oraz kontaktami do CNCS (krajowa władza ds. cyberbezpieczeństwa).
  3. Zaktualizuj wewnętrzne procedury NIS2: klasyfikacja incydentów, progi zgłoszeń i koordynacja z CSIRT – tak, by obsłużyć napływ zgłoszeń od researcherów po wejściu prawa w życie.
  4. Zabroń DoS/socjotechniki w regulaminach testów (np. programy bug bounty), aby nie zachęcać do działań wyłączonych z ochrony.
  5. Przygotuj klauzule prawne (NDA „limited”), które pozwolą na poufność do czasu naprawy i wykazanie usunięcia danych w 10 dni od załatania luki.

Dla researcherów:

  • Dokumentuj intencję i proporcjonalność, prowadź dziennik czynności.
  • Natychmiast zgłaszaj lukę właścicielowi/administratorowi i władzy ds. cyberbezpieczeństwa; zachowuj zgodność z RODO.
  • Unikaj wszystkich technik wyraźnie zakazanych (DoS, phishing, malware itd.).
  • Nie przyjmuj korzyści majątkowych za sam fakt nieautoryzowanego testu (bug bounty po zaproszeniu/uregulowane – tak; wymuszenia – nie).

Różnice / porównania z innymi przypadkami

Nowy portugalski przepis przypomina praktykę „safe harbor” znaną z programów bug bounty, ale ma rangę ustawową i precyzyjnie określone wyłączenia (DoS, socjotechnika, phishing). To bardziej formalne i restrykcyjne rozwiązanie niż ogólne, niepisane zasady „co jest OK” w branży – dzięki temu daje większą pewność prawną zarówno badaczom, jak i organizacjom. Jednocześnie ciężar dowodu dobrej wiary i proporcjonalności spoczywa na researcherze.

Podsumowanie / kluczowe wnioski

Portugalia wprowadza rzadko spotykany, ustawowy parasol ochronny dla badań bezpieczeństwa – ale ściśle skrojony i podporządkowany interesowi publicznemu. Jeśli firmy przygotują VDP i dostosują procesy NIS2, a researcherzy zachowają proporcjonalność, transparentność i zgodność z RODO, ekosystem zyska na szybszym i bezpieczniejszym ujawnianiu podatności.

Źródła / bibliografia

  1. Diário da República – Decreto-Lei n.º 125/2025 (oficjalny tekst; art. 7 dodaje art. 8.º-A do prawa o cyberprzestępczości; wejście w życie po 120 dniach).
  2. BleepingComputer – omówienie zmian i kontekstu dla researcherów. (BleepingComputer)
  3. ANACOM – nota o publikacji dekretu-ustawy i transpozycji NIS2. (Anacom)
  4. DataGuidance – informacja o transpozycji NIS2 w Portugalii. (DataGuidance)
  5. ECO SAPO – termin wejścia w życie: 3 kwietnia 2026 r. (ECO)

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)