Wojciech Ciemski, Autor w serwisie Security Bez Tabu - Strona 204 z 330

Autor: Wojciech Ciemski

SAP Security Patch Day (luty 2026): 26 nowych poprawek i 1 aktualizacja – dwie luki „Hot News” do pilnego załatania

Wprowadzenie do problemu / definicja luki

W comiesięczny SAP Security Patch Day (10 lutego 2026) opublikowano 26 nowych not bezpieczeństwa oraz 1 aktualizację wcześniej wydanej noty. W paczce znalazły się m.in. dwie pozycje o statusie Critical, z bardzo wysokimi ocenami CVSS (9.9 oraz 9.6), dotyczące kluczowych komponentów w wielu krajobrazach SAP: SAP CRM / SAP S/4HANA (Scripting Editor) oraz SAP NetWeaver AS ABAP / ABAP Platform.

W praktyce „luka” (vulnerability) oznacza błąd projektowy lub implementacyjny, który może zostać wykorzystany do naruszenia poufności, integralności lub dostępności systemu. W środowiskach SAP stawka jest wysoka: to często systemy finansowe, logistyczne, HR i integracyjne „kręgosłupy” organizacji.

W skrócie

  • 26 nowych not + 1 aktualizacja w ramach Patch Day z 10.02.2026.
  • Najpoważniejsza luka: CVE-2026-0488 (CVSS 9.9) – „code injection” w SAP CRM / SAP S/4HANA (Scripting Editor), z opisanym scenariuszem prowadzącym nawet do kompromitacji bazy danych (m.in. przez możliwość wykonania dowolnego SQL).
  • Druga krytyczna: CVE-2026-0509 (CVSS 9.6) – brak wymaganej autoryzacji (m.in. w kontekście S_RFC) pozwalający użytkownikowi o niskich uprawnieniach wykonywać określone background RFC.
  • SAP podkreśla priorytetowe wdrożenie poprawek; podobne zalecenia pojawiają się też w zewnętrznych alertach CERT.

Kontekst / historia / powiązania

SAP od lat publikuje poprawki w modelu „Patch Day” (drugi wtorek miesiąca), żeby ułatwić planowanie utrzymania i ograniczyć „patch chaos” w dużych organizacjach. W lutym 2026 szczególnie rzuca się w oczy koncentracja na:

  • ABAP/NetWeaver (autoryzacje, bezpieczeństwo usług i przetwarzania komunikatów),
  • komponentach podatnych na klasyczne błędy aplikacyjne (XSS, open redirect, deserializacja),
  • oraz obszarach „enterprise BI/e-commerce” (BusinessObjects, Commerce Cloud).

Z perspektywy obrony warto pamiętać: wiele exploitów w SAP zaczyna się od poświadczeń o niskich uprawnieniach (np. konto techniczne, użytkownik integracyjny, przejęta sesja), a dopiero potem następuje eskalacja skutków.

Analiza techniczna / szczegóły luki

1) CVE-2026-0488 (CVSS 9.9) – code injection w SAP CRM / SAP S/4HANA (Scripting Editor)

SAP wskazuje podatność jako krytyczną w komponentach związanych ze Scripting Editor. W opisie NVD podkreślono możliwość nadużycia błędu w wywołaniu „generic function module”, co może umożliwić uruchomienie nieautoryzowanych funkcji, w tym wykonanie dowolnego SQL, z potencjalnym skutkiem „full database compromise”.

Dlaczego to groźne?

  • Dostęp uwierzytelniony bywa łatwiejszy do uzyskania niż się wydaje (phishing, reuse haseł, wycieki, słabe konta serwisowe).
  • Jeżeli wektor realnie pozwala na arbitrary SQL, to konsekwencje obejmują nie tylko aplikację, ale często całą warstwę danych.

2) CVE-2026-0509 (CVSS 9.6) – brak autoryzacji w SAP NetWeaver AS ABAP / ABAP Platform

Wg opisu NVD, użytkownik o niskich uprawnieniach może w określonych przypadkach wykonywać background Remote Function Calls bez wymaganej autoryzacji S_RFC, co przekłada się na wysoki wpływ na integralność i dostępność.

Co to oznacza operacyjnie?

  • Ryzyko nadużyć wokół RFC/wywołań funkcji z kontekstu „w tle” (np. obejścia kontroli dostępu dla wybranych scenariuszy).
  • Możliwe skutki: zmiany danych, zakłócenia procesów, destabilizacja systemu (w zależności od tego, jakie funkcje i gdzie da się uruchomić).

3) Dodatkowy kontekst: XML Signature Wrapping (CVE-2026-23687, CVSS 8.8)

W lutowej paczce znalazła się też wysoko oceniona pozycja dotycząca XML Signature Wrapping w NetWeaver AS ABAP/ABAP Platform (CVSS 8.8). To klasa błędów, w której atakujący manipuluje strukturą XML tak, aby weryfikator „zaufał” podpisowi, ale zastosował go do innej części dokumentu. W praktyce grozi to obejściem kontroli integralności komunikatów i nadużyciami w procesach opartych o podpisane XML.

Praktyczne konsekwencje / ryzyko

Najczęstsze realne scenariusze ryzyka dla organizacji z SAP:

  • Kompromitacja danych (w tym potencjalnie baza danych lub wrażliwe rekordy biznesowe) przy podatnościach umożliwiających nieautoryzowane wykonanie operacji wysokiego ryzyka.
  • Sabotaż procesów (integralność) i przestoje (dostępność) przy lukach w autoryzacjach i komponentach wykonawczych (RFC, funkcje systemowe).
  • Efekt domina w integracjach (SAP często jest hubem) – nawet „lokalna” luka może przerodzić się w incydent łańcuchowy (EDI, ESB, systemy finansowe, hurtownie).

Warto też zauważyć, że ostrzeżenia o tej paczce pojawiają się w kanałach CERT/CSIRT, co zwykle jest sygnałem, że temat ma znaczenie dla infrastruktury krytycznej i dużych instytucji.

Rekomendacje operacyjne / co zrobić teraz

  1. Zidentyfikuj ekspozycję
    • Czy używasz podatnych wersji komponentów wymienionych w notach (CRM/S4 Scripting Editor; NetWeaver AS ABAP/ABAP Platform; BusinessObjects; Commerce Cloud; ST-PI)?
  2. Nadaj priorytet „Hot News/Critical”
    • W pierwszej kolejności: CVE-2026-0488 (9.9) i CVE-2026-0509 (9.6), potem „High” (np. XML Signature Wrapping 8.8).
  3. Zaplanuj okno serwisowe i wdrożenie not
    • W SAP najlepszą praktyką jest wdrożenie zgodnie z oficjalnymi notami i zależnościami (często występują prerekwizyty).
  4. Tymczasowe ograniczenia ryzyka (jeśli patching nie jest natychmiastowy)
    • Przegląd ról i uprawnień, zwłaszcza wokół RFC i kont technicznych.
    • Monitoring nietypowych wywołań RFC / zadań w tle, anomalii w logach, nietypowych błędów aplikacji.
    • Weryfikacja ścieżek dostępu do funkcji/edytorów skryptów (kto realnie musi mieć dostęp).
  5. Komunikacja do właścicieli biznesowych
    • Dla krytycznych podatności warto formalnie odnotować ryzyko (GRC/ISMS) i uzgodnić priorytety z właścicielami procesów.

Różnice / porównania z innymi przypadkami

  • Code injection / SQL (CVE-2026-0488) ma potencjalnie „bardziej destrukcyjny” profil skutków (dane + kontrola), ale zwykle wymaga sensownego punktu zaczepienia w aplikacji i uprawnień uwierzytelnionego użytkownika.
  • Braki w autoryzacjach (CVE-2026-0509) często są „cichsze” i bliższe eskalacji uprawnień / nadużyciom wewnętrznym – a jednocześnie w środowiskach enterprise bywają najczęściej wykorzystywanym mechanizmem do lateral movement, gdy atakujący już ma konto.
  • XML Signature Wrapping to klasyk w systemach integracyjnych: szczególnie bolesny, gdy podpisane XML są podstawą zaufania w przepływach (SSO, federacja, integracje B2B).

Podsumowanie / kluczowe wnioski

Lutowy SAP Security Patch Day 2026 (10 lutego) przyniósł dużą paczkę poprawek, z dwiema krytycznymi lukami na czele. Jeśli Twoja organizacja używa SAP CRM/S/4HANA (Scripting Editor) lub SAP NetWeaver AS ABAP/ABAP Platform, priorytetem powinno być szybkie wdrożenie odpowiednich not oraz kontrola ekspozycji (role, RFC, konta techniczne).

Źródła / bibliografia

  1. SAP: SAP Security Patch Day – February 2026 (lista not, priorytety, CVSS, produkty i wersje). (support.sap.com)
  2. NVD (NIST): CVE-2026-0488 (opis, scenariusz i skutki). (NVD)
  3. NVD (NIST): CVE-2026-0509 (opis, S_RFC i background RFC, wektor CVSS). (NVD)
  4. RedRays: SAP Security Patch Day February 2026 (kontekst paczki i opis XML Signature Wrapping). (RedRays – Your SAP Security Solution)
  5. Saudi NCA/CERT alert (odwołanie do lutowego biuletynu SAP i zalecenia aktualizacji). (nca.gov.sa)

Microsoft łata 6 aktywnie wykorzystywanych zero-day w Patch Tuesday (luty 2026) – co wiemy i jak reagować

Wprowadzenie do problemu / definicja luki

Luki typu zero-day to podatności wykorzystywane przez atakujących zanim (lub zanim powszechnie) dostępna jest poprawka. W praktyce oznacza to, że organizacje są w trybie „reakcji na incydent” już w momencie publikacji biuletynów — zwłaszcza gdy producent potwierdza aktywną eksploatację w środowisku (in the wild).

W aktualizacjach Patch Tuesday z lutego 2026 Microsoft naprawił ok. ~60 podatności, w tym 6 zero-day aktywnie wykorzystywanych.

W skrócie

  • 6 aktywnie wykorzystywanych zero-day zostało załatanych w ramach lutowego Patch Tuesday.
  • Trzy z nich to Security Feature Bypass (obejścia mechanizmów ochronnych) i były też oznaczone jako publicznie ujawnione.
  • Najwięcej uwagi operacyjnej wymagają wektory „user interaction”: pliki LNK/skrót, HTML/MSHTML, oraz spreparowany dokument Office (socjotechnika + ominięcie ostrzeżeń/mitigacji).

Kontekst / historia / powiązania

Microsoft (jak zwykle w takich przypadkach) publikuje ograniczone szczegóły o kampaniach, ale sam fakt oznaczenia „exploited in the wild” sugeruje, że exploity działają w realnych scenariuszach. SecurityWeek zwraca uwagę na wspólne kredyty w odkryciu części luk (m.in. Google Threat Intelligence Group), co bywa sygnałem, że luki mogły pojawić się w podobnych kampaniach lub były łańcuchowane.

Warto też zauważyć „profil” tych podatności: sporo z nich dotyczy obejścia mechanizmów ostrzegania/ochrony (SmartScreen, ostrzeżenia powłoki, MSHTML, OLE/Office), czyli elementów, na których polegają polityki bezpieczeństwa w enterprise.

Analiza techniczna / szczegóły luki

Poniżej 6 luk potwierdzonych jako aktywnie wykorzystywane (wg zestawień dla lutego 2026):

  1. CVE-2026-21510 – Windows Shell / SmartScreen: Security Feature Bypass
    Scenariusz: nakłonienie użytkownika do otwarcia złośliwego linku lub pliku skrótu (.LNK), co pozwala ominąć ostrzeżenia SmartScreen/Windows Shell.
  2. CVE-2026-21513 – MSHTML (Internet Explorer framework): Security Feature Bypass
    Scenariusz: użytkownik otwiera złośliwy HTML lub LNK, co może prowadzić do obejścia kontroli bezpieczeństwa i potencjalnie uruchomienia kodu w kontekście przeglądarkowych komponentów MSHTML.
  3. CVE-2026-21514 – Microsoft Word / Office: obejście mitigacji OLE (Security Feature Bypass)
    Scenariusz: ofiara otwiera spreparowany plik Office. Istotny detal operacyjny: według analizy Tenable Preview Pane nie jest wektorem ataku dla tej luki (czyli „samo zaznaczenie pliku” nie powinno wystarczyć).
  4. CVE-2026-21519 – Desktop Window Manager (DWM): Elevation of Privilege
    Scenariusz: lokalny atakujący podnosi uprawnienia (np. do SYSTEM). To typowa składowa łańcuchów: najpierw wejście (phishing/drive-by), potem EoP dla utrwalenia i eskalacji.
  5. CVE-2026-21533 – Remote Desktop Services: Elevation of Privilege
    Scenariusz: lokalny, uwierzytelniony atakujący podnosi uprawnienia do SYSTEM w kontekście usług RDS. W środowiskach z szerokim użyciem RDP to poważny temat „post-exploitation”.
  6. CVE-2026-21525 – Remote Access Connection Manager (RasMan): Denial of Service
    Nietypowo jak na „aktywnie wykorzystywane”: DoS (a nie RCE/EoP). Mimo to luka została oznaczona jako wykorzystywana w środowisku, więc warto traktować ją jako element realnych działań (np. zakłócanie pracy, odwracanie uwagi, destabilizacja endpointów).

Dodatkowy kontekst: część źródeł podaje różne łączne liczby CVE w pakiecie (zależnie od metodologii liczenia i zakresu komponentów/wydań), ale wątek „6 aktywnie wykorzystywanych” jest spójny w analizach branżowych.

Praktyczne konsekwencje / ryzyko

Największe ryzyko w krótkim terminie dotyczy organizacji, które:

  • mają dużą ekspozycję na phishing i uruchamianie plików pobranych z internetu (LNK/HTML/Office),
  • polegają na „warstwie ostrzeżeń” (SmartScreen / ostrzeżenia powłoki) jako ważnym elemencie kontroli,
  • mają użytkowników lokalnych z możliwością uruchamiania kodu + potencjalne ścieżki do EoP (DWM/RDS).

W praktyce: bypass ostrzeżeń zwiększa „klikowalność” ataku i obniża sygnał ostrzegawczy dla użytkownika, co często przekłada się na wyższą skuteczność kampanii socjotechnicznych.

Rekomendacje operacyjne / co zrobić teraz

  1. Priorytetowe łatanie (patch triage)
  • Nadaj priorytet CVE-2026-21510 / 21513 / 21514 w flotach z wysoką ekspozycją na pocztę i przeglądanie treści zewnętrznych (bypass mechanizmów ochronnych).
  • W drugiej kolejności, ale nadal wysoko: CVE-2026-21519 / 21533 (EoP) — szczególnie na stacjach uprzywilejowanych i serwerach skokowych/bastionach.
  1. Tymczasowe ograniczanie ryzyka (gdy nie da się spatchować „od ręki”)
  • Ogranicz dostarczanie i uruchamianie LNK/HTML z kanałów wysokiego ryzyka (poczta, komunikatory, pobrania) — filtrowanie na bramie pocztowej, sandbox, blokady typów plików. (To wynika bezpośrednio z opisanych wektorów dla 21510 i 21513).
  • Wzmocnij polityki dla plików „z internetu” (Mark-of-the-Web) i egzekwuj otwieranie dokumentów Office w trybach ochronnych / z dodatkowymi kontrolami (szczególnie pod 21514).
  1. Detekcja i hunting
  • Poluj na nietypowe uruchomienia explorer.exe / mshta / rundll32 / wscript/cscript w kontekście otwarcia LNK/HTML oraz anomalia procesu pochodzące z katalogów pobrań i załączników. (Wprost mapuje się to na scenariusze social engineering z tych CVE).
  • Dla EoP: koreluj podejrzane zdarzenia eskalacji uprawnień i tworzenia usług/zadań po jednorazowych uruchomieniach payloadu.
  1. RDP/RDS higiena
  • Zweryfikuj, gdzie RDP jest realnie potrzebne; ogranicz ekspozycję, segmentuj, wymuś MFA/conditional access na bramach, monitoruj nietypowe logowania — bo EoP w komponentach RDS bywa „drugim krokiem” po uzyskaniu footholda.

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

Ten pakiet wyróżnia się tym, że aż połowa aktywnie wykorzystywanych zero-day to obejścia mechanizmów ochronnych, a nie klasyczne RCE. To często oznacza szybką falę kampanii phishingowych po upublicznieniu detali technicznych, bo „bypass promptów” bywa łatwiejszy do operacjonalizacji (i bardzo skuteczny na użytkownikach).

Podsumowanie / kluczowe wnioski

  • Luty 2026 to Patch Tuesday, w którym Microsoft potwierdził 6 aktywnie wykorzystywanych zero-day — a to automatycznie winduje priorytet aktualizacji.
  • Najbardziej „pilne” z perspektywy masowych kampanii są bypassy: CVE-2026-21510 / 21513 / 21514 (LNK/HTML/Office).
  • EoP w DWM i RDS są krytyczne dla obrony warstwowej — redukują możliwość pełnego przejęcia hosta po pierwszym naruszeniu.

Źródła / bibliografia

  • SecurityWeek – lista 6 aktywnie wykorzystywanych zero-day i kontekst reporterski. (SecurityWeek)
  • Rapid7 – analiza Patch Tuesday (luty 2026) i charakterystyka bypassów. (Rapid7)
  • Tenable – techniczne streszczenie CVE (m.in. CVSS, wektory, uwagi o Preview Pane dla Word). (Tenable®)
  • Cisco Talos – przegląd Patch Tuesday i priorytety podatności (Snort rules / prominent vulns). (Cisco Talos Blog)
  • BleepingComputer – podsumowanie wydania i kontekst ekosystemu aktualizacji. (BleepingComputer)

Nowy botnet Linux „SSHStalker”: masowy brute force SSH i „retro” IRC jako C2

Wprowadzenie do problemu / definicja luki

SSHStalker to nowo opisany botnet dla Linuksa, który wraca do „starej szkoły” w warstwie dowodzenia: zamiast nowoczesnych frameworków C2 używa klasycznego IRC. Nie chodzi tu jednak o nostalgię, tylko o pragmatykę: niski koszt, prostotę, odporność (wiele serwerów/kanałów) i łatwe skalowanie. Z perspektywy obrońców to groźna mieszanka, bo kampania kładzie nacisk na masowość: głośne skanowanie SSH, brute force, szybkie dosyłanie kolejnych modułów oraz agresywna persystencja realizowana przez crona co minutę.

W skrócie

  • Wejście: automatyczne skanowanie portu 22 i brute force SSH (binarka w Go podszywająca się pod „nmap”).
  • Propagacja: przejęte hosty skanują dalej – zachowanie „robakopodobne”.
  • C2: IRC-boty w C/Perlu z zakodowanymi serwerami/kanałami; widoczna redundancja kanałów/serwerów.
  • Persystencja: cron co 60 sekund + mechanizm „watchdog/update” wznawiający główny proces.
  • Eskalacja uprawnień: wykorzystanie zestawu starych exploitów kernela Linuksa (era 2009–2010).
  • Monetyzacja/funkcje: m.in. skanowanie stron pod kątem kluczy AWS, kopanie krypto (np. PhoenixMiner) oraz potencjalne DDoS (na razie obserwowano raczej „bezczynność” botów).

Kontekst / historia / powiązania

Badacze opisują SSHStalker jako zestaw „zszytych” elementów: klasyczne boty IRC, stare exploity i bardzo proste mechanizmy utrzymania się na hoście – ale spięte w sprawny pipeline masowej kompromitacji.

W analizach pojawiają się podobieństwa do ekosystemu Outlaw/Maxlas oraz wzmianki o „rumuńskich” tropach, ale bez twardej atrybucji (możliwy klon, pochodna lub aktor luźno powiązany).

Ciekawy jest też wątek skali: Flare wskazuje na artefakt ze skanami sugerującymi ok. 7 tys. wyników (styczeń 2026) i dominację infrastruktury chmurowej (m.in. ślady Oracle Cloud/ASN).

Analiza techniczna / szczegóły luki

1) Dostęp początkowy i „nmap”, który nmapem nie jest

Pierwszy etap to binarka nazwana „nmap”, będąca w praktyce skanerem SSH napisanym w Go. Jej rola jest typowo „wormowa”: znaleźć nowe cele z otwartym portem 22 i zasilić łańcuch kolejnych prób logowania.

2) Kompilacja na hoście (GCC) – portowalność i utrudnienie detekcji

Po przejęciu serwera atakujący dociąga narzędzia kompilacji (GCC), a następnie zrzuca źródła (C/Perl) i kompiluje je lokalnie. To daje lepszą „dopasowalność” binarek do środowiska ofiary i utrudnia proste blokowanie po hashu.

3) Warstwa C2 na IRC: boty w C + Perl + elementy „kamuflażu”

Pierwsze payloady to IRC-boty (C) z twardo wpisanymi serwerami/kanałami, a następnie kolejne archiwa („GS”, „bootbou”) zawierające moduły orkiestracji, backdoory, czyszczenie logów oraz logikę dalszego wdrażania.
Flare opisuje też oznaki użycia EnergyMech (historycznie popularny bot IRC) i co ważne: „banki tekstów” (zwroty, losowe powiedzonka), które mogą generować szum w kanałach i utrudniać rozróżnienie ruchu „ludzkiego” od automatycznego.

4) Persystencja: cron co minutę i watchdog „update”

SSHStalker idzie w prostotę: wpis crona uruchamia co minutę skrypt „update”, który sprawdza PID procesu i wznawia całość, jeśli bot został ubity. Dla SOC/IR to oznacza, że „zabicie procesu” bez usunięcia mechanizmu persystencji daje efekt maksymalnie chwilowy.

5) Stare exploity kernela do eskalacji

Po brute force (często do konta z ograniczeniami) botnet sięga po zestaw starych podatności kernela (2009–2010) w celu podbicia uprawnień. To szczególnie groźne w środowiskach „long-tail”: stare VPS-y, porzucone obrazy, przestarzałe appliance’y, OT/IoT.

6) Moduły „zarobkowe” i funkcjonalne

W obserwacjach pojawiają się m.in.:

  • narzędzia do poszukiwania kluczy AWS w zasobach WWW (wzorce typu AKIA…),
  • cryptomining (np. PhoenixMiner oraz inne zestawy kopiące przez pule),
  • komponenty sugerujące możliwość DDoS, choć w momencie opisu boty często zachowywały się pasywnie (podłączenie do C2 i „idle”).

Praktyczne konsekwencje / ryzyko

  1. Ryzyko przejęcia serwerów produkcyjnych przez słabe SSH: jeśli dopuszczasz logowanie hasłem, masz otwarty port 22 do internetu i brak rate-limitów/FA2 (tam gdzie możliwe), jesteś wprost w profilu ofiary.
  2. Szybka reinfekcja po „prostym” czyszczeniu: cron co minutę oznacza, że półśrodki w IR nie działają.
  3. Eskalacja na starych kernelach: infrastruktura legacy jest realnie bardziej narażona – nawet jeśli dostęp początkowy jest „tylko” na niskim koncie.
  4. Egress i „dziwny” IRC z serwerów: w wielu organizacjach ruch IRC z serwera aplikacyjnego powinien być z definicji podejrzany.
  5. Dodatkowe szkody: kradzież kluczy chmurowych + kopanie krypto + potencjalne DDoS to klasyczna ścieżka od „włamania” do kosztów operacyjnych i incydentu regulacyjnego.

Rekomendacje operacyjne / co zrobić teraz

Twarde minimum (szybkie wygrane):

  • Wyłącz SSH password auth i przejdź na klucze (a tam gdzie ma sens: dodatkowa warstwa MFA/bastion/VPN).
  • Wprowadź rate-limiting / banowanie brute force (np. fail2ban, ograniczenia na firewallu, port-knocking w specyficznych przypadkach).
  • Ogranicz ekspozycję portu 22: allow-list, dostęp tylko z sieci zarządzającej, jump-hosty.

Detekcja i monitoring (pod SSHStalker):

  • Alarmuj na instalację/uruchomienie kompilatorów (gcc/make) na serwerach produkcyjnych, szczególnie z /tmp, /dev/shm, katalogów użytkowników.
  • Wykrywaj cron jobs co minutę oraz wpisy tworzone poza CM (Ansible/Puppet itp.).
  • Monitoruj outbound pod kątem IRC handshake / długich połączeń TCP do nietypowych hostów oraz kanałów czatu/relay.

Utrudnianie życia atakującym:

  • Egress filtering „default deny” dla serwerów, które nie muszą wychodzić w internet (lub bardzo restrykcyjna lista).
  • Jeśli możesz: usuń toolchain z obrazów produkcyjnych i uruchamiaj build tylko w kontrolowanych pipeline’ach.
  • Zadbaj o aktualizacje kernela i eliminację legacy systemów — to bezpośrednio obcina wektor eskalacji.

Różnice / porównania z innymi przypadkami

  • Nowoczesne C2 vs IRC: IRC jest „proste”, ale odporne i tanie; przy odpowiedniej redundancji nie musi być wyszukane, żeby było skuteczne.
  • „Stealth-first” vs „scale-first”: SSHStalker jest opisywany jako głośny, nastawiony na masówkę i automatyzację, a nie na APT-ową dyskrecję. To zmienia priorytety obrony: większą wartość mają limity, segmentacja i higiena SSH niż polowanie na ultra-zaawansowane TTP.
  • Podobieństwa do Outlaw/Maxlas: są podobne artefakty/„klimat” kampanii, ale bez jednoznacznej atrybucji – co jest typowe w świecie botnetów Linuksowych, gdzie kit i infrastruktura bywają recyklingowane.

Podsumowanie / kluczowe wnioski

SSHStalker pokazuje, że „stare” techniki (IRC, cron co minutę, zestawy exploitów sprzed ~15 lat) nadal mają sens, gdy celem jest duża skala i trafianie w długi ogon słabo utrzymanych serwerów. Priorytetem dla obrony powinny być: twarde ustawienia SSH, ograniczenie ekspozycji, monitoring uruchamiania kompilatorów i wykrywanie nietypowych połączeń wychodzących (zwłaszcza „chat/relay” z serwerów).

Źródła / bibliografia

  1. Flare – „Old-School IRC, New Victims: Inside the Newly Discovered SSHStalker Linux Botnet” (flare.io)
  2. BleepingComputer – „New Linux botnet SSHStalker uses old-school IRC for C2 comms” (BleepingComputer)
  3. SecurityWeek – „New ‘SSHStalker’ Linux Botnet Uses Old Techniques” (SecurityWeek)

ZeroDayRAT: nowy „komercyjny zestaw szpiegowski”, który daje pełną kontrolę nad iOS i Androidem

Wprowadzenie do problemu / definicja luki

ZeroDayRAT to nowo opisany, komercyjnie sprzedawany toolkit spyware/RAT na urządzenia mobilne, reklamowany w kanałach Telegrama. Według analiz badaczy ma zapewniać operatorowi „total compromise” – od pasywnego zbierania danych (profilowanie, powiadomienia, SMS, konta) po aktywną inwigilację (kamera/mikrofon/screen recording) oraz moduły kradzieży finansowej (bankowość i krypto).

Ważne doprecyzowanie: nazwa „ZeroDayRAT” może sugerować wykorzystanie podatności typu 0-day, ale publiczne materiały wskazują przede wszystkim na infekcję przez dostarczenie złośliwego binarium (APK na Androidzie / payload na iOS) i socjotechnikę, a nie potwierdzony łańcuch 0-day.

W skrócie

  • Sprzedaż i wsparcie: Telegram, z kanałami „sprzedaż / support / aktualizacje” oraz panelem do zarządzania infekcjami.
  • Zakres platform: raportowane wsparcie dla Android 5–16 oraz iOS do wersji 26.
  • Funkcje: profilowanie urządzenia i użytkownika, monitoring powiadomień i aktywności, GPS z historią, kamera/mikrofon/screen recording, keylogger oraz moduły kradzieży bankowej i kryptowalut (m.in. podmiana schowka).
  • Model wdrożenia u atakującego: kupujący zwykle dostaje panel + „builder”, sam hostuje infrastrukturę C2 i generuje próbki.

Kontekst / historia / powiązania

iVerify informuje, że aktywność ZeroDayRAT zaobserwowano po raz pierwszy 2 lutego 2026 r., a 10 lutego 2026 opublikowano techniczny opis.
Narracja wokół zagrożenia jest charakterystyczna dla trendu „demokratyzacji” narzędzi inwigilacyjnych: funkcje kojarzone wcześniej z kosztownymi platformami (często wiązanymi z aktorami o dużych zasobach) trafiają do „masowego rynku” dzięki gotowym panelom operatorskim, dokumentacji i supportowi.

Analiza techniczna / szczegóły „zestawu”

1) Łańcuch infekcji: binarium + dystrybucja po stronie operatora

Z dostępnych opisów wynika, że ZeroDayRAT wymaga umieszczenia na urządzeniu złośliwego komponentu (APK/payload). Dystrybucja jest elastyczna i zależy od operatora: smishing (SMS z linkiem), phishing, fałszywe sklepy/aplikacje, linki w komunikatorach.

2) Panel operatorski: „widok 360°” na ofiarę

Po infekcji panel ma prezentować m.in.: model urządzenia, wersję OS, stan baterii, kraj, lock state, dane SIM/operatora, dual-SIM numery, statystyki użycia aplikacji, „timeline” aktywności oraz podgląd ostatnich SMS. To umożliwia szybkie profilowanie ofiary i dobór dalszych kroków (np. pod przejęcie kont).

3) Dane o kontach i powierzchnia pod ATO

Szczególnie groźny jest wątek „accounts”: enumeracja kont powiązanych z urządzeniem (np. ekosystemy społecznościowe, komunikatory, platformy zakupowe). To skraca drogę do Account Takeover (ATO) i przygotowania precyzyjnej socjotechniki.

4) Inwigilacja w czasie rzeczywistym

Raporty opisują możliwość jednoczesnego: śledzenia GPS, uruchomienia live camera feed (przód/tył), nagrywania ekranu i podsłuchu przez mikrofon – wszystko z jednego panelu. Z perspektywy atakującego to „zdalna obecność” przy ofierze.

5) Keylogger + kradzież finansowa (bankowość i krypto)

  • Keylogger ma rejestrować wpisy/gesty/akcje z dokładnymi znacznikami czasu, co zwiększa szanse na wyciąganie haseł, kodów, treści wiadomości i danych do MFA.
  • Moduł krypto: skanowanie aplikacji portfeli oraz ciągła podmiana adresów w schowku (clipboard injection), by przekierować przelewy.
  • Moduł bankowy: przechwytywanie danych logowania m.in. przez ataki overlay oraz wsparcie dla popularnych platform płatniczych (np. Apple Pay/PayPal) – według opisu badaczy.

Praktyczne konsekwencje / ryzyko

Dla osób prywatnych

  • Utrata prywatności (lokalizacja, treść powiadomień, komunikatory, nagrania audio/wideo).
  • Bezpośrednie straty finansowe (krypto i bankowość mobilna).

Dla firm

  • Telefon pracownika jako punkt przejęcia: kradzież sesji, tokenów, resetów haseł, przejęcia kont (szczególnie gdy SMS/push/MFA „mieszka” na tym samym urządzeniu).
  • Ryzyko wycieku danych i eskalacji do systemów firmowych przez przejęte konta i komunikację (mail, komunikatory, aplikacje SaaS).

Rekomendacje operacyjne / co zrobić teraz

1) Zmniejsz skuteczność wektora dystrybucji

  • Użytkownicy: twarda zasada „brak instalacji spoza zaufanych źródeł”, szczególnie po linkach z SMS/komunikatorów (smishing).
  • Organizacje: polityki blokady „unknown sources” (Android), kontrola profili/MDM tam, gdzie możliwe, oraz edukacja na temat smishingu.

2) Ogranicz szkody finansowe

  • Włącz limity przelewów, dodatkowe potwierdzenia transakcji i alerty bankowe; dla krypto: rozważ whitelisty adresów, opóźnienia wypłat, wymaganie dodatkowej autoryzacji poza telefonem. (To praktyka obronna szczególnie istotna przy scenariuszach podmiany schowka).

3) Utrudnij ATO

  • Przenieś odzyskiwanie kont i MFA tam, gdzie to możliwe, na klucze sprzętowe/FIDO2 lub metody niezależne od SMS.
  • Monitoruj nietypowe logowania i reautoryzacje; traktuj telefon jako element krytyczny łańcucha uwierzytelniania.

4) Detekcja i reakcja

  • Z perspektywy iVerify kluczowe jest podejście „mobile EDR / threat hunting”, bo sam panel MDM nie jest nastawiony na wykrywanie spyware. W praktyce: zbieraj telemetrię mobilną, reaguj na symptomy (nietypowe zużycie baterii, nieznane uprawnienia, podejrzane aplikacje, anomalie sieciowe), miej procedurę izolacji urządzenia i rotacji poświadczeń.

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

  • „Komercyjny spyware klasy masowej” vs „0-day/zero-click klasy premium”: opisy ZeroDayRAT akcentują gotowy panel i socjotechnikę (APK/payload), a nie potwierdzony „zero-click”. To inny profil ryzyka: łatwiejszy do wdrożenia przez przestępców, ale częściej zależny od błędu użytkownika.
  • Skala funkcji: nawet bez eksploita 0-day zestaw oferuje „pełen pakiet” (inwigilacja + kradzież), co zbliża go funkcjonalnie do droższych platform, tyle że sprzedawanych „z instrukcją i supportem”.

Podsumowanie / kluczowe wnioski

ZeroDayRAT jest kolejnym sygnałem, że smartfon staje się pełnoprawnym celem ataków typu „total compromise”, a rynek „gotowych zestawów” obniża próg wejścia. Największe ryzyka to: przejęcia kont (ATO) oparte o dane z urządzenia, inwigilacja w czasie rzeczywistym oraz szybka monetyzacja przez bankowość i krypto.
Priorytety obronne na dziś: twarde ograniczanie dystrybucji (smishing/instalacje), wzmocnienie MFA niezależnego od telefonu oraz wdrożenie procesu detekcji/reakcji na incydenty mobilne.

Źródła / bibliografia

  1. SecurityWeek – „New ‘ZeroDayRAT’ Spyware Kit Enables Total Compromise of iOS, Android Devices” (10 lutego 2026). (SecurityWeek)
  2. iVerify – „Breaking Down ZeroDayRAT – New Spyware Targeting Android and iOS” (10 lutego 2026). (iverify.io)
  3. BleepingComputer – „ZeroDayRAT malware grants full access to Android, iOS devices” (10 lutego 2026). (BleepingComputer)
  4. Dark Reading – „In Bypassing MFA, ZeroDayRAT Is 'Textbook Stalkerware’” (10 lutego 2026). (Dark Reading)
  5. Security Affairs – „ZeroDayRAT spyware grants attackers total access to mobile devices” (10 lutego 2026). (Security Affairs)

Malicious 7-Zip: fałszywa strona 7zip[.]com rozsyła instalator z „proxyware” i robi z PC węzeł proxy

Wprowadzenie do problemu / definicja luki

W lutym 2026 badacze opisali kampanię, w której cyberprzestępcy podszywają się pod projekt 7-Zip i dystrybuują trojanizowany instalator. Na pierwszy rzut oka aplikacja działa poprawnie (użytkownik faktycznie dostaje 7-Zip), ale w tle instalują się dodatkowe komponenty, które rejestrują komputer jako „residential proxy node” – czyli węzeł w sieci pośredniczącej ruch.

To nie jest „klasyczny wirus” nastawiony na natychmiastowe szyfrowanie plików – to cicha monetyzacja zasobów i reputacji Twojego adresu IP.

W skrócie

  • Fałszywa domena 7zip[.]com imituje wygląd i treść oryginalnej strony 7-Zip (prawidłowa to 7-zip.org).
  • Instalator jest podpisany cyfrowo certyfikatem (opisanym jako później cofnięty), co zwiększa wiarygodność w oczach użytkownika.
  • Malware dropuje pliki m.in. Uphero.exe, hero.exe, hero.dll, tworzy usługę Windows (SYSTEM) i modyfikuje reguły zapory.
  • Celem jest proxyware: ruch osób trzecich idzie „przez” komputer ofiary, często na nietypowych portach (np. 1000/1002) i z rotującą infrastrukturą C2.

Kontekst / historia / powiązania

Sprawa wyszła szerzej na jaw po relacji użytkownika, który pobrał „7-Zip” z błędnej strony, idąc za linkiem podanym w kontekście poradnika YouTube dotyczącego składania PC. To pokazuje, jak łatwo atakujący wykorzystują łańcuch zaufania: tutorial, komentarz, link, szybkie pobranie „popularnego narzędzia”.

Warto zauważyć, że podszywanie się pod legalne oprogramowanie i nazewnictwo to klasyczny wzorzec „masquerading” opisywany także w MITRE ATT&CK (dopasowanie nazwy/lokalizacji zasobu do legalnego).

Analiza techniczna / szczegóły luki

1) Warstwa „legit” – żeby ofiara niczego nie zauważyła

Trojanizowany instalator zawiera działający 7-Zip, więc użytkownik widzi oczekiwany efekt i często kończy na tym weryfikację.

2) Dropper i komponenty proxy

W trakcie instalacji zapisywane są dodatkowe pliki (w analizie Malwarebytes/BleepingComputer wskazywane jako):

  • Uphero.exe – menedżer usługi / loader aktualizacji
  • hero.exe – główny payload proxy
  • hero.dll – biblioteka wspierająca
    Wskazywana ścieżka: C:\Windows\SysWOW64\hero\ (lokalizacja, której użytkownicy zwykle nie przeglądają ręcznie).

3) Persistencja: usługa Windows na uprawnieniach SYSTEM

Malware tworzy autostartową usługę Windows i uruchamia się z wysokimi uprawnieniami, co utrudnia wykrycie oraz usunięcie „na oko”.

4) Zmiany w zaporze i komunikacja

W opisie kampanii pojawiają się:

  • modyfikacje reguł zapory przez netsh (inbound/outbound),
  • pobieranie konfiguracji z rotujących domen „smshero”,
  • komunikacja na nietypowych portach (np. 1000, 1002) i lekkie zaciemnianie komunikatów (XOR).

5) Profilowanie hosta i telemetria

Wskazano profilowanie systemu przez WMI/API Windows (sprzęt, pamięć, dysk, sieć) oraz wysyłkę danych do zewnętrznego endpointu.

6) Szersza operacja

Badacze łączą tę kampanię z innymi „przynętami” (trojanizowane instalatory podszywające się pod różne aplikacje), co sugeruje powtarzalny pipeline dystrybucyjny i monetyzację infrastruktury proxy na większą skalę.

Praktyczne konsekwencje / ryzyko

Najważniejsze ryzyka dla użytkownika i organizacji:

  1. Reputacyjne i prawne: ruch przestępców może wychodzić „Twoim” IP (nadużycia, fraud, próby logowania, spam). To Ty możesz zostać pierwszym podejrzanym w logach usług.
  2. Ryzyko eskalacji: proxyware bywa elementem większego łańcucha – dziś „tylko” węzeł, jutro doinstalowanie kolejnych komponentów (loader/aktualizacje).
  3. Trudniejsze wykrycie: bo 7-Zip działa, a usługa w systemie wygląda jak „coś od narzędzia”. To dokładnie mechanika masquerading.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników (endpoint)

  • Natychmiastowa weryfikacja źródła: 7-Zip pobieraj wyłącznie z 7-zip.org, a nie z domen „podobnych”.
  • Jeśli uruchomiłeś instalator z 7zip[.]com: traktuj system jako skompromitowany (takie ostrzeżenie pada w omówieniu sprawy).
  • Sprawdź:
    • obecność katalogu C:\Windows\SysWOW64\hero\ oraz plików Uphero.exe/hero.exe/hero.dll,
    • usługi Windows uruchamiane automatycznie jako SYSTEM,
    • nietypowe reguły zapory dodane narzędziami systemowymi (np. ślady użycia netsh).
  • Wykonaj pełne skanowanie EDR/AV i rozważ reinstalację/odtworzenie z zaufanego obrazu, jeśli potwierdzisz infekcję (proxyware często jest projektowane tak, by utrzymać się długo).

Dla zespołów bezpieczeństwa (SOC/IT)

  • Monitoruj tworzenie nowych usług i zmiany w regułach Windows Firewall (szczególnie na stacjach użytkowników).
  • Wykrywaj ruch na nietypowych portach i wzorce „proxy-like” (utrzymujące się połączenia wychodzące, rotacja domen, TLS/HTTPS do nietypowych hostów).
  • Edukuj: „pobieraj z oficjalnej domeny, bookmarkuj, nie ufaj linkom z tutoriali/komentarzy”.

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

  • Proxyware vs ransomware/stealer: tu monetyzacja nie polega na natychmiastowej kradzieży danych lub szyfrowaniu, tylko na „wynajęciu” Twojego IP/łącza. To sprawia, że incydent jest często później wykrywany (brak oczywistych objawów).
  • Lookalike domain + działająca aplikacja to szczególnie groźne połączenie: użytkownik ma „dowód”, że pobrał właściwe narzędzie, bo ono realnie działa.

Podsumowanie / kluczowe wnioski

Fałszywa strona 7zip[.]com to przykład skutecznej kampanii opartej o podszywanie się pod markę i minimalny „szum” na hoście. Instalator dostarcza prawdziwy 7-Zip, a równolegle wdraża proxyware (Uphero/hero), tworzy usługę SYSTEM i przygotowuje host do routowania ruchu osób trzecich.

Jeśli w Twoim środowisku ktoś pobrał 7-Zip z niewłaściwej domeny, potraktuj to jako incydent bezpieczeństwa: zidentyfikuj artefakty, sprawdź usługi, reguły firewall i ruch sieciowy oraz podejmij działania naprawcze.

Źródła / bibliografia

  1. BleepingComputer – „Malicious 7-Zip site distributes installer laced with proxy tool” (10 lutego 2026). (BleepingComputer)
  2. Malwarebytes Threat Intel – „Fake 7-Zip downloads are turning home PCs into proxy nodes” (9 lutego 2026). (Malwarebytes)
  3. Help Net Security – omówienie ostrzeżeń Malwarebytes i kontekstu dystrybucji przez tutoriale (10 lutego 2026). (Help Net Security)
  4. MITRE ATT&CK – Masquerading: Match Legitimate Resource Name or Location (T1036.005). (attack.mitre.org)

Cyber Resilience Act (CRA) – Kompleksowy Przewodnik Dla Producentów

Czym jest Cyber Resilience Act i kogo dotyczy

W świecie pełnym inteligentnych urządzeń i aplikacji, bezpieczeństwo nie może być już tylko dodatkiem – staje się obowiązkowym wymogiem prawnym. Takim właśnie wymogiem jest europejskie rozporządzenie Cyber Resilience Act (CRA), które wprowadza jednolite zasady cyberbezpieczeństwa produktów cyfrowych we wszystkich krajach UE.

Czytaj dalej „Cyber Resilience Act (CRA) – Kompleksowy Przewodnik Dla Producentów”

Bloody Wolf (Stan Ghouls) uderza w Uzbekistan i Rosję: spear-phishing z NetSupport RAT i ślady możliwego zainteresowania IoT

Wprowadzenie do problemu / definicja luki

Kampanie spear-phishingowe wykorzystujące „legalne” narzędzia zdalnej administracji (RMM/RAT-like) to dziś jeden z najtrudniejszych do obrony scenariuszy. Z perspektywy SOC ruch i pliki mogą wyglądać „normalnie”, bo atakujący nadużywa komercyjnego oprogramowania (np. NetSupport Manager), a złośliwość przenosi do warstwy dostarczenia (loader, phishing, persistence). Właśnie taki model obserwujemy w świeżej kampanii przypisywanej grupie Bloody Wolf, śledzonej przez Kaspersky jako Stan Ghouls.

W skrócie

  • Celem kampanii są głównie Uzbekistan (~50 ofiar) i Rosja (~10 urządzeń), z pojedynczymi infekcjami m.in. w Kazachstanie oraz „odpryskami” w Turcji, Serbii i na Białorusi.
  • Wejście początkowe: spear-phishing z PDF zawierającym linki prowadzące do pobrania złośliwego loadera (Java), który finalnie instaluje NetSupport RAT.
  • Loader implementuje mechanizmy „quality gate”, m.in. limit prób instalacji oraz fałszywy komunikat błędu dla zmylenia ofiary.
  • Persistence: Startup folder + klucz Run w rejestrze + scheduled task uruchamiany przy logowaniu.
  • Kaspersky odnotował też pliki Mirai na infrastrukturze powiązanej z kampaniami grupy (wniosek ostrożny, z niską pewnością).

Kontekst / historia / powiązania

Stan Ghouls/Bloody Wolf działa co najmniej od 2023 r., a w profilu ofiar dominują sektory: przemysł/produkcja, finanse, IT.
Istotny jest też zwrot narzędziowy: wcześniej grupa była łączona z STRRAT (Strigoi Master), natomiast w nowszych kampaniach coraz częściej bazuje na NetSupport jako „legalnym” kliencie zdalnego dostępu, dogrywanym przez własne loadery.

Group-IB opisywał podobny schemat (spear-phishing + PDF podszywający się pod instytucje i „materiały sprawy”), co wzmacnia atrybucję i pokazuje ciągłość TTP.

Analiza techniczna / szczegóły luki

1) Łańcuch infekcji (end-to-end)

  1. E-mail spear-phishing z załącznikiem PDF.
  2. PDF zawiera osadzone linki (pretekst: dokumenty urzędowe, materiały sprawy, decyzje itp.).
  3. Kliknięcie linku prowadzi do pobrania loadera (w analizach opisywany jako „custom Java-based loader”).
  4. Loader:
    • wyświetla fałszywy błąd (maskowanie),
    • sprawdza limit prób instalacji (np. do 3),
    • pobiera komponenty NetSupport RAT z listy domen i uruchamia.

2) Persistence i uruchamianie po restarcie

Kaspersky opisał trzy równoległe mechanizmy utrzymania się:

  • skrypt BAT w Startup folder (%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup),
  • wpis w HKCU\Software\Microsoft\Windows\CurrentVersion\Run,
  • scheduled task typu ONLOGON wskazujący na run.bat.

To „potrójne” podejście zwiększa odporność na częściowe czyszczenie (np. usunięcie jednego artefaktu).

3) C2/infra i domeny

Loadery zwykle zawierają listy domen i iterują po nich, aż trafią na aktywną. W opublikowanych wskaźnikach pojawiają się m.in. domeny stylizowane na lokalne instytucje (np. podatkowe/urzędowe).

4) NetSupport jako „RAT”

Z punktu widzenia obrońcy kluczowe jest to, że NetSupport Manager jest legalnym narzędziem zdalnego dostępu, ale jego „złośliwe warianty/użycia” dają atakującym nieautoryzowany zdalny dostęp, w tym możliwość eksfiltracji danych, obserwacji użytkownika i ruchu bocznego.

5) Wątek Mirai (IoT)

Kaspersky odnalazł na infrastrukturze powiązanej z kampaniami pliki przypisywane do Mirai. Zastrzeżono jednak, że to może oznaczać zarówno rozszerzenie arsenału, jak i współdzielenie infrastruktury z innymi aktorami.

Praktyczne konsekwencje / ryzyko

  • Ryzyko finansowe: ukierunkowanie na sektor finansowy sugeruje motyw „profit”, choć równoległe użycie RAT-ów może wspierać też scenariusze szpiegowskie.
  • Trudniejsza detekcja: legalne komponenty NetSupport mogą przechodzić przez mniej restrykcyjne polityki (zwłaszcza jeśli organizacja dopuszcza RMM).
  • Skalowalność operacji: ponad 60 trafionych celów to jak na kampanię „targeted” wysoki wolumen, sugerujący zasoby do utrzymania równoległych sesji zdalnych.

Rekomendacje operacyjne / co zrobić teraz

Szybkie działania (24–72h)

  • Blokady na poziomie DNS/Proxy dla domen i hostów wskazanych w IoC (oraz ich wariantów typosquat).
  • Hunt na endpointach pod kątem:
    • nietypowych BAT w Startup folder,
    • wpisów w HKCU\...\Run,
    • zadań schtasks uruchamianych ONLOGON wskazujących na run.bat lub podobne ścieżki w %AppData%.
  • Weryfikacja, czy w środowisku NetSupport jest w ogóle dopuszczony. Jeśli nie: dodaj do listy „deny” (AppLocker/WDAC) i reguł EDR.

Utwardzanie (1–4 tyg.)

  • Hardening poczty: sandbox dla PDF, detekcja URL w załącznikach, blokowanie nietypowych skrótów/treści zachęcających do „materiałów sprawy” i pilnych działań.
  • Ograniczenie uruchamiania JAR/Java na stacjach, gdzie nie jest to biznesowo potrzebne (to typowy punkt zaczepienia w tych kampaniach).
  • Segmentacja i least privilege: nawet „tylko RAT” potrafi szybko przejść do ruchu bocznego, jeśli host ma szerokie uprawnienia.

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

  • Od STRRAT do RMM-abuse: wcześniejsze kampanie Bloody Wolf były kojarzone z klasycznym malware (STRRAT), a nowsze pokazują dojrzały trend „living-off-the-land / living-off-legit tools”, gdzie trzonem jest komercyjny klient zdalny, a unikalność daje własny loader i infrastruktura.
  • Podobieństwo do wielu rodzin kampanii phishingowych: PDF jako nośnik linków + etapowy downloader/loader to wzorzec, który dobrze skaluje się operacyjnie i utrudnia blokowanie (URL rotują, domeny się zmieniają).

Podsumowanie / kluczowe wnioski

Kampania Bloody Wolf/Stan Ghouls przeciw Uzbekistanowi i Rosji to przykład skutecznego połączenia precyzyjnego spear-phishingu z nadużyciem legalnego narzędzia zdalnego dostępu (NetSupport). Największą przewagą atakujących jest mieszanie „normalności” (komercyjne RMM) z własnym łańcuchem dostarczenia i persistence. Dla obrony oznacza to konieczność łączenia telemetrii e-mail + endpoint + DNS oraz jasnych polityk, które RMM są dozwolone, a które powinny być blokowane.

Źródła / bibliografia

  1. The Hacker News — Bloody Wolf Targets Uzbekistan, Russia Using NetSupport RAT in Spear-Phishing Campaign (Feb 9, 2026). (The Hacker News)
  2. Kaspersky Securelist — Stan Ghouls attacks in Russia and Uzbekistan: NetSupport RAT and potential IoT interest (Feb 2026). (Securelist)
  3. BI.ZONE — Bloody Wolf evolution: new targets, new tools (Feb 19, 2025). (BI.ZONE)
  4. Group-IB — Bloody Wolf: A Blunt Crowbar Threat To Justice (Nov 2025). (Group-IB)
  5. Microsoft Security Intelligence — Trojan:Win32/NetSupportRat!MTB threat description (Updated Sep 18, 2025). (Microsoft)